AI API 가격표를 보면 이제 Input, Output만 있는 경우가 드뭅니다. Cached input, Cache write 같은 열이 같이 보입니다.
처음에는 복잡해 보이지만 반복 작업에서는 이 차이가 꽤 큽니다.
반복되는 앞부분이 비싸게 느껴지는 이유
예를 들어 agent가 매 요청마다 다음을 보낸다고 해봅시다.
System instructions 10K
Repository summary 30K
Policies / docs 40K
Current user message 1K
-----------------------------
Total 81K
사용자 메시지는 1K밖에 안 바뀌는데 매번 80K 이상의 공통 context가 들어갑니다.
Prompt caching은 이런 반복 prefix를 다시 처리하는 비용을 줄이는 방식입니다.
Cache read와 cache write를 분리해서 보세요
OpenAI GPT-6 계열 가격표에는 일반 input, cached input, cache write가 별도로 표시됩니다.
핵심 구조는 다음과 같습니다.
첫 요청
→ cache 생성 비용 포함 가능
후속 요청
→ 동일한 cached prefix를 더 낮은 단가로 재사용
따라서 요청이 한 번뿐이라면 caching의 이점이 작거나 없을 수 있습니다. 반복 횟수가 늘어날수록 의미가 커집니다.
CodeBridge Mini Lab: Break-even을 직접 계산하기
가정:
공통 context: 100,000 tokens
변하는 input: 2,000 tokens
반복 횟수: N
두 방식을 비교합니다.
A. 매번 uncached input
cost_A = N × 102K × normal_input_rate
B. 첫 요청 cache write + 이후 cache hit
cost_B = first_write + (N-1) × cached_rate + changing_input
실제 모델별 가격을 넣어 N을 1, 2, 5, 10, 50으로 바꾸면 어느 시점부터 이득인지 보입니다.
간단한 Python으로도 계산할 수 있습니다.
for n in [1, 2, 5, 10, 50]:
print(n)
핵심은 정확한 숫자를 외우는 것이 아니라 내 요청 패턴의 반복률을 보는 것입니다.
Cache가 잘 안 먹히는 구조도 있습니다
매 요청마다 prompt 앞부분이 크게 바뀌면 재사용률이 낮아집니다.
나쁜 구조:
[현재 시간]
[동적으로 바뀌는 user data]
[긴 고정 문서]
[system instructions]
고정 영역 앞에 변동 영역이 많이 들어가면 cache-friendly한 prefix를 만들기 어렵습니다.
가능하다면 긴 고정 지침과 문서를 안정적인 구조로 유지하고, 자주 변하는 정보는 별도 위치에 두는 편이 관리하기 쉽습니다.
Caching은 RAG와 경쟁하지 않습니다
RAG로 context를 줄이고, 남은 공통 지침을 cache할 수도 있습니다.
Retrieval
→ 필요한 문서만 선택
→ 반복 system/tool instructions는 cache
→ 모델 호출
둘은 비용 최적화의 서로 다른 층입니다.
Cost per Token보다 Cost per Workflow
Prompt caching을 볼 때도 토큰 가격만 보지 마세요.
cache 때문에 prompt 구조를 지나치게 복잡하게 만들어 agent 실패율이 높아지면 전체 비용은 오히려 커질 수 있습니다.
그래서 최종 지표는 다음이 좋습니다.
총 workflow 비용
──────────────
성공한 작업 수
결론: 반복되는 긴 입력이 있다면 cache를 비용 모델에 넣어야 합니다
짧은 chatbot에서는 차이가 작을 수 있습니다. 하지만 repository agent, 문서 분석, 긴 system prompt처럼 같은 context를 수십 번 재사용한다면 cached input 가격은 모델 선택만큼 중요할 수 있습니다.
가격표를 볼 때 이제 세 줄을 같이 보세요.
Input
Cached input
Cache write
그리고 실제 반복 횟수로 계산해보는 것이 가장 정확합니다.