開放權重 LLM 快取：成效為何取決於供應商運氣

封閉模型的 prompt 快取有一套明確的規格。Claude 使用 cache_control 設定斷點；OpenAI 與 Gemini 會在 token 數超過門檻後自動快取；折扣也有公開且穩定的標準。讀完一頁文件就夠了。

開放權重模型並非如此。同一個 Qwen 或 Llama checkpoint 可能由十多家平台提供，而**快取不是模型本身的屬性，而是執行環境的屬性。**以下是一組實測資料：同一段約 4.7K-token 的 prompt，透過多供應商 router 傳送給同一個 Qwen 模型六次，而且沒有固定上游：

同一個模型、同一個 router、同一段 prompt，帳單卻介於 $0.0141 與 $0.000286，差距達 49×。唯一的差別，是 router 選了哪個上游，以及該上游是否已有暖的 prefix。

摘要

• **開放權重模型的 prompt 快取是路由結果，不是模型功能。**它由推論引擎免費、自動完成，卻可能被上方任何一層保留或破壞。
• **五層中只有一層提供快取，另有三層可能讓它失效。**模型（決定可快取程度，但不提供快取）→ 推論引擎（免費快取）→ 運算主機（包裝成產品，實作品質不一）→ 閘道（多叢集路由）→ router（把請求分散到快取互不相通的供應商）。
• **實測結果。**Router 分散相同請求後，某次選擇的成本比另一次高出 49×；同一個模型在一家主機取得 59.6% 折扣，另一家則是 0%；各模型公開的快取折扣介於 0% 到約 98%。
• 實務做法。固定路由，讓重複 prefix 命中同一份暖快取；稽核時比較成本差異，不要依賴 cached_tokens 欄位，因為真正命中時它也常顯示 0；延遲則要分開評估，即使成本折扣約為 0%，暖 prefill 仍可快上 2–10×。

即時數據於 2026-06-14 測得，測試對象為一個多供應商 router 與我們自己的閘道。測試固定使用約 4.7K-token 的英文 prompt、較小的 max_tokens，並依序執行。文件中的價格也在同一天查核各供應商的第一手文件，並以對抗方式交叉驗證。真正可跨環境參考的是比率，例如折扣百分比與延遲變化；絕對金額則會受平台、prompt 與負載影響。引用前請自行重現。

實務上會遇到的快取類型

先釐清名詞，再看整體架構。開放權重模型的託管平台主要有四種快取形式，計費方式各不相同。

**1. 自動 prefix 快取（不需標記）。**這是最常見的形式。伺服器會對 prompt prefix 計算 hash。若與先前請求相符，就重用 KV 狀態並自動套用折扣，不需要 cache_control，也不必修改程式碼，通常甚至無法停用。DeepSeek、Zhipu GLM 與多數開放權重模型託管平台都採用這種方式。寫入免費；快取可能只在 VRAM 中保留幾分鐘，也可能存到磁碟。DeepSeek 會將 prefix 保留「數小時到數天」。

2. 明確斷點快取（cache_control）。這是 Anthropic 採用的形式，也有少數開放權重模型託管平台提供。Alibaba 的 Model Studio 接受 Qwen 訊息區塊中的 "cache_control": {"type": "ephemeral"}；部分 serving 平台也提供同等標記。使用者標出邊界並支付寫入附加費，換取幅度更大的讀取折扣。

3. 租用式快取物件（收取儲存費）。這類型要特別留意。Moonshot 舊版 moonshot-v1 系列要求呼叫 POST /v1/caching 建立快取，接著收取寫入費、按 token 與分鐘計算的儲存費，以及每次命中的費用。Google 的 Gemini 明確式快取也是相同概念，除了輸入成本，還要支付每 1M-tokens 每小時約 $1.00–$4.50 的儲存費。這類快取是租用資源，使用者必須自行清除。

**4. 自架 KV 重用（免費）。**自行執行權重時，推論引擎會自動免費快取。不收寫入費、讀取費，也沒有儲存租金；命中時只會略過 prefill。

