프롬프트 캐시 최소 길이, 문서보다 실제로는 1.4~2.4배 길다

한 고객이 우리 gateway에서 모델 문서에 명시된 token 수에 도달해도 프롬프트 캐시가 동작하지 않는다고 알려왔다. 문제를 재현한 뒤, 독립된 두 번째 serving 경로인 대형 AI gateway에서도 모든 모델을 다시 테스트했다. 두 경로에서 token 단위까지 동일한 차이가 재현됐다. 낙관적인 쪽은 특정 gateway가 아니라 문서였다. 공개된 최소값은 캐시 대상이 되기 위한 하한일 뿐, 실제 cache hit이 발생하는 길이가 아니다. 자동 캐시 계열에서는 두 값이 1.4~2.4배 차이 났다. OpenAI는 문서상 1,024 token이지만 실제 첫 hit 기준은 약 1,456 token이었다. Gemini 2.5 Flash는 문서상 2,048 token이지만 약 5,000 token부터 처음 캐시에서 읽었다. 명시적 marker를 지정한 위치만 캐시하는 Claude는 모델별 최소값이 문서와 수% 이내로 일치했다.

TL;DR

• OpenAI의 문서상 캐시 최소값은 1,024 token이지만, 두 경로에서 측정한 실제 기준은 약 1,456 token이었다.
• Gemini 2.5 Flash는 문서에 2,048 token으로 나와 있지만, 실제로는 약 5,000 token에서 처음 캐시를 읽었다. 약 2.4배 차이다.
• Claude의 명시적 cache_control은 문서상 최소값과 수% 이내로 일치했다(Opus 1,073 대 1,024).
• GLM 5.2와 DeepSeek V4는 최소값을 공개하지 않으며, 약 800 token부터 읽었다. MiniMax M3는 길이에 관계없이 약 114 cached token을 보고한다.
• 자동 캐시는 첫 read가 발생하기 전에 2~8회의 warm-up 호출도 필요하다.

모든 측정은 자체 gateway와 독립된 대형 AI gateway, 두 serving 경로에서 진행했다. 두 경로의 결과가 일치할 때만 모델의 동작으로 판단했다. 두 번째 경로의 목적은 원인을 구분하는 데 있다. 관련 없는 벤더의 stack에서도 같은 차이가 재현된다면, 문제는 우리 쪽이 아니라 모델에 있다. OpenAI, Gemini, GLM은 두 경로에서 동일한 실제 기준으로 캐시가 동작해 이 교차 검증을 통과했다. 하지만 모든 모델을 같은 방식으로 검증할 수 있는 것은 아니다. 두 번째 gateway에서 open-weight 모델은 주로 벤더의 프롬프트 캐시를 구현하지 않은 GPU host를 통해 제공된다. gateway의 endpoint metadata에서도 provider별로 이를 확인할 수 있다. routing을 고정하지 않으면 요청이 여러 host로 분산돼 cache affinity도 사라진다. 두 번째 경로에서 검증할 수 없는 경우, 아래 수치는 각 벤더의 자체 caching API에 연결되는 경로에서 측정했다. 길이는 문자 수가 아니라 반환된 usage를 기준으로 보정한 각 모델 고유의 token 수다. 각 실험군은 새로운 prefix를 사용했으며, 단 한 번의 hit 또는 miss가 아니라 처음 cache read가 발생한 호출 번호를 기록했다.

문서상 최소값과 실제 기준의 차이

문서에 나온 최소값은 prompt를 캐시할 수 있는 길이를 뜻한다. 실제 기준은 같은 prompt를 반복했을 때 실제로 cache read가 반환되기 시작하는 길이다. 자동 캐시 계열에서는 두 값이 같지 않다.

OpenAI의 측정값은 두 경로에서 token 단위까지 일치했다. 1,356-token prompt는 한 번도 cache read가 발생하지 않았지만, 1,456-token prompt에서는 발생했다. 차이가 가장 큰 모델은 Gemini였다. 처음에는 3,300 token까지 sweep했지만 read가 한 번도 없어 캐시가 꺼져 있는 것처럼 보였다. 범위를 5,000 token까지 늘리자 두 경로 모두 같은 길이에서 정상적으로 read가 발생했다. 문서의 2,048은 캐시 대상이 되는 하한이지, cache read가 제공되는 기준이 아니다.

