“LLM 프롬프트 캐싱을 켰더니 API 요금이 90% 할인된다”는 말을 듣고 기대에 부풀었다가, 막상 청구서를 열어보면 20~30% 남짓 줄어든 걸 보고 당황하는 경우가 많습니다. 이 글은 그 차이가 왜 생기는지를 Anthropic Claude와 OpenAI의 공식 가격 정책을 근거로 뜯어보고, 실제 절감률을 직접 계산하는 방법을 코드와 함께 보여드립니다. 결론부터 말하면 ‘90% 할인’은 특정 조건을 만족한 토큰 일부에만 적용되는 숫자이고, 청구서 전체 절감률은 캐시 적중률·출력 토큰 비중·TTL(캐시 유효시간) 설정에 따라 크게 달라집니다.
‘90% 할인’은 정확히 어떤 토큰에만 붙는 숫자인가
Anthropic이 안내하는 프롬프트 캐싱의 90% 할인은 “요청 전체 비용”이 아니라 “캐시에 적중(cache hit)한 입력 토큰”에만 적용되는 단가입니다. Claude API 응답의 usage 객체를 보면 토큰이 네 종류로 분리되어 찍힙니다.
input_tokens: 캐시와 무관한 일반 입력 토큰 (기본 단가)cache_creation_input_tokens: 이번 요청에서 새로 캐시에 써넣은 토큰 (쓰기 단가, 더 비쌈)cache_read_input_tokens: 이전에 써둔 캐시를 재사용한 토큰 (읽기 단가, 90% 할인)output_tokens: 응답으로 생성된 토큰 (캐싱 할인 대상 아님, 항상 기본 단가)
즉 한 번의 요청 안에서도 네 가지 단가가 섞여서 청구되기 때문에, “캐시 읽기 토큰만 따로 보면 90% 싸다”는 말과 “이번 달 청구서가 90% 줄었다”는 말은 전혀 다른 이야기입니다. 실제 절감률은 전체 요청에서 저 네 카테고리가 차지하는 비율에 의해 결정됩니다. 자세한 필드 정의는 Anthropic 공식 프롬프트 캐싱 문서에서 확인할 수 있습니다.
캐시 쓰기는 오히려 25% 더 비싸고, 5분이 지나면 다시 써야 한다
Anthropic의 표준 캐시(TTL 5분) 기준으로, 캐시를 처음 만드는 “쓰기” 요청은 기본 입력 단가의 1.25배(25% 더 비쌈)가 청구됩니다. 반대로 그 캐시를 읽어서 재사용하면 기본 단가의 0.1배(90% 할인)가 청구됩니다. 문제는 이 캐시가 마지막 사용 시점 기준 5분 안에 다시 호출되지 않으면 그냥 만료된다는 점입니다. 사용자가 답변을 읽고 생각하는 시간, 백엔드 큐잉 지연, 여러 세션이 섞여 들어오는 서비스 구조 등으로 인해 5분 TTL을 놓치는 요청이 섞이면, 그 요청은 다시 “쓰기” 단가(1.25배)로 청구됩니다.
즉 세션 10번 중 캐시가 계속 살아있어 9번은 읽기로 처리되고 1번만 쓰기라면 절감폭이 90%에 가깝게 나오지만, TTL이 자주 끊겨서 쓰기와 읽기가 절반씩 섞이면 절감폭은 급격히 줄어듭니다. Anthropic은 이 문제를 완화하기 위해 1시간짜리 확장 TTL 옵션도 제공하지만, 이 경우 쓰기 단가가 기본 입력가의 2배까지 올라갑니다. 재사용이 확실하지 않은 상황에서 무작정 TTL을 늘리면 오히려 손해를 볼 수 있다는 뜻이므로, 트래픽 패턴을 먼저 확인하는 것이 순서입니다.
출력 토큰과 매번 바뀌는 입력은 할인 대상이 아니다
두 번째로 절감률을 깎아먹는 요인은 캐싱이 ‘입력 토큰’ 중에서도 ‘변하지 않는 부분’에만 적용된다는 점입니다. 시스템 프롬프트, 툴(tool) 정의, 긴 문서·코드베이스 컨텍스트처럼 매 요청 동일하게 들어가는 부분만 캐시 대상이 되고, 사용자가 매번 새로 입력하는 질문이나 대화 히스토리 중 최근 턴은 캐시할 수 없어 기본 단가 그대로 청구됩니다.
더 크게는 출력 토큰이 있습니다. 캐싱은 입력 토큰 처리 비용을 줄이는 기능이지 생성(응답) 비용과는 무관합니다. 코드 생성이나 긴 리포트 작성처럼 응답이 긴 워크로드는 전체 청구서에서 출력 토큰 비중이 높기 때문에, 입력 토큰을 아무리 90% 할인받아도 총액 기준 절감폭은 제한적입니다. 예를 들어 컨텍스트는 짧고 응답만 긴 코딩 에이전트라면, 캐싱을 완벽하게 적용해도 청구서 절감률이 20%대에 머무는 일이 흔합니다. 또한 Claude 3.5/3.7 계열은 모델별로 1,024~2,048 토큰 이상이어야 캐시가 걸리는 최소 길이 조건이 있어서, 컨텍스트 자체가 짧은 애플리케이션은 애초에 캐싱 혜택을 거의 못 받습니다.
실제 절감 계산법: 캐시 적중률 50% 시나리오로 검증하기
말로만 설명하면 체감이 안 되니, 실제 청구 단가 구조(기본 입력가 대비 캐시 쓰기 1.25배, 캐시 읽기 0.1배, 출력가는 별도)를 그대로 반영한 계산을 해보겠습니다. 아래는 시스템 프롬프트·툴 정의 2만 토큰이 캐시 대상이고, 매 턴 사용자 메시지 300토큰은 캐시 불가, 응답이 1,500토큰인 세션을 10회 요청(그중 TTL이 끊겨 쓰기로 처리된 요청 5회, 캐시가 살아있어 읽기로 처리된 요청 5회) 보낸다고 가정한 예시입니다. 단가는 Anthropic이 공개한 배율(쓰기 1.25배, 읽기 0.1배)을 기준으로 임의의 기본 입력가 $3/MTok, 출력가 $15/MTok을 대입한 것으로, 실제 모델별 정확한 단가는 공식 가격표를 확인해야 합니다.
BASE_INPUT = 3.0 # $ / 1M 토큰, 캐싱 없는 일반 입력
CACHE_WRITE = 3.75 # 기본가의 1.25배 (5분 TTL 쓰기)
CACHE_READ = 0.30 # 기본가의 0.1배 (캐시 적중, 90% 할인)
OUTPUT = 15.0 # $ / 1M 토큰, 출력은 캐싱 할인 없음
cached_context = 20000 # 시스템 프롬프트 + 툴 정의 (캐시 대상)
dynamic_input = 300 # 매 턴 새로 들어가는 사용자 메시지 (캐시 불가)
output_tokens = 1500 # 매 턴 응답 길이
write_calls = 5 # TTL이 끊겨 다시 캐시를 써야 했던 요청
read_calls = 5 # 캐시가 살아있어 적중한 요청
def cost(price_per_mtok, tokens):
return price_per_mtok * tokens / 1_000_000
baseline = (
cost(BASE_INPUT, (cached_context + dynamic_input) * 10)
+ cost(OUTPUT, output_tokens * 10)
)
cached = (
write_calls * (cost(CACHE_WRITE, cached_context) + cost(BASE_INPUT, dynamic_input) + cost(OUTPUT, output_tokens))
+ read_calls * (cost(CACHE_READ, cached_context) + cost(BASE_INPUT, dynamic_input) + cost(OUTPUT, output_tokens))
)
print(f"캐싱 미적용 총비용: ${baseline:.4f}")
print(f"캐싱 적용 총비용: ${cached:.4f}")
print(f"실제 절감률: {(1 - cached/baseline) * 100:.1f}%")
캐싱 미적용 총비용: $0.8340
캐싱 적용 총비용: $0.6390
실제 절감률: 23.4%
캐시 읽기 토큰 단가만 보면 90% 할인이 맞지만, 쓰기 비용·비캐시 입력·출력 토큰이 섞이면서 청구서 기준 절감률은 23.4%로 나옵니다. write_calls와 read_calls 비율을 9:1로 바꾸면(캐시가 거의 끊기지 않는 경우) 절감률이 60%를 훌쩍 넘고, 반대로 응답 길이(output_tokens)를 3,000으로 늘리면 절감률이 15% 아래로 떨어집니다. 즉 25% 안팎이라는 숫자는 캐시 적중률이 절반 정도이고 출력 토큰 비중이 어느 정도 있는, 흔히 볼 수 있는 챗봇·에이전트 워크로드에서 나오는 값입니다.
Anthropic과 OpenAI, 캐싱 방식이 달라서 계산도 달라진다
절감률을 계산할 때 사용하는 모델의 캐싱 방식부터 확인해야 합니다. Anthropic Claude는 프롬프트에 cache_control 브레이크포인트를 직접 지정해야 하는 수동 방식이고, 캐시 쓰기에 추가 비용이 붙습니다. 반면 OpenAI는 2024년 10월부터 1,024토큰을 넘는 프롬프트에 대해 별도 설정 없이 자동으로 캐싱을 적용하며, 쓰기에 추가 요금을 부과하지 않고 적중 시 50% 할인만 적용합니다. 두 방식은 계산 공식 자체가 다릅니다.
| 항목 | Anthropic Claude | OpenAI (Automatic Prompt Caching) |
|---|---|---|
| 활성화 방식 | cache_control로 수동 지정 |
1,024토큰 이상이면 자동 적용 |
| 캐시 쓰기 비용 | 기본가의 1.25배(5분) / 2배(1시간) | 추가 비용 없음 |
| 캐시 적중 시 할인 | 기본가의 0.1배 (90% 할인) | 기본가의 0.5배 (50% 할인) |
| TTL | 5분(기본) / 1시간(확장, 베타) | 수 분~1시간, 트래픽에 따라 변동 |
| 출력 토큰 할인 | 없음 | 없음 |
같은 워크로드라도 Anthropic 쪽 계산은 “쓰기 페널티 vs 90% 할인”의 줄다리기이고, OpenAI 쪽은 페널티가 없는 대신 할인율 자체가 50%로 낮아서 상한선이 처음부터 다릅니다. 자세한 조건은 OpenAI 공식 프롬프트 캐싱 가이드에서 확인할 수 있습니다.
캐싱을 켰는데 왜 요금이 거의 그대로인가요?
가장 흔한 원인 세 가지는 다음과 같습니다. 첫째, 프롬프트가 모델별 최소 캐시 길이(대략 1,024~2,048 토큰)에 못 미치는 경우로, 이때는 애초에 캐시 자체가 생성되지 않고 매번 기본 단가로 청구됩니다. 둘째, cache_control 브레이크포인트를 컨텍스트의 앞부분(변하지 않는 부분) 끝에 정확히 걸지 않고 전체 프롬프트 뒤쪽에 걸어버린 경우로, 이러면 매 요청 프롬프트 내용이 조금만 달라져도 캐시가 통째로 무효화됩니다. 셋째, 세션 간 간격이 TTL(5분)보다 길어 매번 쓰기 단가로만 청구되는 경우로, 이때는 캐시를 켠 것이 오히려 기본 단가보다 25% 더 비싸게 작동하고 있을 수 있습니다. 이 경우 usage 응답의 cache_creation_input_tokens와 cache_read_input_tokens 비율을 직접 로그로 남겨 확인하는 것이 가장 확실합니다.
캐시 적중률을 직접 측정해야 진짜 절감률을 알 수 있습니다
프롬프트 캐싱의 90% 할인은 거짓이 아니지만, 그 숫자는 캐시에 적중한 토큰 하나에만 적용되는 단가입니다. 청구서 전체 절감률은 (1) 캐시 쓰기와 읽기 비율, (2) 캐시 대상 토큰과 매번 바뀌는 입력의 비율, (3) 할인되지 않는 출력 토큰의 비중, 이 세 가지에 의해 결정됩니다. 다음 단계로는 API 응답의 cache_creation_input_tokens / cache_read_input_tokens / output_tokens 값을 실제 서비스 로그에서 며칠치 뽑아, 위 예시 코드의 변수 자리에 실측값을 넣어 직접 절감률을 계산해 보는 것을 권합니다. 그래야 TTL을 5분에서 1시간으로 바꿔야 할지, 캐시 브레이크포인트 위치를 조정해야 할지에 대한 판단이 추측이 아닌 숫자에 근거하게 됩니다.
GPT·Claude·Gemini API 실제 월 비용 계산: 1만 요청이면 얼마 나올까 (+캐싱·배치 절감법)
