Prompt cache 쓰기 비용: 1.25x 할증은 언제 이득일까?

Prompt cache 쓰기는 TTL 안에 한 번만 다시 읽어도 비용을 회수한다. 쓰기에는 입력 요금의 1.25x, 읽기에는 0.1x가 청구된다. 따라서 한 번만 hit해도 두 번의 호출에 대한 비용이 25% 할증에서 32.5% 절감으로 바뀐다. 하지만 agent suite의 다섯 가지 시나리오 중 하나에서는 같은 할증으로 실제 비용이 6% 늘었다. 차이를 만드는 값은 traffic의 read:write 비율 하나다. 이 글에서는 청구서를 받기 전에 이 비율을 측정하는 방법을 다룬다. 아래 결과는 모두 Synthorai gateway의 실제 billing meter를 통해 측정했다. Agent 수치는 150개 episode로 구성된 suite에서, TTL과 clustering 결과는 salt를 적용한 전용 probe에서 얻었다.

TL;DR

• 명시적 cache 쓰기는 1.25x(5-minute TTL) 또는 2x(1-hour)로 청구된다. GPT-5.6의 breakpoint도 같은 1.25x/0.1x 구조로 수렴했다. 한 번만 다시 읽으면 손익분기점을 넘는다.
• Agent suite에서 할증의 순효과는 +6%(RAG, read:write 0.2)부터 -83%(batch, 15.7)까지였다.
• Cache hit는 Claude의 TTL을 무료로 갱신한다. Traffic이 꾸준하면 window마다가 아니라 idle gap마다 한 번만 쓰기 비용을 낸다.
• 암묵적 caching의 성능은 편차가 크다. GPT-5.5는 한 번 priming한 뒤 8번 중 7번 연속으로 hit했고, Gemini는 clustering해도 12번 중 1-3번만 hit했다. 어느 쪽도 쓰기 할증은 없다.

Cache 쓰기에는 실제로 얼마가 드는가?

비교 대상 provider의 요금 구조는 세 가지이며, 이 중 두 가지가 쓰기 비용을 청구한다. Claude의 명시적 caching은 기본 5-minute TTL의 cache 생성에 입력 요금의 1.25x, 1-hour tier에는 2x를 청구하며 읽기는 0.1x다. GPT-5.6은 명시적 breakpoint를 도입했으며 쓰기 1.25x, 읽기 0.1x로 multiplier가 같다. 업계에서 가장 큰 두 명시적 구현의 요금 구조가 동일해진 셈이다. 세 번째는 암묵적 caching(Gemini, Kimi, 5.6 이전 OpenAI model)이다. 쓰기 할증은 전혀 없고, provider에서 hit가 발생했을 때만 읽기 할인이 적용된다.

명시적 쓰기의 손익분기 계산은 간단하다. P token 길이의 prefix를 cache하지 않으면 정상 요금으로 P가 든다. Cache하면 첫 호출은 1.25P이고, TTL 안에서 다시 읽을 때마다 P 대신 0.1P가 든다. 한 번 다시 읽으면 두 호출의 합계는 1.35P다. Cache하지 않은 2P보다 32.5% 저렴하다. 이후 hit부터는 prefix 비용의 90%가 절감된다. 위험 요인은 할증 자체가 아니다. 한 번도 다시 읽지 않을 block을 쓰는 것이 문제이며, 이 위험은 workload 형태에 따라 달라진다.

쓰기 할증으로 손해를 보는 경우는?

Prefix가 반복되는 속도보다 더 자주 바뀔 때다. 다섯 가지 agent 시나리오에서 read:write token 비율을 측정했다. Model과 marker 적용 방식은 모두 동일했다. 그런 다음 쓰기 1.25x, 읽기 0.1x 요율로 caching의 순효과를 계산했다.

RAG 행을 기억해야 한다. 검색된 문서는 query마다 달라지므로, 매 호출마다 다음 호출에서 재사용할 수 없는 prefix를 다시 썼다. 다시 읽은 token 하나당 다섯 token을 쓴 셈이며, 1.25x 할증이 누적되어 순손실로 이어졌다. 설정 오류는 없었다. 이 workload는 구조상 쓰기 비용을 상각할 수 없었다. 해결책은 caching을 포기하는 것이 아니라 layer를 나누는 것이다. Query 간에 유지되는 system prompt와 tool definition만 표시하고, 검색된 문서는 마지막 breakpoint 뒤에 표시 없이 둔다. Timestamp, user name, 요청별 context처럼 자주 바뀌는 모든 항목에도 같은 원칙을 적용해야 한다. Prefix를 조용히 무효화하는 설정도 주의해야 한다. Turn 사이에 output_config.effort를 바꾸면 prompt가 다시 rendering되어 cache가 깨진다. 따라서 cache된 session 안에서는 effort를 일정하게 유지해야 한다. LangChain 분석에서도 framework 측에서 같은 실패 패턴이 나타났다. 올바른 부분만 표시하는 것만큼 전체를 표시하기도 쉽게 만든 builder가 원인이었다.