Model Studio 上的 Qwen 同時提供自動與明確兩種模式，兩者之間有實質取捨：隱含模式的命中費用為輸入成本的 20%，寫入免費；明確模式的命中費用為輸入成本的 10%，但寫入時收取 125%，而且項目的 TTL 只有 5 分鐘。折扣更大，但建立快取要付費，每次到期後重新建立也要再付一次。

快取位於架構的哪一層

核心概念很簡單。開放權重模型的 prompt 快取**只在一層得到完整解決，上方每一層都可能讓它失效。**從權重往上逐層檢視：這一層究竟會提供快取，還是只會轉送快取？它是否可能破壞下層已完成的快取？

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

第 1 層：模型決定可快取程度，但不提供快取

多數人以為快取存在於這一層，例如「DeepSeek 有快取」，因此首先要把概念說清楚。Checkpoint 只是一組權重；無論是否存在 KV cache，執行的 attention 都一樣。它不含快取、折扣、TTL 或 cache_control 標記，這些都是 serving 層的功能。嚴格來說，權重不會提供任何快取產品。

但權重也不是完全無關。DeepSeek 正好說明了原因。模型的 attention 架構決定 KV cache 的大小，也就決定快取成本最低能降到什麼程度：

• DeepSeek 的 **Multi-head Latent Attention（MLA）**會把 KV cache 壓縮為低秩 latent，大小約為標準 multi-head cache 的 4–14%。正因為有這層壓縮，DeepSeek API 才能把 prefix 持久化到磁碟，並將快取讀取價格壓到輸入價格的約 2%。架構是必要條件；磁碟快取則是建立在架構上的產品。
• **Grouped-Query Attention（GQA）**由 Llama、Qwen、Mistral 與 DeepSeek 採用。它透過共用 KV head，依 group factor 縮小快取，在 Llama-3 上約可縮小 8×。

因此，第 1 層提供的是可快取程度，而不是快取本身。架構決定上方各層最低能把快取成本壓到哪裡，但權重本身不會提供任何快取 token。「DeepSeek 有快取」其實把兩件名稱相同、實質不同的事混在一起：一是權重，也就是提供 MLA 的這一層；二是 DeepSeek 的 API 與 serving stack，也就是第 2–3 層提供的磁碟快取、折扣與 usage 欄位。下載開放權重自行執行後，仍會保有 MLA 帶來的較小 KV cache，但磁碟快取這項產品仍留在 DeepSeek 的伺服器上。你會改用自己部署的第 2 層實作。實務上的結論不變：不要再問某個模型是否有快取，而要問它在何處提供服務。但這不代表架構不重要。架構決定上限，請求路徑則決定實際結果。

第 2 層：推論引擎實作快取，而且免費

往上一層，快取不只存在，而是**已經完整解決，且完全免費。**現代推論引擎會自動快取 prefix：

• vLLM：Automatic Prefix Caching 會為每個 KV block 計算 hash，重用曾見過相同 prefix hash 的 block，並透過 LRU 淘汰。V1 預設啟用。
• SGLang：RadixAttention 將 KV cache 儲存在 radix tree 中，所有共用 prefix 都能重用，並搭配 cache-aware scheduling。
• TensorRT-LLM：支援 block reuse（enable_block_reuse，預設啟用），也可選擇將 KV block offload 到主機記憶體。

LMCache 等專案更進一步，能把 KV offload 到 CPU 或磁碟，並且跨 instance 共用。這正是解決後續路由問題的起點。重點是：自行託管時，快取問題已經解決。快取會自動運作，除了原本就在使用的 GPU 外不增加成本，採 LRU 淘汰，而且由你完全掌控。命中時只會略過 prefill，降低 TTFT 並提高吞吐量。由於沒有任何計費，也就不需要 cached_tokens 計費欄位；效果會反映在自己的延遲指標上。封閉模型的快取是租來的，開放模型則可以完全由自己掌握。不過，這也有與託管環境相反的限制：快取是暫時性的，存在於 VRAM 並由 LRU 管理，因此只有 prefix 持續保持熱門時才會留存。上方各層的任務，正是維持這項條件。

