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

왜 Prompt Caching인가

Claude API는 cache_control 파라미터로 특정 프롬프트 구간을 서버 사이드에 캐싱한다. 캐시 히트 시 입력 토큰 비용이 기본 요금의 10% 수준으로 떨어진다(Claude 3.5 Sonnet 기준: 일반 $3/MTok → 캐시 히트 $0.30/MTok). 단, 캐시 미스 시 쓰기 비용 $3.75/MTok이 발생하므로 히트율이 낮으면 오히려 손해다. 히트율 80% 미만 시나리오에서는 caching을 적용하지 않는 것이 유리하다.

캐시 TTL은 현재 5분이다. 5분 내 동일 prefix로 재호출이 없으면 캐시가 소멸한다. 따라서 사용자가 드문드문 질의하는 챗봇보다, 배치 파이프라인이나 고빈도 RAG 시스템에 효과적이다.

Break Point 설계 원칙

캐시 효율은 cache_control break point를 어디에 두느냐에 달렸다.

규칙 1 — 변하지 않는 부분을 앞에: 시스템 프롬프트, 문서 컨텍스트, Few-shot 예시처럼 요청마다 동일한 구간을 캐시 대상으로 설정한다. 사용자 메시지처럼 매번 바뀌는 부분은 캐시 대상에서 제외한다.

규칙 2 — Break point는 최소화: break point가 많을수록 캐시 파편화가 발생한다. 보통 1~2개로 충분하다.

규칙 3 — 최소 토큰 요건 확인: 캐시 대상 구간이 1024 토큰 미만이면 캐싱이 적용되지 않는다(Claude 3 Haiku는 2048 토큰). 짧은 시스템 프롬프트만 캐싱하려다 실패하는 대표적 실수다.

import anthropic

client = anthropic.Anthropic()

# 공통 문서 컨텍스트 (변하지 않는 부분 → 캐시 대상)
SYSTEM_DOC = """당신은 내부 API 문서 전문가입니다.
[...수천 토큰 분량의 API 스펙 문서...]
"""

def query_with_cache(user_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"}  # break point
            }
        ],
        messages=[
            {"role": "user", "content": user_question}
        ]
    )
    usage = response.usage
    cache_hit = getattr(usage, "cache_read_input_tokens", 0)
    cache_write = getattr(usage, "cache_creation_input_tokens", 0)
    print(f"캐시 히트: {cache_hit}tok | 캐시 쓰기: {cache_write}tok")
    return response.content[0].text

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

실패 모드 3가지:

• cache_creation_input_tokens만 계속 올라가고 cache_read_input_tokens가 0이라면, TTL 내 재호출이 없거나 prefix가 미묘하게 달라진 것이다. 시스템 프롬프트에 동적 타임스탬프·UUID 삽입 여부를 점검하라.
• 멀티 테넌트 환경에서 테넌트별로 시스템 프롬프트가 다르면 캐시가 공유되지 않는다. 공통 prefix를 최대한 앞으로 빼고, 테넌트 전용 구간은 뒤에 배치하라.
• 캐시 비용 절감을 과신해 불필요하게 긴 컨텍스트를 구겨 넣는 경우, 캐시 쓰기 비용이 누적돼 오히려 비용이 증가한다.

운영 체크리스트:

• [ ] cache_read_input_tokens / (cache_read + input_tokens) 비율을 Datadog/CloudWatch에 메트릭으로 수집
• [ ] 히트율 < 70% 알람 설정
• [ ] 시스템 프롬프트 변경 배포 시 첫 N건 캐시 미스 비용 사전 추정
• [ ] 1024 토큰 미만 구간에 cache_control 설정 여부 린트 검사 CI 추가
• [ ] 고빈도(분당 10회 이상) 엔드포인트에만 caching 우선 적용, 저빈도는 비활성화