LLM 프롬프트 캐싱 #1: KV 캐시와 TTL의 작동 원리

TL;DR — LLM 프롬프트 캐싱은 나중에 덧붙인 최적화가 아닙니다. 그것은 Transformer 아키텍처가 실제로 어텐션을 계산하는 방식에서 자연스럽게 도출됩니다. 안정적인 프리픽스의 Key/Value 벡터가 왜 수학적으로 재사용 가능한지 이해하고 나면, 진짜 놀라운 점은 그 두 가지 이득임이 드러납니다. 즉, 극적인 비용 절감(5090%) 그리고 극적인 첫 토큰까지의 시간(TTFT) 단축(520×)입니다. 본 글은 4부작 시리즈의 1부로, 캐시가 존재하는 아키텍처적 이유, 캐시가 수지에 맞는지를 결정하는 메모리 대 연산의 트레이드오프, 그리고 모든 개발자가 이해해야 할 TTL 동작을 다룹니다. 2부에서는 각 제공자별 구현을 깊이 파고듭니다.

시리즈: 전 4부 중 1부 — 캐싱 원리 · 다음: 2부 — 제공자 비교 및 평가 · 3부 — 동작하는 코드 튜토리얼 · 4부 — 사용 사례별 최적 LLM

왜 당신의 AI 앱 토큰 청구서는 사용자보다 더 빨리 늘어나는가

챗봇, RAG 앱, AI 에이전트를 출시하고 있다면 아마 같은 벽에 부딪혔을 것입니다. 사용량은 그대로인데 청구서는 두 배가 됩니다. 요청 로그를 열어 보면 동일한 수천 토큰짜리 시스템 프롬프트, 동일한 도구 설명, 동일한 지식 베이스 청크가 호출할 때마다 다시 전송되고 있는 것을 발견하게 됩니다.

이것이 LLM 추론의 핵심 경제 문제입니다: 모델은 무상태(stateless)다. 모든 요청이 전체 컨텍스트를 처음부터 다시 처리합니다. 8K 토큰짜리 시스템 프롬프트를 1,000번 호출하면 800만 토큰 분량의 반복 작업과 같습니다. 당신은 그 모든 것에 비용을 지불하고——사용자는 그 모든 것을 기다립니다.

프롬프트 캐싱이 이를 해결합니다. 하지만 대부분의 성능 트릭과 달리, 이것은 아키텍처에 추가된 것이 아닙니다——Transformer 어텐션이 정의되는 방식에서 비롯된 자연스러운 귀결입니다. 그것이 보이고 나면 글의 나머지 부분(가격, TTL, 제공자 차이)이 깔끔하게 정리됩니다.

1. LLM에 애초에 캐시가 있는 이유: Transformer 추론 둘러보기

이 섹션은 거의 모든 “프롬프트 캐싱” 튜토리얼이 건너뛰는 부분입니다. 애초에 왜 캐시가 존재하는지——그리고 제공자가 제시하는 할인이 임의의 마케팅 숫자가 아니라 실제 GPU 경제를 반영하는 이유를 설명합니다.

1.1 한 방정식으로 본 셀프 어텐션

디코더 전용(decoder-only) Transformer(GPT-4, Claude, Gemini, DeepSeek, Qwen이 모두 속하는 계열)는 셀프 어텐션을 반복 적용하여 토큰을 처리합니다. N개의 토큰으로 이루어진 시퀀스에 대해, 각 토큰 i의 어텐션 출력은 다음과 같습니다:

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

여기서 Q, K, V는 형태 [N × d]의 행렬로, 입력 임베딩으로부터 세 개의 학습된 선형 사영(층마다, 헤드마다 하나씩)을 통해 얻어집니다. 원래 정의는 Attention Is All You Need(Vaswani 외, 2017)에서 나왔습니다.

이 방정식의 두 가지 성질이 캐싱에 매우 중요합니다:

성질 1 — 인과적 마스킹(causal masking). 생성 중에 토큰 i는 위치 ≤ i의 토큰에만 어텐션할 수 있습니다. 어텐션 행렬은 하삼각 행렬입니다: 초기 토큰의 K와 V 벡터는 이후의 모든 토큰에 의해 사용되지만, 이후의 토큰이 그것들을 수정하는 일은 결코 없습니다.

