프롬프트 캐싱: 첫 요청과 반복 요청의 비용

이 실험이 측정하는 것

프롬프트 캐시는 입력 중 변하지 않는 부분을 다시 처리하는 양을 줄입니다. 시스템 프롬프트, 지시문의 집합, 큰 문서, 고정된 스토리가 여기에 해당할 수 있습니다. 변경되는 질문은 공통 프리픽스 뒤에 둡니다.

실험에는 세 가지 상태가 필요합니다.

A. first request: stable prefix + question 1
B. cache hit:     stable prefix + question 2
C. cache miss:    changed prefix + question 3

A와 B는 같은 모델, 같은 설정, 같은 캐시 정책을 사용합니다. C에서는 캐시 영역의 문자 하나만 바꾸거나, TTL이 확실히 만료된 뒤 실행합니다. 모델, 출력, 프롬프트 길이를 동시에 바꾸면 결과를 캐시만으로 설명할 수 없습니다.

자신의 usage로 공식을 확인하고 싶으신가요? BetterToken 계정과 API Key를 만들고 요금 페이지에서 현재 요율을 확인한 뒤, 동일한 프리픽스로 첫 요청과 반복 요청을 실행할 수 있습니다. 이후 Dashboard에서 input, output, 해당 캐시 Token, 소비량을 대조하고, 먼저 API 레퍼런스 및 공급자 문서에서 캐시와 TTL 규칙을 확인하세요.

OpenAI와 Anthropic은 캐시를 다르게 집계합니다

같은 캐시라는 단어가 같은 메커니즘을 뜻하지는 않습니다.

OpenAI 프롬프트 캐싱

OpenAI의 지원 API와 모델에서는 적합한 프리픽스에 캐싱이 자동 적용됩니다. usage는 input 세부 정보 안에 캐시된 Token을 표시합니다. 일반적으로 코드에서 별도의 캐시 객체를 만들지는 않지만, 공통 프리픽스는 그대로 유지해야 합니다. 정확한 임계값, 보존 기간, 할인은 공식 Prompt Caching 페이지에서 확인하세요.

Anthropic 프롬프트 캐싱

Anthropic Messages에서는 cache_control로 캐시 경계를 표시할 수 있습니다. usage는 캐시 생성과 읽기를 별도로 보여줄 수 있습니다. 최소 크기, TTL, 블록 순서, 비용은 현재 계약과 모델에 따라 달라지므로 Anthropic 공식 문서에서 검증해야 합니다.

두 프로토콜 사이에서 usage 필드 이름이나 계수를 옮겨 쓰지 마세요. 실험 표에는 현재 endpoint가 반환한 범주만 정확히 기록합니다.

안정적인 프리픽스 준비하기

입력을 두 부분으로 수집합니다.

STABLE_PREFIX
  system instructions
  tool definitions, if they are needed
  unchanged reference document

DYNAMIC_SUFFIX
  current user question

첫 실험에서는 tools와 streaming을 제거하는 편이 좋습니다. 이들이 자동으로 캐시를 방해하는 것은 아니지만 usage와 출력에 변수를 추가합니다.

프리픽스는 선택한 모델의 규칙에 따라 충분히 길어야 합니다. 최소 임계값보다 짧으면 캐시 히트가 없는 것은 예상된 결과입니다. 운영 환경에서 의미 없는 텍스트로 길이를 늘리지 마세요. 실험에는 이미 문제에서 반복되는 실제 문서를 사용하세요.

호출 전에 캐시되는 부분의 해시를 저장합니다.

import hashlib

prefix_hash = hashlib.sha256(STABLE_PREFIX.encode("utf-8")).hexdigest()
print(prefix_hash)

해시는 내용을 공개하지 않고도 A와 B가 같은 프리픽스를 받았음을 확인해 줍니다.

기록할 필드

각 요청마다 다음을 저장합니다.

• 시각과 request ID
• Model ID와 프로토콜
• prefix_hash
• 일반 input Token
• 계약에서 분리하는 경우 캐시 생성/쓰기 Token
• 계약에서 분리하는 경우 캐시 읽기/캐시됨 Token
• output Token
• 실제 소비량
• 진단 필드로만 쓰는 status와 latency

latency는 가격 증거가 아닙니다. 응답이 빨라도 캐시 미스일 수 있고, 캐시 히트여도 대기열에서 기다릴 수 있습니다. 비용에 관한 결론은 usage와 요금표를 기준으로 내립니다.

첫 쿼리의 공식

다음과 같이 둡니다.

I  — regular input tokens
W  — cache write / creation tokens
R  — cache read / cached tokens
O  — output tokens
Pi — regular input price per 1,000,000 tokens
Pw — cache write price per 1,000,000 tokens
Pr — cache read price per 1,000,000 tokens
Po — output price per 1,000,000 tokens

