LLM 提示詞快取如何運作：KV Cache 與 TTL 詳解

TL;DR — LLM 提示詞快取不是外加的最佳化手段，而是 Transformer 架構計算 attention 時自然產生的結果。理解穩定前綴的 Key/Value 向量為何能在數學上重用後，真正令人意外的是它帶來的雙重效益：成本大幅降低 50–90%，首個 token 回應時間也縮短 5–20×。本文是五篇系列文章的第 1 篇，將說明快取存在的架構原因、決定快取是否划算的記憶體與運算取捨，以及每位開發者都必須理解的 TTL 行為。第 2 篇會深入比較各供應商的實作。

系列文章：共 5 篇，第 1 篇 — 快取原理 · 下一篇：第 2 篇 — 供應商比較與評估 · 第 3 篇 — 實作程式碼教學 · 第 4 篇 — 各使用情境的最佳 LLM · 第 5 篇 — LangChain 整合 · 單頁版：完整提示詞快取指南

為什麼 AI 應用程式的 token 帳單成長得比使用者還快

如果你正在開發聊天機器人、RAG 應用程式或 AI agent，大概已經碰過同一個問題：使用量沒有增加，帳單卻翻倍了。打開請求紀錄，就會看到每次呼叫都重複傳送同一份數千 token 的 system prompt、同一組工具說明，以及相同的知識庫片段。

這正是 LLM 推論的核心成本問題：模型沒有狀態。每個請求都必須從頭處理完整 context。假設一份 8K token 的 system prompt 被呼叫 1,000 次，就代表有 800 萬個 token 的重複運算。每個 token 都要付費，使用者也得等待每次運算完成。

提示詞快取能解決這個問題。它不同於多數效能最佳化技巧，並不是額外加到架構上的功能，而是 Transformer attention 定義本身帶來的自然結果。理解這一點後，後面的定價、TTL 與供應商差異就都能清楚串起來。

1. LLM 為什麼會有快取：逐步解析 Transformer 推論

幾乎所有「提示詞快取」教學都略過這一段。然而，這正是解釋快取為何存在的關鍵，也能說明供應商提供的折扣並非任意訂出的行銷數字，而是反映真實的 GPU 成本結構。

1.1 用一條公式理解 Self-Attention

Decoder-only Transformer（GPT-4、Claude、Gemini、DeepSeek、Qwen 都屬於這一類）會反覆套用 self-attention 來處理 token。對於一個包含 N 個 token 的序列，每個 token i 的 attention 輸出為：

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

其中 Q、K、V 是形狀為 [N × d] 的矩陣，由輸入 embedding 經過三個學習得到的線性投影產生，每一層、每個 head 各有一組。這個定義最早出自 Attention Is All You Need（Vaswani et al., 2017）。

這條公式有兩項性質，對快取極為重要：

性質 1 — Causal masking。 在生成過程中，token i 只能關注位置 ≤ i 的 token。attention 矩陣是下三角矩陣：前面 token 的 K 與 V 向量會供所有後續 token 使用，但後面的 token 永遠不會修改它們。

性質 2 — K 和 V 只取決於前綴。 它們是位置 1…i 的輸入 embedding 經固定權重矩陣計算而來，因此位置 i 的 K 與 V 向量是位置 1…i 這些 token 的確定性函數，而且只受這些 token 影響。位置 i+1 的任何內容都不會改變 K_i 或 V_i。

結論很直接：如果兩個請求具有長度為 P 的相同前綴，K 和 V 的前 P 列就會逐 bit 完全相同。

這就是提示詞快取的完整理論基礎。剩下的全是工程實作。

1.2 推論的兩個階段

現代 LLM 推論分成兩個截然不同的階段，兩者消耗 GPU 時間的方式差異很大。Efficiently Scaling Transformer Inference（Pope et al., 2022）對這項劃分有完整說明。

Prefill 階段。 模型一次讀入完整 prompt。每一層都會為所有輸入 token 計算 Q、K、V，並執行 self-attention。Prefill 屬於運算受限，會用滿 GPU 的矩陣乘法單元。因為要計算 attention 矩陣，成本會隨 prompt 長度以 O(N²) 成長。

Decode 階段。 模型以 autoregressive 方式，一次產生一個輸出 token。在步驟 t，只計算新 token 的 Q，再讓它對所有先前 token 的 K/V 執行 attention。Decode 屬於記憶體頻寬受限，大部分時間花在從 GPU 記憶體讀取 K/V，而不是矩陣乘法。每個 token 的成本為 O(N)，會隨目前 context 長度線性成長。