쓰기 비용을 실제로 얼마나 자주 다시 내는가?

TTL window마다가 아니라 idle gap마다 한 번이다. Hit가 TTL을 무료로 갱신하기 때문이다. Claude Opus 4.8에서 salt를 적용한 4,981-token prefix로 이를 확인했다.

4번째 호출은 최초 5-minute TTL을 훨씬 지났지만 정상적으로 읽혔다. 2번째와 3번째 호출이 각각 무료로 window를 갱신했기 때문이다. 7-minute 동안 요청이 없었을 때만 다시 써야 했다. 실무적으로는 호출 간격이 TTL보다 짧은 route라면 쓰기 할증은 일회성 비용이다. 5-minute tier가 사실상 만료 없는 cache처럼 동작한다. 1-hour tier는 다른 traffic을 위한 선택지다. 쓰기 비용은 2x이며, gateway를 통해 전용 ephemeral_1h_input_tokens bucket에 청구되는 것도 확인했다. 1.25x를 반복해서 내는 대신 2x를 한 번 내므로, 재쓰기를 한 번만 피할 수 있어도 이득이다. Idle gap이 5분에서 1시간 사이인 route에 적합하다. 1시간 넘게 요청이 없으면 어떤 tier도 실행 간 cache를 유지하지 못한다. Scheduled job은 한 번의 실행 안에서 벌어지는 일을 기준으로 비용을 잡아야 한다. 요청 하나만 보내는 cron은 쓰기로 얻는 이점이 없다. 반면 같은 prefix로 여러 요청을 fan-out하는 cron은 사실상 batch이며, caching도 batch와 똑같이 동작한다.

Traffic 형태를 조정해 암묵적 caching을 살릴 수 있는가?

전적으로 provider의 암묵적 cache에 달렸다. Best-effort의 성능 편차가 매우 크기 때문이다. 좋은 쪽에 속하는 GPT-5.5의 automatic caching은 안정적인 메커니즘처럼 동작했다. 한 번 priming한 항목은 2초 뒤 읽을 수 있었고, 두 개 salt에서 모두 첫 probe가 hit했다. 이어진 burst에서는 5,170-token prompt 중 4,864 token을 8번의 probe 가운데 7번 cache에서 읽었다. 이 과정에 쓰기 할증은 전혀 없었다. 같은 prefix를 두 번 보내는 것만으로 확실한 비용 절감이 가능했다. 반대편에는 Gemini 3.6 Flash가 있다. 같은 agent suite에서 명시적 caching은 Claude 입력 token의 77-78%를 처리했지만, 반복되는 prefix가 실제로 존재하는 workload에서도 Gemini의 암묵적 cache가 처리한 비율은 4%였다.

성능이 낮은 쪽을 개선하기 위해 같은 prefix의 호출을 모아 provider cache가 warm한 상태를 유지하도록 traffic을 조정해 봤다. Gemini 3.6 Flash에 12번 연속 호출하자 정확히 한 번 hit했다. 10번째 호출만 hit했고, 11번째는 다시 miss였다. 3-minute 간격으로 8번 호출했을 때는 hit가 하나도 없었다. 우연일 가능성을 배제하기 위해 두 번째 독립 request path와 Gemini 3.5 Flash에서도 clustered arm을 다시 실행했다. 각각 12번 중 3번과 1번 hit했으며, 긴 연속 hit는 없었다. Cache된 한 block은 두 path 모두 같은 4,073 token으로 돌아왔다. 동작 방식은 일관됐지만 확률은 그렇지 않았다.

Miss 비율의 원인 중 하나는 ingestion lag이며, 크기는 provider마다 다르다. GPT-5.5의 항목은 prime 후 2초 만에 읽을 수 있었지만, Gemini는 생성에 수십 초가 걸린다. 따라서 첫 호출 직후 이어지는 burst는 cache가 준비되기 전에 지나가 버린다. 실제로 모든 실행의 Gemini arm에서 4번째 호출 전에 hit한 사례는 없었다. Prefix를 한 번 priming하고 burst 전에 45초 기다리자 8번 중 3번 hit했다. Traffic shaping으로 얻은 가장 좋은 결과였다. 하지만 90초 기다린 뒤에는 8번 모두 miss였다. 다시 호출했을 때는 이미 항목이 사라진 상태였다. 며칠 전 같은 model에서 더 길게 warm-up을 수행했을 때는 hit가 유지됐으므로, 비율은 시간과 load에 따라서도 변한다. 생성 지연, 짧은 lifetime, 시간에 따른 변동을 함께 고려하면, 성능이 낮은 쪽에서 clustering은 hit 한 번이 세 번으로 늘어나는 정도의 도움만 준다. (테스트할 때는 호출 간격을 둔 probe와 prime 후 대기하는 arm을 함께 사용해야 한다. Prime 이후 간격을 단계적으로 늘려 생성 지연 자체도 측정해야 한다. 연속 probe로 측정되는 것은 cache가 아니라 요청 속도다.)

