LLM 프롬프트 캐싱: API 비용 90% 절감 (주요 3개 제공업체 모두)

LLM 프롬프트 캐싱: API 비용 90% 절감 (주요 3개 제공업체 모두)

LLM 프롬프트 캐싱은 API 호출 간에 이전에 처리된 토큰을 재사용할 수 있게 해 주어, 입력 비용을 최대 **90%**까지 절감하고 첫 번째 토큰 생성 시간(TTFT)을 최대 **85%**까지 단축시킵니다. 매 요청마다 동일한 시스템 프롬프트, 도구 정의 또는 퓨샷 예제를 전송한다면, GPU가 이미 수행한 작업에 대해 정가를 지불하고 있는 셈입니다.

이 가이드에서는 다른 어떤 가이드에서도 다루지 않는 방식으로, 세 가지 SDK 모두에서 구현된 동일한 챗봇을 통해 OpenAI, Anthropic, Gemini를 비교합니다. 또한 Anthropic의 2026년 2월 자동 캐싱 업데이트, 실제 달러 금액이 포함된 프로덕션 비용 시나리오, 그리고 캐시 히트율을 은연중에 파괴하는 안티패턴들에 대해서도 살펴봅니다.

한눈에 보는 주요 3개 제공업체 요약

구현 세부 사항으로 들어가기 전에 전체 비교표를 확인하세요. 사용 중인 제공업체가 이미 정해져 있다면 해당 섹션으로 건너뛰세요. 평가 중이라면 이 표 하나로 10초 만에 모든 것을 파악할 수 있습니다.

핵심 요약: OpenAI는 가장 간단합니다(설정 zero, 50% 할인). Anthropic은 가장 깊은 할인(90%)과 가장 강력한 제어 기능을 제공합니다. Gemini는 설정 가능한 TTL과 2.5+ 모델에서의 암시적 캐싱을 제공하며, Anthropic과 비슷한 수준의 할인을 제공합니다.

LLM 프롬프트 캐싱은 어떻게 작동하나요?

프롬프트 캐싱을 효과적으로 사용하기 위해 트랜스포머 내부 구조를 깊이 이해할 필요는 없습니다. 하지만 한 가지 개념은 반드시 이해해야 합니다. 바로 **접두사 매칭(prefix matching)**입니다.

60초 안에 이해하는 KV 캐시

LLM이 프롬프트를 처리할 때 모든 토큰에 대한 어텐션 상태(키-값 쌍)를 계산합니다. 이러한 KV 캐시 항목이 비용이 많이 드는 부분으로, GPU 메모리와 연산 시간을 소모하는 주범입니다. 프롬프트 캐싱은 이러한 계산된 상태를 저장하여, 동일한 접두사를 가진 다음 요청이 재계산을 완전히 건너뛸 수 있도록 합니다.

여기서 핵심 단어는 *접두사(prefix)*입니다. 캐시는 프롬프트의 시작 부분부터 앞으로 매칭됩니다. 처음 2,000개의 토큰이 캐시된 항목과 일치하지만 2,001번째 토큰이 다르다면, 앞의 2,000개 토큰은 캐시에서 제공됩니다. 분기점 이후의 모든 내용은 새로 계산됩니다.

이것이 프롬프트 순서가 중요한 이유입니다. 프롬프트를 다음과 같이 구성하세요:

1. 도구 정의 (가장 정적임)
2. 시스템 프롬프트
3. 정적 퓨샷 예제
4. 검색된 컨텍스트 (반동적)
5. 대화 기록 (회차마다 증가)
6. 사용자 쿼리 (항상 다름)

정적 콘텐츠는 앞에, 동적 콘텐츠는 뒤에 배치하세요. 캐시된 접두사와 일치하는 토큰이 많을수록 절약 효과가 커집니다.

프롬프트 캐싱 vs 의미론적 캐싱(Semantic Caching) vs 응답 캐싱(Response Caching)

