Synthorai
🎁 新用戶 免費註冊，送 10 次呼叫，最高 $1，免綁卡。
LLM 提示快取完整指南（2026）：輸入成本降低 50-90%

LLM 提示快取完整指南（2026）：輸入成本降低 50-90%

2026年5月26日 · 更新於 2026年7月15日 · prompt-cache · series-overview · llm-architecture
目錄
  1. 從哪裡開始
  2. 第 1 篇：LLM 提示快取如何運作
  3. 第 2 篇：比較各供應商的 LLM 提示快取
  4. 第 3 篇：可直接執行的 Python 教學
  5. 第 4 篇：依使用情境選擇最佳模型
  6. 第 5 篇：整合 LangChain
  7. 閱讀方式
  8. 本系列的實測數據

如果你的聊天機器人、RAG 應用或 AI agent 串接大型語言模型，提示快取是最有效的一項最佳化：不犧牲品質，就能省下 50–90% 的輸入成本，並將首個 token 延遲縮短 3–10 倍。這不是額外加上的小技巧，而是直接源自 Transformer attention 的定義。理解這點後，TTL、供應商差異與提示結構等問題就會自然串起來。

TL;DR

  • 提示快取不犧牲品質，就能省下 50-90% 的輸入成本，並將首個 token 延遲縮短 3-10 倍。
  • 2026-05-25 實測：Claude 的 cache_control 標記讓輸入成本降低 88-89%；GPT-5.4-mini 的自動快取將 TTFT 從 3.6s 降至 0.73s；DeepSeek-v4-flash 的磁碟快取提供 74% 折扣。
  • TTL 之所以短，是因為 KV 狀態非常龐大：70B 級模型處理 32K-token context 時，約需 10 GB。
  • DeepSeek 的快取粒度是 64 token，常見的最低門檻則是 1,024 token，因此前綴只有部分符合時仍可獲得折扣。

本頁是五篇系列文章的索引，內容從理論一路延伸到 production 決策矩陣，以及實際組裝提示的 framework 層。你可以依照目前的理解程度，選擇最合適的起點。

從哪裡開始

如果你想要……從這裡開始
了解快取存在的原因，以及 KV 快取究竟是什麼第 1 篇：KV 快取與 TTL 如何運作
選擇供應商，並掌握各家的差異第 2 篇：比較 Claude、GPT、Gemini、DeepSeek
直接使用可執行的 Python 程式碼，並實測自己的資料第 3 篇：可直接執行的 Python 教學
為聊天機器人、RAG 或 agent 工作負載選擇合適的模型第 4 篇：聊天、RAG 與 agent 的最佳模型
透過 LangChain 正確使用快取（template、tool、agent）第 5 篇：真正能命中快取的 LangChain 設定

每一篇都可以獨立閱讀，但依序讀完，能在不重複內容的前提下建立完整觀念。

第 1 篇：LLM 提示快取如何運作

LLM 提示快取如何運作：解析 KV 快取與 TTL →

這篇談底層架構。文章用一條方程式說明 self-attention，解釋穩定前綴的 K、V 向量在數學上為何可以重複使用，也會說明記憶體與運算量之間的取捨，如何形成每位開發者都必須納入設計的 TTL 行為。

重點如下：

  • 提示快取不是疊加在模型之上的最佳化，而是 causal-masked attention 的直接結果。位置 i 的 K/V 是 token 1…i 的確定性函數，因此相同前綴會產生位元完全一致的 K/V。
  • 快取省下的是 prefill（受運算能力限制，O(N²)）；decode（受記憶體頻寬限制，每個 token 為 O(N)）則是所有 inference engine 原本就會最佳化的部分。
  • TTL 的存在，是因為 KV 快取非常龐大（70B 模型處理 32K context 時約需 10 GB）。5 分鐘是 GPU 記憶體壓力下的實際保存期限；只有磁碟快取才能將時間延長到數小時甚至數天，例如 DeepSeek 的 MLA 架構。
  • 快取同時改善成本（命中時輸入成本降低 50–90%）與延遲（提示長度為 5–10K token 時，TTFT 可縮短 3–10 倍；超過 100K 時效果更明顯）。

第 2 篇：比較各供應商的 LLM 提示快取

提示快取比較：Claude、GPT-5、Gemini、DeepSeek、Qwen（2026）→

這篇是採購指南。五家供應商提供提示快取的方式各不相同：Claude 採用明確標記，GPT-5 與 DeepSeek-v4 完全自動化，Gemini 與 Qwen 混合使用隱式與顯式快取，而 DeepSeek 的 MLA 則在架構上以磁碟為後端。文章逐項比較功能，並提供一套五個面向的評估框架，協助你依照實際工作負載評分。

重點如下：

  • 不要只比較原價，應依命中率加權計算實際成本（公式見 §4.1）；即時的 LLM 價格比較與成本計算器可直接套用你的工作負載。
  • Claude 單次呼叫的折扣最高（約 90%），但必須明確加入 cache_control 標記。
  • DeepSeek-v4 是唯一大規模提供磁碟快取的供應商；其快取粒度為 64 token，而非 1,024 token，因此前綴只有部分符合時仍可獲得折扣。
  • Gemini 的顯式快取會按小時收取儲存費；損益兩平點取決於呼叫頻率。
  • 控制命中率變因後，真正能區分供應商的五個面向是 API 易用性、命中率可預測性、TTL 是否符合需求、未命中時的延遲，以及遷移成本。

第 3 篇：可直接執行的 Python 教學

用 Python 實作 LLM 提示快取：可直接執行的程式碼教學 →