第 3 層：運算主機把快取包裝成產品，但品質不一

商業推論主機會包裝第 2 層，並執行由多個 replica 組成的叢集。它們承接免費的自動快取，問題在於實作品質，而不同平台在兩個面向上差異很大。

首先，揭露方式與價格差距很大。在主要的開放權重模型託管平台中，一家對快取輸入統一打五折，並讓快取 token 不計入 rate limit；另一家的 serverless 預設也提供五折；第三家依模型設定快取輸入價格，例如某個 Qwen tier 約有八折折扣，並提供 cache-key hint 以改善 affinity；第四家則在 dedicated endpoint 強制啟用快取，也不提供揭露方式。底層使用相同引擎，卻形成四種不同的定價策略。

其次，這也是快取第一次可能失效的地方，也就是多 replica 問題。暖 prefix 只存在於處理冷請求的那個 replica 的 VRAM 中。主機本身的 load balancer 可能把下一個請求送到另一個快取仍是冷的 replica。我們實際看到了這種情況：每次將相同 Qwen 模型固定到單一上游，依序執行冷→暖請求：

供應商 A 能正確快取並回報結果。供應商 B 雖然公開宣稱此模型有 cache-read 價格，但測試中的一次冷呼叫與兩次暖呼叫都沒有任何折扣。原因可能是請求不符合條件、被分散到不同 replica，或需要超過兩個請求才能完成 warm-up。不論原因為何，這條路徑的實測結果都是零。第 2 層已經解決功能問題，但使用者是否真的取得快取，取決於第 3 層的執行細節，而且各家主機的結果不同。

第 4 層：閘道的多叢集問題

閘道位於一個或多個上游前方，會把 replica 問題擴大成叢集問題。如果閘道在不同叢集或供應商之間 round-robin 分配請求，卻沒有 cache affinity，暖快取在架構上就無法命中。每個請求都會落到沒有該 prefix 的位置。具備 cache-aware 能力的閘道必須依 prefix hash 路由，讓相同 prefix 固定送往同一個上游，就像第 2 層將它們對應到相同 KV block。無論閘道是自行維運的 LiteLLM 等軟體，或是託管服務，皆適用相同原則；相關營運取捨可參考 LiteLLM 與代管閘道比較。

我們在第三方閘道上，對多個開放權重模型進行冷→暖測試，並直接讀取每次請求的 cost：

DeepSeek-V4 命中後取得 97–99% 折扣，代表 affinity 在整條路徑上正常運作；qwen3.5-plus 與 qwen3-max 雖然在目錄中列有 cache-read 價格，暖呼叫卻只有約 0% 折扣。這張表還能看出兩項閘道實務重點：

• **Usage 欄位可能不準，成本不會。**這裡的每一次呼叫，cached_tokens 都是 0，包括成本下降 99% 的請求。許多 OpenAI-compatible 閘道不會為自動快取的上游填寫 cached-token 欄位。稽核時應比較冷、暖呼叫之間的 cost 差異，而非 token 欄位。這與稽核閘道快取聲明時的結論相同。
• **即使成本不變，延遲仍會改善。**所有暖呼叫都快上 2–10×，例如 qwen3.5-flash 從 10.2s 降至 1.0s，包含折扣約為 0% 的模型。無論主機如何計價，命中後都會略過 prefill。因此，即使閘道未提供帳單折扣，快取仍能改善 TTFT。

不保留 affinity 的閘道，會提供一份無法命中的快取；不揭露快取成本的閘道，則會提供一份無法驗證的快取。

第 5 層：Router 在供應商之間隨機分配

最上層的多供應商 router，會把同一個模型 ID 的流量分散到不同公司的叢集，而各家都有互不相通的快取。此時，即使單一供應商內部的 affinity 完美運作也無濟於事：第 1 次呼叫若進入某家供應商，第 2 次進入另一家，就沒有可共用的快取。這正是文章開頭的分散情況，而且還會放大第 4 層的問題。不只是叢集不同，供應商之間的快取狀態與價格也完全分離，最昂貴的選擇，其基本費率是最便宜上游的 20×。只有當路由碰巧持續使用同一家供應商時，快取才會生效。

