프롬프트 캐싱이란? 반복되는 프롬프트가 재사용되는 방식

프롬프트 캐싱은 API가 요청의 시작 부분을 기억해 두었다가, 다음에 같은 시작 부분을 보내면 재사용하는 것을 말합니다. 매 호출마다 전체 텍스트를 여전히 보내지만, 제공자는 반복되는 부분을 다시 읽는 작업을 건너뛸 수 있고, 일부 제공자는 그 부분을 더 낮은 요금으로 청구합니다. 이는 요청의 시작 부분에만 적용되며, 그 시작 부분이 동일할 때만 작동합니다.

같은 페이지를 계속 다시 읽는 지원 봇#

하루에 2,000건의 티켓을 처리하는 지원 봇을 운영한다고 가정해 봅시다. 모든 요청은 동일한 3,000 토큰으로 시작합니다: 말투, 환불 규칙, 배송 정책. 그 뒤에 "내 주문은 어디 있나요?" 같은 한 줄짜리 고객 메시지가 옵니다. (토큰이 아직 낯설다면 토큰이란 무엇인가부터 시작하세요.)

캐싱이 없으면 제공자는 티켓 1번, 티켓 2번, 티켓 2,000번에 대해 3,000 토큰의 규칙을 매번 다시 읽습니다. 같은 페이지를 2,000번 읽는 셈입니다. 캐싱이 있으면 첫 요청이 전체 가격을 지불하고, 같은 텍스트로 시작하는 이후 요청은 그 작업을 재사용할 수 있습니다.

DeepSeek의 API 가이드(2026년 10월 24일 확인)는 바로 이것을 설명합니다: 컨텍스트 캐싱은 기본으로 켜져 있고, 코드 변경이 필요 없으며, 겹치는 접두사가 있는 이후 요청은 "캐시 적중"으로 간주됩니다. 입력만 캐시됩니다. 답변은 매번 새로 생성됩니다.

"같다"의 기준: 접두사 규칙#

캐시는 첫 문자부터 일치합니다. 요청이 캐시된 것과 달라지는 순간, 그 지점 이후의 모든 것은 새로운 것입니다. 그래서 요청의 순서가 길이보다 더 중요합니다.

캐싱을 조용히 무력화하는 실수가 있습니다. 한 개발자가 봇이 시간을 알게 하려고 맨 위에 시간을 넣습니다:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

시간은 매초 바뀌므로 첫 줄이 매 요청마다 달라지고, 그 뒤의 어떤 것도 일치할 수 없습니다. 해결책은 변하는 것을 끝으로 옮기는 것입니다:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

이제 3,000 토큰의 규칙이 먼저 오고 동일하게 유지됩니다. 같은 논리가 다른 두 가지 흔한 경우에도 적용됩니다: 긴 채팅은 매 턴마다 전체 기록을 다시 보내므로 오래된 메시지가 반복되는 시작 부분 역할을 하고(긴 채팅이 더 비싼 이유에서 더 다룹니다), 에이전트는 매 단계마다 도구 정의와 지시를 반복합니다.

캐싱은 최선 노력 방식이기도 합니다. DeepSeek에 따르면 캐시가 구축되는 데 몇 초가 걸리고, 적중하려면 기존 캐시 접두사 단위와 완전히 일치해야 하며, 적중률은 보장되지 않고, 사용되지 않는 캐시는 보통 몇 시간에서 며칠 안에 정리됩니다. 따라서 첫 요청 후 0.5초 만에 보낸 두 번째 요청은 아직 적중하지 않을 수 있고, 적중이 전체 접두사보다 적게 포함할 수도 있습니다.

확인하는 방법: usage의 캐시 필드#

작동했는지 추측할 필요가 없습니다. 각 제공자는 응답의 usage 부분에 자체 필드 이름으로 이를 보고합니다.

DeepSeek는 두 필드를 사용합니다:

• prompt_cache_hit_tokens — 캐시에서 찾은 입력 토큰
• prompt_cache_miss_tokens — 찾지 못한 입력 토큰

첫 지원 티켓이 prompt_cache_hit_tokens: 0과 prompt_cache_miss_tokens: 3200로 돌아오고, 1분 후 티켓이 prompt_cache_hit_tokens: 3000과 prompt_cache_miss_tokens: 200을 보여준다고 합시다. 3,000 토큰의 규칙이 재사용되었고, 새 고객 메시지와 몇 개의 토큰만 처음부터 읽혔습니다. 매 호출마다 적중 수가 0으로 유지된다면 요청의 시작 부분을 살펴보세요: 그 안의 무언가가 변하고 있습니다.

Anthropic은 캐시할 대상을 직접 표시하기 때문에 다르게 작동합니다. 요청이나 콘텐츠 블록에 ephemeral 유형의 cache_control를 추가합니다:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Anthropic의 프롬프트 캐싱 문서(2026년 10월 24일 확인)에 따르면, 응답은 세 가지 숫자를 보고합니다: cache_creation_input_tokens(지금 캐시에 기록됨), cache_read_input_tokens(캐시에서 읽음), input_tokens(마지막 캐시 중단점 이후의 것). 첫 호출이 cache_creation_input_tokens: 10000, cache_read_input_tokens: 0을 보여주고 두 번째가 0과 10000을 보여준다고 합시다. 이는 캐시 쓰기 후 캐시 읽기입니다.

