프롬프트 캐싱

Prompt caching; 프롬프트 캐싱

여러 요청이 공유하는 프롬프트 앞부분(접두사)의 KV 캐시를 저장해 두고 다시 써서, 그 부분의 프리필 계산을 건너뛰는 기법

프롬프트 캐싱(prompt caching)은 대형 언어 모델 요청끼리 앞부분이 같을 때, 이전 요청에서 계산해 둔 KV 캐시를 재사용해 프롬프트 처리 시간과 비용을 줄이는 기법이다. 긴 시스템 프롬프트, 도구 정의, 문서, 대화 기록처럼 매 요청 반복되는 앞부분이 클수록 효과가 크다. 서빙 엔진에서는 접두사 캐싱(prefix caching)이라고도 부른다. 앤트로픽, OpenAI, 구글(컨텍스트 캐싱), 아마존 베드록, 마이크로소프트 등이 API 기능으로 제공하며 캐시에서 읽은 입력 토큰을 할인한다.

출력 토큰 생성에는 영향이 없다. 같은 입력이면 캐시를 쓰든 안 쓰든 응답 분포는 같다.

원리

왜 접두사만 재사용할 수 있나

디코더 전용 트랜스포머는 인과 마스크를 쓰므로 $i$번째 토큰의 층별 키·값 $k_i^{(\ell )},v_i^{(\ell )}$는 그 토큰과 앞 토큰들 $x_1,\dots ,x_i$에만 의존한다. 두 프롬프트가 처음 $P$개 토큰까지 똑같다면 그 구간의 KV 캐시도 비트 단위로 같으니, 한 번 계산해 저장해 두면 다음 요청은 $P+1$번째 토큰부터 프리필하면 된다.

반대로 한 토큰이라도 앞에서 달라지면 그 뒤의 모든 키·값이 달라진다. 위치 인코딩(예: RoPE)도 절대 위치를 반영하므로 같은 문서라도 앞에 붙은 내용이 다르면 재사용할 수 없다. 프롬프트 캐싱이 "정확히 같은 접두사"를 요구하는 이유다.

얼마나 아끼나

매개변수 $N$개 모델의 프리필은 토큰당 약 $2N$ FLOPs에 어텐션 비용이 더해진다. 접두사 $P$개를 캐시에서 읽으면 이 계산이 빠지고, 대신 저장해 둔 KV 캐시를 메모리에서 읽는다. 그래서 첫 토큰까지의 시간(TTFT)이 크게 줄고, 출력 토큰당 시간은 거의 그대로다. 앤트로픽은 2024년 발표 당시 10만 토큰짜리 책을 캐시한 대화에서 TTFT가 11.5초에서 2.4초로 줄고 비용이 90% 줄었다는 예를 들었다.

대가는 메모리다. 토큰당 KV 캐시 크기는 다음과 같다.

$\text{bytes/token}=2\times n_{\text{layers}}\times n_{\mathrm{k}\mathrm{v}\mathrm{\_}\mathrm{h}\mathrm{e}\mathrm{a}\mathrm{d}\mathrm{s}}\times d_{\text{head}}\times \text{bytes per element}$

예를 들어 층 32개, KV 헤드 8개(그룹 쿼리 어텐션), 헤드 차원 128인 80억 매개변수급 모델을 BF16으로 저장하면 토큰당 $2\times 32\times 8\times 128\times 2=\mathrm{131,072}$바이트, 즉 128KiB다. 10만 토큰이면 약 12.5GiB라, 캐시를 오래 붙잡아 두면 다른 요청의 배치 자리를 빼앗는다. 상용 API가 캐시 수명을 몇 분 단위로 짧게 두고, 오래 보관하면 따로 요금을 받는 이유다.

구현 방식

