Prompt Cache 最低門檻：官方文件低估了 1.4 到 2.4 倍
有客戶回報，在我們的閘道上，prompt caching 並沒有在模型官方文件所宣稱的 token 數量就開始生效。我們先重現了這個問題，接著把每個模型都拿到第二條獨立的服務路徑上重跑一遍——那是目前最大的 AI 閘道之一，結果同樣的落差在那裡一個 token 都不差地重現出來。真正過度樂觀的是文件本身，而不是某一家閘道：官方公布的最低門檻只是「符合資格」的下限，並不是真正能拿到快取命中的長度。對於採用自動快取的那幾個系列來說，兩者相差 1.4 到 2.4 倍。OpenAI 實測的首次命中門檻落在約 1,456 個 token，文件寫的是 1,024；Gemini 2.5 Flash 首次讀到快取是在約 5,000 個 token，文件寫的是 2,048；至於 Claude，它只在你明確放置標記的位置做快取，命中值與文件標示的各模型最低門檻誤差在幾個百分點以內。
TL;DR
- OpenAI 文件寫的快取最低門檻是 1,024 個 token，但實測有效門檻約 1,456 個 token，兩條路徑都一致。
- Gemini 2.5 Flash 文件寫 2,048，但首次讀取快取要到約 5,000 個 token，高出約 2.4 倍。
- Claude 的顯式
cache_control命中值與文件最低門檻的誤差在幾個百分點以內（Opus 為 1,073，文件為 1,024）。 - GLM 5.2 與 DeepSeek V4 沒有公布最低門檻，約 800 個 token 就開始讀取；MiniMax M3 則不論長度都回報約 114 個快取 token。
- 自動快取在首次讀取前還需要 2 到 8 次呼叫來預熱。
每一項測量都跑過兩條服務路徑——我們自己的閘道，以及最大的獨立 AI 閘道之一——只有兩條路徑結果一致，我們才視為模型本身的行為。用第二條路徑的目的是歸因：如果一個落差在毫不相干的廠商技術堆疊上也能重現，那問題就出在模型，而不是我們。這個交叉驗證在 OpenAI、Gemini 和 GLM 上乾淨俐落——三者在兩條路徑上都會快取，有效門檻也一致。但並非每個模型都適用：在第二條閘道上，open-weight 模型大多是由沒有實作廠商 prompt cache 的 GPU 主機提供服務，這一點閘道自己的 endpoint metadata 也逐一按 provider 確認過，加上未固定的路由會在這些主機之間漂移，快取的親和性就丟失了。凡是第二條路徑無法佐證的，下面的數字就取自能觸及各廠商自家快取 API 的那條路徑。長度採用的是各模型自己的 token，依回傳的 usage 校準，而不是字元數。每一組測試都用全新的 prefix，並記錄第一個產生快取讀取的呼叫序號，而不是單次的命中與否。
文件寫的門檻與實際生效的門檻不一樣
文件裡的最小值告訴你一個 prompt 什麼時候「可以」被快取。而實際生效的門檻，是重複送出同一個 prompt 時真正能命中快取讀取的長度。對於自動快取的這幾個模型家族，這兩個數字並不相同。
| 家族 | 快取型態 | 文件最小值 | 實測首次命中 | 差距 |
|---|---|---|---|---|
| OpenAI GPT-5.5 / 5.4-mini | 自動 | 1,024 | ≈1,456 | +40% |
| Gemini 2.5 Flash | 自動 | 2,048 | ≈5,000 | 2.4 倍 |
| Gemini 3.5 Flash | 自動 | 4,096 | ≈5,200 | +27% |
| Claude Opus 4.8 / Sonnet 5 | 顯式標記 | 1,024 | 1,073 | 準確 |
| Claude Haiku 4.5 | 顯式標記 | 4,096 | 4,206 | 準確 |
OpenAI 的數字在兩條路徑上都精準到 token：1,356 個 token 的 prompt 完全讀不回來，1,456 個 token 的就能命中。Gemini 的差距最大。有一輪測試上限只到 3,300 個 token，結果零命中，看起來像是完全沒開快取；把測試延伸到 5,000 個 token 後，兩條路徑在同樣長度下都乾淨命中。文件寫的 2,048 只是快取「有資格」的門檻，不是真正能命中讀取的門檻。
整份研究看下來的規律是：你自己顯式標記的快取，規格是準確的；自動發生的快取則不然。
最小值不是唯一沒寫進文件的變數
跨過實際生效門檻是必要條件，但還不夠。自動快取的這幾個家族需要暖機：第一次命中發生在比較後面的呼叫，而不是第二次。
- OpenAI：第 2 到第 3 次呼叫首次命中。
- Gemini：第 4 到第 8 次呼叫首次命中。
這對成本估算有影響。6,000 個 token 的 prompt 超過了 Gemini 所有文件門檻與實際門檻，但如果一個工作負載只送兩次就結束，兩次都可能付全價，因為快取還沒暖起來。短促或突發的流量即使長度達標，也是按未快取的費率計費。我們是在至少重複呼叫十二次、每次之間留有沉澱時間後，才判定「不快取」；比較短的測試在 Gemini 上會產生假陰性，較深入的測試則推翻了它。
快取計數也會對齊到固定的區塊，這在對帳時值得知道：OpenAI 是 128 個 token 一塊，DeepSeek 是 64 個 token 一塊。5,014 個 token 的 prompt 讀到 4,073 個快取 token，是部分前綴命中後對齊到區塊邊界的結果，不是 bug。
你能控制的快取是精準的
Claude 只快取你用 cache_control 標記的片段，而這種控制搭配的是準確的規格。我們測過的每一項 Anthropic 宣稱都成立：
- 各模型的最小值精準到 token。 Opus 4.8 和 Sonnet 5 在 1,073 個 token 首次命中，文件寫 1,024；Haiku 4.5 在 4,206 命中，文件寫 4,096。多出來的一點是區塊取整，不是飄移。
- 讀取費率為輸入的 0.1 倍。 我們先從每個模型自己的冷啟動資料算出輸入單價，再從命中資料反推出快取費率。Opus 4.8 和 Haiku 4.5 都算出 0.10，與文件的倍率一致。
- 五分鐘刷新，每次讀取免費。 種下一個前綴後，分別在第二、第四、第六分鐘重新讀取，每次都命中。只要在每個五分鐘視窗內讀取一次，就能讓該筆項目保持存活，不會產生額外寫入。
- 級聯失效。 在系統前綴穩定、且定義了一個工具的情況下，只更改該工具的 description，就會強制重寫其下方的整個系統快取。更改工具定義會讓系統快取與訊息快取一併失效，符合文件描述的階層關係。
過程中還冒出一個文件互相矛盾的情況。某份第三方表格把 Claude Opus 的最小值列為 4,096 個 token；但實測在 1,073 命中，Anthropic 自己的 1,024 才是正確數字。
開源權重模型通常什麼都沒寫
前面提到的那些模型，至少還公布了一個數字讓你去驗證對錯。開源權重和中國實驗室的模型大多完全不公布最小長度，那就只能靠實測。我們的供應商快取比較分析了各家在命中之後公布的費率如何對應；這裡只討論一個問題：第一次讀取出現在什麼長度。
| 模型家族 | 文件標示的最小值 | 實測首次命中 | 顆粒度 |
|---|---|---|---|
| GLM 5.2 (Z.ai) | 無 | 約 800 起讀取，兩條路徑皆是 | 64-token 區塊 |
| DeepSeek V4 | 無 | 對供應商 API 約 800 起讀取 | 64-token 區塊 |
| MiniMax M3 | 512 | 任何長度都回報固定約 114 快取 | 非標準 |
GLM 5.2 沒有公布最小長度，兩條路徑都從大約 800 個 token 開始快取，顆粒度為 64-token 區塊，門檻比任何有公布文件的模型家族都低。DeepSeek V4 同樣沒公布最小值，也是從大約 800 個 token 開始讀取，顆粒度一樣是 64-token，但只有對它自己的快取 API 才成立。DeepSeek 的文件把快取定位為盡力而為，不保證命中率，而中介層暴露出來的正是這一點：另一家閘道透過一組 GPU 主機提供 DeepSeek，只有 DeepSeek 自己的端點實作了快取，因此路由若沒有固定到那個端點，就完全讀不到任何快取。
MiniMax M3 則是回報數字本身會誤導的例子。它的文件標示最小值為 512 個 token，但從第一次呼叫開始，在 200 到 5,000 個 token 的每一種長度下，都回報接近 114 的固定快取數。這個數字不隨 prompt 長度變化，而且連完全不做快取的路徑上也會出現，所以它只是模型自己的記帳，而非真正重用了什麼的訊號。這跟較新的 OpenAI 模型從另一個方向給出的教訓一樣：usage 的 token 欄位和實際快取可能對不上，所以當省下的成本很重要時，要以 usage.cost 為準來對帳，而不是 token 數。
最新的模型正在改寫規則
在你假設舊行為會延續下來之前，有兩個文件層級的變動值得注意。在 GPT-5.6 家族上，OpenAI 的指南寫明快取寫入的費用是未快取輸入費率的 1.25 倍，而較早的家族寫入是免費的。同一份指南把隱式快取描述成在最新一則訊息上放一個斷點，這跟跨回合快取一個穩定 system 區塊的前綴快取形態不同。如果你想在這些模型上讓一段穩定前綴跨不同 user 回合被重用，就用明確的斷點標記，別依賴隱式路徑。每個模型都要各自確認寫入倍率和最小值，因為這兩者現在會因家族而異，單一文件頁面把這些差異抹平了。
如何運用這些結論
- 量測你自己的有效門檻。 用你實際的 token 掃過不同的 prompt 長度，記下第一個能回傳 cache read 的長度。不要假設文件上的最低值就是命中的起點。
- 把暖機成本算進去。 對於自動 cache 的供應商，在成本模型裡把新 prefix 的前 2 到 8 次呼叫都當成沒有命中 cache。
- 供應商有提供顯式標記就優先用。 Claude 的 cache_control 給了一份準確、可測試的規格：最低值明確、read rate 明確、TTL 明確、失效規則也明確。這種可預測性，比一個你根本沒法依賴、卻標得更低的門檻值更有價值。
- 換到新的模型家族就重新建立基準。 這次研究過程中，光是同一家廠商的產品線，最低值、write 定價和 breakpoint 行為就變過了。
這些門檻背後的 read rate、TTL 和 key 規則，可以參考我們的 prompt caching 指南，裡面有各家供應商的細節。
一句話總結：文件上的最低值是「符合資格」的下限，不是命中的門檻；對於自動 cache，這兩個數字差了 1.4 到 2.4 倍。用你自己的 token、對著你自己的流量，去驗證那個真正影響帳單的數字。