LLM 提示快取 #2：對比 Claude、GPT、Gemini、DeepSeek

太長不看 —— 五家主流 LLM 供應商以五種截然不同的形態暴露提示快取：顯式標記（Claude）、全自動（GPT-5、DeepSeek-v4）、隱式+顯式混合（Gemini、Qwen），或架構層面的磁碟落地（DeepSeek 的 MLA）。本文給你逐項功能對比，以及一套五維評估框架，協助你針對自己的工作負載為它們評分——成本、命中率可預測性、延遲、TTL 契合度與 API 易用性。架構背景見第 1 篇：快取原理；實測數字與可執行的 Python 見第 3 篇：教學。

系列：全 4 篇之第 2 篇 · 上一篇：第 1 篇 —— 快取原理 · 下一篇：第 3 篇 —— 可執行程式碼教學 · 第 4 篇 —— 按使用情境選最佳 LLM

1. LLM 快取類型分類法

在逐家供應商展開之前，有四個設計維度值得先釐清：

1.1 控制方式：顯式 vs 隱式 vs 混合

• 顯式 —— 開發者標記提示中哪些部分要快取（Anthropic Claude cache_control）。控制力最強；需要改程式碼。
• 隱式 / 自動 —— 供應商自動偵測相符的前綴（OpenAI GPT-5、DeepSeek-v4）。零程式碼改動；無法強制命中。
• 混合 —— 兩種模式都可用；按呼叫逐次選擇（Gemini、Qwen）。

1.2 持久化：記憶體 vs 磁碟落地

由供應商的 KV 快取架構決定，而非 API 表層決定。

• 記憶體（HBM） —— 快取存活於 GPU 記憶體，存活時間短（分鐘級），最小分塊大（1,024 個權杖）。多數供應商的預設方式。
• 磁碟落地 —— 快取持久化到 SSD/NVMe，TTL 長得多、粒度更細。DeepSeek 已大規模上線此能力，得益於其多頭潛在注意力（MLA）壓縮，將 KV 快取縮小約 4 倍（DeepSeek-AI，2024）。

1.3 粒度：比對解析度

多小的前綴就能拿到折扣？

• 64 個權杖 —— DeepSeek（業界最細）
• 128 個權杖 —— OpenAI（比對增量）
• 1,024 個權杖 —— Claude、OpenAI、Gemini、Qwen 的最小可快取分塊

更細的粒度意味著部分前綴重疊也能算數——對小幅提示變動寬容得多。

1.4 物件模型：逐呼叫標記 vs 具名快取物件

• 逐呼叫標記 —— 每個請求內聯要快取的內容，由供應商做雜湊（Claude、OpenAI、DeepSeek、Qwen 隱式）。
• 具名快取物件 —— 開發者透過獨立的 API 呼叫建立快取，取得 cache_id，後續引用它（Gemini 顯式、Qwen 顯式）。以額外的儀式感換取顯式的生命週期控制。

這四個維度相互交織。一家供應商的方案，就是由它在每個維度上的位置來描述的。下一節會逐家展開。

2. 逐家供應商深度剖析

2.1 Anthropic Claude —— 顯式、記憶體、1,024-權杖粒度

主力模型（2026-05）： claude-haiku-4-5、claude-sonnet-4-5 / 4-6、claude-opus-4-5 / 4-6 / 4-7。

快取 API。 在你的 system 或 messages 陣列中任意位置最多標記四個 cache_control 斷點。快取命中花費約為基礎輸入費率的 10%；快取寫入花費 125%（25% 的溢價）。預設 TTL 為 5 分鐘滑動（每次命中都重置），另有 1 小時選項。

定價形態。 Anthropic 在其定價頁按模型公布每百萬權杖費率；快取折扣在整個系列中保持一致。對於 claude-sonnet-4-5 上一個 8,000-權杖的 system 提示、每天 10 萬次呼叫，一旦前綴變熱，每次呼叫成本大約下降 8–10 倍——單次命中即可回本。

TTL 行為。 預設 5 分鐘滑動——每次命中都把到期時間往後推 5 分鐘。1 小時 TTL 讓寫入成本翻倍，但對任何閒置間隔 > 5 分鐘的工作負載都是必需的。

粒度。 1,024-權杖最小值。雜湊基於精確的權杖序列；最前面改一個字元就會讓整個前綴失效。

API 易用性。 最高。多斷點設計讓你能獨立快取「永不變」+「很少變」+「逐任務變」——對於提示各段以不同節奏變化的代理與 RAG 工作負載，這是同類最佳。

坑點。

