LLM 캐시는 어떻게 작동할까: 앤트로픽 S-1 보고서로 읽는 AI 인프라 효율화

Anthropic은 S-1에서 같은 수준의 모델 성능을 제공하는 데 필요한 추론 연산을 줄이고, 운영 환경에서 연산 자원의 활용 효율도 높여 왔다고 설명한다. – 「Compute Efficiency」 요약¹

TL;DR

• LLM 인프라는 같은 성능의 작업에 필요한 연산을 줄이고, 확보한 자원을 더 잘 활용하는 방향으로 발전하고 있다. Anthropic S-1의 추론 효율 설명은 이 흐름을 보여주는 근거 중 하나다.
• 프롬프트 캐시는 동일한 입력 앞부분을 처리하며 만든 KV 캐시를 재사용한다. 긴 문서를 다시 계산하는 일을 줄이되, 새 질문의 처리와 답변 생성은 계속 수행한다.
• 대규모 인프라에서는 공통 계산을 메모리 블록으로 공유하고, 캐시 위치와 부하를 고려해 요청을 분산한다. 일부 시스템은 GPU 밖의 메모리와 저장소에도 캐시를 보관한다.
• 캐시 효율을 높이려면 누구의 계산을 누구와 공유할지 먼저 정해야 한다. 사용자별 격리는 재사용 범위를 줄일 수 있으며, GPU 밖으로 옮긴 캐시에도 같은 권한 경계를 유지해야 한다.
• 캐시의 효과는 재사용 빈도, 메모리 여유, 전송 비용에 따라 달라진다. 재처리하는 입력 토큰이 줄어든 비율을 전체 비용 절감률로 해석해서는 안 된다.

같은 제품 설명서를 들고 상담원을 찾아간다고 생각해 보자. 첫날에는 설명서를 처음부터 읽어야 한다. 다음 날 다른 질문을 했는데, 상담원이 그 설명서를 또 처음부터 읽는다면 어떨까. 질문에 답하는 시간보다 같은 자료를 반복해서 읽는 시간이 더 길어질 수 있다.

LLM 서비스에도 비슷한 일이 생긴다. 질문을 보낼 때 제품 문서, 도구 사용법, 대화 이력을 함께 전달하기 때문이다. 화면에는 새 질문 한 줄만 보이지만, 서버로 가는 입력에는 이미 보낸 내용이 길게 붙는다.

LLM 인프라의 효율화는 이 반복 작업을 찾아 줄이는 과정이기도 하다. 더 많은 GPU를 설치하는 것과 함께, 이미 수행한 계산을 다시 쓰는 기술이 발전하고 있다. 그 중심에 캐시가 있다.

2026년 10월 26일 공개된 Anthropic의 상장 등록신고서(S-1)는 이런 변화를 확인할 수 있는 근거 중 하나다. 이 글에서는 S-1의 설명에서 출발해, 대규모 인프라에서 캐시가 어떻게 작동하는지 일곱 장의 그림으로 풀어본다.

이때 운영자가 마주하는 중요한 질문이 있다. 캐시 효율을 높이면서도 여러 사용자의 컨텍스트를 서로 격리할 수 있을까? 저장 공간을 늘리는 설계와 함께, 누구에게 재사용을 허용할지도 살펴봐야 한다.

이후 그림은 vLLM·SGLang·LMCache의 공개 기술로 일반 원리를 설명한다. Anthropic의 실제 내부 구성을 나타내는 그림은 아니다.

1. S-1이 보여주는 변화: 같은 자원으로 더 많은 일을 한다

S-1은 추론에 필요한 연산을 줄이는 연구와, 확보한 연산 자원을 더 효율적으로 쓰는 운영 최적화를 함께 설명한다. 별도의 플랫폼 기능 설명에서는 긴 프롬프트에 캐싱을 적용하면 같은 요청을 캐싱 없이 처리할 때보다 비용을 최대 약 97%, 지연시간을 약 60% 줄일 수 있다고 제시한다.¹

여기서 읽어야 할 흐름은 모델을 서비스하는 방식도 계속 개선되고 있다는 점이다. 다만 이 수치는 긴 프롬프트에 대한 조건부 효과다. Anthropic 전체 인프라 운영비가 그만큼 줄었다거나, 그 개선이 모두 캐시 덕분이라는 뜻은 아니다.