以典型的聊天機器人負載為例：8K token 的 system prompt、100 token 的使用者查詢，以及 300 token 的回覆。Prefill 在實際執行時間與金額成本上，大約都以 4:1 的比例高於 decode。快取省下的正是這一部分。

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 KV Cache：保留 Prefill 結果供 Decode 使用

「KV cache」原本指的是單次請求內的最佳化。在 decode 過程中，每個新生成的 token 都必須對所有先前 token 的 K 和 V 執行 attention。若每一步都重新計算，decode 就會從 O(N) 變成 O(N²)。因此，每個推論引擎都會將 prefill 產生的 K 和 V 保留在 GPU 記憶體中，並在整個 decode 階段重複使用。所有商用 LLM 都採用這種做法；沒有它，生成成本根本無法負荷。

供應商對外提供的「提示詞快取」，是這個概念的下一步延伸：請求結束後仍保留 KV cache，讓下一個具有相同前綴的請求重複使用。

1.4 記憶體與運算的取捨：TTL 為什麼存在

既然如此，供應商為什麼不把所有內容永久快取？因為 KV cache 非常龐大。

假設模型有 L 個 transformer layer、H 個 attention head、D 的 head 維度，而且每個值占用 B bytes（fp16 通常是 2），那麼 N 個 token 的 KV cache 大小為：

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

以 70B 級模型為例：80 層、經 grouped-query-attention 後有 8 個 KV head、head 維度為 128，並採用 fp16 權重。每個 token 大約需要 320 KB。32K token context 需要 ~10 GB 的 KV cache，而且這還只是一個請求。現代 H100 GPU 有 80 GB 記憶體，同一時間最多只能容納少數幾個這種請求。

PagedAttention（Kwon et al., 2023，vLLM 背後的論文）就是為了在 batch 層級解決這個核心限制。同一項限制也會在跨請求層級約束提示詞快取：

因此，供應商的 cache TTL 本質上就是一種記憶體驅逐政策：GPU 最終需要將記憶體提供給其他使用者的活躍工作負載，於是快取的前綴就會被驅逐。位於 HBM 的快取通常保留 5 分鐘；可分頁至 DRAM 的快取最多 1 小時；以磁碟為後端的快取則可保留數小時。

DeepSeek 的做法。 DeepSeek-V2 導入 Multi-head Latent Attention（MLA）。相較於標準 grouped-query attention，它能將 KV cache 壓縮約 4×（DeepSeek-AI, 2024）。正因為有這項壓縮，DeepSeek 才能將 KV cache 持久化到磁碟，而不是放在 HBM。這也讓它能使用更小的最低快取單位（64 token；位於 HBM 的快取通常是 1,024），並提供長得多的有效 TTL。

這也解釋了跨請求快取為何要求逐 token 完全相同的前綴。快取以 token ID 的雜湊值建立索引。只要有任何差異，就算只是一個字元造成不同的 tokenization，從那個位置起就會產生不同的 K 和 V。這一層沒有「模糊比對」；語意快取才會這麼做，但那是閘道中的另一套機制。

1.5 兩層快取

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

本系列後續內容，以及開發者實際上需要調校的大多數項目，都在第 2 層。

2. 兩項收益：成本與延遲

多數文章只把快取視為成本最佳化，這低估了它的價值。對面向使用者的聊天服務來說，正式環境團隊導入快取的更大原因，往往是延遲改善。

2.1 成本試算

定價頁面通常只列出價格，很少套用到真實工作負載中。以下用一個客服機器人為例：system prompt 為 8,000 token，每天有 100K 次查詢，每則使用者訊息為 200 token。模型採用 claude-sonnet-4-5，並依 Anthropic 公布的 2026 年費率計算：快取輸入收取 10%，寫入快取則加收至 125%。

未使用快取

• 每次呼叫的輸入：8,200 token × 基本輸入費率
• 單次呼叫成本（實測單一呼叫）：~$0.022
• 每月成本：100K × 30 × $0.022 = ~$66,000

使用提示詞快取

• 一次性快取寫入：8,000 token × 125% 加價（相較每月流量可忽略）
• 後續每次呼叫：8,000 token × 基本費率的 10% + 200 token × 基本費率 + 輸出
• 實際單次呼叫成本：~$0.003
• 每月成本：~$9,000

節省約 86%。 這是將 Anthropic 公布的折扣套用到實際輸入結構後的結果。後續的第 3 篇 — 教學會列出其他供應商的實測數據。