방식	재사용 단위	찾는 법	예
블록 해시 체인	고정 크기 KV 블록	블록마다 "앞 블록 해시 + 블록 안 토큰 + 추가 식별자"로 해시를 만들어 해시 표에서 찾는다. 꽉 찬 블록만 캐시, LRU로 내보냄	vLLM 자동 접두사 캐싱
기수 트리	토큰 열	모든 요청의 접두사를 기수 트리(radix tree)로 저장해 가장 긴 공통 접두사를 찾는다. LRU로 내보냄	SGLang RadixAttention
모듈 단위 재사용	프롬프트 안의 정해진 조각(문서, 예시)	조각마다 위치를 미리 정한 스키마로 KV를 따로 계산·저장해, 접두사가 아니어도 끼워 맞춘다	Prompt Cache(MLSys 2024). GPU에서 TTFT 약 8배, CPU에서 약 60배 단축
명시적 캐시 객체	사용자가 만든 캐시	캐시를 API로 생성하고 이름으로 참조. TTL 동안 보관	구글 Gemini 명시적 컨텍스트 캐싱

vLLM은 V1 엔진부터 접두사 캐싱을 기본으로 켰다. 적중률이 0%여도 처리량 손실이 1% 미만이 되도록 자료 구조를 고쳤기 때문이다. 멀티 테넌트 환경에서는 캐시 솔트(cache salt)를 첫 블록 해시에 섞어 같은 솔트를 가진 요청끼리만 공유하게 할 수 있다.

공급자별 방식

아래는 2026년 10월 16일 공식 문서 기준이다. 가격, 최소 길이, 지원 모델은 자주 바뀌므로 쓰기 전에 공식 문서를 다시 확인해야 한다.

항목	앤트로픽	OpenAI	구글 Gemini
도입	2024년 클로드 3.5 소네트 등에 공개 베타, 2024년 12월 17일 정식	2024년 10월 1일, 자동 적용	2024년 5월 명시적 캐싱, 2025년 5월 8일 암묵적 캐싱
켜는 법	요청 최상위에 cache_control 하나(자동), 또는 콘텐츠 블록마다 cache_control(명시적 중단점, 최대 4개)	기본으로 켜짐. GPT-5.6 이후 모델은 prompt_cache_options.mode(implicit/explicit)와 prompt_cache_breakpoint로 위치 지정 가능, 이전 모델은 암묵적 캐싱만	2.5 이후 모델은 암묵적 캐싱이 기본. 명시적 캐싱은 caches.create로 캐시를 만들고 cached_content로 참조(일부 모델만)
캐시 순서	tools, system, messages 순서로 접두사를 이룬다	숨은 시스템 지시, 도구, 개발자 메시지, 대화 기록 순	캐시 내용이 프롬프트 앞부분이 된다
최소 길이	모델별 512~4,096토큰	GPT-5.6 이후 1,024토큰. 캐시 적중 토큰 수는 128 단위로 내림	모델별 2,048~4,096토큰(암묵적)
수명	기본 5분(쓰일 때마다 갱신), 선택 1시간	GPT-5.6 이후 최소 30분. 이전 모델은 in_memory(보통 비활성 5~10분, 최대 1시간)나 24h	명시적 캐싱 TTL 기본 1시간, 상하한 없음
가격	쓰기는 기본 입력가의 1.25배(5분) 또는 2배(1시간), 읽기는 0.1배(일부 최신 모델은 0.05배, 0.025배)	GPT-5.6 이후 쓰기 1.25배, 읽기 대개 0.1배. 도입 당시에는 쓰기 할증 없이 읽기 50% 할인	캐시 토큰 할인(도입 당시 75%)에 명시적 캐싱은 보관 시간당 저장 요금 추가
격리	조직 간 공유 없음. 클로드 API 등에서는 워크스페이스 단위 격리	조직 간 공유 없음, 처리 지역 경계를 넘어 재사용 안 함	문서에 명시 없음
확인 필드	cache_creation_input_tokens, cache_read_input_tokens	cached_tokens, cache_write_tokens	usage_metadata의 캐시 토큰 수

출처: 앤트로픽, OpenAI, 구글.

세부 동작 차이도 크다.