• 忘了加 cache_control 就意味著完全沒有快取——不像 GPT 或 DeepSeek，這裡沒有隱式兜底。
• 快取雜湊即便在 tool/function 陣列內部也對順序敏感——要確定性地排序它們。
• 5 分鐘預設值讓 Claude 不適合沒有顯式保活的零散批次任務。
• 如果你透過閘道呼叫 Claude，請確認閘道支援 Anthropic 原生的 /v1/messages 路徑並帶 cache_control 標記（OpenAI 相容的 /chat/completions 路徑通常不會傳遞這些標記——用指向閘道 base URL 的 Anthropic SDK）。

最適合。 長脈絡代理、帶穩定 system 提示的多輪對話、帶分層快取的結構化 RAG。

2.2 OpenAI GPT-5.x —— 自動、記憶體、1,024-權杖粒度

主力模型（2026-05）： gpt-5.4-nano、gpt-5.4-mini、gpt-5.2、gpt-5.4-pro、gpt-5.5-pro。程式碼用的 Codex 變體：gpt-5.2-codex、gpt-5.3-codex。

快取 API。 無需操作——對每個 ≥1,024 權杖的請求自動生效。快取命中按輸入費率的 50% 計費；無寫入溢價。比對增量：128 個權杖。

定價形態。 OpenAI 在其定價頁公布每百萬權杖費率。快取輸入打 5 折；輸出不變。

實測（2026-05-25，約 6,900-權杖 system 提示）：

* gpt-5.4-mini 命中那一輪的補全遠短於未命中那一輪；此處的成本差混入了快取折扣與補全長度的變化。5 倍的延遲下降（3.63 → 0.73 s）才是更乾淨的訊號。

TTL 行為。 確切數值未公布；現場回報顯示 5–60 分鐘不等，取決於負載和前綴熱度。熱門的共享前綴存活更久（LRU 偏向它們）。

API 易用性。 微不足道——現有程式碼照常執行。記錄 prompt_tokens_details.cached_tokens 來衡量命中率。

坑點。

• 無法強制命中。如果你的流量產生唯一前綴，你什麼都拿不到。
• 5 折的折扣比 Claude/DeepSeek 的 90%/75% 淺（與 Gemini 隱式的約 25% 相當）。
• 串流有時只在最後一個 chunk 回報快取命中——要仔細埋點並傳 stream_options={"include_usage": True}。

最適合。 既有的用 GPT 的程式碼庫，改造成本超過邊際節省。前綴重複天然較高的突發流量。

2.3 Google Gemini —— 混合、記憶體、具名快取物件

主力模型（2026-05）： gemini-2.5-flash、gemini-2.5-pro、gemini-3-flash-preview、gemini-3.1-pro-preview、gemini-3.1-flash-lite-preview。

快取 API。 兩種模式：

• 隱式：自動，像 GPT 一樣。快取權杖按輸入費率的約 25% 計費。無儲存費、無需設定。
• 顯式：透過獨立的 API 呼叫建立一個 cachedContent 物件。在後續請求中按名稱引用它。快取權杖按約 10%（更低）計費，但你要按每百萬權杖支付一筆每小時的儲存費。

定價形態。 長脈絡是 Gemini 的強項；定價按脈絡長度級距遞增（低於 20 萬 vs 高於 20 萬的門檻，對應更高的每權杖費率）。

實測（2026-05-25）：

TTL 行為。 隱式：分鐘級，未揭露。顯式：開發者設定，預設 1 小時，最高 24 小時。

API 易用性。 顯式快取需要兩步流程（建立 → 引用）。cachedContent 的生命週期（建立、更新 TTL、刪除）由你負責。

坑點。

• 儲存費是低用量顯式快取的致命傷。 始終按你的呼叫頻率計算回本點。
• 隱式快取命中率波動大；不要依賴它做成本建模。
• 快取物件綁定區域——多區域應用需要複製快取。
• gemini-*-pro 是推理模型：max_tokens 太小時，補全會被隱藏的思考消耗掉，你會看到 completion_tokens=0。在任何面向使用者的路徑上把 max_tokens 提到 ≥256。

最適合。 一份大文件（>2 萬權杖）每小時被查詢 10+ 次。影片問答。對企業 PDF 的多模態 RAG。

2.4 DeepSeek-v4 —— 自動、磁碟落地、64-權杖粒度

主力模型（2026-05）： deepseek-v4-flash（通用），deepseek-v4-flash（本代也涵蓋 coder 類工作負載）。

快取 API。 自動，像 GPT 一樣——但由 MLA 壓縮驅動，使快取緊湊到足以持久化到磁碟。快取命中按輸入費率的約 25% 計費；無寫入溢價。最小比對：64 個權杖。