그렇다면 캐시는 이 흐름에 어떻게 기여할까. 이를 이해하려면 LLM이 답을 만드는 과정을 둘로 나눠 보면 된다.

2. 답변하기 전에, 먼저 입력을 읽어야 한다

일반적인 생성형 LLM의 추론에는 크게 두 단계가 있다.

• 프리필(prefill): 입력된 문장을 처리하고, 답변을 만들 때 참조할 내부 상태를 계산한다.
• 디코딩(decoding): 그 상태를 참조하면서 답변을 토큰 단위로 생성한다. 토큰은 모델이 텍스트를 다루는 작은 단위다.

첫 단계는 자료를 읽고 작업 준비를 하는 과정, 두 번째는 그 자료를 보며 답을 써 내려가는 과정으로 생각하면 쉽다.

모델은 이 과정에서 어텐션에 사용하는 키(key)와 값(value)이라는 숫자 배열을 만든다. 이를 보관한 것이 KV 캐시다. 같은 요청 안에서는 다음 답변 토큰을 만들 때 이전 토큰의 키·값을 다시 계산하지 않도록 돕는다.²

이 재사용을 요청 사이로 확장할 수도 있다. 같은 모델과 호환되는 실행 조건에서 새로운 요청이 이전 요청과 같은 입력으로 시작한다면, 이미 계산한 앞부분의 KV 캐시를 가져와 이어서 처리하는 것이다. 이를 프롬프트 캐싱 또는 프리픽스 캐싱이라고 부른다.³

그림 1. 캐시는 긴 공통 문서를 다시 계산하는 일을 줄인다. 새 질문을 처리하고 답을 생성하는 과정은 남는다.

앞의 상담원 비유로 돌아가면, KV 캐시는 읽은 내용을 다음 계산에서 바로 참조할 수 있도록 준비해 둔 작업 자료에 가깝다. 다만 사람이 쓰는 요약문은 아니다. 모델 계산에 쓰이는 숫자 배열이며, 모델 자체를 다시 학습시키는 것도 아니다.

따라서 “지난번과 비슷한 답을 꺼내준다”와는 동작이 다르다. 같은 문서를 재사용해도 이번 질문에 대한 답은 새로 생성한다.

3. 같은 문서라도, 앞에 무엇이 있느냐가 중요하다

고객 두 명이 같은 제품 설명서를 두고 질문한다고 하자. 한 명은 기능을 묻고, 다른 한 명은 외부 시스템 연동 방법을 묻는다. 질문은 달라도 설명서까지의 입력이 같다면 공통 계산을 재사용할 기회가 생긴다.

그림 2. 프리픽스는 입력의 앞부분이다. 공통 경로를 따라간 뒤, 질문이 달라지는 지점부터 각자 계산한다.

왜 문서의 내용만 같으면 안 될까. 일반적인 자기회귀 트랜스포머에서 한 토큰의 내부 상태는 앞서 나온 토큰들의 영향을 받는다. 문서 앞에 다른 지침이 붙으면, 같은 문서도 다른 맥락에서 처리된다. 이 때문에 앞부분이 어디까지 일치하는지가 중요하다.³

예를 들어 요청 맨 앞에 매번 다른 시각이나 세션 ID를 넣으면, 그 뒤에 같은 설명서가 있어도 이전 계산을 그대로 연결하기 어려워진다. 반대로 공통 지침과 문서를 먼저 두고 새 질문을 뒤에 붙이면 공통 경로가 길어진다.

에이전트도 같은 원리다. 도구 정의, 작업 지침, 이전 대화가 유지되고 새 실행 결과만 뒤에 추가되면 재사용할 부분이 늘어난다. 대화 이력을 요약본으로 교체하거나 공통 지침을 수정하면, 바뀐 지점 이후에는 새 계산이 필요할 수 있다.

이것이 “문장을 짧게 만들기”와 다른 최적화인 이유다. 긴 입력이라도 대부분이 안정적으로 반복된다면 재사용할 계산이 많다.

4. 수많은 요청을 위해, 캐시를 블록으로 나눈다

사용자가 늘어나면 설명서 한 벌을 재사용하는 것만으로는 충분하지 않다. 수많은 대화가 동시에 진행되고, 각 대화의 길이도 다르다. KV 캐시를 놓을 메모리를 어떻게 관리할지가 중요해진다.