• 앤트로픽: 쓰기는 중단점 위치에서만 일어난다. 읽을 때는 중단점에서 시작해 뒤로 최대 20블록까지 거슬러 올라가며 예전 요청이 써 둔 항목을 찾는다. 그래서 매 요청 바뀌는 블록(시각, 요청별 문맥)에 중단점을 두면 적중이 영영 안 난다. 동시에 보낸 요청은 첫 응답이 시작된 뒤에야 캐시를 쓸 수 있다.
• OpenAI: 캐시는 개별 머신에 저장되므로 요청이 그 머신으로 가야 적중한다. 앞부분 토큰의 해시와 prompt_cache_key로 라우팅하며, GPT-5.6 이전 모델에서는 키 하나당 분당 15건 안팎을 넘으면 다른 머신으로 넘쳐 적중률이 떨어진다.
• 구글: 암묵적 캐싱은 할인 보장이 없고, 명시적 캐싱은 저장 요금을 내는 대신 할인이 보장된다. 최신 일부 모델은 명시적 캐싱을 지원하지 않는다.

코드 예

앤트로픽 파이썬 SDK에서 긴 시스템 프롬프트에 명시적 중단점을 두는 예다.

import anthropic

client = anthropic.Anthropic()
manual = open("manual.md", encoding="utf-8").read()   # 매 요청 같은 긴 문서

resp = client.messages.create(
    model="모델 ID",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "너는 사내 규정 안내 도우미다."},
        {"type": "text", "text": manual,
         "cache_control": {"type": "ephemeral"}},     # 여기까지가 캐시 접두사
    ],
    messages=[{"role": "user", "content": "연차는 며칠까지 이월되나?"}],
)
u = resp.usage
print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)
# 첫 요청: 쓰기 토큰 > 0, 5분 안의 다음 요청: 읽기 토큰 > 0

자체 서빙에서는 vLLM이 접두사 캐싱을 기본으로 켜므로, 같은 시스템 프롬프트로 시작하는 요청을 보내기만 해도 재사용된다(--enable-prefix-caching, --disable-prefix-caching로 조정).

프롬프트 설계 요령

• 바뀌지 않는 것을 앞에, 바뀌는 것을 뒤에: 도구 정의, 시스템 지시, 참고 문서, 퓨샷 예시, 대화 기록, 새 질문 순서로 둔다.
• 앞부분에 현재 시각, 요청 ID, 사용자 이름처럼 매번 달라지는 값을 넣지 않는다. 한 토큰만 달라도 그 뒤 전부가 캐시 실패다.
• 도구 목록과 순서를 고정한다. 쓰지 않을 도구를 빼기보다 호출을 막는 옵션(tool_choice 등)을 쓰는 편이 캐시에 유리하다.
• 모델, 응답 형식(구조화된 출력 스키마), 추론 노력 같은 설정을 바꿔도 내부 지시문이 달라져 캐시가 깨질 수 있다.
• 손익 계산: 쓰기 1.25배, 읽기 0.1배라면 같은 접두사를 $n$번 쓸 때 비용은 $1.25+0.1(n-1)$배이고 캐시가 없으면 $n$배다. 두 번만 써도 1.35배 대 2배로 이득이고, 10번이면 2.15배 대 10배다. 수명 안에 다시 쓰이지 않으면 쓰기 할증만 남는다.

보안

캐시 적중은 응답이 빨라지므로 시간 차이가 정보를 흘릴 수 있다. 2025년 스탠퍼드 연구진은 통계적 감사로 실제 API 공급자 7곳(OpenAI 포함)에서 사용자 간 전역 캐시 공유를 탐지했고, 이것이 다른 사용자의 프롬프트를 추정하는 데 쓰일 수 있다고 지적했다. 같은 방법으로 OpenAI 임베딩 모델이 디코더 전용 트랜스포머라는 비공개 정보도 추정했다. 현재(2026-10) 앤트로픽과 OpenAI 문서는 조직 단위(앤트로픽은 워크스페이스 단위) 격리를 명시하고 있다. 자체 서빙에서 여러 고객을 받는다면 vLLM의 캐시 솔트처럼 테넌트별로 캐시를 나눠야 한다.

같이 보기

• KV 캐시
• vLLM
• 연속 배칭
• 컨텍스트 윈도우
• RAG (인공지능)
• 프롬프트 엔지니어링
• 대형 언어 모델 효율화

참고 문헌

• 프롬프트 캐싱 (Claude API 문서, 한국어)
• Azure OpenAI 프롬프트 캐싱 (한국어)
• Amazon Bedrock 프롬프트 캐싱 (한국어)