이 세 용어는 종종 혼동됩니다. 프롬프트 캐싱(이 가이드에서 다루는 내용)은 동일한 토큰 접두사에 대해 GPU 레벨에서 계산된 KV 상태를 재사용하며, 정확도 손실이 없고 캐시되지 않은 경우와 동일한 출력을 생성합니다. 의미론적 캐싱은 임베딩 유사성을 사용하여 "충분히 유사한" 쿼리에 대해 이전에 생성된 응답을 반환하므로 더 빠르지만 잘못된 답변을 반환할 수 있습니다. 응답 캐싱은 정확한 입력-출력 쌍을 저장하고 캐시된 응답을 그대로 반환하며, 완전히 동일한 요청에만 작동합니다.

프롬프트 캐싱은 유일한 "공짜 최적화"로, 정확도 trade-off 없이 비용과 지연 시간을 줄여줍니다. KV 캐싱背后的 심층 트랜스포머 수학에 관심이 있다면, Hugging Face의 기술 설명서에서 T4 GPU 기준 약 5.21배의 속도 향상을 측정했다는 내용을 확인할 수 있습니다.

OpenAI는 프롬프트 캐싱을 어떻게 처리하나요?

OpenAI의 프롬프트 캐싱은 완전히 자동입니다. 2024년 10월 이후, 1,024개 이상의 입력 토큰을 가진 모든 API 호출은 자동으로 캐싱의 혜택을 받습니다. 옵트인(opt-in) 절차가 필요 없으며, 헤더를 추가하거나 코드를 변경할 필요가 없습니다.

OpenAI 자동 캐싱 작동 방식

최소 1,024개의 토큰을 포함한 요청을 보내면, OpenAI는 접두사가 조직 내 최근 요청과 일치하는지 확인합니다. 캐시 히트는 표준 입력 토큰 가격의 **50%**에 불과합니다. 초기 1,024토큰 임계값 이후에는 캐시가 128토큰 단위로 매칭됩니다.

캐시는 일반 사용 시 5-10분 동안 유지되며, 비수기 시간대에는 확장된 보존 기간을 통해 최대 24시간까지 지속될 수 있습니다. 조직 단위로 범위가 지정되므로, 동일한 조직 내의 다른 프로젝트들도 공유 캐시의 혜택을 받습니다.

지원되는 모델에는 GPT-4o, GPT-4o-mini, GPT-4.1, o1, o3-mini 및 모든 신규 모델이 포함됩니다.

OpenAI Python SDK 예제

from openai import OpenAI

client = OpenAI()

# This system prompt is ~2,000 tokens -- well above the 1,024 minimum
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": user_message},
        ],
    )

    # Check if caching kicked in
    usage = response.usage
    cached = usage.prompt_tokens_details.cached_tokens
    total_input = usage.prompt_tokens
    print(f"Cached: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")

    return response.choices[0].message.content

# First call: cache miss (full price)
chat("Review this async function for race conditions...")

# Second call within 5-10 min: cache hit (50% off on cached tokens)
chat("Now optimize the same function for throughput...")

첫 번째 호출은 정가로 모든 것을 처리하고 캐시를 채웁니다. 두 번째 호출은 캐시된 시스템 프롬프트 토큰을 절반의 가격으로 재사용합니다. 출력에서 Cached: 1920/2048 tokens (94%)와 같은 메시지를 볼 수 있을 것입니다.

판단: OpenAI는 시작하기 가장 쉽습니다. 설정이 필요 없으며, 캐싱이 자동으로 발생합니다. 50% 할인은 세 제공업체 중 가장 낮지만, 그 단순함을 따라올 수는 없습니다.

Anthropic/Claude는 프롬프트 캐싱을 어떻게 처리하나요?

Anthropic은 두 가지 모드를 제공합니다. 기본 자동 캐싱(2026년 2월 이후 기본 활성화)과 cache_control 중단점을 사용한 명시적 캐싱입니다. 무시하기 어려운 핵심 숫자는 캐시된 읽기가 표준 입력 가격의 **10%**만 차지한다는 점, 즉 90% 할인입니다.