전체 실험에서 일관된 패턴이 나타났다. 명시적으로 지정하는 캐시는 문서가 정확했고, 자동으로 동작하는 캐시는 그렇지 않았다.

문서에 없는 변수는 최소값뿐이 아니다

실제 기준을 넘는 것은 필요조건일 뿐 충분조건은 아니다. 자동 캐시 계열에는 warm-up이 필요하다. 첫 read는 두 번째 호출이 아니라 그 이후에 발생한다.

• OpenAI: 2~3번째 호출에서 첫 read.
• Gemini: 4~8번째 호출에서 첫 read.

비용을 모델링할 때 이 특성을 반영해야 한다. 6,000-token prompt는 Gemini의 문서상 최소값과 실제 기준을 모두 넘는다. 그래도 두 번만 전송하고 더 이상 호출하지 않는 workload라면 두 번 모두 전체 요금을 낼 수 있다. 아직 캐시가 warm-up되지 않았기 때문이다. 길이 조건을 충족하더라도 짧거나 burst 형태인 traffic에는 uncached 요금이 적용된다. 최소 12번 반복 호출하고 호출 사이에 안정화 시간을 둔 뒤에야 “캐시되지 않는다”고 판단했다. 더 짧게 sweep했을 때 Gemini에서 false negative가 나왔지만, 반복 횟수를 늘리자 결과가 뒤집혔다.

Cached token 수도 고정 block 단위로 맞춰진다. 청구 내역을 대조할 때 알아둘 필요가 있다. OpenAI는 128-token block, DeepSeek는 64-token block을 사용한다. 5,014-token prompt에서 cached token이 4,073으로 나왔다면, 이는 block 경계에 맞춰 반올림된 부분 prefix hit이지 bug가 아니다.

직접 제어하는 캐시는 문서와 정확히 일치한다

Claude는 cache_control로 지정한 segment만 캐시하며, 관련 사양도 정확하다. 테스트한 Anthropic의 설명은 모두 실제 동작과 일치했다.

• 모델별 최소값이 token 단위로 일치한다. Opus 4.8과 Sonnet 5는 문서상 1,024 token에 대해 1,073 token에서 처음 읽었고, Haiku 4.5는 4,096 token에 대해 4,206 token에서 처음 읽었다. 이 작은 차이는 기준의 변동이 아니라 block rounding 때문이다.
• Read 요율은 input의 0.1x다. 각 모델의 cold row에서 input 가격을 계산한 다음, hit row로 cached 요율을 역산했다. Opus 4.8과 Haiku 4.5 모두 0.10으로 나와 문서의 multiplier와 일치했다.
• 5분 TTL이며, read할 때마다 무료로 갱신된다. Prefix를 기록한 뒤 2분, 4분, 6분 시점에 다시 읽었고 매번 hit가 발생했다. 각 5분 window 안에서 한 번 읽으면 추가 write 비용 없이 entry의 수명이 연장된다.
• 연쇄 무효화가 적용된다. 안정적인 system prefix와 tool 하나를 정의한 상태에서 tool의 description만 변경하자, 그 아래에 있는 system cache 전체가 다시 작성됐다. Tool definition을 변경하면 system cache와 message cache가 무효화되며, 이는 문서의 계층 구조와 일치한다.

문서끼리 상충하는 사례도 하나 확인했다. 한 third-party 표에는 Claude Opus의 최소값이 4,096 token으로 나와 있었지만, 실제로는 1,073 token에서 read가 발생했다. Anthropic 자체 문서의 1,024가 올바른 값이다.

Open-weight 계열은 대부분 아무 기준도 공개하지 않는다

앞에서 다룬 계열은 틀린 값이라도 최소한 숫자는 공개한다. Open-weight 모델과 중국 연구소 계열 모델은 대부분 최소값 자체를 공개하지 않아 직접 측정하는 수밖에 없다. Hit가 발생한 뒤 공개 요율과 실제 요율이 어떻게 일치하는지는 provider별 캐시 비교에서 다뤘다. 여기서는 첫 read가 발생하는 길이만 본다.