성질 2 — K와 V는 프리픽스에만 의존한다. 이들은 위치 1…i의 입력 임베딩으로부터 고정된 가중치 행렬을 통해 계산되므로, 위치 i의 K와 V 벡터는 위치 1…i의 토큰들의 결정론적 함수입니다——그리고 오직 그 토큰들에만 의존합니다. 위치 i+1에 관한 어떤 정보도 K_i나 V_i를 바꿀 수 없습니다.

여기서 곧바로 다음 결론이 나옵니다: 두 요청이 길이 P의 동일한 프리픽스를 공유하면, K와 V의 처음 P개 행은 비트 단위로 완전히 동일하다.

이것이 프롬프트 캐싱의 이론적 기반 전부입니다. 나머지는 모두 엔지니어링입니다.

1.2 추론의 두 단계

현대 LLM 추론은 GPU 시간을 매우 다르게 소비하는 두 개의 뚜렷한 단계로 작동합니다. 이 분할은 Efficiently Scaling Transformer Inference(Pope 외, 2022)에 자세히 기록되어 있습니다.

프리필(Prefill) 단계. 모델이 전체 프롬프트를 한 번에 받아들입니다. 각 층에 대해 모든 입력 토큰의 Q, K, V를 계산하고 셀프 어텐션을 수행합니다. 프리필은 연산 제약(compute-bound) 입니다: GPU의 행렬 곱셈 유닛을 포화시킵니다. 어텐션 행렬 때문에 비용은 프롬프트 길이에 대해 O(N²) 로 증가합니다.

디코드(Decode) 단계. 모델이 자기회귀적으로 한 번에 하나의 출력 토큰을 생성합니다. 단계 t에서는 새 토큰의 Q만 계산되며, 이전의 모든 토큰의 K/V에 어텐션합니다. 디코드는 메모리 대역폭 제약(memory-bandwidth-bound) 입니다——대부분의 시간이 곱셈이 아니라 GPU 메모리에서 K/V를 읽는 데 쓰입니다. 비용은 토큰당 O(N) (현재 컨텍스트 길이에 대해 선형)으로 증가합니다.

전형적인 챗봇 워크로드(8K 토큰 시스템 프롬프트 + 100 토큰 사용자 질의 + 300 토큰 응답)에서는 프리필이 벽시계 시간과 금전 비용을 대략 4:1 비율로 지배합니다. 바로 그것이 캐싱이 절약하는 부분입니다.

호출당 분해(8K 프롬프트, 300 출력 토큰, Claude급 모델):

  ████████████████████████████████░░░░░░░░  Prefill: 연산의 약 80%
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  연산의 약 20%

1.3 KV 캐시: 프리필 작업을 디코드를 위해 저장하기

“KV 캐시”는 원래 요청 내부의 최적화를 가리켰습니다. 디코딩 중에는 새로 생성되는 각 토큰이 이전의 모든 토큰의 K와 V에 어텐션해야 합니다. 매 단계마다 그것들을 재계산하면 O(N) 디코드가 O(N²) 디코드가 됩니다. 그래서 모든 추론 엔진은 프리필에서 나온 K와 V를 GPU 메모리에 저장하고 디코드 단계 전체에 걸쳐 재사용합니다. 이는 보편적입니다——모든 상용 LLM이 이렇게 합니다. 그것이 생성을 연산적으로 가능하게 만드는 것입니다.

제공자가 “프롬프트 캐싱”으로 노출하는 것은 그다음 일반화입니다: 요청이 끝난 뒤에도 KV 캐시를 유지하고, 동일한 프리픽스를 공유하는 다음 요청에서 재사용한다.

1.4 메모리-연산 트레이드오프(TTL이 존재하는 이유)

그렇다면 왜 모든 제공자가 그냥 모든 것을 영원히 캐싱하지 않을까요? KV 캐시가 엄청나게 크기 때문입니다.

L개의 Transformer 층, H개의 어텐션 헤드, 헤드 차원 D, 값당 B 바이트(fp16에서는 보통 2)인 모델의 경우, N 토큰의 KV 캐시 크기는 다음과 같습니다:

KV 캐시 크기  =  2 × L × H × D × B × N
                ↑   ↑   ↑   ↑   ↑   ↑
                K&V 층  헤드 헤드차원 바이트 토큰