解法是移除隨機性，改用確定性路由，讓重複 prefix 落在同一份暖快取：

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

這個 router 的優點是確實會回報 cached_tokens，命中時為 4,224，也會回傳每次請求的 cost，因此兩者都能驗證，比第 4 層固定顯示 0 的閘道更好。但路由限制仍需自行設定。**快取本質上是路由問題，只是表面看起來像定價功能：**第 2 層的快取免費，而第 3、4、5 層則以逐步升高的規模，把請求路由到無法命中的位置。

折扣到底有多大？各家差異極大

路由確實對齊後，究竟能省多少？封閉模型的 cache-read 折扣大多接近 90%。開放權重模型公開的 cache-read 價格，則從象徵性折扣到幾乎免費都有，即使同一家供應商的不同產品線也可能差距很大。以下是第一方公開費率：

DeepSeek 的自動磁碟快取提供目前幅度最大的折扣。deepseek-v4-flash 的快取輸入讀取價格為 $0.0028/M，未命中價格則為 $0.14/M，比例是 1:50。第 4 層測試也重現了 97.9% 的結果。提供相同開放權重的第三方主機會自行決定快取輸入價格，有些統一提供約 50% 折扣，有些則依模型提供約 50% 到約 90% 不等的折扣。因此，實際折扣取決於請求進入哪一家主機，不只取決於模型。同一項功能名稱，折扣差距可達 48 個百分點。

折扣是平台屬性，因此同一模型在不同託管位置會有不同的快取成本。以下是 deepseek-v4-pro 的四種情況：

「DeepSeek-V4-Pro 支援快取」這句話沒錯，卻幾乎沒有實務價值。真正該問的是：「在哪裡支援、費率是多少、如何回報？」

決策檢查清單

• ✅ 模型決定上限，不提供快取（第 1 層）。MLA、GQA 等 attention 架構決定快取成本最低可能降到哪裡，但不會自行提供快取 token。因此仍要確認模型在哪裡提供服務，以及該主機的 stack 如何實作。
• ✅ 自行託管時，快取已經免費可用（第 2 層）。確認 automatic prefix caching 已啟用，vLLM／SGLang 預設就是開啟，並監控 prefix hit rate。
• ✅ 使用運算主機時，驗證實際結果，不要只看價格欄（第 3 層）。Cache-read 價格只是一項聲明；應實測冷→暖請求的成本差異。若主機提供 cache-key affinity hint，也應使用。
• ✅ 透過閘道時，要求 cache-affinity 路由與成本回報（第 4 層）。如果相同 prefix 無法固定到單一上游，或暖呼叫的 cost 沒有下降，快取就是無法命中或無法驗證。
• ✅ 使用 router 時固定上游（第 5 層）。限制路由，例如指定供應商順序並關閉 fallback；否則 load balancing 會讓請求分散到快取互不相通的環境，不只無法命中，還可能進入價格高出 20–50× 的上游。
• ✅ **分開評估延遲與成本。**即使金額折扣約為 0，暖 prefill 仍會快上 2–10×。
• ✅ **留意收取儲存費的快取類型。**租用式快取會依閒置快取的 token 與時間計費，例如 Moonshot moonshot-v1、Gemini 明確式快取；automatic prefix cache 則不收儲存費。

結論

對封閉模型而言，「是否支援快取」只有一個答案。對開放權重模型而言，推論引擎層早在多年前就已解決這項能力。vLLM 與 SGLang 會自動免費快取每個 prefix。上方各層只是管線，它們可能保留命中條件，也可能把請求分散到無法命中的位置，包括運算主機的 replica balancer、閘道的叢集路由，以及 router 在不同供應商之間的隨機分配。模型架構決定快取成本的理論下限。MLA 與 GQA 的確是模型層的實質優勢，但請求實際經過的路徑才決定最後能取得什麼結果。應把快取行為視為路由屬性：在實際使用的完整路徑上用成本衡量，固定路由以確保命中先前建立的快取。無論折扣多大，如果第二個請求落到第一個請求從未到過的位置，就完全沒有價值。

