Prompt Caching 비용 가이드: Cache Hits, Prefixes 및 실제 API 사용 비용

프롬프트 캐싱 비용은 세 가지 변수에 따라 달라집니다. 프롬프트 중 재사용 가능한 접두사(prefix)의 비중, 해당 접두사가 캐시의 활성 창(active window) 내에서 얼마나 자주 반복되는지, 그리고 특정 제공업체가 캐시 쓰기(write)와 캐시 적중(hit)에 가격을 어떻게 책정하는지입니다. 이 세 가지 수치를 정확히 파악하면 반복적인 작업 부하에서 입력 토큰 비용을 의미 있게 낮출 수 있지만, 잘못 계산하면 재사용되지 않는 캐시에 대해 쓰기 프리미엄만 지불하게 될 수 있습니다.

이 가이드는 제공업체가 문서화한 내용, 공개 API 인터페이스에서 확인할 수 있는 내용, 그리고 프로덕션 비용을 캐싱 전략에 투입하기 전에 테스트해야 할 내용을 구분하여 설명합니다.

핵심 요약

• 프롬프트 캐싱 비용은 두 가지 요소로 구성됩니다. 쓰기 비용(보통 새로운 캐시 항목이 생성될 때 청구)과 적중 비용(보통 요청이 해당 항목을 재사용할 때 청구)입니다. Anthropic의 문서는 이러한 쓰기 대 적중의 차이를 명확히 설명하고 있습니다. 비용 모델을 수립하기 전에 문서 페이지에서 현재 배수를 확인해야 합니다.
• 캐시 적중을 위해서는 정의된 중단점(breakpoint)까지 정확하거나 거의 일치하는 접두사가 필요합니다. 시스템 지침, 도구 정의 또는 퓨샷(few-shot) 예제를 해당 중단점 앞에 재배치하면 캐시가 무효화되어 강제로 다시 쓰기가 발생합니다.
• 캐시 항목은 제공업체가 정의한 TTL(time-to-live) 이후 만료됩니다. 특정 접두사에 대한 요청 볼륨이 너무 적어 해당 창 내에 들어오지 못하면, 적중을 통한 절감 효과를 누리지 못하고 반복적인 쓰기 비용만 지불하게 됩니다.
• OpenRouter의 문서는 프롬프트 캐싱 동작과 가격이 기본 제공업체 및 모델에 따라 다르다고 명시하고 있으므로, 한 백엔드에서 비용을 절감하는 캐싱 전략이 다른 백엔드에 자동으로 적용되지 않습니다. 예상 절감액을 기준으로 트래픽을 라우팅하기 전에 모델별 지원 여부를 확인하십시오.

프롬프트 캐싱의 실제 과금 방식

프롬프트 캐싱을 사용하면 API 제공업체가 프롬프트 접두사의 처리된 표현을 저장하여, 해당 접두사를 공유하는 후속 요청이 중복 계산을 건너뛸 수 있습니다. 이에 따른 과금 모델은 "캐시된 토큰은 무료"가 아닙니다. 오히려 "캐시된 토큰은 재사용 시 저렴하지만, 첫 번째 쓰기는 표준 입력 토큰보다 비용이 더 든다"는 개념에 가깝습니다.

Anthropic의 프롬프트 캐싱 문서는 이 구조를 직접적으로 설명합니다. 새로운 캐시 항목을 생성하는 요청은 기존 항목을 적중하는 요청과 다르게 청구됩니다. 정확한 배수는 시간이 지남에 따라 모델별로 변경되므로, 이 게시물을 포함한 블로그 게시물에서 보는 모든 수치는 고정된 상수가 아닌 현재 문서와 대조하여 확인해야 할 대상으로 간주하십시오.

실질적인 의미는 프롬프트 캐싱이 재사용에 대한 내기라는 점입니다. 시스템 프롬프트, 도구 스키마 또는 검색된 컨텍스트 블록이 한 번 전송되고 다시 반복되지 않는다면, 캐싱은 상쇄할 적중 절감액 없이 쓰기 프리미엄만 추가하게 됩니다. 반면 동일한 블록이 캐시의 활성 창 내에서 수백 번 전송된다면, 적중 절감액이 쓰기 비용을 훨씬 상회할 수 있습니다.

캐시 적중의 원리: 접두사, 접두사, 그리고 중단점

캐시 적중은 모호한 의미에서의 콘텐츠 기반이 아니라 접두사 기반입니다. 프롬프트의 캐시된 부분은 캐시 경계(중단점이라고도 함)가 설정된 지점까지 들어오는 요청과 토큰 단위로 일치해야 합니다. Anthropic의 문서는 개발자가 프롬프트 중 캐싱 대상(일반적으로 호출 간에 변경되지 않는 안정적인 시스템 지침, 도구 정의 및 긴 참조 문서)을 표시하는 명시적 메커니즘으로 이를 설명합니다.