2.2 延遲改善：往往才是重點

Prefill 不只昂貴。只要 prompt 超過數百個 token，它通常也是首個 token 回應時間的最大來源。快取命中後，幾乎可以跳過整個 prefill。

以下數據於 2026-05-25 透過公開的 Synthorai 閘道測得，採用 streaming TTFT 與約 7,300 token 的穩定 system prompt：

數據來自單次執行與單一租戶。長 prompt（>5K token）的 TTFT 改善最明顯；短 prompt 的 prefill 占比太低，不足以主導延遲。Claude 的最大實測優勢在成本：讀取快取時，輸入成本約降低 88–89%。根據 Anthropic 公布的數據，當 prompt 達到 100K+ 時，TTFT 改善也會大幅累積。

在聊天 UI 中，TTFT 超過約 1 s，使用者就會明顯感受到延遲；第一段有用文字若超過 ~2 s，感受會更差。未使用快取的 10K token RAG prompt 顯然會超過這條線。使用快取後，相同工作負載的回應幾乎是即時的。

對有 15+ 個步驟的 agent loop 而言，節省 50% 成本已經很有價值，但延遲改善才是讓產品真正能上線的關鍵：15 個步驟 × 5s prefill = 每項任務有 75 s 的空等時間；使用快取後則是 15 × 0.5s = 7.5 s。

2.3 這對產品策略有什麼影響

常見錯誤是把快取當成「維運團隊負責的成本最佳化」，等產品上線後再補上。延遲改善表示，快取同樣是使用者體驗的一部分：

• TTFT 低於 1 s 的聊天機器人顯得反應靈敏；延遲 3 s 的同一個機器人則像是故障。
• retrieval 加 prefill 需要 4 s 的 RAG 產品，競爭力不如只需 1 s 的同類產品。
• 能在 20 s 內完成任務的 agent，勝過需要 90 s 的 agent。

決定模型與 prompt 結構時，就應同時規劃快取策略，而不是等產品上線三個 sprint 後才處理。

3. 快取新鮮度、TTL 與實際維運方式

TTL 是提示詞快取最常被問、卻最少被完整解釋的問題之一。需要先理解兩件事：

3.1 新鮮度有兩種意思，別混為一談

快取新鮮度 ≠ 回應內容的新鮮度。 這兩個不同概念經常被混在一起：

從模型品質來看，快取回應不會「過期」，它與未快取的結果在數學上完全相同。但如果你在 system prompt 裡放入「目前時間是 14:32:05」，又持續依賴快取命中，那麼在 TTL 到期前，「目前時間」都會停留在 14:32:05，模型也會很有自信地向使用者提供錯誤時間。

3.2 各供應商的 TTL 行為

預設 5 分鐘並非隨意決定。對熱門模型而言，這大致就是尖峰負載時 GPU 記憶體壓力允許的保留時間。如 §1.4 所算，單一大型 context 的 KV cache 可能占用數十 GB，供應商無法無限期保留。

3.3 TTL 的設計模式

以下三種模式已在正式環境證實有效：

模式 A — 維持 session 熱度。 聊天情境中，每輪對話通常只間隔數秒到數分鐘，自然就能維持快取有效。無須擔心 TTL，只要別把動態資料放在前綴即可。

模式 B — 為 batch 加入 heartbeat。 對於持續數小時的 batch job，每隔 TTL/2 傳送一次最小請求，以維持快取熱度。成本幾乎為零，只有少量輸入 token，並可避免大量快取同時被驅逐。

模式 C — 使用長 TTL 供應商進行冷儲存。 如果有一份 50K token 的文件，只會偶爾被查詢，例如一週內每小時一次，那麼 Gemini explicit cache（24 小時 TTL）或 DeepSeek 磁碟快取即使收取儲存費，仍會優於短 TTL 方案。

4. 每位開發者都應知道的通用原則

供應商提供的快取形式差異很大，可分為五種：explicit marker、全自動、hybrid、架構層級的磁碟後端，或完全不支援。下一篇文章會專門比較這些差異（第 2 篇 — 供應商比較與評估）。不過，無論使用哪個供應商，以下四項原則都適用，而且都直接源自前面說明的架構：

4.1 快取以 Prefix 為基礎，順序很重要

由於位置 i 的 K/V 取決於位置 1…i 的 token，供應商只能比對從 token 0 開始的連續前綴。只要位置 0 有一個字元改變，整段前綴就會失效。穩定內容放前面，變動內容放後面。 這不是經驗法則，而是 self-attention causal 結構的直接結果（§1.1）。