這篇著重實作。透過單一閘道，同時使用一套 OpenAI SDK 與一套 Anthropic SDK，並提供 2026-05-25 的實測資料。涵蓋完整 Claude 系列（haiku-4-5 到 opus-4-7）、GPT-5.x、Gemini 2.5、DeepSeek-v4 與 Qwen3。

重點如下：

  • 搭配 cache_control 標記的 Claude：haiku/sonnet/opus 4-x 的實測成本降幅一致達到 88–89%。請使用 Anthropic SDK，並設定 base_url="https://synthorai.io/"。
  • GPT-5.4-mini 自動快取：TTFT 改善 5 倍（7K-token 提示從 3.6 s 降至 0.73 s），system token 的快取命中率為 93%。
  • Gemini 2.5-flash 隱式快取：正確擷取串流 usage 後，快取命中時成本降低 88%。
  • DeepSeek-v4-flash：折扣 74%，並使用磁碟快取（閒置數小時後快取仍然有效）。
  • 配合 TTL 的實作模式：cron 的 keep-alive heartbeat、前綴穩定性規則，以及每次呼叫應記錄的欄位。

第 4 篇：依使用情境選擇最佳模型

聊天、RAG 與 agent 的最佳 LLM：2026 模型與成本決策矩陣 →

這篇協助你做決策。不同工作負載影響成本與延遲的方式不同：聊天本身很適合快取；RAG 會受到前綴穩定性問題影響；agent 則仰賴累積前綴的一致性。文章依工作負載型態提供模型建議與成本估算。

重點如下：

  • 聊天機器人：任何支援自動快取的模型都適用；session 本來就容易命中。可依成本與品質選擇。gpt-5.4-nano 最便宜，gpt-5.4-mini 的快取 TTFT 最快，claude-haiku-4-5 則以略高價格提供最佳指令遵循能力。
  • RAG：若每次都重新排列檢索文件，就會破壞提示中段的快取命中。可採用三種修正方式：將參考資料移到最後、固定 chunk 排序，或使用 Claude 的多個 cache_control breakpoint。
  • Agent：tool call 與結果必須只能附加，且每個 step 的位元內容完全相同。claude-sonnet-4-5 搭配 4 個 cache_control 標記，可提供最高的累積前綴折扣；gpt-5.4-mini 不需修改程式碼即可節省 50%。
  • TTL 配置：聊天使用 5 分鐘；包含 human-in-the-loop step 的 agent 使用 1 小時；零星 batch 工作則使用磁碟快取。

第 5 篇：整合 LangChain

LangChain 提示快取：真正能命中快取的設定 →

這篇談 framework 整合。第 1–4 篇都假設你能控制提示的每個 byte；LangChain 會代為組裝提示，而它最方便的語法卻會在沒有警告的情況下停用 Claude 快取。本文以帶有標記的 system 前綴，在 langchain-core 1.4.8 上進行實測。

重點如下：

  • ("system", "...") 這種字串 tuple template 無法攜帶 cache_control：即使呼叫內容完全相同，實測快取活動仍為零。解法是使用包含 content block 的 SystemMessage。
  • 提示順序是左右命中率的關鍵。若把檢索到的 RAG context 放在靜態規則之前，每次呼叫都會成為 cold write；考慮 Claude 的寫入加價後，這種做法甚至比完全不用快取更貴。
  • 在 system block 上加入標記，也會涵蓋已綁定的 tool；bind_tools 的序列化結果具有 byte 穩定性，而 Anthropic 格式的 tool dict 上的標記也會原樣傳遞。
  • 多輪 agent：將標記移到最新訊息，每一輪都會重新讀取完整的先前前綴，但只寫入新增部分（實測：讀取 1,864、寫入 15）。
  • 自動快取模型（GPT、GLM、DeepSeek）的順序錯誤不會出現明顯徵兆：不會加價、不會報錯，只是永遠拿不到折扣。請監控 usage 欄位。

閱讀方式

  • 剛接觸這個主題的工程師：依序閱讀。第 1 篇的架構說明能讓你迅速理解第 2–4 篇。
  • 正在評選供應商的 PM 或架構師：直接閱讀第 2 篇與第 4 篇。若團隊成員詢問「為什麼會有 TTL」，再參考第 1 篇。
  • 今天就要上線特定工作負載的工程師：先讀第 4 篇，在矩陣中找到對應項目，再到第 3 篇取得完整程式碼。
  • 已經使用 LangChain：直接閱讀第 5 篇。第 3 篇的原生 SDK 模式仍可套用，但字串 template、變數位置與 usage 欄位名稱等問題是 framework 特有的。
  • 正在最佳化現有應用程式的任何人：閱讀第 3 篇 §6 的跨供應商 benchmark，並以自己的提示重跑。這只需一天，不必花數週遷移。

本系列的實測數據

第 1–4 篇的數據測於 2026-05-25，第 5 篇的 LangChain 數據測於 2026-07-04。測試透過 Synthorai 閘道進行（OpenAI 相容介面使用 https://synthorai.io/v1，Anthropic 原生介面使用 https://synthorai.io/），環境為單一租戶、單次循序執行，且無並行負載。實際數據會隨區域、時段及其他租戶的競爭負載變動。請將這些結果視為起點；在引用前，務必以自己的流量重新測試。

價格表與 TTL 行為依據供應商截至 2026-05 的公開文件。供應商每隔幾個月就會更新這些資訊；第 1 篇的架構原理不會改變，但第 2、3 篇的比較數據會逐漸出現差異。

← 返回部落格