GLM 5.2는 최소 길이를 공개하지 않지만, 두 경로 모두 약 800 token부터 64-token block 단위로 캐시됐다. 문서에 최소값이 명시된 어떤 계열보다도 하한이 낮았다. DeepSeek V4도 최소값을 공개하지 않으며 약 800 token부터 같은 64-token 단위로 read가 발생했지만, 자체 caching API에서만 동작했다. DeepSeek 문서에는 캐시가 hit rate를 보장하지 않는 best-effort 방식이라고 나와 있으며, 중개 gateway에서는 실제로 그렇게 보인다. 다른 gateway는 여러 GPU host를 통해 DeepSeek를 제공하며, 이 중 DeepSeek 자체 endpoint만 캐시를 구현한다. 따라서 해당 endpoint로 routing이 고정되지 않으면 read가 전혀 반환되지 않는다.

MiniMax M3는 보고되는 숫자 자체가 오해를 부르는 사례다. 문서에는 최소값이 512 token으로 나와 있지만, 200~5,000 token의 모든 길이에서 첫 호출부터 약 114 cached token이라는 고정값을 보고한다. 이 숫자는 prompt 길이에 따라 변하지 않으며, caching을 전혀 수행하지 않는 경로에서도 나타난다. 재사용된 양을 나타내는 신호가 아니라 모델 자체의 bookkeeping 값이다. 최신 OpenAI 모델도 반대 방향에서 같은 교훈을 준다. Usage token field와 실제 caching이 일치하지 않을 수 있으므로, 절감액이 중요하다면 token 수가 아니라 usage.cost를 기준으로 대조해야 한다.

최신 모델에서는 규칙이 달라지고 있다

과거 동작이 그대로 이어질 것이라고 가정하기 전에 문서상 변경 두 가지를 확인해야 한다. OpenAI 가이드에 따르면 GPT-5.6 계열의 cache write 비용은 uncached input 요율의 1.25x다. 이전 계열에서는 write가 무료였다. 같은 가이드에서는 implicit caching을 최신 message에 breakpoint를 두는 방식으로 설명한다. 여러 turn에서 안정적인 system block의 prefix를 캐시하는 방식과는 형태가 다르다. 이 모델에서 서로 다른 user turn 사이에 안정적인 prefix를 재사용하려면 implicit 경로에 의존하지 말고 명시적 breakpoint를 지정해야 한다. Write multiplier와 최소값은 모델별로 확인해야 한다. 이제 두 값 모두 같은 벤더 안에서도 계열마다 다르지만, 하나의 문서 페이지에서는 이런 차이가 드러나지 않는다.

실무 적용 방법

• 자체 환경에서 실제 기준을 측정하라. 자체 token 기준으로 prompt 길이를 sweep하고, cache read가 처음 반환되는 길이를 기록한다. 문서상 최소값부터 hit가 시작된다고 가정하면 안 된다.
• Warm-up을 비용에 반영하라. 자동 캐시 provider의 새 prefix는 처음 2~8회 호출까지 uncached라고 가정해 비용을 계산한다.
• Provider가 명시적 marker를 지원한다면 우선 사용하라. Claude의 cache_control은 최소값, read 요율, TTL, 무효화 규칙이 모두 명확하고 검증 가능했다. 신뢰할 수 없는 낮은 문서상 하한보다 이런 예측 가능성이 더 가치 있다.
• 새 모델 계열이 나오면 기준을 다시 측정하라. 이번 실험 기간에만 한 벤더의 lineup 내에서 최소값, write 가격, breakpoint 동작이 달라졌다.

이 기준과 함께 고려해야 할 read 요율, TTL, keying 규칙은 프롬프트 캐시 가이드에 provider별로 정리했다.

요약하면 문서상 최소값은 캐시 대상이 되는 하한이지, hit가 시작되는 기준이 아니다. 자동 캐시에서는 두 값이 1.4~2.4배 차이 난다. 실제 비용을 결정하는 값을 자체 token과 실제 traffic으로 검증해야 한다.

← 블로그로 돌아가기