Prompt Cache 최소 토큰: 문서 값이 실제보다 1.4~2.4배 적다

한 고객이 우리 게이트웨이에서 prompt caching 이 모델 문서가 약속한 토큰 수에서는 동작하지 않는다고 알려왔다. 이를 재현한 뒤, 독립적인 두 번째 서빙 경로, 즉 가장 큰 AI 게이트웨이 중 하나로 모든 모델을 다시 돌려봤다. 같은 차이가 토큰 단위까지 그대로 재현됐다. 낙관적이었던 쪽은 특정 게이트웨이가 아니라 문서였다. 공개된 최소값은 캐시 적격 하한선일 뿐, 캐시 히트를 얻는 길이가 아니었다. auto-cache 계열에서는 이 둘이 1.4~2.4배 차이가 났다. OpenAI 의 실제 첫 히트 임계값은 문서상 1,024 토큰에 비해 약 1,456 토큰으로 측정됐고, Gemini 2.5 Flash 는 문서상 2,048 인데 실제로는 약 5,000 토큰에서 처음 캐시를 읽었다. 명시적 마커를 둔 위치에서만 캐시하는 Claude 는 모델별 문서 최소값에 몇 퍼센트 이내로 근접했다.

TL;DR

• OpenAI 가 문서에 적은 1,024 토큰 캐시 최소값은 실제 임계값보다 낮다. 두 경로에서 측정한 실제 값은 약 1,456 토큰이다.
• Gemini 2.5 Flash 는 문서상 2,048 이지만 실제로는 약 5,000 토큰에서 처음 읽었다. 약 2.4배 높은 값이다.
• Claude 의 명시적 cache_control 은 문서 최소값에 몇 퍼센트 이내로 근접했다 (Opus 는 1,073 대 1,024).
• GLM 5.2 와 DeepSeek V4 는 최소값을 공개하지 않고 약 800 토큰부터 읽었다. MiniMax M3 는 길이와 무관하게 대략 114 캐시 토큰을 보고한다.
• auto-cache 는 첫 읽기 전에 2~8회의 워밍업 호출도 필요하다.

모든 측정은 두 개의 서빙 경로, 즉 우리 게이트웨이와 가장 큰 독립 AI 게이트웨이 중 하나를 통해 진행했고, 두 경로가 일치할 때만 모델 동작으로 인정했다. 두 번째 경로를 쓴 이유는 원인 규명이다. 무관한 벤더의 스택에서 재현되는 차이라면 우리 문제가 아니라 모델의 문제다. 이 교차 검증은 OpenAI, Gemini, GLM 에서 깔끔하게 통했다. 세 모델 모두 두 경로에서, 같은 실제 임계값으로 캐시했다. 다만 모든 모델에 통하는 건 아니다. 그 두 번째 게이트웨이에서 open-weight 모델은 대부분 벤더의 prompt cache 를 구현하지 않는 GPU 호스트로 서빙되는데, 게이트웨이 자체의 엔드포인트 메타데이터가 프로바이더별로 이를 확인해 준다. 게다가 라우팅이 고정되지 않아 이 호스트들 사이를 오가면서 캐시 affinity 가 사라진다. 두 번째 경로로 확증할 수 없는 경우, 아래 수치는 각 벤더의 캐싱 API 에 직접 닿는 경로에서 얻은 값이다. 길이는 문자가 아니라 반환된 usage 로 보정한 각 모델 고유의 토큰 기준이다. 모든 조건에서 새 prefix 를 사용했고, 단순 히트 여부가 아니라 캐시 읽기가 발생한 첫 호출 인덱스를 기록했다.

문서에 적힌 값과 실제로 동작하는 값의 차이

문서에 적힌 최솟값은 프롬프트를 캐시할 수 있는 시점을 알려준다. 반면 실효 임계값은 반복된 프롬프트가 실제로 읽기(read)로 되돌아오는 길이를 말한다. 자동 캐시 계열에서는 이 둘이 같은 값이 아니다.