定價形態。 DeepSeek 定價頁以人民幣計價。命中率大致換算為 75% 的輸入成本削減。

實測（2026-05-25）：

TTL 行為。 小時級，對高流量前綴有時更久。磁碟落地儲存意味著快取能挺過會讓其他廠商記憶體快取被驅逐的 GPU 記憶體壓力。

粒度。 64-權杖最小值是業界最小的。小幅提示編輯會讓大部分前綴仍然相符，而不是像 1,024-權杖供應商那樣完全失效。

API 易用性。 OpenAI 形態的 API；換 base URL 即可。標準的 prompt_tokens_details.cached_tokens 欄位。

坑點。

• 僅限 DeepSeek 系列模型。無法將此快取用於其他模型家族。
• 英文上品質優異，但在最難的推理基準上落後於 Claude/GPT-5。

最適合。 中文工作負載（成本）。粒度重要的高頻前綴工作負載（檢索順序不穩定的 RAG）。成本敏感的批次任務。

2.5 阿里 Qwen3 —— 混合、記憶體、具名快取物件 + 隱式

主力模型（2026-05）： qwen3-max、qwen3.5-plus、qwen3.5-flash。視覺變體：qwen3-vl-plus、qwen3-vl-flash。

快取 API。 兩種模式：

• 隱式：常開，像 GPT 一樣。快取部分按輸入費率的約 20% 計費。
• 顯式：透過 API 建立帶自訂 TTL 的快取。命中約 10%，寫入 125%。

實測（2026-05-25）：

TTL 行為。 預設 5 分鐘，可按快取物件設定。顯式為滑動視窗；隱式為短的固定 TTL。

API 易用性。 隱式是 GPT 形態（零工作量）。顯式是帶快取生命週期的兩步流程。

坑點。

• 目前只有 qwen3-max 和 qwen3.5-plus 支援顯式快取。
• 多區域（新加坡、美國）可用性正在逐步推出——在依賴它處理非中國資料前請確認區域。
• 相對 Anthropic/OpenAI 的文件存在缺口——建議做經驗性測試。

最適合。 需要嚴格快取控制的中國企業工作負載。已在阿里雲上的客戶。

3. 並排對比

3.1 折扣結構（廠商文件，2026-05）

3.2 TTL、粒度與持久化

3.3 在 7K-權杖前綴上的實測延遲（2026-05-25）

† Claude 各行是透過 Anthropic 原生 /v1/messages 端點帶 cache_control 標記測得的（見第 3 篇 §2）。Claude 最大的收益在成本上（輸入約省 88–89%——完整成本表見第 3 篇 §2）；按 Anthropic 公布的數字，對於 10 萬+ 權杖的提示，TTFT 改善會急劇放大。

單次循序執行，無並行負載。你的數字會隨區域、時段和競爭租戶負載而變動。

4. 五維評估框架

像「Claude 省 90%」這樣的標題很有意思，但很少能告訴你該選什麼。針對你自己的工作負載，為每家供應商在這五個維度上評分，然後按你在意的程度加權。

4.1 每百萬權杖的有效成本（按命中率加權）

不要比基礎價——要比你真實命中率下的期望成本：

effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate

70% 前綴重複（典型聊天機器人）的算例：

• Claude：約 90% 折扣 × 0.7 命中 + 25% 寫入 × 0.3 → 有效 ≈ base × 0.45
• GPT-5：約 50% × 0.7 + 0 → 有效 ≈ base × 0.65
• Gemini 隱式：約 75% × 0.7 + 0 → 有效 ≈ base × 0.48
• DeepSeek-v4：約 75% × 0.7 + 0 → 有效 ≈ base × 0.48

乘以每家廠商各自的實際基礎費率（各家不同）才能得到可比的美元數字。評分：為你的工作負載計算 effective_cost；越低越好。

4.2 命中率可預測性

• 顯式快取者（Claude、Qwen 顯式、Gemini 顯式）—— 可預測性高。你標了它，它就會命中（TTL 內）。
• 自動快取者（GPT-5、DeepSeek-v4、Gemini 隱式、Qwen 隱式）—— 取決於前綴相似度以及供應商負載（LRU 驅逐）。

對於與成本掛鉤的 SLA，優先選顯式。對於盡力而為的最佳化，自動也行。

4.3 TTL ↔ 流量節奏契合度

4.4 快取未命中下的延遲

一家命中快但未命中慢的供應商，如果你的命中率不高，仍然有問題。比較 §3.3 裡的兩個數字，並按期望命中率加權。