이 범주들을 분리하는 endpoint의 계산식은 다음과 같습니다.

cost = I / 1_000_000 × Pi
     + W / 1_000_000 × Pw
     + R / 1_000_000 × Pr
     + O / 1_000_000 × Po

첫 요청에서는 W가 0보다 클 수 있고, R도 0보다 클 수 있습니다. 자동 캐싱에서는 필드의 조합이 다를 수 있습니다. 실제 usage의 미캐시 input과 캐시된 input을 사용하고, 존재하지 않는 범주를 만들지 마세요.

캐시 생성에 별도 비용이 청구되면 첫 요청의 가격이 캐시 없는 요청보다 높을 수 있습니다. 이는 그 자체로 오류가 아닙니다. 충분히 많은 읽기가 있어야 비용을 회수합니다.

반복 요청 공식과 손익분기점

다음과 같이 둡니다.

C0 — cost of the first request that creates the cache
Ch — cost of one request with a cache hit
Cu — cost of one comparable request without cache
n  — total number of requests

한 번의 생성과 n - 1번의 히트가 있는 시퀀스는 다음과 같습니다.

C_cached(n) = C0 + (n - 1) × Ch
C_uncached(n) = n × Cu

캐시가 비용을 회수하는 최소 n은 다음 조건을 만족하는 첫 정수입니다.

C_cached(n) < C_uncached(n)

다른 모델의 가격을 공식에 넣지 마세요. Ch >= Cu라면 현재 구성은 절감 효과를 제공하지 않습니다. 캐시 히트, 프리픽스 크기, 요금 범주를 확인하세요.

대조 캐시 미스

A와 B 다음에 C를 실행합니다. 모델과 예상 응답 길이는 유지하고 캐시되는 프리픽스만 바꾸세요. 계약에 따라 캐시 읽기 범주는 줄어들거나 사라져야 하며, 일반 처리 또는 캐시 생성은 변해야 합니다.

예상하지 못한 미스의 원인은 다음과 같습니다.

• 프리픽스 안의 기호 또는 공백이 바뀌었다
• tool definitions가 다른 순서로 들어왔다
• system block이 이동했다
• 모델 또는 endpoint가 바뀌었다
• 요청이 TTL 범위를 벗어났다
• 프리픽스가 최소 임계값보다 짧았다
• 클라이언트가 같은 데이터를 다른 순서로 직렬화했다

안정적인 프리픽스 뒤의 질문을 바꾸는 것은 예상된 일입니다. 프리픽스 내부를 바꾸면 다른 캐시 ID가 만들어집니다.

"달러로 표시한 결과"를 공개하지 않는 이유

이 글은 특정 계정의 API Key와 usage에 접근할 수 없으므로, 수행된 테스트의 계산된 예시를 제공하지 않습니다. 가격, 모델, 캐싱 규칙은 변합니다. 임의의 숫자를 게시하면 재현 가능한 실험이 곧 낡은 광고가 됩니다.

자신의 결과를 얻으려면 다음을 수행하세요.

1. 모델 하나와 프로토콜 하나를 선택한다
2. 현재 BetterToken 요금 페이지를 연다
3. A, B, C를 실행한다
4. Dashboard에서 usage와 소비량을 옮겨 적는다
5. C0, Ch, Cu와 손익분기점을 계산한다
6. 확인 날짜와 prefix_hash를 저장한다

FAQ

캐시가 있는 첫 요청이 더 비쌀 수 있는 이유는 무엇인가요?

일부 프로토콜은 캐시 생성/쓰기에 별도로 청구합니다. 초기 추가 비용은 반복 캐시 읽기를 통해서만 보상됩니다. 특정 모델의 현재 가격을 확인하세요.

반복 요청이 캐시 히트를 얻지 못한 이유는 무엇인가요?

프리픽스 길이와 불변성, 블록 순서, 모델, endpoint, TTL, 최소 임계값을 점검하세요. prefix_hash를 비교합니다.

하나의 usage 필드로 OpenAI와 Anthropic을 비교할 수 있나요?

아니요. 메커니즘, 구성, 범주 이름이 다릅니다. 원래 필드는 보존하면서 값을 자체 I, W, R, O 필드로 정규화하세요.

캐시는 항상 비용을 줄이나요?

아니요. 짧은 프리픽스, 드문 반복, 잦은 변경, 낮은 캐시 히트율은 캐시 생성 비용을 회수하지 못할 수 있습니다.

BetterToken의 실제 차감액은 어디에서 확인할 수 있나요?

Dashboard에서 시간, 모델, request status별로 확인할 수 있습니다. 요금은 요금 페이지에서, 캐싱 규칙은 해당 프로토콜 문서에서 가져오세요.