OpenAI 수치는 두 경로 모두에서 token 단위까지 정확히 맞았다. 1,356 token 프롬프트는 절대 읽기로 돌아오지 않았고, 1,456 token 프롬프트는 돌아왔다. 차이가 가장 큰 건 Gemini였다. 3,300 token까지 훑어본 sweep에서는 읽기가 하나도 없어서 캐시가 꺼진 것처럼 보였는데, sweep을 5,000 token까지 늘리자 두 경로 모두에서 같은 길이에 깔끔하게 읽기가 잡혔다. 문서상 2,048은 캐시 대상이 되는 하한선일 뿐, 읽기를 서빙하는 기준은 아니다.

이번 연구 전반에서 드러난 패턴은 이렇다. 명시적으로 표시하는 캐시는 스펙이 정확하고, 자동으로 이뤄지는 캐시는 그렇지 않다.

최솟값만이 문서에 없는 변수는 아니다

실효 임계값을 넘기는 건 필요조건이지 충분조건은 아니다. 자동 캐시 계열은 워밍업이 필요하다. 첫 읽기는 두 번째 호출이 아니라 그보다 뒤쪽 호출에서 잡힌다.

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

이건 비용 모델링에서 중요하다. 6,000 token 프롬프트는 Gemini의 문서상·실효 임계값을 모두 넘지만, 이 프롬프트를 두 번 보내고 끝내는 워크로드라면 두 번 다 정가를 낼 수 있다. 캐시가 아직 워밍되지 않았기 때문이다. 짧거나 버스트성 트래픽은 길이 조건을 충족해도 캐시되지 않은 요금을 낸다. “캐시되지 않는다”는 결론은 중간에 안정화 구간을 두고 최소 12번 반복 호출한 뒤에야 내렸다. sweep을 짧게 하면 Gemini에서 거짓 음성이 나왔고, 더 깊게 돌리자 그게 뒤집혔다.

캐시된 개수는 고정 블록 단위로 스냅된다는 점도 청구서를 대조할 때 알아둘 만하다. OpenAI는 128 token 블록, DeepSeek은 64 token 블록이다. 5,014 token 프롬프트에서 4,073 캐시 token이 읽힌 건 부분 prefix hit가 블록 경계로 반올림된 것이지 버그가 아니다.

직접 제어하는 캐시는 정확하다

Claude는 cache_control로 표시한 구간만 캐시하고, 그 제어에는 정확한 스펙이 따라온다. 우리가 테스트한 Anthropic의 주장은 모두 그대로 맞았다.

• 모델별 최솟값이 token 단위까지 정확하다. Opus 4.8과 Sonnet 5는 문서상 1,024에 대해 1,073 token에서 첫 읽기가 잡혔고, Haiku 4.5는 4,096에 대해 4,206에서 잡혔다. 이 작은 초과분은 드리프트가 아니라 블록 반올림이다.
• 읽기 요금은 input의 0.1x. 각 모델의 cold row에서 input 가격을 도출한 뒤, hit row에서 캐시 요금을 풀었다. Opus 4.8과 Haiku 4.5 모두 0.10으로 나와 문서상 배수와 일치했다.
• 5분 갱신, 읽기마다 무료. prefix를 심어두고 2분, 4분, 6분에 다시 읽었더니 매번 hit가 났다. 5분 창 안에서 읽기가 한 번 일어나면 추가 쓰기 없이 항목이 유지된다.
• 연쇄 무효화. 안정적인 system prefix와 tool 하나를 정의한 상태에서 그 tool의 description만 바꿨더니 그 아래에 있는 system 캐시가 전부 다시 써졌다. tool 정의를 바꾸면 system 캐시와 message 캐시가 무효화되며, 이는 문서상 계층 구조와 일치한다.

여기서 문서 간 충돌이 하나 드러났다. 서드파티 표에는 Claude Opus의 최솟값이 4,096 token으로 적혀 있었지만, 측정에서는 1,073에서 읽혔고 Anthropic 자체 값인 1,024가 맞는 수치다.

open-weight 계열은 대개 아무것도 문서화하지 않는다

위에서 다룬 계열들은 그래도 틀릴 여지가 있는 숫자라도 공개한다. open-weight 모델과 중국 연구소 모델은 최소 길이를 아예 공개하지 않는 경우가 대부분이라, 직접 측정하는 수밖에 없다. 히트가 발생했을 때 공개된 요율이 실제로 어떻게 맞아떨어지는지는 provider 캐시 비교에서 다뤘고, 여기서는 첫 read 가 나타나는 길이만 본다.