자동 vs 명시적 캐싱 (2026 업데이트)

2026년 2월 5일부터 Anthropic은 자격 조건을 갖춘 모든 프롬프트에 대해 자동 캐싱을 기본적으로 활성화했습니다. 더 이상 이전의 베타 헤더가 필요하지 않습니다. 시스템이 최적의 캐시 중단점을 자동으로 결정합니다.

세밀한 제어가 필요할 때는 명시적 캐싱을 여전히 사용할 수 있습니다. 특정 콘텐츠 블록에 cache_control: {"type": "ephemeral"}를 배치하여 캐시 경계가 되어야 할 위치를 정확히 표시합니다. 이는 프롬프트에 특정 구조가 있고 특정 섹션이 캐시되도록 보장하고 싶을 때 유용합니다.

두 가지 TTL 옵션이 존재합니다:

• 5분 캐시 (기본): 쓰기 비용은 기본 입력 가격의 1.25배, 읽기 비용은 0.1배. 캐시 히트 1회 후에 본전 찾음.
• 1시간 캐시: 쓰기 비용은 기본 입력 가격의 2배, 읽기 비용은 0.1배. 캐시 히트 2회 후에 본전 찾음. Claude 4.5+ 모델에서 사용 가능.

2026년 2월 5일부터 캐시 격리 범위가 조직 수준에서 워크스페이스 수준으로 변경되었습니다. 이는 동일한 조직 내의 서로 다른 워크스페이스가 별도의 캐시를 유지한다는 의미입니다.

Anthropic의 캐싱을 사용할 때는 최적의 캐싱을 위해 프롬프트를 구조화하는 것이 도움이 됩니다. 쓰기 프리미엄을 지불하므로 정적 콘텐츠를 동적 콘텐츠 앞에 배치하는 것이 여기서 더욱 중요합니다.

Anthropic Python SDK 예제

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-5-20250514",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},  # Explicit breakpoint
            }
        ],
        messages=[
            {"role": "user", "content": user_message},
        ],
    )

    # Read cache metrics from the response
    usage = response.usage
    created = usage.cache_creation_input_tokens
    read = usage.cache_read_input_tokens
    standard = usage.input_tokens
    print(f"Cache write: {created}, Cache read: {read}, Standard: {standard}")

    return response.content[0].text

# First call: cache_creation_input_tokens = ~1920 (write at 1.25x)
chat("Review this async function for race conditions...")

# Second call: cache_read_input_tokens = ~1920 (read at 0.1x -- 90% off!)
chat("Now optimize the same function for throughput...")

캐시 쓰기 vs 캐시 읽기 가격 이해

Anthropic의 가격 정책이 흥미로운 지점이 바로 여기입니다. Claude Sonnet 4.5(기본 입력 $3/MTok)를 예로 들어보겠습니다:

• 표준 입력: 백만 토큰당 $3.00
• 캐시 쓰기 (5분): 백만 토큰당 $3.75 (1.25배), 첫 번째에는 더 많이 지불함
• 캐시 읽기: 백만 토큰당 $0.30 (0.1배) -- 이후 모든 히트에서 90% 저렴

5분 캐시는 단 1회의 읽기 후에 본전을 찾습니다. 1시간 캐시($6.00/MTok 쓰기)는 2회의 읽기 후에 본전을 찾습니다. 동일한 접두사로 분당 몇 번 이상의 요청을 보낸다면, 계산 결과는 압도적으로 유리합니다.

판단: Anthropic은 가장 깊은 할인(90%)과 가장 강력한 제어 기능을 제공합니다. 고Volume, 비용 민감도가 높은 워크로드에 최적입니다.

Google Gemini는 프롬프트 캐싱을 어떻게 처리하나요?