한 가지 방법은 캐시를 작은 블록으로 나누는 것이다. 책 전체를 사람마다 복사하는 대신, 공통으로 보는 페이지 묶음을 함께 참조하는 방식으로 생각할 수 있다. PagedAttention은 KV 캐시를 블록으로 관리해 메모리 낭비를 줄이는 접근을 제시했다.²

그림 3. 공통 계산은 한 벌을 함께 참조하고, 각 요청의 다른 부분은 별도로 관리한다. vLLM의 블록 관리 원리를 단순화한 그림이다.

공통 블록을 찾으려면 식별표도 필요하다. vLLM은 블록의 토큰뿐 아니라 그 앞 블록의 해시 등을 식별에 사용한다. 해시는 내용을 찾기 위한 식별값이라고 이해하면 된다. 앞부분까지 식별에 연결하므로, 같은 단어가 나온다는 이유만으로 다른 문맥의 계산을 섞지 않는다.⁴

메모리가 유한하므로 모든 캐시를 영원히 보관할 수는 없다. 아직 요청이 쓰고 있는 블록과, 사용이 끝나 재사용을 기다리는 블록을 구분해야 한다. 공간이 부족하면 후자 중에서 교체할 대상을 고른다.⁴

잘 쓰이는 공통 자료를 남기면 다음 요청의 재계산을 줄인다. 드물게 다시 쓰이는 자료를 너무 오래 붙잡으면 새 요청이 쓸 공간이 줄어든다. 캐시 관리는 결국 미래의 재사용 기회와 현재의 메모리 수요를 조절하는 일이다.

5. 서버가 많아지면 “어디로 보낼까”도 중요해진다

이제 추론 서버가 여러 대 있다고 하자. 서버 A에는 제품 설명서의 캐시가 있고 서버 B에는 없다. 같은 질문을 어느 서버로 보내느냐에 따라 다시 해야 할 계산량이 달라진다.

단순히 요청 수를 똑같이 나누는 방식에서는 이미 있는 캐시를 놓칠 수 있다. 그래서 캐시를 고려한 라우팅이 등장한다. 라우팅은 들어온 요청을 처리할 서버로 보내는 일이다.

그림 4. 캐시는 클러스터 어딘가에 존재하는 것만으로 충분하지 않다. 요청이 그 계산 결과를 이용할 수 있어야 한다.

책을 이미 읽은 상담원에게 다음 질문을 보내는 것과 비슷하다. 다만 그 상담원 앞에 대기자가 너무 많다면, 다른 상담원이 새로 읽는 편이 빨리 끝날 수 있다.

따라서 라우터는 “누가 이 앞부분을 재사용할 수 있는가”와 “얼마나 기다려야 하는가”를 함께 판단해야 한다. 공개 서빙 프로젝트인 SGLang의 모델 게이트웨이도 캐시와 부하를 고려하는 정책을 제공한다.⁵

그림의 서버 한 대는 실제로 여러 GPU가 함께 일하는 추론 단위일 수도 있다. 핵심은 물리적인 장비 수보다 캐시가 놓인 위치다. 캐시 전송이나 공유 계층을 갖춘 시스템은 결과를 가져올 수도 있지만, 그런 구성이 없다면 해당 서버에서 다시 계산해야 한다.

이 단계부터 캐시는 서버 하나의 메모리 기능을 넘어 클러스터 전체의 요청 배치 문제가 된다.

6. 비싼 작업대에는 지금 필요한 자료를 둔다

GPU 메모리는 빠르지만 용량이 제한된 작업대다. 읽었던 자료를 모두 작업대 위에 쌓아 두면 다음 작업을 시작할 자리가 사라진다.

그래서 일부 시스템은 KV 캐시를 GPU 밖으로 옮겨 보관한다. 자주 바로 쓸 자료는 GPU에, 그보다 덜 급한 자료는 CPU 메모리나 저장소에 두는 식이다. LMCache는 CPU 메모리, 로컬 저장소, 원격 저장소를 활용하는 KV 캐시 계층을 제공한다.⁶

그림 5. 빠른 작업대와 더 큰 보관함을 나눠 쓴다. 모든 시스템이 이 계층을 갖추는 것은 아니며, 실제 구성은 다르다.