4.2 快取儲存的是 K/V，不是答案

快取命中不會回傳先前生成的答案，而是回傳先前計算完成的 K 和 V 向量。模型接著使用這些向量，針對目前問題生成新的回覆。這代表：

• 輸出品質與未使用快取的呼叫完全相同（§1.1）。
• 輸出仍會以一般方式呈現非確定性，temperature、top-p 等設定仍然有效。
• 從模型品質來看，快取回應永遠不會「過期」；只有 prompt 的內容，如時間戳記與價格，可能過期。請再參考 §3.1。

4.3 寫入快取是一項投資，不是免費的

部分供應商會收取寫入加價，例如 Anthropic 125%、Gemini explicit 125%。因此，使用新前綴的第一次呼叫，成本會高於完全不用快取。通常只要命中一次就能損益兩平，但如果所謂的「穩定」前綴在每個請求都改變，就會不斷支付寫入成本，卻得不到任何回報。依相關性排序檢索文件是最典型的反模式，尤其要留意。

4.4 不同供應商的快取 API 無法直接移植

cache_control（Anthropic）≠ cached_content（Gemini）≠ cache_id（Qwen）。如果應用程式必須支援多家供應商，就得維護三套整合，或在前方加上一層 Token Gateway 統一介面。第 2 篇會詳細說明。

5. 提示詞快取等於白省錢嗎？

幾乎是。符合以下條件就會有回報：

• Prompt 具有穩定前綴，例如 system prompt、知識庫、工具 schema
• 呼叫頻繁或彼此相連，例如同一個 session、batch 工作負載、執行中的 agent
• Prompt 結構能讓穩定內容放在最前面

只要符合這三點，通常不必更換模型，就能將支出降低 50–90%，並讓 TTFT 加快 3–20×。

下一篇：第 2 篇 — 供應商快取比較與評估框架會把上述架構概念轉成 Claude、OpenAI、Gemini、DeepSeek 與 Qwen 的逐項功能比較，並提供一套評估標準，協助你為工作負載選出合適的供應商。

快速開始：使用 OpenAI SDK 呼叫所有供應商

Synthorai 提供 OpenAI 相容 endpoint。只要把官方 openai SDK 指向這個 endpoint，所有模型（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 欄位回傳提示詞快取命中 metadata，另外也會提供以 USD 計價的 cost 欄位，因此不必在本機維護各供應商的定價矩陣。

常見問題

LLM 提示詞快取與語意快取相同嗎？ 不同。提示詞快取以前綴為基礎，針對 prompt 開頭完全相同的 token 重用 K/V 值。語意快取則透過 embedding 在語意層級進行比對，並回傳先前的回覆。兩者都有用途，好的 Token Gateway 會分層結合這兩種機制。

提示詞快取會改變模型輸出嗎？ 不會。K 和 V 是輸入 token 的確定性函數（§1.1）。模型使用快取 K/V 產生的 logits，與重新計算 K/V 所產生的結果在數學上完全相同。快取純粹是效率最佳化，不會影響品質。

為什麼 cache TTL 這麼短，不能永久保留嗎？ KV cache 非常龐大（§1.4：70B 模型的每個 32K context 約需 ~10 GB）。GPU 記憶體是瓶頸；伺服器需要把記憶體提供給活躍工作負載時，就會驅逐快取。以磁碟為後端的快取（DeepSeek）可保留數小時，但記憶體內快取通常做不到。

KV cache 與 prompt cache 有什麼差別？ KV cache 是推論期間使用的記憶體內資料結構。「Prompt cache」則是跨請求重用這份 KV cache。也就是上方 §1.5 的第 1 層與第 2 層。

快取的 prompt 是否可能因過期而降低品質？ 從模型角度來看，不會。但如果 prompt 包含時效性資訊，從內容角度來看就會。快取儲存的是 K/V 向量，不是現實世界的事實。請參考 §3.1。

如何衡量快取命中率？ 每個供應商都會透過回應的 usage object 回傳相關資訊：cache_read_input_tokens（Anthropic）、cached_tokens（OpenAI）、cached_content_token_count（Gemini）、prompt_cache_hit_tokens（DeepSeek）。請在 logging pipeline 中追蹤這些欄位。

參考資料與來源： 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 架構 · Anthropic 提示詞快取文件 · OpenAI 提示詞快取文件 · Google Gemini Context 快取文件 · DeepSeek KV Cache 指南 · Alibaba Bailian Context Cache

← 返回部落格