이는 엔지니어링 측면에서 직접적인 결과를 초래합니다. 캐시 중단점 앞에 배치하는 모든 것은 공백과 순서를 포함하여 요청 간에 바이트 단위로 동일해야 합니다. 흔히 하는 실수는 요청별 변수(타임스탬프나 사용자 ID 등)를 캐시 경계 앞의 시스템 프롬프트에 삽입하는 것입니다. 그 단 하나의 변수가 전체 접두사에 대한 캐시를 무효화하며, 적중을 누적하는 대신 모든 호출에서 쓰기 비용을 지불하게 됩니다.

해결책은 간단합니다. 진정으로 정적인 콘텐츠(도구 정의, 하우스 스타일 지침, 대규모 참조 문서)는 캐시된 접두사에 유지하고, 요청별로 달라지는 내용은 일반적으로 사용자 메시지인 캐시되지 않은 접미사(suffix)로 밀어 넣으십시오.

캐시 수명은 접두사 설계만큼이나 중요합니다. Anthropic의 문서는 기본 캐시 지속 시간을 분 단위로 설명하며, 필요한 작업 부하를 위해 더 긴 지속 시간 옵션을 제공합니다. 트래픽 패턴이 몇 분마다 한 번씩 공유 접두사를 보내는 경우, 짧은 수명의 캐시는 다음 요청이 도착하기 전에 만료될 수 있으며, 결국 쓰기 비용을 반복적으로 지불하게 됩니다. 고주파 작업 부하(채팅 세션, 에이전트 루프, 연속 실행되는 배치 파이프라인)가 저주파의 산발적인 호출보다 훨씬 더 적합한 대상입니다.

실제 API 지출 모델링: 작업 접근 방식

절감 비율을 단정 짓기보다는 다음 형태로 자신의 작업 부하를 모델링하십시오. 이 예시는 요청 구조를 개념적으로 보여줍니다. 구현하기 전에 제공업체 문서에서 정확한 필드 이름과 현재 가격을 확인하십시오.

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

시스템 블록의 cache_control 마커는 이 콘텐츠가 캐싱 대상임을 알립니다. 세션의 첫 번째 호출은 해당 블록에 대한 쓰기 비용을 지불합니다. 캐시의 활성 창 내에서 동일한 접두사를 재사용하는 모든 후속 호출은 해당 토큰에 대해 전체 입력 요율 대신 적중 요율을 지불합니다.

서비스에 구현할 가치가 있는지 평가하려면 자신의 로그에서 다음 네 가지 수치를 수집하십시오.

1. 접두사 크기: 캐시하려는 안정적인 콘텐츠(시스템 프롬프트, 도구 스키마, 참조 문서)의 토큰 수.
2. TTL 창 내 호출 빈도: 캐시의 활성 기간 내에 해당 접두사를 정확히 재사용하는 요청 수.
3. 쓰기 및 적중 요율: 메모리에 의존하지 말고 현재 제공업체 문서에서 가져온 수치.
4. 접미사 가변성: 프롬프트의 캐시되지 않은 부분이 캐시된 부분에 비해 작은지 여부(절감액은 전체 프롬프트 중 캐시 중단점 뒤에 위치한 비율에 따라 커지기 때문).

접두사가 크고, TTL 창 내 호출 빈도가 높으며, 접미사가 작다면 캐싱을 통해 지출을 줄일 가능성이 높습니다. 이 세 가지 조건 중 하나라도 약하다면 캐싱을 광범위하게 도입하기 전에 비용 비교를 수행하십시오. AI API 비용 절감에 관한 TokenLab의 가이드는 모델 선택 및 배치 처리를 포함하여 캐싱 외의 더 넓은 범위의 레버리지를 다루고 있으며, /blog/cut-ai-api-costs-30-percent에서 확인할 수 있습니다.

의사결정 표: 프롬프트 캐싱이 효과적인 경우

작업 부하 패턴	캐시 효과 여부	참고
세션 내 여러 호출에서 재사용되는 긴 시스템 프롬프트 또는 도구 스키마	예	전형적인 사례; 쓰기 비용이 적중을 통해 상쇄됨
짧은 후속 질문 버스트에서 재사용되는 대규모 검색 문서	예(TTL 내 호출 시)	재사용 창을 가정하기 전에 현재 문서의 TTL 확인
반복 트래픽이 없는 일회성 프롬프트	아니요	상쇄할 적중 없이 쓰기 프리미엄만 발생
"안정적인" 섹션이 계속 변경되는 고가변성 프롬프트	아니요	중단점 앞의 모든 변경 사항은 캐시를 무효화함
여러 턴에 걸쳐 도구 정의가 반복되는 에이전트 루프	예	도구 스키마는 주요 캐싱 대상임
캐시 TTL을 넘어선 저주파 배치 작업	아니요	재사용 전 캐시 만료; 매번 쓰기 비용 발생
일부 백엔드만 캐싱을 지원하는 다중 제공업체 라우팅	모델별 확인	캐싱 지원이 제공업체 간에 이전된다고 가정하지 말 것