80개 층, 8개 KV 헤드(그룹 쿼리 어텐션 GQA 적용 후), 헤드 차원 128, fp16 가중치의 70B급 모델이라면 대략 토큰당 320 KB입니다. 32K 토큰 컨텍스트 = 약 10 GB의 KV 캐시, 단 하나의 요청을 위해서 말입니다. 현대 H100 GPU는 80 GB를 갖추고 있으니, 이런 것을 동시에 담을 수 있는 것은 기껏해야 몇 개뿐입니다.

이것이 바로 PagedAttention(Kwon 외, 2023, vLLM의 기반 논문)이 배치 수준에서 해결하도록 설계된 핵심 제약입니다——그리고 같은 제약이 요청 간 수준에서 프롬프트 캐싱을 제한합니다:

그래서 제공자의 캐시 TTL은 본질적으로 메모리 축출 정책입니다: 어느 시점에서 GPU는 그 메모리를 다른 사용자의 활성 워크로드에 필요로 하게 되고, 캐시된 프리픽스는 축출됩니다. HBM 상주 캐시는 5분, DRAM으로 페이징되는 캐시는 최대 1시간, 디스크 기반 캐시는 수 시간입니다.

DeepSeek의 묘수. DeepSeek-V2는 멀티헤드 잠재 어텐션(Multi-head Latent Attention, MLA)을 도입했는데, 이는 표준 그룹 쿼리 어텐션에 비해 KV 캐시를 약 4배 압축합니다(DeepSeek-AI, 2024). 바로 그 압축이 KV 캐시를 HBM 대신 디스크에 영속화할 수 있게 해 주며——그것이 다시 훨씬 작은 최소 캐시 단위(HBM 상주 캐시의 1,024 토큰 대비 64 토큰)와 훨씬 긴 실효 TTL을 가능하게 합니다.

이것이 또한 요청 간 캐싱이 토큰 단위로 동일한 프리픽스를 요구하는 이유입니다. 캐시는 토큰 ID의 해시로 색인되며, 어떤 차이든——재토큰화가 다르게 되는 한 글자조차——그 지점 이후로 다른 K와 V를 만들어 냅니다. 이 계층에는 “퍼지 매칭”이 없습니다(그것은 시맨틱 캐싱이 하는 일이지만, 그것은 게이트웨이 안의 다른 메커니즘입니다).

1.5 두 계층의 캐싱

┌──────────────────────────────────────────────────────────────┐
│  계층 1: 요청 내 KV 캐시(항상 켜짐, 모든 제공자)            │
│  → 디코드를 O(N²)가 아닌 O(N)으로 유지                       │
│  → 당신이 신경 쓸 필요 없음; 제공자가 알아서 함             │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  계층 2: 요청 간 프롬프트 캐시(이 시리즈가 다루는           │
│           비용과 시간 절약 장치)                              │
│  → 프리픽스가 일치하는 요청 간에 프리필 K/V를 재사용         │
│  → 노출 형태: 명시적 / 완전 자동 / 하이브리드               │
│  → TTL에 의해 제약됨(메모리 축출에 의해 구동)               │
└──────────────────────────────────────────────────────────────┘

시리즈의 나머지——그리고 개발자로서 당신이 튜닝할 내용의 대부분——은 계층 2에 있습니다.

2. 두 가지 승리: 비용 그리고 지연 시간

대부분의 글은 캐싱을 비용 최적화로 규정합니다. 그것은 과소평가입니다. 지연 시간 이득은, 특히 사용자 대면 채팅에서, 프로덕션 팀이 캐싱을 채택하는 더 큰 이유인 경우가 많습니다.

2.1 비용 계산

가격 페이지는 헤드라인 숫자를 주지만, 그것을 현실적인 워크로드에 적용한 모습은 좀처럼 보여 주지 않습니다. 8,000 토큰 시스템 프롬프트, 하루 10만 질의, 200 토큰 사용자 메시지를 가진 고객 지원 봇을 생각해 봅시다. Anthropic이 공개한 2026년 요율(캐시 입력 10%, 캐시 쓰기 프리미엄 125%)로 claude-sonnet-4-5를 사용해 가격을 산정합니다:

캐싱 없이

• 호출당 입력: 8,200 토큰 × 기본 입력 요율
• 호출당 비용(단발 실측): 약 $0.022
• 월간 비용: 100K × 30 × $0.022 = 약 $66,000

프롬프트 캐싱 사용

