LLM 提示詞快取 #1：KV 快取與 TTL 的運作原理

TL;DR — LLM 提示詞快取並不是外掛式的最佳化手段；它本就是 Transformer 架構計算注意力方式的自然產物。一旦你理解了為什麼穩定前綴的 Key/Value 向量在數學上可以重用，真正令人驚訝的便是它的雙重收益：大幅降低成本（50–90%）以及大幅降低首字延遲（5–20×）。本文是四篇系列文章的第 1 篇，講解快取存在的架構原因、決定快取是否划算的記憶體-算力取捨，以及每位開發者都需要理解的 TTL 行為。第 2 篇將深入各家供應商的具體實作。

系列：四篇之第 1 篇 — 快取原理 · 下一篇：第 2 篇 — 供應商比較與評估 · 第 3 篇 — 可執行程式碼教學 · 第 4 篇 — 依使用情境挑選最佳 LLM

為什麼你的 AI 應用程式 Token 帳單漲得比使用者還快

如果你在做聊天機器人、RAG 應用程式或 AI 代理，你大概撞過同一堵牆：帳單翻倍，使用量卻沒翻倍。打開請求記錄，你會發現同一份數千 token 的系統提示詞、同樣的工具說明、同樣的知識庫片段——每次呼叫都在重新傳送。

這就是 LLM 推論的核心經濟難題：模型是無狀態的。每個請求都從頭重新處理整個情境。一份 8K token 的系統提示詞被呼叫 1,000 次，就等於 800 萬 token 的重複工作。你要為每一個 token 付費——而你的使用者要為每一個 token 等待。

提示詞快取解決了這個問題。但與大多數效能技巧不同，它並不是被加進架構裡的——它是 Transformer 注意力定義方式的自然結果。一旦你看清這一點，文章的其餘部分（定價、TTL、供應商差異）就會自然順暢地理順。

1. LLM 為何會有快取：一次 Transformer 推論走查

這一節是幾乎所有「提示詞快取」教學都跳過的部分。它解釋了快取為何會存在——以及為什麼供應商給出的折扣並不是隨意的行銷數字，而是反映了真實的 GPU 經濟學。

1.1 一個方程式概括自注意力

僅解碼器（decoder-only）的 Transformer（GPT-4、Claude、Gemini、DeepSeek、Qwen 都屬於這一族系）透過反覆施加自注意力來處理 token。對於一個有 N 個 token 的序列，每個 token 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）。 在生成過程中，token i 只能關注位置 ≤ i 的 token。注意力矩陣是下三角形的：早期 token 的 K 和 V 向量會被之後的每一個 token 使用，但之後的 token 永遠不會修改它們。

性質 2 —— K 和 V 只依賴前綴。 因為它們是由位置 1…i 的輸入嵌入經固定權重矩陣計算而來，位置 i 處的 K 和 V 向量是位置 1…i 這些 token 的確定性函式——而且僅依賴這些 token。位置 i+1 的任何資訊都無法改變 K_i 或 V_i。

由此立即得出結論：如果兩個請求共享一段長度為 P 的相同前綴，那麼 K 和 V 的前 P 列是逐位元完全相同的。

這就是提示詞快取的全部理論基礎。其餘的一切都是工程實作。

1.2 推論的兩個階段

現代 LLM 推論分為兩個截然不同的階段，它們消耗 GPU 時間的方式大不相同。這一劃分在 Efficiently Scaling Transformer Inference（Pope 等人，2022）中有詳盡記載。

預填（Prefill）階段。 模型一次性吞入完整提示詞。對於每一層，它為每個輸入 token 計算 Q、K、V 並執行自注意力。預填是**算力受限（compute-bound）**的：它會讓 GPU 的矩陣乘法單元滿載。由於注意力矩陣的存在，成本隨提示詞長度按 O(N²) 增長。

解碼（Decode）階段。 模型以自迴歸方式一次產生一個輸出 token。在第 t 步，只計算新 token 的 Q；它會對之前所有 token 的 K/V 做注意力。解碼是**記憶體頻寬受限（memory-bandwidth-bound）**的——大部分時間花在從 GPU 記憶體讀取 K/V，而非做乘法。成本按每個 token O(N) 增長（與目前情境長度成線性）。

