哪家 LLM 提示詞快取最便宜？5 家供應商比較（2026）

TL;DR — 五家主要 LLM 供應商的提示詞快取設計截然不同：Claude 採顯式標記、GPT-5.x 與 DeepSeek-v4 全自動、Gemini 與 Qwen 則結合隱式與顯式模式；DeepSeek 的 MLA 架構還支援磁碟持久化。本文逐項比較各家的功能，並提供一套 5 維度評估框架，讓你依自己的工作負載評分：成本、命中率可預測性、延遲、TTL 適配度，以及 API 易用性。架構背景請見第 1 篇：快取原理；實測數據與可執行的 Python 程式碼則在第 3 篇：實作教學。

系列文章：第 2 篇，共 5 篇 · 上一篇：第 1 篇 — 快取原理 · 下一篇：第 3 篇 — 可執行程式碼教學 · 第 4 篇 — 各使用情境的最佳 LLM · 第 5 篇 — LangChain 整合

1. LLM 快取類型分類

逐一分析各家供應商前，先釐清四個設計面向：

1.1 控制方式：顯式、隱式或混合

• 顯式 — 開發者標記提示詞中要快取的部分（Anthropic Claude 的 cache_control）。控制力最高，但需要修改程式碼。
• 隱式／自動 — 供應商自動偵測相符的前綴（OpenAI GPT-5.x、DeepSeek-v4）。不必修改程式碼，但也無法強制命中。
• 混合 — 兩種模式都能使用，可在每次呼叫時選擇（Gemini、Qwen）。

1.2 持久性：記憶體或磁碟

這取決於供應商的 KV cache 架構，而不是 API 介面。

• 記憶體（HBM） — 快取存放於 GPU 記憶體，生命週期短（數分鐘），最小區塊較大（1,024 個 token）。多數供應商預設採用這種方式。
• 磁碟 — 快取持久化至 SSD/NVMe，TTL 長得多，粒度也更細。DeepSeek 已大規模部署這項設計，關鍵是其 Multi-head Latent Attention（MLA）壓縮技術，可將 KV cache 縮小約 4×（DeepSeek-AI，2024）。

1.3 粒度：比對解析度

多短的前綴可以獲得折扣？

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

粒度越細，前綴只有部分重疊時也能計入，對提示詞的小幅變動寬容得多。

1.4 物件模型：每次呼叫標記或具名快取物件

• 每次呼叫標記 — 每個請求都內嵌要快取的內容，再由供應商計算 hash（Claude、OpenAI、DeepSeek、Qwen 隱式模式）。
• 具名快取物件 — 開發者透過獨立 API 呼叫建立快取，取得 cache_id，之後再引用（Gemini 顯式模式、Qwen 顯式模式）。設定流程較多，但能明確控制生命週期。

這四個面向會互相影響。每家供應商的方案，都可以用它在各面向上的位置來描述。下一節將逐一分析。

2. 各供應商深入分析

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

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

GPT-5.6 更新（2026-06）： GPT-5.6 系列已改變以下規則。現在快取寫入按輸入費率的 1.25x 計費；若要可靠比對，必須提供 prompt_cache_key；此外也新增顯式的 30 分鐘 TTL 中斷點。本文表格描述的是 GPT-5.5/5.4 的行為；5.6 請參閱 GPT-5.6 成本指南與我們實測的快取最低門檻。

快取 API。 可在 system 或 messages 陣列的任意位置設定最多四個 cache_control 中斷點。快取命中的費用約為基本輸入費率的 10%；快取寫入則按 125% 計費（加價 25%）。預設 TTL 是滑動式 5 分鐘，每次命中都會重新計時；另有 1 小時選項。

計價方式。 Anthropic 在定價頁面公布各模型每百萬 token 的費率，整個模型系列的快取折扣一致。以 claude-sonnet-4-5 為例，若 system prompt 有 8,000 個 token、每天呼叫 100K 次，前綴預熱後，每次呼叫成本約可降至原本的 1/8 至 1/10；命中一次就能損益兩平。

TTL 行為。 預設為滑動式 5 分鐘，每次命中都會將到期時間再延後 5 分鐘。1 小時 TTL 的寫入成本會加倍，但只要工作負載的閒置間隔超過 5 分鐘，就很有必要。