• 일회성 캐시 쓰기: 8,000 토큰 × 125% 프리미엄(월간 볼륨 대비 무시 가능)
• 이후 호출마다: 8,000 토큰 × 10% 기본 + 200 토큰 × 기본 + 출력
• 실효 호출당 비용: 약 $0.003
• 월간 비용: 약 $9,000

약 86% 절감. 이 숫자는 Anthropic이 공개한 할인을 현실적인 입력 형태에 적용한 것입니다. 이어지는 글(3부 — 튜토리얼)에서는 나머지 제공자 전반에 걸친 실측 숫자를 보여 줍니다.

2.2 지연 시간 승리(종종 더 큰 이야기)

프리필은 비싸기만 한 것이 아닙니다——수백 토큰을 넘는 모든 프롬프트에 대해 첫 토큰까지의 시간(TTFT)에 대한 단일 최대 기여 요인입니다. 캐시 히트는 그것의 거의 전부를 건너뛰게 해 줍니다.

공개 Synthorai 게이트웨이를 대상으로 실측한 스트리밍 TTFT, 2026-05-25, 약 7,300 토큰의 안정적인 시스템 프롬프트:

단일 실행, 단일 테넌트. TTFT 이득은 긴 프롬프트(>5K 토큰)에서 가장 잘 드러납니다; 짧은 프롬프트에서는 프리필 부분이 너무 작아 지연 시간을 지배하지 못합니다. Claude의 실측 최대 이득은 비용입니다(캐시 읽기 시 입력 약 88~89% 절감)——100K+ 범위의 프롬프트 크기에서는 Anthropic이 공개한 숫자에 따라 TTFT 이득이 상당히 누적됩니다.

채팅 UI에서 사용자가 의식적으로 지연을 인지하는 임계값은 TTFT의 경우 약 1초, 첫 유용한 텍스트의 경우 약 2초입니다. 캐싱 없는 10K 토큰 RAG 프롬프트는 그 선을 확실히 넘어섭니다. 캐싱이 있으면 동일한 워크로드가 즉각적으로 느껴집니다.

15단계 이상의 에이전트 루프에서는 비용 이야기도 좋지만(50% 절감), 제품을 실제로 출시 가능하게 만드는 것은 지연 시간 이야기입니다: 15단계 × 5s 프리필 = 작업당 75초의 죽은 시간 → 캐싱이 있으면 15 × 0.5s = 7.5초.

2.3 이것이 제품 전략에 중요한 이유

흔한 실수는 캐싱을 “운영팀이 하는 비용 최적화”——출시 후에 덧붙이는 것——로 취급하는 것입니다. 하지만 지연 시간 이득은 캐싱이 UX 표면의 일부이기도 하다는 것을 의미합니다:

• TTFT가 1초 미만인 챗봇은 살아 있는 것처럼 느껴집니다; 같은 봇이 3초이면 고장 난 것처럼 느껴집니다.
• 검색+프리필에 4초가 걸리는 RAG 제품은 그것이 1초에 끝나는 같은 제품에 집니다.
• 작업을 20초에 완료하는 에이전트는 90초가 걸리는 것에 이깁니다.

캐시 전략은 모델과 프롬프트 구조를 정하는 것과 동시에 정해야 합니다——출시 세 스프린트 후가 아니라.

3. 캐시 신선도, TTL, 그리고 운영 모델

TTL 문제는 프롬프트 캐싱에서 가장 많이 질문받지만 가장 적게 설명되는 부분 중 하나입니다. 이해해야 할 두 가지가 있습니다:

3.1 신선도에는 두 가지 의미가 있다 — 혼동하지 말 것

캐시 신선도 ≠ 응답 신선도. 자주 혼동되는 두 개의 별개 개념이 있습니다:

다시 말해: 캐시된 응답은 어떤 모델 품질의 의미에서도 “오래된” 것이 아닙니다. 그것들은 수학적으로 캐시되지 않은 것과 동일합니다. 하지만 “현재 시각은 14:32:05”를 시스템 프롬프트에 넣고 캐시 히트에 의존하면, 당신의 “현재 시각”은 TTL 만료까지 14:32:05에 머물고 모델은 그것에 대해 사용자에게 자신만만하게 거짓말을 하게 됩니다.

3.2 제공자별 TTL 동작

5분이라는 기본값은 임의가 아닙니다——피크 부하에서 인기 모델의 대략적인 GPU 메모리 압박 시점입니다. §1.4에서 계산했듯이, 하나의 큰 컨텍스트의 KV 캐시는 수십 GB가 될 수 있습니다; 제공자는 그것들을 무기한 보유할 여유가 없습니다.

