Synthorai

LLM 提示快取：2026 完整指南

2026年5月26日 · prompt-cache · series-overview · llm-architecture
目錄
  1. 從哪裡開始
  2. 第 1 部分 —— LLM 提示快取如何運作
  3. 第 2 部分 —— 跨服務商比較 LLM 提示快取
  4. 第 3 部分 —— 可執行的 Python 教學
  5. 第 4 部分 —— 依使用情境挑選最佳模型
  6. 如何閱讀本系列
  7. 本系列中的數據

如果你針對大型語言模型打造聊天機器人、RAG 應用或 AI 代理，提示快取是唯一能在不犧牲品質的前提下，幫你拿回 50–90% 的輸入成本與 3–10× 的首字延遲（TTFT） 的最佳化手段。它不是外掛的小技巧——它直接源自 Transformer 注意力機制的定義方式。一旦你理解了這一點，技術堆疊的其餘部分（TTL、各服務商的差異、提示結構）就都水到渠成了。

本頁是一個四部分系列的索引，帶你從理論一路走到正式環境的決策矩陣。請依你既有的知識儲備挑選進入點。

從哪裡開始

如果你想……從這裡開始
理解快取為什麼存在，以及 KV 快取究竟是什麼第 1 部分 —— KV 快取與 TTL 如何運作
挑選一個服務商，並了解每一家的不同之處第 2 部分 —— 比較 Claude、GPT、Gemini、DeepSeek
複製貼上可執行的 Python，量測你自己的數據第 3 部分 —— 可執行的 Python 教學
為聊天機器人 / RAG / 代理工作負載搭配合適的模型第 4 部分 —— 聊天、RAG 與代理的最佳模型

每一部分都可獨立閱讀，但它們的寫法保證了依序閱讀時層層遞進、不重複。

第 1 部分 —— LLM 提示快取如何運作

LLM 提示快取 #1：KV 快取與 TTL 如何運作 →

這是架構篇。把自注意力當作一個單一公式來講解，說明為什麼穩定前綴的 K 與 V 向量在數學上可以重複使用，並展示記憶體與計算之間的取捨如何產生每位開發者都必須圍繞其設計的 TTL 行為。

重點：

  • 提示快取不是疊加在上層的最佳化——它是因果遮罩注意力的直接結果。位置 i 處的 K/V 是權杖 1…i 的確定性函數，因此相同的前綴會產生位元級完全一致的 K/V。
  • Prefill（計算受限，O(N²)）才是快取所節省的部分；decode（記憶體頻寬受限，每個權杖 O(N)）是每個推論引擎本來就已經最佳化好的。
  • TTL 存在是因為 KV 快取非常龐大（在 70B 模型上，32K 上下文約需 ~10 GB）。5 分鐘是 GPU 記憶體壓力的臨界點；只有藉助磁碟支撐的快取（DeepSeek 的 MLA 架構）才可能實現數小時到數天的快取。
  • 快取在成本（快取命中時輸入便宜 50–90%）與延遲（5–10K 權杖範圍的提示 TTFT 下降 3–10×，100K+ 的提示降幅更大）兩方面都受益。

第 2 部分 —— 跨服務商比較 LLM 提示快取

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

這是選型指南。五家服務商以五種截然不同的形態揭露提示快取——顯式標記（Claude）、全自動（GPT-5、DeepSeek-v4）、隱式+顯式混合（Gemini、Qwen），或架構層面的磁碟支撐（DeepSeek 的 MLA）。本文提供逐項功能比較，外加一套 5 維評估框架，依你具體的工作負載為它們評分。

重點：

  • 不要比較基礎價格——要比較依你的命中率加權後的有效成本（公式見 §4.1）。
  • Claude 擁有最深的單次呼叫折扣（~90%），但需要顯式的 cache_control 標記。
  • DeepSeek-v4 是唯一在規模上提供磁碟支撐快取的服務商；由於粒度是 64 個權杖而非 1,024 個，部分前綴比對也能拿到折扣。
  • Gemini 的顯式快取需要按小時支付儲存費——損益兩平點取決於呼叫頻率。
  • 一旦你把命中率這個變數控制住，真正區分各服務商的就是這五個維度：API 易用性、命中率可預測性、TTL 適配度、未命中時的延遲，以及遷移成本。

第 3 部分 —— 可執行的 Python 教學

LLM 提示快取 #3：可執行的 Python 教學 →

這是動手實作篇。一個 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 權杖提示上從 3.6 秒降到 0.73 秒），系統權杖上的快取命中率 93%。
  • Gemini 2.5-flash 隱式快取：在擷取串流 usage 的前提下，快取命中時成本下降 88%。
  • DeepSeek-v4-flash：便宜 74%，磁碟支撐（快取可挺過小時級的閒置）。
  • TTL 感知模式：為 cron 設定保活心跳、前綴穩定性規則、每次呼叫應記錄哪些內容。

第 4 部分 —— 依使用情境挑選最佳模型

LLM 提示快取 #4：聊天、RAG 與代理的最佳模型 →

這是決策篇。不同的工作負載會以不同方式拉動成本/延遲槓桿——聊天天生對快取友善，RAG 要對抗前綴穩定性問題，代理則仰賴累積前綴的紀律性。本文依工作負載形態提供模型建議並附上成本估算。

重點：

  • 聊天機器人：任何帶自動快取的模型都能用；對話天生會命中。依成本/品質挑選。gpt-5.4-nano 最便宜，gpt-5.4-mini 快取後的 TTFT 最快，claude-haiku-4-5 在略高的溢價下指令遵循最佳。
  • RAG：檢索文件的重新排序會摧毀提示中段的快取命中。三種修正辦法——把引用推到末尾、確定性的分塊排序，或使用 Claude 的多 cache_control 斷點。
  • 代理：工具呼叫與結果必須是僅追加的，且逐步之間位元級完全一致。帶 4 個 cache_control 標記的 claude-sonnet-4-5 提供最強的累積前綴折扣；gpt-5.4-mini 無需改程式碼即可獲得 50% 的節省。
  • TTL 搭配：聊天用 5 分鐘，帶人在迴路步驟的代理用 1 小時，零散的批次處理用磁碟支撐快取。

如何閱讀本系列

  • 剛接觸此主題的工程師：依序閱讀。第 1 部分的架構會讓第 2–4 部分瞬間通透。
  • 做供應商選型的 PM 或架構師：直接跳到第 2 部分 + 第 4 部分。若同事問起「可是 TTL 為什麼存在」，再回頭看第 1 部分。
  • 今天就要上線某個特定工作負載的工程師：先看第 4 部分（在矩陣裡找到你那一列），再看第 3 部分拿到確切的程式碼。
  • 最佳化現有應用的任何人：第 3 部分 §6 的跨服務商基準——用你自己的提示重現它；這是一天的工作量，而不是長達數週的遷移工程。

本系列中的數據

所有實測數據均於 2026-05-25 針對 Synthorai 閘道擷取（OpenAI 相容用 https://synthorai.io/v1，Anthropic 原生用 https://synthorai.io/），單租戶、單次循序執行、無並行負載。你的數據會隨地區、時段與競爭租戶負載而變化——請把它們當作起點，在引用之前先用你自己的流量重現。

定價表與 TTL 行為反映的是截至 2026-05 各供應商的公開文件。供應商每隔幾個月就會更新這些內容；架構層面的推理（第 1 部分）是穩定的，而比較性的數據（第 2 與第 3 部分）會漂移。

← 返回部落格