粒度。 最少 1,024 個 token。系統會針對完全一致的 token 序列計算 hash；開頭只改一個字元，就會讓整個前綴失效。

API 易用性。 最高。多中斷點設計可以分別快取「永不變動」、「很少變動」與「依任務變動」的內容。對提示詞各區段更新頻率不同的 agent 與 RAG 工作負載而言，這是目前最好的設計。

注意事項。

• 忘記加入 cache_control 就會完全不使用快取。它不像 GPT 或 DeepSeek，沒有隱式備援機制。
• 即使在 tool/function 陣列內，快取 hash 也會受到順序影響，請使用確定性的排序方式。
• 若未明確設定 keep-alive，預設 5 分鐘 TTL 不適合零星執行的批次工作。
• 如果透過閘道呼叫 Claude，請確認閘道支援 Anthropic 原生 /v1/messages 路徑與 cache_control 標記。OpenAI 相容的 /chat/completions 路徑通常不會傳遞這些標記，應改用 Anthropic SDK，並將 base URL 指向閘道。

最適合。 長上下文 agent、system prompt 穩定的多輪對話，以及採分層快取的結構化 RAG。

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

主力模型（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 個 token 的請求都會自動使用快取。快取命中按輸入費率的 50% 計費，寫入不加價。比對增量為 128 個 token。

計價方式。 OpenAI 在定價頁面公布每百萬 token 的費率。快取輸入打五折，輸出費率不變。

實測（2026-05-25，約 6,900-token system prompt）：

* gpt-5.4-mini 命中測試的 completion 比未命中測試短得多，因此成本差異同時受到快取折扣與 completion 長度變化影響。延遲降低 5 倍（3.63 → 0.73 s）是更可靠的指標。

TTL 行為。 確切值未公開；根據實際使用回報，會隨負載與前綴熱門程度落在 5–60 分鐘。熱門的共用前綴會保留更久，因為 LRU 會優先保留它們。

API 易用性。 非常簡單，現有程式碼可直接繼續使用。記錄 prompt_tokens_details.cached_tokens 即可衡量命中率。

注意事項。

• 無法強制命中。如果流量產生的前綴都不相同，就無法獲得任何效益。
• 50% 折扣低於 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 一樣自動運作。快取 token 約按輸入費率的 25% 計費，沒有儲存費，也不必設定。
• 顯式：透過獨立 API 呼叫建立 cachedContent 物件，後續請求再以名稱引用。快取 token 約按 10% 計費，費率更低，但每百萬 token 另收每小時儲存費。

計價方式。 長上下文是 Gemini 的強項；價格會依上下文長度級距調整，低於 200K 與高於 200K 的每 token 費率不同。

實測（2026-05-25）：

TTL 行為。 隱式模式：數分鐘，未公開確切時間。顯式模式：由開發者設定，預設 1 小時，最長 24 小時。

API 易用性。 顯式快取需要兩個步驟（建立 → 引用）。cachedContent 的生命週期，包括建立、更新 TTL 與刪除，都由你負責。

注意事項。

• 對低流量的顯式快取來說，儲存費是致命成本。 務必根據呼叫頻率計算損益平衡點。
• 隱式快取命中率不固定，不應用它來建立確定性的成本模型。
• 快取物件綁定區域，多區域應用程式必須建立多份快取。
• gemini-*-pro 是推理模型：若 max_tokens 太小，hidden thinking 會耗盡 completion 額度，導致 completion_tokens=0。任何面向使用者的流程都應把 max_tokens 提高到 ≥256。

最適合。 同一份大型文件（>20K 個 token）每小時查詢 10 次以上、影片問答，以及企業 PDF 的多模態 RAG。

2.4 DeepSeek-v4 — 自動、磁碟、64-token 粒度

主力模型（2026-05）： deepseek-v4-flash（一般用途；此世代也用於 coder 工作負載）。

快取 API。 像 GPT 一樣自動運作，但底層採用 MLA 壓縮，使快取體積小到足以持久化至磁碟。快取命中約按輸入費率的 25% 計費，寫入不加價。最小比對單位為 64 個 token。

計價方式。 DeepSeek 定價頁面以人民幣列出費率。快取命中約可降低 75% 的輸入成本。

實測（2026-05-25）：