Gemini는 두 가지 distinct 캐싱 메커니즘으로 다른 접근 방식을 취합니다. 명시적 컨텍스트 캐싱(생성하고 참조하는 이름 지정 캐시 객체)과 암시적 캐싱(자동, 설정 zero, 2026년 Gemini 2.5+ 모델에 추가됨)입니다.

명시적 컨텍스트 캐싱 (이름 지정 캐시)

캐싱이 투명한 OpenAI 및 Anthropic과 달리, Gemini의 명시적 캐싱은 먼저 이름 지정 캐시 객체를 생성한 후 후속 요청에서 이를 참조해야 합니다. 최소 토큰 임계값은 Gemini Flash 모델의 경우 1,024토큰, Pro 모델의 경우 4,096토큰입니다. TTL은 설정 가능하며 기본값은 1시간이지만 필요에 따라 조정할 수 있습니다.

Gemini 2.5 Pro의 캐시된 토큰 가격은 표준 입력 가격 $1.25/MTok 대비 $0.125/MTok로, 90% 할인입니다. 또한 Pro의 경우 시간당 백만 토큰당 $4.50, Flash의 경우 $1.00의 스토리지 비용이 발생합니다.

Gemini 2.5의 암시적 캐싱 (2026)

Gemini 2.5 Pro 및 Flash부터 Google은 OpenAI의 접근 방식과 유사하게 작동하는 암시적 캐싱을 추가했습니다. 설정이 필요 없습니다. 프롬프트 시작 부분에 크고 공통적인 콘텐츠를 배치하고 유사한 접두사를 가진 요청을 빠르게 연속으로 보내세요. 시스템은 자동으로 캐시 대상 콘텐츠를 감지하고 할인을 적용합니다.

Gemini Python SDK 예제

from google import genai
from google.genai import types

client = genai.Client()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

# Step 1: Create a named cache object
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        display_name="python-review-guidelines",
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",  # 1 hour
    ),
)

print(f"Cache created: {cache.name}, expires: {cache.expire_time}")

# Step 2: Use the cache in requests
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Review this async function for race conditions...",
    config=types.GenerateContentConfig(
        cached_content=cache.name,
    ),
)

# Check cache usage in the response
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")

명시적 접근 방식의 큰 장점은 TTL을 정밀하게 제어할 수 있다는 점입니다. 배치 작업이 4시간 동안 실행된다는 것을 알고 있다면, 4시간 TTL을 설정하여 처리 중간에 캐시가 만료되는 것을 방지할 수 있습니다.

판단: Gemini의 설정 가능한 TTL과 이중 캐싱 모드(명시적 + 암시적)는 다용도적입니다. 최소 임계값은 이제 다른 제공업체와 비슷해졌으며, 캐시된 읽기에 대한 90% 할인은 Anthropic과 맞먹습니다.

나란히 비교하는 코드: 동일한 사용 사례, 3개 제공업체 모두

다음은 캐시된 시스템 프롬프트를 사용하는 동일한 챗봇을 세 가지 SDK 모두로 구현한 것입니다. 개발자 경험(DX)을 직접 비교해 보세요.

# --- OpenAI: Zero config, just call the API ---
from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},  # Cached automatically
        {"role": "user", "content": user_message},
    ],
)
cached = response.usage.prompt_tokens_details.cached_tokens

# --- Anthropic: Explicit cache_control breakpoint ---
import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},  # Mark cache boundary
    }],
    messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens

# --- Gemini: Named cache object ---
from google import genai
from google.genai import types

client = genai.Client()
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",
    ),
)
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=user_message,
    config=types.GenerateContentConfig(cached_content=cache.name),
)
cached = response.usage_metadata.cached_content_token_count

노력 zero의 절약을 원한다면 OpenAI를 선택하세요. 가장 깊은 할인과 세밀한 제어를 원한다면 Anthropic을 선택하세요. 설정 가능한 캐시 수명이 필요하거나 이미 Google Cloud를 사용 중이라면 Gemini를 선택하세요.

프로덕션 비용 계산기: 규모에 따른 실제 절약액