이 표를 최종 답변이 아닌 시작 체크리스트로 사용하십시오. 사용하려는 특정 모델에 대한 제공업체 문서와 TTL, 쓰기/적중 가격, 중단점 메커니즘을 확인하십시오. 이러한 세부 사항은 모델 제품군에 따라 변경되고 달라지기 때문입니다.

커밋 전 확인해야 할 제공업체별 차이점

프롬프트 캐싱은 모든 곳에서 동일하게 구현되지 않으며, 여러 제공업체나 모델 간에 트래픽을 라우팅하는 경우 이는 중요합니다. 프롬프트 캐싱 모범 사례에 대한 OpenRouter의 문서는 캐싱 지원 및 동작이 기본 제공업체에 따라 다르다고 언급하고 있습니다. 즉, 한 모델의 캐시 메커니즘에 맞춰 조정된 전략이 모델을 전환하거나 다른 백엔드를 통해 라우팅할 때 자동으로 적용되지 않습니다.

아키텍처에서 비용을 제어하기 위해 모델 라우팅을 사용하는 경우(예: 일상적인 분류 작업은 DeepSeek V4 Flash, GLM-5.2 또는 Gemini 3.5 Flash와 같은 저비용 모델로 보내고, 더 어려운 추론 작업은 Claude Sonnet 5 또는 GPT-5.5로 예약하는 경우), 라우팅 테이블의 각 모델에 대해 캐싱 지원을 독립적으로 확인해야 합니다. 한 모델의 문서에 대해 검증된 캐싱 전략은 다른 모델에 대해 안전한 가정이 아닙니다. TokenLab의 순위 페이지(/models/rankings)에서 모델 수준의 차이를 참조할 수 있으며, 라우팅 벤치마크 분석(/blog/ai-model-routing-benchmark-cost-per-task)에서는 라우팅 결정이 캐싱 결정과 어떻게 상호작용하여 작업당 비용에 영향을 미치는지 다룹니다.

본 분석의 한계

이 가이드는 위에서 관찰된 날짜를 기준으로 Anthropic이 문서화하고 OpenRouter가 참조하는 프롬프트 캐싱의 일반적인 메커니즘을 설명합니다. 정확한 쓰기/적중 배수, 정확한 TTL 지속 시간 또는 모델별 가격은 포함하지 않습니다. 이러한 수치는 모델에 따라 변경되고 다르기 때문입니다. 프로덕션 트래픽에 대한 비용 모델을 구축하기 전에, 본 기사를 포함한 제3자 콘텐츠에 인용된 고정 수치에 의존하지 말고 위에서 링크된 제공업체 문서에서 현재 수치를 직접 가져오십시오. 추론 지향 모델, 멀티모달 프롬프트 및 매우 긴 컨텍스트 창에 대한 캐싱 동작은 여기서 설명한 일반적인 접두사 캐싱 패턴과 다를 수 있으므로, 사용하려는 특정 모델의 문서를 확인하십시오.

FAQ

프롬프트 캐싱은 항상 API 지출을 줄여주나요? 아니요. 안정적인 접두사가 캐시의 활성 창 내에서 쓰기 비용을 상쇄할 만큼 충분히 자주 재사용될 때만 지출을 줄여줍니다. 산발적이거나 가변성이 높은 프롬프트는 캐싱을 활성화했을 때 그렇지 않을 때보다 비용이 더 많이 드는 경우가 많습니다.

캐시 적중을 깨뜨리는 것은 무엇인가요? 공백, 토큰 순서 또는 정적인 시스템 프롬프트에 삽입된 단일 변수를 포함하여, 캐시 중단점 앞의 프롬프트 콘텐츠에 대한 모든 변경 사항입니다. 일치는 중단점까지 정확해야 합니다.

프롬프트 캐싱은 모든 제공업체에서 동일하게 구현되나요? 아니요. Anthropic은 정의된 쓰기 및 적중 가격과 함께 명시적인 캐시 제어 메커니즘을 문서화합니다. OpenRouter의 문서는 캐싱 지원 및 가격이 기본 제공업체 및 모델에 따라 다르다고 명시하고 있으므로, 지원이 이전된다고 가정하지 말고 모델별로 지원 여부를 확인해야 합니다.

프롬프트 캐싱, 모델 라우팅 또는 이 둘의 조합이 귀하의 트래픽 패턴에 적합한지 평가 중이라면, TokenLab을 시작하여 프로덕션 비용을 투입하기 전에 모델 옵션과 비용 구조를 비교해 보십시오.