프롬프트 캐싱

프롬프트 캐싱 (Prompt Caching)

반론: 대화 중간에 모델을 바꾸는 라우터는 프롬프트 캐시를 버리는 게 아니냐?

측정 결과: 그렇지 않아요. 라우터 + 캐싱은 고정 모델 하나에 캐싱만 하는 것보다 모든 데이터셋에서 더 저렴합니다.

• 전환은 축출(eviction)이 아니에요. 세션이 이전에 사용했던 모델로 돌아가면 캐시는 여전히 그곳에 있습니다.
• 라이브 게이트웨이 트래픽에서 실제 전환-복귀 4,684건: 5분 TTL에서 97.4%, 1시간 TTL에서 99.3%가 캐시가 따뜻한 것을 발견했어요.
• 비싼 실수는 반대쪽이에요. 캐싱을 끈 라우터는 고정 모델 하나에 캐싱하는 것보다 약 4배 비쌉니다.
• 절감 회계는 이를 정직하게 다룹니다. all-frontier 기준선은 지속되는 턴에서 따뜻한 캐시로 가격을 매기고, 전환 후의 새 캐시 쓰기는 절감에 부정적으로 계산됩니다. Reported savings 문서 참고.

Prompt Caching Works with Auto Router — 5개 데이터셋, 캐싱 유무별 데이터셋당 비용, 전환-복귀 측정, 구성.

Session affinity and deployment affinity — 원할 때 대화를 한 모델과 한 배포에 고정하는 두 핀.

그래도 고정(pin)해야 할 때

• session_affinity는 기본적으로 꺼져 있고, 이것이 대부분 라우터에 올바른 설정이에요. 위 숫자들은 캐시를 위해 필요하지 않다는 것을 보여주며, 고정은 이후 턴을 더 낮은 티어로 라우팅하는 절감을 포기하게 합니다.
• 티어 전환이 클라이언트가 의존하는 동작을 바꿀 때 켜세요. 두 종류의 경우:
  • 히스토리의 프로바이더 상태. 한 모델이 만든 히스토리는 다른 모델에서 실패할 수 있어요. Anthropic thinking 블록이나 cache_control 마커가 비-Anthropic 티어로 재생되거나, 프로바이더 간 다른 tool-call 형식. 고정은 세션을 히스토리를 만든 모델에 유지시킵니다.
  • 사용자가 볼 수 있는 일관성. 각 모델은 고유한 스타일이 있어요. 여러 턴에 걸쳐 레이아웃·형태·컴포넌트를 생성하는 디자인 워크플로는 모든 턴이 같은 모델에서 나올 때만 한 가지 모습을 유지합니다. 같은 목소리를 유지해야 하는 글쓰기 어시스턴트도 같은 경우예요.
• 단일 계열 사다리(single-family ladders)는 거의 필요 없어요. 모든 티어가 같은 프로바이더(전부 Claude, 전부 GPT)일 때 히스토리는 깔끔하게 재생되고 위 캐시 측정이 적용됩니다. 꺼두고 후속이 아래로 라우팅되게 하세요.
• 뒤에 여러 배포가 있는 티어는 deployment_affinity와 router_settings의 prompt_caching 사전 호출 검사도 필요해요. 그래야 지속되는 턴이 캐시를 보관한 배포로 돌아갑니다.
• 둘 다 함께: 로드 밸런싱이 있는 코딩 에이전트.

로드 밸런싱 배포 간 캐싱

라우터와 별개로, prompt_caching 사전 호출 검사는 같은 모델이 배포 또는 AWS 계정에 걸쳐 로드 밸런싱될 때 Anthropic 캐싱이 계속 동작하게 합니다.

Claude Code: prompt cache routing — 중복 배포 간에 prompt_caching 사전 호출 검사를 활성화하고 요청 로그에서 캐시 읽기를 확인하세요.

출처: 문서

더 알아보기 (Learn more)

• Auto Router
• Recommended Configurations
• Public Benchmarks