추상적인 비율로는 결정을 내리기 어렵습니다. 달러 금액이 결정적입니다. 다음은 Claude Sonnet 4.5(입력 $3/MTok), GPT-4o(입력 $2.50/MTok), Gemini 2.5 Pro(입력 $1.25/MTok)를 사용한 실제 비용 추정치가 포함된 세 가지 프로덕션 시나리오입니다.

가격은 2026년 3월 기준 검증되었습니다. 현재 요금은 Anthropic 가격, OpenAI 가격, Gemini 가격을 확인하세요.

가정: 80% 캐시 히트율(잘 구조화된 프롬프트의 경우 현실적임), 출력 토큰은 제외(캐싱은 입력 비용에만 영향을 미침).

성장기 티어에서는 OpenAI보다 기본 가격이 높은 Anthropic임에도 불구하고 캐싱을 통해 월 $576을 절약합니다. 엔터프라이즈 규모에서는 Anthropic으로 월 $7,200, 즉 연간 $86,400를 절약할 수 있습니다. 이는 구성 변경만으로 시니어 엔지니어 한 명분의 비용을 절약하는 것과 같습니다.

패턴은 명확합니다. 요청 볼륨이 높고 정적 접두사가 길수록 캐싱 절약 효과가 큽니다. Anthropic의 90% 할인은 규모가 클 때 지배적이지만, 총 비용을 고려할 때 Gemini의 낮은 기본 가격도 경쟁력이 있습니다.

프롬프트 캐싱 안티패턴: 캐싱을 사용하지 말아야 할 때

캐싱은 간단해 보이지만 캐시 히트율이 mysteriously 0%에 머무르는 경우가 있습니다. 프롬프트 캐싱을 은연중에 파괴하는 실수와 해결 방법은 다음과 같습니다.

캐시를 무효화하는 실수 (및 해결책)

시스템 프롬프트의 타임스탬프, 가장 흔한 실수입니다. 시스템 프롬프트에 datetime.now()가 포함되어 있으면 캐시 키가 매초 변경됩니다.

# BAD: Cache misses every single request
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""

# GOOD: Move the timestamp to the user message
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""

user_message = f"[Current time: {datetime.now().isoformat()}]\n{user_query}"

정적 콘텐츠 앞의 사용자별 콘텐츠, 시작 부분에 session_id나 사용자 선호도를 배치하면 모든 사용자가 고유한 접두사를 갖게 됩니다.

