비용, Latency, 그리고 Cache 비대칭성

들어간다고 공짜는 아니야

context가 커지면 prefill 부담이 커져. 모형이 첫 token을 뱉기 전에 그 긴 prefix를 다 처리해야 하거든. provider가 거대한 window를 지원한다고 해도, 사람이 옆에서 기다리는 협업에는 못 쓸 만큼 느려질 수 있어. prefill 연산은 token 수에 거의 제곱으로 붙어서, 1M token 요청이 200K보다 5배 느린 게 아니라 훨씬 더 나빠.

비용이 어긋나는 지점 셋

1. input과 output — output은 보통 input의 3-5배 값이야. 2. cached와 fresh — cached input이 fresh보다 10-90% 싸 (Anthropic cached read는 90%쯤 깎이고, OpenAI랑 Gemini도 비슷한 할인 구간이 있어). 3. 기본 구간과 확장 구간 — long-context 문턱(보통 200K)을 넘으면 token 단가가 뛴다.

숫자로 보면

50K token짜리 코드베이스를 훑고 8K token짜리 피드백을 뽑는다고 해보자. 예시용 Sonnet 가격($3/M input, $15/M output, $0.30/M cached)으로 계산하면 이래. 한 방에 끝내면 $0.27. cache 없이 10번 더 주고받으면 약 $4.70. prompt caching을 켜고 10번 주고받으면 약 $1.60. 같은 대화인데 3배 싸. prefix를 재사용할 수 있게 짜놓은 것만으로.

대화형이냐 배치냐

거대한 context는 한 번 돌리고 마는 분석에는 딱 맞고, 빡빡한 편집 루프에는 최악이야. 사람이 실시간으로 붙어 있으면 반응 속도 자체가 품질의 일부거든. 배치 작업은 느려도 봐주지만, 대화형 session은 안 봐줘.

Code

비용 모양 스케치·python

scenarios = {
  "single_shot_50k":          {"input": 0.150, "output": 0.120, "total": 0.27},
  "ten_turns_no_cache":       {"input": 3.50,  "output": 1.20,  "total": 4.70},
  "ten_turns_with_caching":   {"input": 0.40,  "output": 1.20,  "total": 1.60},
}
# Caching is the single biggest cost lever after prompt design.

stable prefix와 variable tail 가려내기·yaml

stable_prefix:
  - system rules
  - tool schemas
  - reusable examples
  - corpus snippets you re-read each turn
variable_tail:
  - this turn's user question
  - latest diff
  - latest tool result
  - timestamp (if truly needed)

Exercise

반복해서 돌리는 워크플로 하나 골라봐. 같은 repo를 놓고 질문을 여러 번 던지는 것 같은 거. stable prefix랑 매번 바뀌는 variable tail을 가려내고, 20번 주고받을 때 caching이 있을 때랑 없을 때 비용을 어림해봐.

Hint

stable prefix는 규칙, tool schema, 자료. variable tail은 이번 turn 질문, 최신 diff, 방금 돌린 명령 결과.