4.5 API 易用性與遷移成本

• 遷移成本最低：GPT-5 ↔ DeepSeek-v4（都是 OpenAI 形態，都是自動快取）。
• 中等：GPT-5 → Gemini 隱式（不同 SDK，無快取程式碼要重寫）。
• 高：GPT-5 → Claude（必須加 cache_control，重構提示分層）。
• 最高：在沒有閘道的情況下從任意單家遷到多供應商（多套快取 API）。

5. 按工作負載形態的快速結論

6. 遷移考量

如果你的評分說該換，有三件事要規劃：

資料遷移。 快取前綴不會在供應商之間轉移——每次切換都是冷啟動。為預熱期預留幾個小時高於平常的成本。

提示重新架構。 Anthropic 的多斷點設計鼓勵一種分層提示結構，它對任何供應商其實都更好——重構一次也惠及非 Claude 路徑。

透過閘道避險。 如果你拿不準，就透過一個 Token Gateway 路由。你保留了選擇彈性而不必押注單一廠商，代價是多一跳，以及（取決於閘道）可能失去對廠商專屬快取控制的存取。關於 Synthorai 閘道實際做了什麼、以及哪些說法你該持懷疑態度，見第 3 篇 §9。

7. 隨時間變化的內容

關於這些對比的持久性提個醒：本文中的數字會變動。快取已成為價格競爭性的特性，供應商每隔幾個月就更新其方案。有兩件事值得關注：

• TTL 延長。 Anthropic 的 1 小時選項已正式可用；Gemini 可能延伸到多天。預期 TTL 焦慮會緩解。
• 粒度。 OpenAI 和 Anthropic 最終很可能放棄其 1,024-權杖最小值；DeepSeek 的 64-權杖門檻已設立了新的預期。

當折扣趨同時，差異化因素將變成 API 易用性和延遲——而非標題上的節省。

下篇預告：第 3 篇 —— 提示快取教學：可執行的 Python 把上面的架構圖景變成可執行的程式碼，並把 §3.3 的延遲表復現為一個你可以自己跑的基準測試。

常見問題

綜合各方面考量，哪家 LLM 供應商的提示快取最便宜？ 在同等命中率（約 75%）下，按我們 2026-05 的實測，中文工作負載選 deepseek-v4-flash、英文選 gemini-2.5-flash 隱式，是每百萬權杖有效成本最便宜的。claude-sonnet-4-5 擁有最深的單次呼叫折扣（約 90%）但基礎價更高——當命中率 >85% 時它勝出。把你自己的命中率代入 §4.1 的公式。

為什麼 Gemini 在低用量工作負載上更貴？ 顯式快取的每小時儲存費會吃掉折扣，除非你頻繁查詢快取。對於低用量工作負載，用 Gemini 隱式快取（無儲存費，約 25% 折扣）。

我能把 Claude 的 cache_control 用在 OpenAI 上嗎？ 不能直接用——它們是各自獨立的快取實作。在 OpenAI 相容的 /chat/completions 端點上，該欄位對非 Anthropic 模型通常是個空操作（那些模型本來就自動快取）。對於 Claude 具體而言，請用 Anthropic 原生的 /v1/messages 端點並帶上標記。

DeepSeek 的 MLA 架構是專有的嗎？ 論文（DeepSeek-AI 2024）是公開的。其他供應商可以採用 MLA 式的 KV 壓縮，但這需要重新訓練基礎模型——不是一個執行時開關。截至 2026-05，DeepSeek 仍是唯一在生產中上線它的主流供應商。

開源自架模型怎麼樣？ vLLM、SGLang 和其他推論引擎原生支援前綴快取（PagedAttention 論文是其基礎）。如果你在 H100/H200 上自架，可以用 LMCache 或類似方案實作磁碟落地快取。這裡的定價分析只適用於託管服務——自架的經濟帳完全不同。

為什麼這個對比裡沒有 Mistral、Cohere 或 Llama API 供應商？ 截至 2026-05，它們的快取方案不夠成熟。Mistral 的快取在早期試用階段；Cohere 不暴露顯式快取；Llama API 供應商（Groq、Together、Replicate）差異很大。等它們的特性集穩定後再回頭看。

來源：Anthropic Prompt Caching · OpenAI Prompt Caching · Google Gemini Context Caching · DeepSeek KV Cache · Alibaba Bailian Context Cache · DeepSeek-V2 / MLA paper · PagedAttention / vLLM (Kwon et al. 2023)。實測數字來自 https://synthorai.io/v1，於 2026-05-25 測得。

← 返回部落格