따라서 규칙은 메커니즘 단위가 아니라 provider 단위로 정해야 한다. Provider의 암묵적 cache가 GPT-5.5처럼 동작하는지, 즉 한 번 prime한 뒤 신뢰할 수 있는지 측정해야 한다. Gemini처럼 동작한다면 hit는 우연히 받은 할인으로 봐야 한다. Kimi K3는 둘 사이에 있다. 할증이 없고 최소 기준이 낮으며, 별도 설정 없이도 입력의 57-62%가 cache에서 처리됐다. 어느 방식이 유리한지 보여주는 사례도 있다. OpenAI는 측정 대상 중 가장 좋은 암묵적 cache를 갖고 있었지만, GPT-5.6에서는 명시적 breakpoint로 전환했다. Provider가 운에 따라 제공하던 할인을 고객이 직접 통제하는 marker로 바꾼 것이다.

어떤 workload가 할증을 상각할 수 있는가?

Read:write 비율과 idle gap을 기준으로 결정하면 된다. 둘 다 도입 전에 자체 usage record에서 확인할 수 있다.

측정 결과에서 얻은 마지막 두 가지 원칙이 있다. 첫째, hit가 자주 발생하는 것처럼 느껴지는지가 아니라 자체 usage itemization의 cache_read와 cache_creation을 비교해 caching을 판단해야 한다. RAG 시나리오는 cache에 적합해 보였지만 실제 측정값은 0.2였다. 둘째, 비율이 충분히 좋으면 할증은 반올림 오차 수준으로 작아진다. Suite 전체 수치인 read:write 3.5에서는 지금까지 지불한 모든 쓰기 비용을 포함해 prefix 비용이 64% 줄었다.

FAQ

RAG에 prompt caching을 사용할 가치가 있는가?

검색된 문서에는 가치가 없다. 측정 결과 RAG는 다시 읽은 token 하나당 다섯 token을 썼고, 1.25x 할증으로 6% 순손실이 발생했다. System prompt와 tool definition처럼 안정적인 layer만 cache하고, 검색된 content는 마지막 breakpoint 뒤에 둬야 한다. 전체 caching 가이드에서 prompt layering을 자세히 다룬다.

5-minute cache TTL과 1-hour cache TTL 중 무엇을 써야 하는가?

Session 길이가 아니라 idle gap을 기준으로 선택한다. Hit는 5-minute TTL을 무료로 갱신한다. 따라서 호출 간격이 5분 미만인 route는 다시 쓸 필요가 없고, 저렴한 tier가 계속 유지된다. Gap이 5분에서 1시간 사이라면 1-hour tier의 2x 쓰기 비용을 내는 편이 낫다. 1.25x 재쓰기를 한 번만 피할 수 있어도 이득이다. Gap이 1시간을 넘는다면 cache가 없는 것으로 보고 비용을 잡아야 한다.

암묵적 caching에도 쓰기 비용이 청구되는가?

아니다. 구조적으로도 청구할 수 없다. 쓰기 할증은 caller가 caching을 직접 선택할 때만 성립하므로 명시적 방식에만 존재한다. 예를 들면 Anthropic의 1.25x/2x multiplier, GPT-5.6의 breakpoint, Gemini의 token-hour당 비용처럼 명시적 cached-content API의 storage rent 구조가 있다. 측정한 모든 암묵적 구현(Gemini, Kimi, 5.6 이전 OpenAI)과 주요 공개 rate card(DeepSeek, Qwen, Grok)는 암묵적 caching에 읽기 할인만 적용한다. 차이는 신뢰성이다. GPT-5.5의 암묵적 cache는 priming한 probe 8번 중 7번 hit했지만, Gemini는 agent suite 입력의 4%만 처리했고 clustering도 거의 효과가 없었다. 안정적으로 받는 할인에 할증까지 없다면 가장 유리하다. 반면 무작위로 적용되는 무할증 할인은 직접 통제할 수 있는 소액 할증보다 가치가 낮다.

2026-07-25부터 2026-07-29까지 Synthorai gateway를 통해 측정했다. 시나리오별 read:write 비율은 호출별 cache itemization이 포함된 Claude arm agent episode 150개에서 산출했다. Gemini와 Kimi 비율은 각자 suite 실행 결과다. TTL 갱신 및 1-hour bucket probe는 claude-opus-4-8에서 salt를 적용한 4,981- 및 3,742-token prefix로 수행했다. 암묵적 cache probe는 gemini-3.6-flash 및 gemini-3.5-flash에서 salt를 적용한 약 6,800-token prefix를 사용해 clustered, spread, prime-and-wait arm으로 진행했고, gpt-5.5에서는 salt를 적용한 5,170-token prompt로 primed burst를 실행했다. 순효과 비율은 측정된 비율에 쓰기 1.25x, 읽기 0.1x multiplier를 적용해 계산했다. 요금과 cache 동작은 바뀔 수 있으므로 자체 usage record로 확인해야 한다.

← 블로그로 돌아가기