Prompt Caching: How It Works, What It Costs, and How to Keep the Cache Hitting

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

프롬프트 캐싱은 동일한 접두부의 처리 상태를 요청 간 재사용해 비용과 응답 시작 시간을 줄이며, 실제 효과는 접두부의 안정성, 제공업체별 설정과 수명, 캐시 적중률에 달려 있다.

📌 핵심 요약

• 프롬프트 캐싱은 프롬프트 접두부의 KV 상태를 요청 간 재사용하며 출력은 바꾸지 않는다. 재사용하려는 내용 앞부분의 바이트가 달라지면 해당 지점 이후의 캐시는 사용할 수 없으므로, 고정 내용은 앞에 두고 변경 내용은 뒤에 배치하는 것이 핵심이다.
• Requesty의 2026년 4월 트래픽에서 동일한 Claude 모델의 입력 토큰 중 캐시에서 읽은 비율은 Anthropic 직접 API에서 77%, Vertex에서 24%였다. Requesty는 이를 설정 문제로 해석했으며, 원문은 요청별 캐시 적중률 측정과 하락 감지를 강조한다.
• 2026년 10월 기준 Anthropic의 캐시 읽기 가격은 기본 입력 가격의 0.025~0.1배, OpenAI GPT-5.6 이상의 읽기 가격은 0.05~0.1배다. 쓰기 가격은 Anthropic의 5분 캐시와 GPT-5.6 이상에서 1.25배, Anthropic의 1시간 캐시에서 2배이며, Gemini 암시적 캐싱에는 추가 쓰기 할증이 없다.
• 원문은 1.25배 쓰기 요금은 한 번, 2배 쓰기 요금은 두 번 재사용하면 손익분기점을 넘는다고 설명한다. LangChain의 2026년 6월 에이전트 평가에서는 Anthropic·OpenAI·Gemini에서 토큰 비용이 49~80% 감소했으며, 별도의 2026년 4월 연구는 에이전트 코딩 작업이 코드 채팅보다 1,000배 많은 토큰을 소비했다고 보고했다.
• Anthropic은 캐싱을 명시적으로 활성화해야 하며 기본 수명은 5분, 선택 수명은 1시간이다. OpenAI와 Gemini는 기본 활성화 방식이지만 최소 접두부 길이와 제어 기능이 다르며, 도구 정의·설정 변경과 요청 간 공백은 캐시 재사용을 방해할 수 있다. 제공된 본문은 Gemini 설명 도중 끝나므로 이후 세부 내용은 확인할 수 없다.

🧩 주요 포인트

1. 동일한 접두부만 재사용 가능 → 고정된 시스템 지침·도구 정의를 앞에 유지하고 매번 달라지는 내용을 뒤에 붙이는 요청 구조가 비용 절감의 기반이다.
2. 동일 Claude 모델에서도 77%와 24%로 갈린 캐시 이용 비율 → 모델 선택과 함께 제공 경로·캐싱 설정·요청별 적중률을 살펴야 실제 효과를 판단할 수 있다.
3. 쓰기 할증·최소 접두부 길이·5분 또는 1시간 수명이라는 제약 → 반복 사용 횟수와 요청 간격에 맞춰 캐싱 방식을 선택해야 하며, 49~80% 절감 사례를 모든 작업에 그대로 적용할 수는 없다.

🧠 상세 정리

1. 에이전트 비용과 실제 캐시 이용 격차

모델 API는 상태를 유지하지 않으므로 채팅이나 에이전트가 다음 단계로 진행할 때마다 시스템 프롬프트, 도구 정의, 누적 대화를 다시 보내고 처리한다. Longju Bai 등의 2026년 4월 연구는 SWE-bench Verified에서 프런티어 모델 8개를 평가해 에이전트 코딩 작업이 코드 채팅보다 1,000배 많은 토큰을 소비했으며, 입력 토큰이 비용의 대부분을 차지했다고 보고했다. 원문 첫머리에 제시된 LangChain의 2026년 6월 에이전트 평가에서는 Anthropic·OpenAI·Gemini의 토큰 비용이 캐싱으로 49~80% 줄었다. 그러나 Requesty의 2026년 4월 트래픽에서 동일한 Claude 모델의 입력 토큰 중 캐시에서 읽은 비율은 Anthropic 직접 API에서 77%, Vertex에서 24%였고, Requesty는 이 차이를 설정 문제로 해석했다. Anthropic의 Claude Code 팀은 적중률 하락을 장애로 취급하며, OpenAI는 2026년 9월 관련 대시보드와 미적중 진단 필드를 도입했다고 원문은 설명한다.