GLM 5.2 는 최소 길이를 공개하지 않으며, 양쪽 경로 모두 약 800 token 부터 64-token 블록 단위로 캐싱된다. 문서화된 어떤 계열보다도 낮은 하한이다. DeepSeek V4 역시 최소값을 공개하지 않고 같은 64-token 세분성으로 약 800 token 부터 read 가 잡히지만, 자체 캐싱 API 를 상대로 할 때만 그렇다. DeepSeek 문서는 캐시를 best-effort 로 규정하고 히트율을 보장하지 않는데, 중개 계층에서는 이 점이 그대로 드러난다. 다른 게이트웨이는 DeepSeek 를 여러 GPU 호스트를 통해 서비스하는데, 캐시를 구현한 것은 DeepSeek 자체 엔드포인트뿐이다. 따라서 그 엔드포인트에 고정되지 않은 라우팅에서는 read 가 전혀 반환되지 않는다.

MiniMax M3 는 보고되는 숫자 자체가 오해를 부르는 사례다. 문서상 최소값은 512 token 이지만, 200 에서 5,000 token 까지 모든 길이에서 첫 호출부터 약 114 캐시 token 이 일정하게 보고된다. 이 숫자는 prompt 길이를 따라가지 않고, 캐싱을 전혀 수행하지 않는 경로에서도 나타난다. 재사용된 양을 나타내는 신호가 아니라 모델 자체의 장부 기록일 뿐이다. 최신 OpenAI 모델이 반대 방향에서 가르쳐 준 교훈과 같다. usage token 필드와 실제 캐싱은 서로 어긋날 수 있으므로, 절감액이 중요하다면 token 수가 아니라 usage.cost 로 대조하라.

최신 모델은 규칙을 바꾸고 있다

예전 동작이 그대로 이어진다고 가정하기 전에, 문서 수준의 변화 두 가지를 짚어 둘 필요가 있다. GPT-5.6 계열에서 OpenAI 가이드는 캐시 쓰기 비용이 캐시되지 않은 입력 요율의 1.25배라고 명시한다. 이전 계열은 쓰기가 무료였다. 같은 가이드는 implicit 캐싱을 가장 최근 메시지에 breakpoint 를 두는 방식으로 설명하는데, 이는 여러 턴에 걸쳐 안정적인 system 블록을 prefix 캐싱하는 것과는 다른 형태다. 이 모델들에서 서로 다른 사용자 턴에 걸쳐 안정적인 prefix 를 재사용하려면, implicit 경로에 기대지 말고 명시적 breakpoint 로 표시하라. 쓰기 배수와 모델별 최소값을 직접 확인하라. 이제는 둘 다 계열마다 달라지는데, 문서 한 페이지로는 그 차이가 뭉뚱그려진다.

이걸로 무엇을 할 것인가

• 자기 환경에서 실제 임계값을 측정하라. 프롬프트 길이를 직접 자기 토큰 단위로 훑어가면서 cache read가 처음 반환되는 길이를 기록하라. 문서에 적힌 최소값이 hit가 시작되는 지점이라고 가정하지 마라.
• 워밍업을 비용에 반영하라. 자동 캐시 제공자라면, 새 prefix에 대한 처음 2~8회 호출은 비용 모델에서 캐시되지 않은 것으로 취급하라.
• 제공자가 명시적 마커를 지원하면 그걸 써라. Claude 의 cache_control 은 정확하고 검증 가능한 스펙을 준다. 최소값도, read rate 도, TTL 도, 무효화 규칙도 모두 알려져 있다. 이 예측 가능성은 믿을 수 없는 낮은 문서상 하한선보다 더 가치 있다.
• 새 모델 계열이 나오면 기준을 다시 잡아라. 이번 연구 기간에도 한 벤더의 라인업 안에서 최소값, write 가격, breakpoint 동작이 바뀌었다.

이 임계값 뒤에 있는 read rate, TTL, 키 규칙은 prompt caching 가이드에서 제공자별 메커니즘을 다룬다.

요약하면 이렇다. 문서상 최소값은 자격 하한선이지 hit 임계값이 아니다. 자동 캐시에서는 둘이 1.4~2.4배 차이가 난다. 당신의 청구서를 좌우하는 그 숫자를, 당신의 토큰으로, 당신의 트래픽에 대해 직접 확인하라.

← 블로그로 돌아가기