對於典型的聊天機器人負載（8K token 系統提示詞 + 100 token 使用者查詢 + 300 token 回覆），預填在牆鐘時間和金錢成本上以大約 4:1 的比例佔主導。這正是快取所節省的部分。

單次呼叫拆解（8K 提示詞，300 輸出 token，Claude 級模型）：

  ████████████████████████████████░░░░░░░░  Prefill：約 80% 算力
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode： 約 20% 算力

1.3 KV 快取：把預填的成果留給解碼用

「KV 快取」最初指的是請求內部的一種最佳化。在解碼過程中，每個新生成的 token 都需要對之前每個 token 的 K 和 V 做注意力。如果每一步都重新計算這些，O(N) 的解碼就會變成 O(N²) 的解碼。因此每個推論引擎都會把預填得到的 K 和 V 存在 GPU 記憶體裡，並在整個解碼階段重用。這是普適做法——每個商用 LLM 都這麼做。它正是讓生成在算力上變得可行的關鍵。

而供應商以「提示詞快取」形式對外公開的，是更進一步的推廣：在請求結束後仍保留 KV 快取，並在下一個共享相同前綴的請求中重用它。

1.4 記憶體-算力取捨（TTL 為何存在）

那為什麼供應商不乾脆把一切都永久快取呢？因為 KV 快取極其龐大。

對於一個有 L 個 Transformer 層、H 個注意力頭、頭維度為 D、每個值佔 B 位元組（fp16 通常為 2）的模型，N 個 token 的 KV 快取大小為：

KV 快取大小  =  2 × L × H × D × B × N
                ↑   ↑   ↑   ↑   ↑   ↑
                K&V 層  頭  頭維 位元 token

對於一個 70B 級別、80 層、8 個 KV 頭（經分組查詢注意力 GQA 後）、頭維度 128、fp16 權重的模型，大約是每 token 320 KB。一個 32K token 的情境 = 約 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——而這反過來又使得最小快取單元小得多（64 token，而 HBM 常駐快取為 1,024 token），有效 TTL 也長得多。

這也是為什麼跨請求快取需要逐 token 完全相同的前綴。快取是按 token ID 的雜湊索引的，任何分歧——哪怕只有一個字元導致重新分詞不同——都會從該點起產生不同的 K 和 V。這一層沒有「模糊比對」（那是語意快取做的事，但那是閘道中的另一種機制）。

1.5 兩層快取

┌──────────────────────────────────────────────────────────────┐
│  第 1 層：請求內 KV 快取（始終開啟，每個供應商都有）         │
│  → 讓解碼保持 O(N) 而非 O(N²)                                │
│  → 你無需關注它；供應商自然會做                              │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  第 2 層：跨請求提示詞快取（本系列要講的省錢又省時的部分）   │
│  → 在前綴比對的請求間重用預填 K/V                            │
│  → 公開形式：顯式 / 全自動 / 混合                            │
│  → 受 TTL 約束（由記憶體淘汰驅動）                           │
└──────────────────────────────────────────────────────────────┘

本系列其餘內容——也是你身為開發者要調校的大部分內容——都位於第 2 層。

2. 雙重勝利：成本與延遲

大多數文章把快取定位為一種成本最佳化。這低估了它。延遲收益往往是生產團隊採用快取的更主要原因，尤其是面向使用者的聊天情境。

2.1 成本計算

定價頁給出了頭條數字，卻很少展示它們套用到真實負載上的結果。以一個客服機器人為例：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 延遲收益（往往是更重要的故事）

預填不僅昂貴——對於任何超過幾百 token 的提示詞，它都是首字延遲（TTFT）的最大單一貢獻者。快取命中讓你幾乎可以跳過它的全部。

針對公開的 Synthorai 閘道實測的串流 TTFT，2026-05-25，約 7,300 token 的穩定系統提示詞：

單次執行、單租戶。TTFT 收益在長提示詞（>5K token）上最明顯；對於短提示詞，預填佔比太小，不足以主導延遲。Claude 實測的最大收益是成本（快取讀取時輸入約省 88–89%）——對於 100K+ 量級的提示詞規模，按 Anthropic 公布的數字，TTFT 收益會大幅疊加。

對於聊天 UI，使用者有意識地感知到延遲的閾值大約是 TTFT 1 s、首段有用文字 2 s 左右。一個 10K token 的 RAG 提示詞在不快取時穩穩越過這條線。有了快取，同樣的負載感覺是即時的。