2. 접두부의 KV 상태를 재사용하는 원리

프롬프트 캐싱은 프롬프트 시작 부분의 처리 상태를 저장해, 다음 요청이 같은 토큰으로 시작할 때 그 부분의 재처리를 건너뛰는 API 기능이다. Prefill 단계에서는 전체 입력을 병렬로 읽으며 각 계층에서 토큰별 키·값 벡터를 계산하고, decode 단계에서는 앞선 토큰의 키·값을 참조하며 출력 토큰을 하나씩 생성한다. 한 요청 안의 KV 캐시는 생성 단계마다 이전 계산을 반복하지 않게 하며, 프롬프트 캐싱은 이 KV 텐서를 요청 종료 후에도 보관해 요청 사이에서 재사용한다. 인과적 어텐션 때문에 500번째 토큰의 상태는 앞선 1~499번째 토큰에 의존하므로, 12번째 토큰이 바뀌면 그 지점 이후의 저장 상태를 재사용할 수 없지만 마지막 메시지만 바뀌면 앞부분은 유효하다. Anthropic은 지정 블록까지의 누적 해시로 캐시를 찾고, 일치하지 않으면 이전 요청이 저장한 항목을 최대 20개 블록까지 거슬러 탐색한다. 자체 호스팅에서도 vLLM은 고정 크기 KV 블록의 해시를, SGLang의 RadixAttention은 기수 트리를 사용해 공통 접두부의 계산을 공유하며, Anthropic 문서는 캐싱 여부가 응답을 바꾸지 않는다고 명시한다.

3. KV 캐싱·프롬프트 캐싱·의미 기반 캐싱의 차이

KV 캐싱은 현재 요청의 토큰별 키·값 벡터를 GPU 메모리에 저장하며, 한 요청 안에서 이전 토큰의 계산을 반복하지 않도록 자동으로 작동한다. 프롬프트 캐싱은 제공업체의 서빙 인프라에 접두부의 KV 상태를 요청 사이에도 유지하고, 바이트 단위로 동일한 접두부가 들어오면 캐시되지 않은 뒷부분만 새로 처리한다. 두 방식 모두 모델 실행을 지원하는 계산 재사용이며, 원문은 캐싱 자체가 답변을 바꾸지 않는다고 구분한다. 반면 의미 기반 캐싱은 질의의 임베딩을 기준으로 완성된 응답을 애플리케이션의 Redis나 벡터 저장소 등에 보관하고, 유사도가 임계값을 넘으면 모델을 실행하지 않고 저장된 답변을 반환한다. 이 방식은 비슷한 질문이 반복되는 FAQ형 트래픽에 유리하지만 오래되거나 잘못된 답을 반환할 가능성이 있으며, 요청마다 고유한 이력을 포함하는 에이전트에서는 원문상 접두부 캐싱이 대부분의 역할을 담당한다.

4. 제공업체별 가격과 재사용의 손익분기점

2026년 10월 18일에 확인한 제공업체 문서를 기준으로, Anthropic의 캐시 쓰기 가격은 기본 입력 가격 대비 5분 수명에서 1.25배, 1시간 수명에서 2배이며 OpenAI GPT-5.6 이상은 1.25배다. Anthropic 읽기 가격은 일반적으로 0.1배이고 Opus 5.5와 Sonnet 5.5는 0.05배, Fable 5.1은 0.025배이며, OpenAI는 일반적으로 0.1배이고 GPT-6.1 Sol은 0.05배다. Gemini 암시적 캐싱은 쓰기 할증이 없고 읽기 할인이 적용되지만, 원문 표에는 정확한 할인율이 없으며 적중도 보장되지 않는다. 원문은 쓰기 가격이 1.25배인 경우 한 번 재사용하면, Anthropic의 1시간 요금처럼 2배인 경우 두 번 재사용하면 쓰기 할증을 회수한다고 설명한다. 최소 접두부는 Anthropic 현행 모델에서 512토큰이고 구형 모델에서는 1,024~4,096토큰이며, OpenAI는 가시 입력 1,024토큰을 요구한다. Gemini는 Gemini 4 Argon과 3.x에서 4,096토큰, 2.5에서 2,048토큰을 요구하므로, 가격 할인과 함께 실제 입력 길이와 반복 사용 조건을 고려해야 한다.