여기에도 대가가 있다. 보관함에서 자료를 가져오는 데 시간이 든다. 원격 저장소라면 네트워크도 사용한다. 저장된 KV 캐시를 읽어 왔더라도, 새 답변을 만드는 동안에는 그 상태를 계속 참조해야 한다.

따라서 “캐시가 있다”가 곧 “언제나 빠르다”는 뜻은 아니다. 가져오는 비용이 다시 계산하는 비용보다 낮을 때 이득이다. 짧은 입력은 새로 계산하는 편이 나을 수 있고, 긴 공통 문서는 가져오는 편이 유리할 수 있다.

대규모 인프라의 효율은 이런 선택이 쌓인 결과다. 무엇을 남길지, 어디에 둘지, 어느 요청에 연결할지를 함께 설계한다.

7. 작은 재사용이 규모를 만나면 차이가 커진다

규모의 효과를 숫자로 생각해 보자. 아래는 실제 서비스 측정값이 아닌 가상 예시다.

100개의 요청이 각각 10,000토큰짜리 같은 문서와 500토큰짜리 서로 다른 질문을 보낸다. 캐시가 없으면 매번 문서까지 포함한 입력을 처리한다. 캐시를 완전히 재사용할 수 있다면 문서는 처음 한 번 계산하고, 이후에는 새 질문을 처리한다.

그림 6. 동일 모델·동일 문서이며, 첫 계산 이후 만료·퇴거·라우팅 미스 없이 재사용한다고 가정한 토큰 수 비교다. 막대는 시간이나 비용을 나타내지 않는다.

캐시 없이 새로 처리할 입력은 10,500 × 100 = 1,050,000토큰이다. 공통 문서를 재사용하면 10,000 + 500 × 100 = 60,000토큰으로 줄어든다. 새로 프리필하는 입력 토큰은 약 94.3% 감소한다.

전체 비용이나 연산 시간이 94.3% 줄었다는 뜻은 아니다. 캐시를 읽는 작업, 보관할 메모리, 필요한 전송, 그리고 모든 답변의 생성이 남는다. 입력 길이에 따른 연산량도 토큰 수와 단순 비례한다고 볼 수 없다.

그럼에도 이 예시는 효율화의 방향을 보여준다. 같은 계산에 자원을 반복해서 쓰는 대신, 새 질문과 새 작업에 더 많이 쓸 기회가 생긴다. 실제 효과는 공통 입력의 길이, 재사용 빈도, 메모리 여유, 라우팅에 따라 달라진다.

8. 효율을 높이면서 사용자 컨텍스트를 격리할 수 있을까

가능하다. 다만 격리 범위를 좁힐수록 재사용할 수 있는 요청도 줄어든다. 목표는 모든 요청을 한 캐시에 모으는 것이 아니라, 허용된 경계 안에서 반복 계산을 최대한 재사용하는 것이다.

앞에서 본 GPU·CPU·저장소는 어디에 보관할지를 나누는 계층이다. 공개·조직·사용자·세션은 누가 재사용할 수 있는지를 나누는 경계다. 두 구분은 별개다. 같은 원격 저장소를 쓰더라도 사용자별 접근은 나눌 수 있어야 하고, GPU에 있다고 해서 격리가 자동으로 보장되는 것도 아니다.

같은 내용을 찾는 것과 사용 권한은 다르다

도서관의 공개 책은 함께 볼 수 있지만, 개인 상담 기록은 해당 사용자에게만 열려야 한다. 캐시에서도 내용이 일치한다는 식별값과 그 내용을 사용할 자격은 서로 다른 문제다. 해시는 암호화나 접근 권한의 증명이 아니다.

이 표는 정책을 정하는 기준이다. 모든 엔진이 한 요청 안에서 이 경계들을 자동으로 나눠 주는 것은 아니다. 예를 들어 vLLM의 cache_salt는 첫 블록의 해시에 들어가며, 그 경계가 뒤 블록 식별에도 이어진다. 사용자별로 다른 salt를 쓰면 같은 공개 문서까지 별도로 계산·보관하게 될 수 있다.⁴