TTL 行為。 可達數小時，高流量前綴有時會更久。快取採磁碟儲存，不會因 GPU 記憶體壓力而像其他供應商的記憶體快取一樣被逐出。

粒度。 64 個 token 是業界最小門檻。提示詞稍微修改時，大部分前綴仍可比對，不會像採 1,024-token 門檻的供應商那樣整段失效。

API 易用性。 API 採 OpenAI 格式，只要更換 base URL。使用標準的 prompt_tokens_details.cached_tokens 欄位。

注意事項。

• 僅限 DeepSeek 系列模型，無法將此快取用於其他模型系列。
• 英文品質優秀，但在最困難的推理 benchmark 上仍落後 Claude/GPT-5.x。

最適合。 注重成本的中文工作負載、重複前綴頻率高且粒度很重要的情境（例如檢索結果順序不穩定的 RAG），以及成本敏感的批次工作。

2.5 Alibaba 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，建議自行實測。

最適合。 需要精確控制快取的中國企業工作負載，以及已使用 Alibaba Cloud 的客戶。

3. 並列比較

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

3.2 TTL、粒度與持久性

3.3 7K-token 前綴的實測延遲（2026-05-25）

† Claude 各列透過 Anthropic 原生 /v1/messages 端點，使用 cache_control 標記實測（請參閱第 3 篇 §2）。Claude 最大的優勢是成本，輸入費用約可降低 88–89%；完整成本表請見第 3 篇 §2。根據 Anthropic 公布的數據，當提示詞達 100K 個 token 以上時，TTFT 改善幅度會顯著放大。

測試採單次循序執行，沒有並行負載。實際數據會隨區域、時段與其他租戶的競爭負載而變動。

4. 5 維度評估框架

「Claude 可省 90%」這類標題很吸引人，卻很少能直接告訴你該選哪一家。請依自己的工作負載，從以下五個維度為各供應商評分，再按你重視的項目加權。

4.1 每百萬 Token 實際成本（依命中率加權）

不要比較基本價格，應比較實際命中率下的預期成本。你可以把自己的數據代入 LLM 成本計算器，或瀏覽跨供應商的即時 LLM 價格比較：

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

以前綴重複率 70% 的典型聊天機器人為例：

• Claude：90% 折扣 × 0.7 命中 + 25% 寫入 × 0.3 → 實際約為基本費率 × 0.45
• GPT-5.5：50% × 0.7 + 0 → 實際約為基本費率 × 0.65
• Gemini 隱式模式：75% × 0.7 + 0 → 實際約為基本費率 × 0.48
• DeepSeek-v4：75% × 0.7 + 0 → 實際約為基本費率 × 0.48

再乘上各供應商實際且彼此不同的基本費率，才能得到可比較的美元金額。評分方式：依工作負載計算 effective_cost，越低越好。

4.2 命中率可預測性

• 顯式快取（Claude、Qwen 顯式模式、Gemini 顯式模式）— 可預測性高。只要你做了標記，且仍在 TTL 內，就會命中。
• 自動快取（GPT-5.x、DeepSeek-v4、Gemini 隱式模式、Qwen 隱式模式）— 取決於前綴相似度與供應商負載，因為 LRU 可能逐出快取。

若 SLA 與成本綁定，優先選擇顯式快取。若只是盡力最佳化，自動快取就足夠。

4.3 TTL 與流量頻率的適配度

4.4 快取未命中時的延遲

如果命中時很快，未命中時卻很慢，而且你的命中率不高，仍然會有問題。請同時比較 §3.3 的兩組數據，再依預期命中率加權。

4.5 API 易用性與遷移成本

• 遷移成本最低：GPT-5.x ↔ DeepSeek-v4（兩者都採 OpenAI 格式，也都自動快取）。
• 中等：GPT-5.x → Gemini 隱式模式（SDK 不同，但不必重寫快取程式碼）。
• 高：GPT-5.x → Claude（必須加入 cache_control，並重整提示詞分層）。
• 最高：不透過閘道，直接從單一供應商改為多供應商（需要處理多套快取 API）。

5. 依工作負載型態快速選擇

6. 遷移注意事項

如果評分結果顯示應該切換供應商，請先規劃三件事：

資料搬移。 快取前綴無法在供應商之間轉移，每次切換都會從冷啟動開始。預熱期間的成本會高於平常，預算應涵蓋數小時。