如要了解 KV cache 存在的原因與 TTL 運作方式，可先閱讀 KV Cache 與 TTL 的運作方式；如要稽核閘道的快取聲明，請參考 你的 LLM 閘道是否謊報快取？。

常見問題

開放權重模型支援 prompt 快取嗎？ 權重決定快取成本最低能降到什麼程度。MLA 與 GQA 等 attention 架構會縮小 KV cache，但快取本身、折扣與 API 都來自 serving stack。快取由推論引擎實作，例如 vLLM、SGLang、TensorRT-LLM；運算主機承接這項能力，再由閘道與 router 轉送或分散。同一個 checkpoint 部署到三家主機，可能分別得到免費自動快取、完全沒有快取，或只能使用明確式快取。

為什麼同一模型的某次呼叫比另一次貴 49×？ 在多供應商 router 上，未固定的請求會被 load balance 到不同供應商的叢集。各家的基本價格不同，快取狀態也互不相通。一次呼叫可能冷啟動昂貴的供應商，另一次則命中便宜供應商的暖快取。固定上游，例如限制供應商順序並關閉 fallback，即可同時控制兩者。

自行託管時，需要為快取付費嗎？ 不需要。vLLM、SGLang 與 TensorRT-LLM 預設提供免費的 automatic prefix caching，命中時只會略過 prefill。成本只有原本就在使用的 GPU；快取由自己掌控，並在 VRAM 不足時透過 LRU 淘汰。

API 顯示 cached_tokens: 0，但帳單降低了，快取有生效嗎？ 很可能有。許多閘道不會為自動快取的上游填寫 cached_tokens。應以 cost 欄位為準：如果冷呼叫與內容完全相同的暖呼叫之間有明顯成本差異，就代表快取已命中。

哪個開放權重模型的快取折扣最大？ DeepSeek 的自動磁碟快取。deepseek-v4-flash 的快取輸入讀取價格約為 $0.0028/M，未快取時則為 $0.14/M，約有 98% 折扣。我們在 V4 系列的冷→暖測試中重現了 97.9–99.2% 的結果。許多第三方主機則統一只提供約 50% 折扣。

收取儲存費的快取有什麼風險？ Moonshot moonshot-v1 的明確式快取與 Gemini 明確式快取，會依 token 與存活時間計費。Gemini 約為 $1–4.50 / 1M-tokens / hour。忘記刪除的閒置快取仍會持續產生成本。Automatic prefix cache 不收儲存費。

驗證方式：即時成本與延遲數據於 2026-06-14 測得，測試對象為多供應商 router 與我們自己的閘道。測試使用固定約 4.7K-token 的 prompt、較小的 max_tokens，並依序執行冷→暖請求；折扣由每次請求回傳的 cost 計算。文件價格與快取機制均在同一天查核第一手供應商文件，並以對抗方式交叉驗證。部分供應商的數據變動頻繁，尤其是 Moonshot 的明確式快取費用，引用前請確認最新價格。實際結果會因供應商、prompt、區域與負載而異。

資料來源

• DeepSeek：價格
• DeepSeek：KV cache／Context Caching 指南
• DeepSeek-V3 技術報告：MLA（KV-cache 壓縮）
• GQA：訓練 Generalized Multi-Query Transformer 模型（Ainslie 等人）
• Alibaba Cloud Model Studio：context cache 與價格
• Moonshot AI：Context Caching
• Zhipu／Z.AI：價格與快取
• vLLM：Automatic Prefix Caching
• SGLang：RadixAttention／快取
• LMCache：KV cache offloading 與共享
• Google：Gemini context caching

以上資料皆於 2026-06-14 查核。本文不構成財務建議；採用前請確認最新價格。

← 返回部落格