3.3 TTL을 고려한 설계

프로덕션에서 효과가 있는 세 가지 패턴:

패턴 A — 세션을 따뜻하게 유지하라. 채팅의 경우 자연스러운 요청 주기(턴 사이 수 초에서 수 분)만으로도 캐시가 스스로 살아 있습니다. TTL을 걱정하지 마세요; 그저 동적 데이터를 프리픽스에 넣지만 마세요.

패턴 B — 배치를 위한 하트비트. 수 시간에 걸친 배치 작업의 경우, TTL/2마다 최소 요청을 보내 캐시를 따뜻하게 유지하세요. 비용은 사실상 0(몇 개의 입력 토큰)이며 캐시 축출 폭풍을 방지합니다.

패턴 C — 콜드 스토리지에는 긴 TTL 제공자를. 드물게 질의되는(예: 일주일 동안 시간당 한 번) 50K 토큰 문서가 있다면, 저장 요금이 들더라도 Gemini 명시적 캐시(24시간 TTL)나 DeepSeek 디스크 캐시가 짧은 TTL 대안을 능가합니다.

4. 모든 개발자가 알아야 할 보편 원칙

제공자들은 캐싱을 매우 다른 다섯 가지 형태로 노출합니다——명시적 마커, 완전 자동, 하이브리드, 아키텍처 수준의 디스크 백업, 또는 아예 없음. 그 비교에는 다음 글을 통째로 할애합니다(2부 — 제공자 비교 및 평가). 하지만 어떤 제공자든 적용되며, 방금 둘러본 아키텍처에서 직접 도출되는 네 가지 원칙이 있습니다:

4.1 캐싱은 프리픽스 기반이다 — 순서가 중요하다

위치 i의 K/V는 위치 1…i의 토큰에 의존하므로, 제공자는 토큰 0에서 시작하는 연속된 프리픽스만 매칭할 수 있습니다. 위치 0의 한 글자를 바꾸면 전체 프리픽스가 무효화됩니다. 안정적인 내용을 앞에, 변동성 있는 내용을 뒤에. 이것은 휴리스틱이 아닙니다——셀프 어텐션의 인과 구조(§1.1)의 직접적인 귀결입니다.

4.2 캐시는 K/V를 저장하지, 답을 저장하지 않는다

캐시 히트는 이전에 생성된 답을 반환하지 않습니다——이전에 계산된 K와 V 벡터를 반환하며, 모델은 그것을 사용해 현재 질문에 대한 새로운 응답을 생성합니다. 이는 다음을 의미합니다:

• 출력 품질은 캐시되지 않은 호출과 동일하다(§1.1).
• 출력은 통상적인 의미에서 비결정론적이다——temperature, top-p 등은 여전히 적용됩니다.
• 캐시된 응답은 모델 품질의 의미에서 결코 “오래되지” 않는다——오래될 수 있는 것은 프롬프트의 내용(타임스탬프, 가격)뿐입니다. §3.1을 다시 보세요.

4.3 캐시 쓰기는 투자이지, 무료가 아니다

쓰기 프리미엄을 부과하는 제공자(Anthropic 125%, Gemini 명시적 125%)의 경우, 새 프리픽스로 하는 첫 호출은 캐싱 없이 하는 것보다 더 비쌉니다. 손익분기는 빠르지만(보통 히트 한 번), “안정적인” 프리픽스가 요청마다 바뀐다면 아무 보상 없이 쓰기 비용을 거듭 지불하게 됩니다. 검색된 문서를 관련도로 정렬하고 있다면 주의하세요——그것이 고전적인 안티패턴입니다.

4.4 캐싱 API는 제공자 간에 이식되지 않는다

cache_control(Anthropic) ≠ cached_content(Gemini) ≠ cache_id(Qwen). 애플리케이션이 여러 제공자에서 실행되어야 한다면, 세 가지 통합을 유지하거나 앞단에 Token 게이트웨이를 두어 그것들을 통일하거나 둘 중 하나입니다. 2부에서 자세히 다룹니다.

5. 프롬프트 캐싱은 공짜로 생기는 돈인가?

거의 그렇습니다. 다음의 경우 수지가 맞습니다:

• 프롬프트에 안정적인 프리픽스가 있다——시스템 프롬프트, 지식 베이스, 도구 스키마
• 호출이 빈번하거나 연결되어 있다——같은 세션, 배치 워크로드, 진행 중인 에이전트 실행
• 안정적인 내용이 맨 앞에 오도록 프롬프트를 구성할 수 있다

이 세 가지를 충족하면, 모델을 바꾸지 않고도 보통 지출 50~90% 감소와 TTFT 3~20× 가속을 보게 됩니다.

다음 편 예고: 2부 — 제공자 프롬프트 캐싱 비교 및 평가 프레임워크에서는 위의 아키텍처 그림을 Claude, OpenAI, Gemini, DeepSeek, Qwen에 대한 기능별 비교로 바꾸고, 당신의 워크로드에 맞는 제공자를 고르기 위한 평가 루브릭을 제공합니다.

빠른 시작: OpenAI SDK로 모든 제공자에 접근하기

Synthorai는 OpenAI 호환 엔드포인트를 노출합니다——공식 openai SDK를 거기로 향하게 하면 모든 모델(Claude, GPT, Gemini, DeepSeek, Qwen)이 한 줄짜리 모델 교체가 됩니다. 게이트웨이는 cache_control을 각 제공자의 네이티브 캐싱 구문으로 변환합니다.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

같은 호출이 gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max에도 동작합니다——바뀌는 것은 model 필드뿐입니다. 게이트웨이는 프롬프트 캐시 히트 메타데이터를 표준 OpenAI prompt_tokens_details.cached_tokens 필드로 반환하며, 추가로 USD 단위의 cost 필드도 반환하므로 벤더별 가격 매트릭스를 로컬에서 유지할 필요가 없습니다.

FAQ

LLM 프롬프트 캐싱은 시맨틱 캐싱과 같은가요? 아니요. 프롬프트 캐싱은 프리픽스 기반입니다——프롬프트 시작 부분의 정확한 토큰 수준 일치에 대해 K/V 값을 재사용합니다. 시맨틱 캐싱은 의미 수준에서(임베딩을 통해) 일치시키고 이전 응답을 반환합니다. 둘 다 유용하며, 좋은 Token 게이트웨이는 그것들을 계층적으로 결합합니다.

프롬프트 캐싱이 모델의 출력을 바꾸나요? 아니요. K와 V는 입력 토큰의 결정론적 함수입니다(§1.1). 모델이 캐시된 K/V로부터 생성하는 로짓은 새로 재계산된 K/V로부터 생성하는 것과 수학적으로 동일합니다. 캐싱은 품질에 영향이 없는 순수한 효율 최적화입니다.

왜 캐시 TTL이 그렇게 짧은가요 — 그냥 영원히 유지할 수 없나요? KV 캐시는 엄청나게 큽니다(§1.4: 70B 모델의 32K 컨텍스트에 약 10 GB). GPU 메모리가 병목이며, 서버가 그 메모리를 활성 워크로드에 필요로 할 때마다 캐시는 축출됩니다. 디스크 기반 캐시(DeepSeek)는 수 시간 살아남을 수 있지만, 인메모리 캐시는 보통 그러지 못합니다.

KV 캐시와 프롬프트 캐시의 차이는 무엇인가요? KV 캐시는 추론 중에 사용되는 인메모리 데이터 구조입니다. “프롬프트 캐시”는 그 KV 캐시를 요청 간에 재사용하는 것입니다. 위 §1.5의 계층 1 대 계층 2입니다.

캐시된 프롬프트가 품질을 떨어뜨리는 방식으로 오래되는 경우가 있나요? 모델의 관점에서는 없습니다. 당신의 내용의 관점에서는, 프롬프트가 시간에 민감한 정보를 인코딩하고 있다면 있습니다. 캐시는 K/V 벡터를 저장하지, 세상에 대한 사실을 저장하지 않습니다. §3.1을 참조하세요.

캐시 히트율은 어떻게 측정하나요? 모든 제공자가 응답의 usage 객체에서 그것을 반환합니다——cache_read_input_tokens(Anthropic), cached_tokens(OpenAI), cached_content_token_count(Gemini), prompt_cache_hit_tokens(DeepSeek). 이것들을 로깅 파이프라인에서 추적하세요.

참고 문헌 및 출처: Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “Efficient Memory Management for LLM Serving with PagedAttention” (SOSP 2023, vLLM) · DeepSeek-AI, “DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model” (2024) — MLA architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← 블로그로 돌아가기