따라서 “공개 프리픽스는 모두 공유하고, 개인 부분부터만 격리하자”는 목표를 구현하려면 엔진의 구간별 공유 지원과 보안 특성을 따로 확인해야 한다. 단순히 사용자 데이터를 뒤에 배치하거나, 요청 중간에 캐시 옵션을 추가하는 것만으로는 충분하지 않다. 지원하지 않는 환경에서는 사용자별 또는 권한 그룹별로 전체 캐시를 나누고 그 안에서 재사용하는 설계가 현실적인 선택이다.

공통 입력은 공유하고 개인 컨텍스트는 분리한다

그림 7. 여러 사용자의 요청이 공통 프리픽스 캐시로 모이는 지점에서 사용자 간 히트가 발생한다. 개인 컨텍스트는 그 뒤에서 분리한다. 구간별 공유와 접근 통제를 지원하는 엔진의 설계 개념이며, 요청 전체에 salt를 적용하는 vLLM의 기본 격리 방식과는 다르다.

공개 프리픽스에는 개인 정보가 영향을 준 상태가 들어가면 안 된다. 공개 자료가 먼저 오고 개인 컨텍스트가 뒤에 와야 하며, 입력 배치와 별도로 엔진이 공유 경계를 강제해야 한다. 개인 부분을 분리했다고 해서 모든 종류의 부채널까지 차단되는 것은 아니다.

사용자 A와 B가 서로 다른 캐시 영역을 사용하더라도, A의 두 번째 요청은 A의 첫 번째 요청에서 만든 문서 블록을 재사용할 수 있다. B도 자신의 영역 안에서는 같은 방식으로 재사용한다. 사용자 사이의 공유를 막는 것과 같은 사용자의 반복 요청까지 모두 다시 계산하는 것은 다르다. 여러 세션에서도 같은 권한 경계와 호환되는 입력을 유지한다면 재사용할 기회가 있다. 반대로 요청마다 다른 격리값을 붙이면 이런 기회까지 사라진다.

이 구조를 지원하지 않아 사용자별로 전체 캐시를 나누더라도, 사용자 내부의 재사용은 남는다. 이를 비교하기 위해 사용자 10명이 각각 동일한 10,000토큰 문서와 매번 다른 500토큰 질문으로 10회 요청한다고 가정하자. 모든 영역이 비어 있는 상태에서 시작하고, 이후 만료·퇴거·라우팅 미스·블록 경계 손실은 없다고 가정한다.

이때 전체 입력은 앞의 예시와 같은 1,050,000토큰이다. 사용자별로 첫 요청은 문서를 계산하지만 나머지 9회는 읽어 쓸 수 있으므로, 캐시에서 읽는 문서는 10명 × 9회 × 10,000 = 900,000토큰이다. **토큰 기준 히트율은 900,000 / 1,050,000, 약 85.7%**다. 사용자 간 캐시를 공유하지 않아도 같은 사용자 안의 반복으로 높은 히트율을 얻을 수 있는 조건이다.

모든 입력의 공유가 허용된 단일 신뢰 그룹이라는 별도 가정에서는, 문서를 한 번 계산한 뒤 99회 재사용해 약 94.3%가 된다. 이 비교는 사용자 격리로 줄어드는 재사용 기회를 보여주기 위한 것이다. 서로 신뢰하지 않는 사용자를 같은 그룹에 넣어도 안전하다는 뜻은 아니다. 각 사용자가 한 번만 요청하고 떠난다면 사용자별 캐시는 이런 이득을 얻기 어렵다. 격리 단위와 그 안의 반복 빈도를 함께 봐야 한다.

여기서 사용한 히트율은 캐시에서 읽은 입력 토큰을 전체 입력 토큰으로 나눈 값이다. 조금이라도 캐시를 읽은 요청의 비율과는 다르며, 전체 비용 절감률을 뜻하지도 않는다.

캐시가 있다는 사실도 정보가 될 수 있다

격리는 다른 사용자의 문서를 직접 읽지 못하게 하는 데서 끝나지 않는다. 캐시 적중 시 응답이 빨라지는 차이를 반복 관찰하면, 특정 입력이 이전에 사용됐는지 추정하는 단서가 생길 수 있다. 이를 타이밍 부채널이라고 한다. PrefixWall 연구도 공유 프리픽스 캐시에서 이런 정보 추론 위험을 다룬다.⁷

