Prompt Caching으로 반복 추론 비용 70% 절감하기

캐시 앵커 위치가 전부다

prompt caching은 cache_control: {type: 'ephemeral'} 마커를 기준으로 그 이전 전체 prefix를 캐싱한다. 마커를 system prompt 끝에 두면 매 턴마다 시스템 프롬프트를 재사용한다. 반면 마커를 user 메시지 중간에 두면 캐시 키가 매번 달라져 캐시 미스만 반복된다.

최적 배치 원칙:

• 정적 콘텐츠(시스템 프롬프트, 대형 문서, few-shot 예시)를 앞에 집중
• cache_control 마커는 정적 블록의 마지막 content 항목에만 선언
• 동적 사용자 입력은 항상 마커 이후에 위치

import anthropic

client = anthropic.Anthropic()

SYSTEM_DOC = "..." * 500  # 대형 정책 문서, ~10만 토큰

def ask(question: str) -> str:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_DOC,
                "cache_control": {"type": "ephemeral"},  # 정적 블록 끝
            }
        ],
        messages=[{"role": "user", "content": question}],
    )
    usage = response.usage
    print(f"cache_read={usage.cache_read_input_tokens}, "
          f"cache_write={usage.cache_creation_input_tokens}")
    return response.content[0].text

# 첫 호출: cache_write 발생 (1.25× 비용)
# 이후 호출: cache_read 발생 (0.1× 비용)
ask("환불 정책 요약해줘")
ask("배송 기간은?")

수치로 보는 트레이드오프

| 시나리오 | 입력 토큰 비용 배수 | 지연 변화 | |---|---|---| | 캐시 미스 (write) | 1.25× | 기준 | | 캐시 히트 (read) | 0.10× | -50~85% | | 마커 위치 오류 | 1.25× 반복 | 기준보다 나쁨 |

cache TTL은 5분. 트래픽이 5분당 1회 미만인 엔드포인트에는 적용 실익이 없다. 최소 손익분기 호출 수: write_cost / (base_cost - read_cost) ≈ 2.5회 이상이면 무조건 이득.

실패 모드 & 운영 체크리스트

실패 모드

1. 동적 타임스탬프·UUID를 정적 블록 내부에 삽입 → 매번 캐시 미스
2. few-shot 예시를 user 턴에 분산 배치 → 앵커 이후라 캐싱 안 됨
3. 멀티 테넌트 환경에서 테넌트별 system을 동적으로 prepend → 공유 prefix 없음

운영 체크리스트

• [ ] usage.cache_read_input_tokens > 0 로그 확인 (첫 배포 후 즉시)
• [ ] 캐시 히트율 = read / (read + write) → 목표 80% 이상
• [ ] 정적 블록 변경 시 write 급증 알람 설정 (CloudWatch / Datadog)
• [ ] 5분 TTL 고려해 warm-up 요청 스케줄러 운영 (트래픽 저조 시간대)