# BAD: Unique prefix per user = zero cache reuse
messages = [
    {"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
    {"role": "user", "content": query},
]

# GOOD: Static content first, user context at the end
messages = [
    {"role": "system", "content": GUIDELINES},  # Same for all users -> cached
    {"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]

프롬프트 캐싱이 실제로 도움이 되지 않는 경우

프롬프트를 완벽하게 구조화해도 다음과 같은 시나리오에서는 캐싱의 혜택을 받지 못합니다:

• 단일 사용 프롬프트: 모든 요청이 완전히 고유한 컨텍스트를 가지고 공유되는 접두사가 없다면, 캐시할 것이 없습니다.
• 매우 짧은 프롬프트: 1,024토큰 미만(OpenAI/Anthropic) 또는 4,096토큰 미만(Gemini Pro)이면 캐싱이 활성화되지 않습니다.
• 드문 요청: 요청 간격이 몇 시간씩 떨어진다면, 두 번째 요청이 도착하기 전에 캐시가 만료됩니다. OpenAI의 5-10분 창과 Anthropic의 기본 5분 TTL은 일관된 트래픽이 필요함을 의미합니다.

프롬프트 캐싱은 스트리밍과 함께 작동하나요?

예. 프롬프트 캐싱과 스트리밍은 독립적입니다. 캐싱은 입력 토큰에서 작동하고, 스트리밍은 출력 전달에 영향을 미칩니다. 이들은 요청 라이프사이클의 다른 단계에서 서로 다른 문제를 해결합니다.

캐시는 프리필(prefill) 단계(입력 프롬프트 처리)를 담당합니다. 스트리밍은 디코드(decode) 단계(출력 토큰을 증분적으로 생성 및 전송)를 담당합니다. 두 가지 혜택을 동시에 얻을 수 있습니다. 캐시 히트로 인한 빠른 프리필과 스트리밍으로 인한 점진적인 출력 전달입니다.

다음은 캐싱이 활성화된 상태의 스트리밍 예제입니다:

import anthropic

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "Explain Python's GIL..."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    # After streaming completes, check cache metrics
    usage = stream.get_final_message().usage
    print(f"\nCache read: {usage.cache_read_input_tokens} tokens")

캐싱으로 인한 TTFT 개선은 실제로 스트리밍에서 가장 눈에 띕니다. 캐싱이 없으면 첫 번째 토큰이 스트리밍되기 전에 전체 프리필을 기다려야 합니다. 캐싱이 있으면 프리필이 거의 즉시 완료되므로 토큰이 거의 즉시 흐르기 시작합니다.

프로덕션에서 캐시 히트율을 모니터링하는 방법

캐싱 설정은 전투의 절반입니다. 실제로 작동하는지 아는 것이 나머지 절반입니다. 캐시 히트율이 50% 아래로 떨어지면 프롬프트 구조에 변화가 생겼고 돈을 낭비하고 있다는 신호입니다.

제공업체별 캐시 지표

간단한 캐시 히트율 로거

다음은 모든 프로젝트에 삽입하여 API 응답 필드를 통해 캐시 히트율을 추적할 수 있는 유틸리티 함수입니다:

import logging

logger = logging.getLogger("cache_monitor")

def log_cache_metrics(provider: str, usage: dict) -> float:
    """Extract and log cache metrics from any provider's response. Returns hit rate."""

    if provider == "openai":
        cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0)
        total = usage.prompt_tokens
    elif provider == "anthropic":
        cached = usage.cache_read_input_tokens
        created = usage.cache_creation_input_tokens
        total = cached + created + usage.input_tokens
    elif provider == "gemini":
        cached = getattr(usage, "cached_content_token_count", 0)
        total = usage.prompt_token_count
    else:
        raise ValueError(f"Unknown provider: {provider}")

    hit_rate = (cached / total * 100) if total > 0 else 0
    logger.info(f"[{provider}] Cache hit rate: {hit_rate:.1f}% ({cached}/{total} tokens)")

    if hit_rate < 50:
        logger.warning(f"[{provider}] Low cache hit rate! Check prompt structure.")

    return hit_rate

건강한 프로덕션 시스템은 70-90%의 캐시 히트율을 유지해야 합니다. 50% 미만이라면 안티패턴 섹션을 다시 검토하세요. 또한 이를 자동 평가 지표와 통합하여 프롬프트 파이프라인의 회귀(regression)를 감지할 수도 있습니다.

실제 사용 사례에서의 프롬프트 캐싱

위의 챗봇 예제는 메커니즘을 설명하지만, 프롬프트 캐싱은 특정 아키텍처 패턴에서 빛을 발합니다.

RAG 파이프라인

RAG 설정에서 시스템 프롬프트와 퓨샷 예제는 모든 쿼리에서 정적입니다. 검색된 문서는 매번 변경됩니다. 캐시된 접두사를 최대화하도록 프롬프트를 구조화하세요:

1. 시스템 프롬프트 (캐시됨)
2. 퓨샷 예제 (캐시됨)
3. 검색된 문서 (동적, 마지막에 배치)
4. 사용자 쿼리 (항상 고유함)

5,000토큰의 시스템 프롬프트와 3,000토큰의 퓨샷 예제가 있다면, 매 요청마다 8,000토큰이 캐시됩니다. Anthropic에서 일 1,000회 요청 시, 캐시된 접두사만으로 하루 약 $6.50를 절약할 수 있습니다. 컨텍스트 블록을 검색하고 캐시할 때, 검색 출력이 정적 접두사 뒤에 오도록 하세요.

멀티 턴 챗봇

멀티 턴 대화는 프롬프트 캐싱의sweet spot입니다. 각 턴마다 대화 기록이 추가되지만, 전체 이전 대화는 이전 턴들로부터 이미 캐시되어 있습니다. 캐시 혜택은 누적됩니다. 10번째 턴쯤 되면 최신 사용자 메시지의 신선한 토큰 200개に対して 캐시된 기록 15,000토큰을 보유할 수 있습니다.

에이전틱 시스템 및 MCP 도구 정의

도구 사용을 갖춘 에이전트를 구축하는 경우, 도구 정의는 매 API 호출마다 반복되는 정적 JSON 스키마입니다. 일반적인 에이전트는 정의 토큰 합계가 3,000-5,000개인 20개 이상의 도구를 가질 수 있습니다. 이는 캐싱의 최적 재료입니다.

이는 특히 서버 도구 정의가 매 호출마다 전송되는 MCP 기반 아키텍처에서 관련성이 높습니다. Anthropic의 명시적 cache_control을 사용하여 tools 배열을 캐싱용으로 표시하고 해당 토큰이 재사용되도록 보장할 수 있습니다.

어떤 제공업체를 선택해야 할까요?

이미 한 제공업체를 사용하고 있다면 거기서 시작하세요. 프롬프트 캐싱을 위해 전환할 필요는 없습니다. LiteLLM은 프록시 레이어로 작용하여 제공업체 간 캐싱 매개변수를 정규화하므로, 여러 모델로 요청을 라우팅하는 경우에 유용합니다.

FAQ: LLM 프롬프트 캐싱

LLM에서 프롬프트 캐싱이란 무엇인가요?

프롬프트 캐싱은 이전에 처리된 프롬프트 접두사에서 계산된 어텐션 상태(KV 캐시)를 저장합니다. 후속 요청이 동일한 토큰 시퀀스로 시작하면, 제공업체는 이를 재계산하는 대신 저장된 상태를 재사용하여 출력 품질에 zero 영향으로 비용과 지연 시간을 줄입니다.

프롬프트 캐싱은 API 비용을 얼마나 절약하나요?

제공업체에 따라 **50%에서 90%**까지 절약됩니다. OpenAI는 캐시된 입력 토큰에 50% 할인을 제공합니다. Anthropic은 최대 90% 할인(기본 가격의 0.1배로 캐시된 읽기)을 제공합니다. Gemini는 캐시된 읽기에 대해 약 90% 할인을 제공합니다. 실제 절약액은 캐시 히트율, 프롬프트 길이 및 요청 빈도에 따라 달라집니다.

OpenAI 프롬프트 캐싱은 자동으로 발생하나요?

예, 2024년 10월부터 그렇습니다. 1,024개 이상의 입력 토큰을 가진 모든 API 호출은 자동으로 캐싱의 혜택을 받습니다. 옵트인, 헤더, 코드 변경이 필요하지 않습니다. 캐시는 프롬프트 시작 부분의 토큰 접두사를 매칭합니다.

프롬프트 캐싱과 의미론적 캐싱의 차이점은 무엇인가요?

프롬프트 캐싱은 GPU 레벨에서 정확한 토큰 접두사를 매칭하므로 정확도 손실이 없고 출력이 캐시되지 않은 요청과 동일합니다. 의미론적 캐싱은 임베딩 유사성을 사용하여 "충분히 가까운" 이전 쿼리를 찾고 캐시된 응답을 반환하므로 더 빠르지만 부정확하거나 outdated 답변을 반환할 수 있습니다. 이들은 근본적으로 다른 문제를 해결합니다.

프롬프트 캐시는 얼마나 오래 지속되나요?

제공업체마다 다릅니다. OpenAI: 5-10분 (확장된 보존 시 최대 24시간). Anthropic: 5분 (기본) 또는 1시간 (Claude 4.5+ 모델에서 사용 가능, 쓰기 비용 2배). Gemini: 설정 가능, 명시적 캐시의 경우 기본 1시간. 암시적 캐싱 TTL은 Google이 자동으로 관리합니다.

프롬프트 캐싱의 최소 토큰 길이는 얼마인가요?

OpenAI: 1,024토큰. Anthropic: 대부분의 최신 모델에서 1,024토큰. Gemini: Flash 모델은 1,024토큰, Pro 모델은 4,096토큰. 이 임계값 미만의 프롬프트는 캐싱을 활성화하지 않으며, 이것이 "작동하지 않는다"는 가장 흔한 함정입니다.

프롬프트 캐싱은 스트리밍 응답과 함께 작동하나요?

예. 캐싱과 스트리밍은 요청의 다른 단계에서 작동합니다. 캐싱은 입력 프리필 단계를 가속화하고, 스트리밍은 출력 토큰을 증분적으로 전달합니다. 둘 다 동시에 작동하며, 스트리밍이 활성화되면 TTFT 개선 효과를 더 뚜렷하게 느낄 수 있습니다.

언제 프롬프트 캐싱을 사용하지 않아야 하나요?

프롬프트가 최소 토큰 임계값 미만인 경우, 시스템 프롬프트에 타임스탬프나 세션 ID를 포함하는 경우, 호출 간에 퓨샷 예제를 회전시키는 경우, 또는 캐시가 만료되기 전에 요청이 너무 드물어 캐시에 히트되지 않는 경우(OpenAI/Anthropic의 5-10분 창)에는 캐싱 의존을 피하세요.

LangChain이나 LiteLLM으로 프롬프트 캐싱을 사용할 수 있나요?

예. LangChain은 API 래퍼를 통해 제공업체별 캐싱 매개변수를 전달합니다. LiteLLM은 통일된 캐싱 구문을 제공하여 Anthropic, OpenAI, Gemini, Vertex AI 및 Bedrock 전반에 걸쳐 cache_control를 정규화하므로, 다중 제공업체 설정에 특히 유용합니다.

캐시 히트와 캐시 미스는 무엇인가요?

캐시 히트는 제공업체가 메모리에서 일치하는 접두사를 찾아 저장된 KV 상태를 재사용했음을 의미하며, 할인된 캐시 토큰 요금을 지불하고 더 빠른 TTFT를 얻습니다. 캐시 미스는 일치를 찾지 못했음을 의미하므로 전체 프롬프트가 표준 가격으로 처음부터 처리됩니다. API 응답의 cached_tokens(OpenAI), cache_read_input_tokens(Anthropic) 또는 cachedContentTokenCount(Gemini) 필드를 확인하여 어느 것이 발생했는지 확인할 수 있습니다.

최종 판정

프롬프트 캐싱은 LLM API 스택에서 노력이 가장 적고 수익이 가장 높은 최적화입니다. 모델을 변경하지 않고, 품질을 희생하지 않으며, 구현은 "아무것도 하지 않기"(OpenAI)에서 "필드 하나 추가"(Anthropic), "캐시 객체 생성"(Gemini)까지 다양합니다.

현재 사용 중인 제공업체의 자동 캐싱으로 시작하세요. 위의 로깅 유틸리티로 캐시 히트율을 측정하세요. 70% 미만이라면 프롬프트를 재구성하고(정적 먼저, 동적 마지막) 안티패턴을 제거하세요. 대부분의 팀은 이러한 변화를 구현한 지 하루 만에 50-80%의 비용 절감을 경험합니다.

출처

• Anthropic 프롬프트 캐싱 문서
• OpenAI 프롬프트 캐싱 가이드
• Gemini 컨텍스트 캐싱 문서
• Anthropic 모델 가격
• Gemini API 가격
• KV 캐싱 설명, Hugging Face 블로그
• LiteLLM 프롬프트 캐싱 문서