iBetter Books
수정

프롬프트 캐싱과 비용 최적화

긴 시스템 프롬프트, 큰 도구 정의, 반복 참조하는 문서를 매 호출마다 다시 처리하는 것은 낭비다. 프롬프트 캐싱은 자주 재사용되는 입력 앞부분(프리픽스)을 서버에 캐시해 두고, 다음 호출에서 같은 프리픽스를 다시 보내면 처리 결과를 재사용한다. 효과는 두 가지다. 캐시에서 읽은 토큰은 단가가 크게 낮아져(읽기 비용은 기본 입력의 약 10퍼센트 수준) 비용이 줄고, 재처리를 건너뛰므로 첫 토큰까지의 지연도 단축된다. 시험은 "긴 시스템 프롬프트를 가진 에이전트의 비용을 줄이려면" 같은 시나리오에서 캐싱을 정답으로 배치한다.

캐싱은 cache_control 블록으로 캐시 분기점(breakpoint)을 지정해 켠다. 분기점을 둔 콘텐츠 블록까지의 프리픽스 전체가 캐시 대상이 된다. 핵심 규칙 몇 가지를 정확히 외워야 한다. 첫째, 캐시는 정확한 프리픽스 일치로만 적중한다. 캐시 분기점 이전의 내용이 토큰 하나라도 달라지면 캐시는 무효화되어 새로 생성된다. 둘째, 프롬프트는 도구 정의(tools), 시스템 프롬프트(system), 메시지(messages) 순서로 구성되며 캐시도 이 순서를 따른다. 셋째, 캐시 대상 프리픽스에는 최소 토큰 요건이 있다(대부분의 모델에서 약 1024 토큰, 더 작은 모델은 약 2048 토큰). 그보다 짧으면 분기점을 둬도 캐시되지 않는다. 넷째, 한 요청에 캐시 분기점은 최대 네 개까지 둘 수 있다.

가장 자주 출제되는 함정은 캐시 무효화다. 매 호출마다 값이 바뀌는 동적 내용(예: 현재 시각, 사용자별 변수, 요청마다 다른 컨텍스트)을 캐시하려는 프리픽스 앞쪽에 두면, 프리픽스가 매번 달라져 캐시는 절대 적중하지 않는다. 그래서 배치 순서가 결정적이다. 변하지 않는 것을 앞에, 자주 변하는 것을 뒤에 두어야 한다. 안정적인 시스템 지침과 도구 정의를 맨 앞에 두고 cache_control을 그 뒤에 걸며, 매번 달라지는 사용자 입력은 캐시 분기점 뒤쪽 메시지에 배치하는 것이 정석이다. "동적 데이터를 시스템 프롬프트 맨 앞에 넣고 캐싱을 적용했다"는 선택지는 전형적인 오답이다.

%% 프롬프트 캐싱 배치 (안정적인 것 앞, 변하는 것 뒤) flowchart LR T["tools\n도구 정의 (안정)"] --> S["system\n시스템 지침 (안정)"] S --> CC{"cache_control\n캐시 분기점"} CC --> M["messages\n사용자 입력 (가변, 캐시 뒤)"] CC -. "여기까지 프리픽스 캐시" .- S

비용 구조도 시험 포인트다. 캐시는 공짜로 만들어지지 않는다. 캐시를 처음 생성(write)할 때는 기본 입력보다 단가가 높다(5분 TTL 기준 약 1.25배, 1시간 TTL은 그보다 더 높음). 대신 이후 읽기(read)는 매우 저렴하다. 따라서 같은 프리픽스를 충분히 여러 번 재사용해야 본전을 넘어 이득이 된다. 한 번 쓰고 마는 프롬프트에 캐싱을 거는 것은 오히려 손해다. TTL은 두 가지로, 기본 5분(5m)과 연장 1시간(1h)이며, ephemeral 타입으로 지정한다. 캐시는 마지막 적중 시점부터 TTL이 갱신되므로, 호출 간격이 TTL보다 짧게 이어지면 캐시가 살아 있다. 호출이 드물면 짧은 TTL은 만료되어 매번 재생성 비용만 무는 결과가 된다.

효과 검증은 추측이 아니라 측정으로 한다. 응답 usage의 cache_creation_input_tokens는 이번에 새로 캐시한 토큰 수, cache_read_input_tokens는 캐시에서 읽어 절약한 토큰 수다. read 값이 호출마다 꾸준히 잡히면 캐싱이 제대로 동작하는 것이고, creation만 계속 발생하고 read가 0이면 프리픽스가 매번 깨지고 있다는 신호다. 이 두 필드를 보지 않고 "캐싱을 켰으니 됐다"고 판단하는 것은 아키텍트의 태도가 아니다.

정리

  • 프롬프트 캐싱은 재사용되는 프리픽스를 캐시해 비용(읽기 약 10퍼센트 단가)과 지연을 줄인다. cache_control 분기점으로 켠다.
  • 캐시는 정확한 프리픽스 일치로만 적중한다. 분기점 이전이 조금이라도 바뀌면 전체 무효화된다. 변하지 않는 것을 앞, 변하는 것을 뒤에 둔다.
  • 순서는 tools → system → messages이며, 최소 약 1024 토큰(작은 모델은 약 2048) 이상, 분기점은 최대 4개다.
  • 캐시 생성은 기본 입력보다 비싸므로(5m 약 1.25배) 충분히 재사용해야 이득이다. TTL은 5m·1h이고 적중 시 갱신된다.
  • cache_read_input_tokens와 cache_creation_input_tokens로 캐시 적중을 측정해 효과를 검증한다.