화면에 함정이 하나 있습니다. 모델의 최소값(모델에 따라 512, 1,024 또는 4,096 토큰)보다 짧은 프롬프트는 오류 없이 캐싱 없이 처리됩니다. 두 캐시 필드 모두 0이 표시되고 경고는 없습니다. 기본 수명은 5분이며 사용할 때마다 무료로 갱신되고, 선택적 1h의 ttl는 더 오래 유지합니다.

청구서에 미치는 영향#

캐싱은 반복되는 부분의 가격을 바꾸므로 한 번 계산해 볼 가치가 있습니다. Anthropic은 기본 입력 가격에 대한 배수를 나열합니다: 5분 수명의 캐시 쓰기는 1.25배, 읽기는 0.1배(Opus 5.5와 Sonnet 5.5는 0.05배)입니다. 5분 창 안에서 20번의 요청에 재사용되는 10,000 토큰 접두사를 표준 0.1배 읽기로 계산해 봅시다:

캐싱 없이 기본 가격으로 10,000 × 20 = 200,000 토큰

캐시를 기록하는 첫 요청에 10,000 × 1.25 = 12,500

캐시를 읽는 19번의 요청에 19 × 10,000 × 0.1 = 19,000

캐싱 시 12,500 + 19,000 = 31,500 토큰 상당

따라서 반복되는 부분의 비용은 캐싱하지 않을 때의 5분의 1보다 훨씬 낮습니다. 주의할 점: 요청 사이에 5분이 지나면 다음 요청이 1.25배로 캐시를 다시 기록하며, 드물게 사용되는 접두사는 캐싱을 전혀 하지 않는 것보다 더 비쌀 수 있습니다.

이제 처음의 봇을 일반적인 전체 가격 기준으로 봅시다. 하루 2,000 요청, 각각 3,000 입력 토큰과 약 300 출력 토큰:

하루 2,000 × 3,000 = 6,000,000 입력 토큰

하루 2,000 × 300 = 600,000 출력 토큰

표는 그날의 작업량을 OpenRouter 옆에 있는 모든 사용 가능한 CheapTokens 모델로 가격을 매깁니다:

DeepSeek-V4-Flash는 입력과 출력을 합산한 총액에서 OpenRouter보다 저렴하며, 작업량도 쉽게 들어갑니다: 380K 컨텍스트와 답변당 최대 32,768 출력 토큰. 이는 작업량의 전체 가격 비용입니다: 입력 토큰 × 토큰당 가격. 길고 안정적인 접두사가 바로 그 입력 비중이 가장 큰 곳입니다.

5분 만에 직접 해보기#

계획: 같은 긴 시스템 프롬프트를 다른 질문과 함께 두 번 보내고 usage를 확인합니다. support_rules.txt에 자신의 규칙 텍스트를 넣으세요(한두 페이지면 충분합니다). 엔드포인트는 OpenAI 호환 CheapTokens API이며, 계정에서 키를 가져올 수 있습니다.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

출력에서 확인할 것: prompt_tokens는 요청이 얼마나 큰지 알려줍니다. 두 요청 모두 같은 SYSTEM 텍스트를 담고 있으므로, 그 숫자의 대부분은 요청마다 반복됩니다 — 대략 규칙 파일의 크기입니다. 그 반복되는 시작 부분이 위의 DeepSeek API나 Anthropic처럼 캐싱을 지원하는 제공자가 재사용할 수 있는 부분입니다. 이제 순서에 대한 연습: SYSTEM 맨 위에 현재 시간(datetime.now())을 넣은 줄을 추가하고 다시 실행하세요. 두 요청은 첫 줄부터 달라지므로 더 이상 시작 부분을 공유하지 않습니다. 같은 줄을 프롬프트 끝에 넣으면 공유되는 시작 부분이 돌아옵니다.

자신의 프롬프트를 위한 짧은 체크리스트:

1. 안정적인 텍스트를 먼저: 지시, 규칙, 도구 정의, 예시.
2. 변하는 텍스트를 마지막에: 날짜, 사용자 이름, 최신 메시지.
3. 접두사를 바이트 단위로 동일하게 유지 — 여분의 공백 하나도 영향을 줍니다.
4. 아무것도 캐시되지 않는 이유를 궁금해하기 전에 제공자의 최소 크기를 확인하세요.
5. 변경 후에 usage 필드를 확인하세요, 그 전이 아니라.

자신의 작업량 가격을 매기려면 가격 페이지를 열고 입력과 출력 크기를 입력하거나, DeepSeek 페이지에서 시작하세요. 첫 요청이 작동하면, 같은 추정은 작성하는 모든 프롬프트에 대해 1분이면 됩니다. 요청의 양쪽 비용에 대해서는 입력 vs 출력 토큰을 참고하세요.