5. Anthropic의 활성화·중단점·수명 관리

Claude API의 프롬프트 캐싱은 선택적으로 활성화하며, 2026년 2월 19일 출시된 자동 캐싱은 요청 최상위에 cache_control을 추가하면 마지막 캐싱 가능 블록까지 저장하고 대화가 길어질 때 그 지점을 앞으로 옮긴다. 대화가 이어지면 이전 사용자 메시지까지 읽고 새 어시스턴트 응답과 사용자 메시지를 쓰는 방식으로 재사용 범위가 확장된다. 변경 주기가 다른 도구·문서·대화를 나누려면 블록별 명시적 중단점을 사용할 수 있지만 요청당 최대 4개이고 자동 중단점도 한 자리를 차지하며, 접두부는 tools, system, messages 순서로 구성된다. 기본 캐시는 적중할 때마다 갱신되는 5분 수명이고 1시간 옵션도 있지만, 수명은 요청이 시작된 시점부터 계산된다. 따라서 응답 스트리밍에 4분이 걸리면 기본 캐시를 재사용할 후속 요청은 응답 종료 후 약 1분 안에 시작해야 한다. 병렬 요청은 첫 응답이 시작되기 전까지 캐시를 공유하지 못하므로 동일 접두부의 요청 10개를 동시에 보내면 모두 쓰기가 발생하며, 원문은 첫 요청의 응답 시작을 기다린 뒤 나머지를 보내는 방식을 제시한다.

6. Anthropic에서 캐시를 무효화하는 변경

접두부의 앞쪽이 바뀌면 뒤쪽의 저장 상태도 달라지므로, Anthropic에서 도구 정의를 수정하면 전체 캐시가 무효화되고 특정 계층의 변경은 그 계층과 이후 계층에 영향을 준다. 웹 검색·인용·빠른 모드의 전환은 시스템 및 메시지 캐시를 무효화하며, tool_choice·이미지·thinking 구성·effort 설정의 변경은 메시지 블록을 무효화한다. 원문은 타임스탬프, 불안정한 JSON 직렬화, 모델이나 effort의 전환, 긴 요청 간 공백 역시 캐시 적중을 깨뜨리는 요인으로 제시한다. 고정 내용을 앞에 두더라도 그 앞부분의 표현이나 설정이 바뀌면 재사용이 끊길 수 있다는 점이 운영상 핵심 제약이다. 한편 대화 중간에 role이 system인 메시지를 추가하면 기존 접두부를 다시 쓰지 않고 지침을 갱신할 수 있으며, 2026년 9월 릴리스 노트에는 메시지별 effort 변경과 메시지 내부의 새 도구 정의를 지원하는 베타도 소개됐다고 원문은 설명한다.

7. OpenAI의 기본 캐싱과 접두부 보존 방법

OpenAI의 프롬프트 캐싱은 기본 활성화되며, GPT-5.6 이상에서 암시적 모드는 가장 최근의 적격 메시지 끝에 중단점을 놓고 명시적 모드는 사용자가 위치를 지정하게 하며 요청당 최대 4회의 캐시 쓰기를 지원한다. 마지막 명시적 중단점 뒤의 내용은 쓰기 할증 없이 일반 입력 가격으로 과금되므로, 다시 사용할 가능성이 낮은 내용을 그 뒤에 둘 수 있다. 저장 상태는 개별 머신에 존재하고 분당 15회를 넘는 트래픽은 해당 캐시가 없는 머신으로 넘쳐날 수 있으며, 원문 표는 마지막 쓰기나 재사용 뒤 최소 30분의 수명을 제시한다. GPT-5.6 이전 모델에서는 사용자나 세션 ID처럼 안정적인 prompt_cache_key가 관련 요청을 같은 캐시로 라우팅하는 데 도움이 되지만, 이후 모델은 자동 라우팅하며 이 키는 캐시 사용량 집계를 구분하는 용도로만 쓰인다. 2026년 9월 22일 발표된 방식은 요청 수준의 reasoning.effort를 유지한 채 configuration_update 입력 항목을 덧붙여 대화 중 추론 강도를 바꿀 수 있게 한다. 특정 턴에서 도구를 제한할 때도 정의를 제거하는 대신 allowed_tools나 tool_choice의 none 값을 사용하면 접두부를 보존할 수 있다.