캐시가 일치한다고 다른 사용자의 대화가 현재 요청에 자동으로 덧붙는 것은 아니다. 하지만 내용이 요청에 섞이는 문제와 사용 흔적이 드러나는 문제는 각각 방어해야 한다. 캐시 키를 맞추는 정확성 검증만으로 보안 검증을 대신할 수 없는 이유다.

관리형 API의 격리 범위도 확인해야 한다. Claude API는 워크스페이스 단위로 캐시를 격리하지만, 한 워크스페이스를 사용하는 우리 서비스의 개별 사용자를 각각 분리해 준다는 의미는 아니다. 애플리케이션이 여러 고객을 한 워크스페이스에서 처리한다면 고객별 문서 권한과 필요한 격리 구성을 별도로 설계해야 한다.⁸

보관함으로 옮겨도 열쇠는 그대로 따라가야 한다

다층 캐시에서 중요한 운영 조건은 다음과 같다. 아래는 특정 제품의 보장 목록이 아니라 설계할 때 확인해야 할 항목이다.

• 경계 결정: 인증된 사용자와 문서 권한을 기준으로 서버가 재사용 범위를 정한다. 클라이언트가 보낸 사용자 ID나 salt만 믿고 다른 사용자의 영역을 선택하게 두지 않는다.
• 경계 유지: GPU 블록 조회뿐 아니라 CPU 캐시, 원격 저장소, 서버 간 전송, 캐시 위치 목록에도 같은 구분을 유지한다. 저장 위치를 옮기면서 권한 범위가 넓어져서는 안 된다.
• 접근 통제와 암호화 구분: 전송·저장 암호화는 필요에 따라 적용하되, 복호화할 수 있는 서비스가 누구의 자료를 꺼내 줄 수 있는지도 따로 제한한다.
• 권한 변경과 삭제: 권한이 회수되면 캐시가 남아 있어도 다음 사용을 막아야 한다. 보관 기한과 삭제 정책은 GPU 밖 복사본과 저장소에도 적용해야 한다.

LMCache의 저장 암호화 문서도 이 차이를 보여준다. 사용자·테넌트별 salt에 따라 암호화 키를 나누더라도, 공통 마스터 키를 가진 서버는 모든 테넌트의 데이터를 복호화할 수 있다. 이 구성만으로 테넌트 간 접근 격리가 성립하지 않는다고 명시한다.⁹

결국 확인할 질문은 “캐시가 얼마나 잘 맞는가”에 더해 **“누가 어떤 캐시를 찾고, 가져오고, 다시 사용할 수 있는가”**다. 효율 지표와 함께 권한이 다른 사용자 사이의 조회·재사용이 거부되는지도 검증해야 한다.

결론

LLM 인프라는 모델을 실행하는 장비와 함께, 그 장비가 수행할 일을 배분하는 방식도 발전하고 있다. 같은 입력의 계산을 공유하고, 캐시가 있는 서버로 요청을 보내고, 제한된 GPU 메모리와 외부 보관 공간을 나눠 쓰는 것이 그 예다.

Anthropic S-1의 추론 효율 설명은 이 변화가 실제 사업 운영에서도 중요해졌다는 근거 중 하나다. 이 글의 다이어그램은 공개된 vLLM·SGLang·LMCache 기술로 일반 원리를 설명한 것이며, Anthropic의 내부 배치 구조를 재현한 것은 아니다.

캐시의 원리는 간단하다. 이미 한 계산을 보관하고, 다음 요청이 그 지점에서 이어가게 한다. 대규모 인프라의 어려움은 그 계산을 수많은 요청 사이에서 제때 찾고, 필요한 곳에 두고, 공간이 부족할 때 적절히 비우는 데 있다. 그 모든 과정에서 사용자별 권한 경계를 유지해야 한다. 효율화의 목표는 허용된 공유를 늘리면서 비공개 컨텍스트의 경계를 지키는 것이다.

단위 작업의 효율이 좋아져도 사용량이 더 빠르게 늘면 전체 인프라 지출은 커질 수 있다. 효율화의 의미는 같은 성능의 작업 하나에 필요한 자원을 줄이거나, 같은 자원으로 더 많은 작업을 처리할 수 있다는 데 있다. 캐시는 그 변화를 이해하기에 좋은 창이다.