重新設計提示詞。 Anthropic 的多中斷點設計鼓勵使用分層提示詞結構，而這種結構其實對所有供應商都更好。只要重構一次，非 Claude 路徑也能受益。

透過閘道分散風險。 如果還不確定，可透過 Token Gateway 路由。這樣不必綁定單一供應商，仍能保留選擇空間；代價是多一個網路 hop，而且依閘道實作不同，可能無法使用供應商特有的快取控制。Synthorai 閘道實際做了什麼，以及哪些宣稱應該保持懷疑，請參閱第 3 篇 §9。

7. 這些比較會如何變化

本文的數據會隨時間變動。快取已成為價格競爭的重要功能，供應商每隔幾個月就會更新方案。接下來應關注兩件事：

• TTL 延長。 Anthropic 的 1 小時選項已正式推出；Gemini 可能延長至數天。TTL 不足的問題可望逐步緩解。
• 粒度。 OpenAI 與 Anthropic 最終很可能降低 1,024-token 門檻；DeepSeek 的 64-token 標準已重新定義市場期待。

當各家的折扣逐漸接近，真正的差異會轉向 API 易用性與延遲，而不是標題上的節省幅度。

下一篇：第 3 篇 — 提示詞快取教學：可執行的 Python會把上述架構轉成可執行程式碼，並將 §3.3 的延遲表做成你可以自行執行的 benchmark。

常見問題

綜合所有因素，哪家 LLM 供應商的提示詞快取最便宜？ 在相同命中率（約 75%）下，根據我們 2026-05 的實測，中文工作負載以 deepseek-v4-flash 最便宜，英文則是採隱式快取的 gemini-2.5-flash，兩者每百萬 token 的實際成本最低。claude-sonnet-4-5 的單次呼叫折扣最深（約 90%），但基本價格也較高；命中率超過 85% 時才會勝出。請將自己的命中率代入 §4.1 的公式。

為什麼 Gemini 在低流量工作負載下更貴？ 除非頻繁查詢快取，否則顯式快取的每小時儲存費會吃掉折扣。低流量工作負載應使用 Gemini 的隱式快取，不收儲存費，折扣約 25%。

可以在 OpenAI 使用 Claude 的 cache_control 嗎？ 不能直接使用，兩者是不同的快取實作。在 OpenAI 相容的 /chat/completions 端點上，這個欄位對非 Anthropic 模型通常不會產生任何作用；那些模型本來就會自動快取。若使用 Claude，請改用 Anthropic 原生 /v1/messages 端點並加入標記。

DeepSeek 的 MLA 架構是專有技術嗎？ 論文（DeepSeek-AI 2024）已公開。其他供應商可以採用類似 MLA 的 KV 壓縮，但這需要重新訓練基礎模型，不是執行階段切換設定就能完成。截至 2026-05，DeepSeek 仍是唯一在正式環境部署這項技術的主要供應商。

開源自架模型呢？ vLLM、SGLang 與其他推論引擎原生支援前綴快取，其基礎是 PagedAttention 論文。如果在 H100s/H200s 上自行託管，可以使用 LMCache 或類似工具實作磁碟快取。本文的價格分析只適用於託管服務；自架環境的成本結構完全不同。如果想使用多供應商路由，又不想自行維運路由器，託管式 LiteLLM 替代方案可以用同一套 API 存取相同供應商，並保留快取功能。哪些開放權重模型在哪些平台支援快取，以及哪些託管商已將它產品化，請參閱開放權重 LLM 的提示詞快取。

為什麼比較中沒有 Mistral、Cohere 或 Llama API 供應商？ 截至 2026-05，它們的快取功能還不夠成熟。Mistral 的快取仍處於 early access；Cohere 未提供顯式快取；Llama API 供應商（Groq、Together、Replicate）之間的差異很大。等功能穩定後再重新評估。

資料來源：Anthropic 提示詞快取 · OpenAI 提示詞快取 · Google Gemini 上下文快取 · DeepSeek KV Cache · Alibaba Bailian 上下文快取 · DeepSeek-V2／MLA 論文 · PagedAttention／vLLM（Kwon 等人，2023）。實測數據來自 2026-05-25 的 https://synthorai.io/v1。

← 返回部落格