8. Gemini의 암시적 캐싱과 관측 범위

Gemini API는 Gemini 2.5 이상에서 별도 설정 없이 암시적 캐싱을 제공하며, 상태를 유지하는 대화와 상태를 유지하지 않는 대화 모두에 적용된다고 원문은 설명한다. Google이 제시한 배치 원칙은 크고 공통적인 내용을 프롬프트 앞에 두는 것이지만, 제공된 본문은 비슷한 접두부를 가진 요청에 관한 설명 도중 끝나므로 이어지는 조건은 확인할 수 없다. 비교표에서도 Gemini의 캐시 수명은 공개되지 않은 것으로, 미적중 진단과 사전 예열은 문서화되지 않은 것으로 표시되며, 읽기 할인은 있어도 적중은 보장되지 않는다고 제시한다. 실제 사용량을 확인하는 필드는 Anthropic의 cache_read_input_tokens와 cache_creation_input_tokens, OpenAI의 cached_tokens와 cache_write_tokens, Gemini의 total_cached_tokens로 서로 다르다. Anthropic은 diagnostics.cache_miss_reason을, OpenAI는 prompt_cache_diagnostics와 대시보드를 제공하므로, 원문이 강조하는 요청별 측정과 적중률 하락 감지는 제공업체의 관측 기능 차이를 고려해야 한다. 목차에는 추가 비용 분석, 웹 콘텐츠 배치, 2026년 연구와 캐싱이 도움이 되지 않는 경우 등이 예고돼 있지만, 제공된 범위만으로 해당 후반부의 상세 주장까지 요약할 수는 없다.

🧾 핵심 주장 / 시사점

• 프롬프트 캐싱의 효과는 할인율만으로 결정되지 않는다. 동일한 Claude 모델에서도 제공 경로에 따라 캐시 이용 비율이 크게 달랐다는 관측은 설정과 요청 구성의 중요성을 보여준다.
• 캐시를 오래 유지하는 선택에는 쓰기 할증이 따르므로, 변경 빈도와 재사용 간격이 서로 다른 내용을 어떻게 나누는지가 경제성에 영향을 준다.
• 프롬프트 캐싱은 계산 상태를 재사용하지만 의미 기반 캐싱은 완성된 답변을 재사용한다. 따라서 비용 절감 방식뿐 아니라 답변이 오래되거나 잘못될 가능성도 구분해 판단해야 한다.

✅ 액션 아이템

• 고정된 시스템 지침·도구 정의를 접두부 앞에 유지하고, 매번 달라지는 내용은 뒤에 배치한다.
• 요청별 캐시 적중률을 측정하고, Anthropic 직접 API의 77%와 Vertex의 24% 사례를 참고해 제공 경로와 캐싱 설정을 점검한다.
• 쓰기 가격 1.25배·2배와 5분·1시간 수명을 반복 사용 횟수 및 요청 간격과 비교해 캐싱 방식을 선택한다.

❓ 열린 질문

• 현재 요청에서 고정된 시스템 지침·도구 정의 앞부분을 바꾸어 동일한 접두부의 재사용을 막는 내용은 무엇인가?
• Anthropic 직접 API의 77%와 Vertex의 24% 사례처럼 제공 경로와 캐싱 설정에 따라 실제 캐시 적중률이 달라지는가?
• 실제 반복 사용 횟수와 요청 간격은 1.25배 쓰기 요금의 한 번 재사용 및 2배 쓰기 요금의 두 번 재사용 조건을 5분 또는 1시간 수명 안에 충족하는가?