對於 15 步以上的代理迴圈，成本故事不錯（省 50%），但真正讓產品可以上線的是延遲故事：15 步 × 5s 預填 = 每個任務 75 s 的空等時間 → 有了快取，15 × 0.5s = 7.5 s。

2.3 為何這對產品策略至關重要

一個常見的錯誤是把快取當成「維運做的成本最佳化」——一個上線後再外掛上去的東西。但延遲收益意味著快取同時是 UX 表層的一部分：

• 一個 TTFT 低於 1 s 的聊天機器人感覺鮮活；同一個機器人在 3 s 時感覺壞了。
• 一個檢索+預填耗時 4 s 的 RAG 產品，會輸給同樣產品耗時 1 s 的版本。
• 一個 20 s 完成任務的代理，會勝過耗時 90 s 的那個。

你應該在決定模型和提示詞結構的同時就決定快取策略——而不是上線三個 sprint 之後才考慮。

3. 快取新鮮度、TTL 與維運模型

TTL 問題是提示詞快取中被問得最多、解釋得最少的部分之一。有兩件事需要理解：

3.1 新鮮度有兩層含義——別混為一談

快取新鮮度 ≠ 回應新鮮度。 兩個截然不同的概念經常被混淆：

換句話說：快取的回應在任何模型品質意義上都不是「陳舊」的。它們在數學上與未快取的回應完全相同。但如果你把「目前時間是 14:32:05」放進系統提示詞並依賴快取命中，你的「目前時間」會一直停留在 14:32:05 直到 TTL 過期，而你的模型會自信滿滿地就此向使用者撒謊。

3.2 各供應商的 TTL 行為

5 分鐘的預設值並非隨意——它大致是熱門模型在尖峰負載下的 GPU 記憶體壓力時間窗。正如我們在 §1.4 計算的，一個大情境的 KV 快取可達數十 GB；供應商無力無限期持有它們。

3.3 面向 TTL 的設計

三種在生產中行之有效的模式：

模式 A —— 保持工作階段溫熱。 對於聊天，自然的請求節奏（每輪之間數秒到數分鐘）本身就能讓快取存活。不用擔心 TTL；只要別把動態資料放進前綴就行。

模式 B —— 為批次處理設定心跳。 對於跨越數小時的批次處理作業，每隔 TTL/2 傳送一個最小請求以保持快取溫熱。成本基本為零（幾個輸入 token），並能避免快取淘汰風暴。

模式 C —— 用長 TTL 供應商做冷儲存。 如果你有一份 50K token 的文件，被零星查詢（例如一週內每小時一次），那麼 Gemini 顯式快取（24 小時 TTL）或 DeepSeek 磁碟快取會勝過短 TTL 的替代方案，儘管要付儲存費。

4. 每位開發者都應了解的普適原則

各家供應商以五種迥然不同的形態公開快取——顯式標記、全自動、混合、架構層面的落碟，或者乾脆沒有。我們用下一篇文章專門做這個比較（第 2 篇 — 供應商比較與評估）。但有四條原則無論哪家供應商都適用，並直接源自我們剛剛走查過的架構：

4.1 快取基於前綴——順序很重要

因為位置 i 處的 K/V 依賴位置 1…i 的 token，供應商只能比對從 token 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. 提示詞快取是天上掉的錢嗎？

差不多。它在以下情況下能帶來回報：

• 你的提示詞有一段穩定前綴——系統提示詞、知識庫、工具 schema
• 你的呼叫是頻繁的或彼此關聯的——同一工作階段、批次處理負載、進行中的代理執行
• 你能把提示詞組織成讓穩定內容位於最前面

滿足這三點，你通常會看到開銷降低 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 欄位，這樣你就不必在本地維護一張按供應商區分的定價表。

常見問題

LLM 提示詞快取與語意快取是一回事嗎？ 不是。提示詞快取是基於前綴的——它在提示詞開頭對精確的 token 級比對重用 K/V 值。語意快取在語意層面比對（透過嵌入），並返回一個先前的回應。兩者都有用，好的 Token 閘道會分層把它們結合起來。

提示詞快取會改變模型的輸出嗎？ 不會。K 和 V 是輸入 token 的確定性函式（§1.1）。模型從快取 K/V 產生的 logits 與從重新計算的 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

← 返回部落格