提示詞快取最低門檻：文件低估了 1.4-2.4 倍

有客戶告訴我們，提示詞的 token 數已達模型文件標示的門檻，但閘道上的提示詞快取仍未生效。我們重現問題後，又透過另一條獨立的服務路徑重新測試所有模型。這條路徑來自規模最大的 AI 閘道之一，而結果逐個 token 重現了相同落差。過度樂觀的是文件，不是任何一個閘道：公布的最低門檻只代表提示詞具備快取資格，不代表這個長度一定能命中快取。對自動快取系列而言，兩者相差 1.4 到 2.4 倍。OpenAI 文件標示 1,024 token，實際首次命中門檻約為 1,456 token；Gemini 2.5 Flash 文件標示 2,048 token，接近 5,000 token 才首次從快取讀取；Claude 只會在明確標記的位置建立快取，實測門檻與各模型文件標示的數字相差不到幾個百分點。

TL;DR

• OpenAI 文件標示的快取最低門檻為 1,024 token，但兩條路徑的實測有效門檻約為 1,456 token。
• Gemini 2.5 Flash 文件標示 2,048 token，卻接近 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 都通過這項交叉驗證；它們在兩條路徑上都會快取，有效門檻也相同。但並非所有模型都能這樣驗證。第二個閘道上的開放權重模型，大多由未實作供應商提示詞快取的 GPU 主機提供服務；該閘道自己的端點中繼資料也依供應商證實了這一點。此外，未固定路由的流量會在這些主機之間漂移，導致快取親和性失效。若第二條路徑無法佐證，以下數字便取自能連到各供應商原生快取 API 的路徑。所有長度都以各模型自己的 token 計算，並依回傳的 usage 校準，而非字元數。每組測試都使用全新的前綴，記錄首次產生快取讀取的呼叫序號，而不是只看單次命中或未命中。

文件門檻與有效門檻之間的落差

文件標示的最低門檻，代表提示詞從什麼長度開始「可以」快取。有效門檻則是重複送出提示詞後，實際開始從快取讀取的長度。對自動快取系列而言，兩者不是同一個數字。

OpenAI 的數字在兩條路徑上逐個 token 一致：1,356-token 的提示詞始終無法讀取，1,456-token 的提示詞則可以。Gemini 的落差最大。掃描上限設為 3,300 token 時完全沒有讀取，看起來就像快取未啟用；把上限延伸到 5,000 token 後，兩條路徑都在相同長度明確讀到快取。文件標示的 2,048 只是具備快取資格的下限，不是開始提供快取讀取的門檻。

整體測試呈現出一個固定模式：明確標記的快取有準確規格，自動發生的快取則沒有。

最低門檻不是唯一未記載的變數

超過有效門檻是必要條件，但還不夠。自動快取系列需要暖機：第一次讀取會出現在更後面的呼叫，不是第二次。

• OpenAI：第 2 到第 3 次呼叫首次讀取。
• Gemini：第 4 到第 8 次呼叫首次讀取。

這會影響成本模型。6,000-token 的提示詞已超過 Gemini 文件與實測的所有門檻，但如果工作負載只送兩次就換下一個提示詞，兩次仍可能都按完整價格計費，因為快取尚未暖機。即使長度符合資格，短暫或突發流量仍會按未快取費率計價。我們至少會重複呼叫十二次，且每次之間留出穩定時間，之後才判定「不會快取」。較短的掃描曾讓 Gemini 出現偽陰性，增加呼叫次數後便推翻了原結論。

已快取數量也會對齊固定區塊，核對帳單時要納入考量：OpenAI 使用 128-token 區塊，DeepSeek 使用 64-token 區塊。若 5,014-token 的提示詞回報讀取 4,073 個已快取 token，代表部分前綴命中並對齊區塊邊界，不是錯誤。

可自行控制的快取門檻很準確

Claude 只會快取以 cache_control 標記的區段，而且規格準確。我們測試的每項 Anthropic 說明都符合結果：

• 各模型的最低門檻準確到 token。 Opus 4.8 與 Sonnet 5 的文件門檻為 1,024 token，實測在 1,073 token 首次讀取；Haiku 4.5 的文件門檻為 4,096，實測為 4,206。這些小幅差距來自區塊取整，而非門檻漂移。
• 讀取費率為輸入費率的 0.1x。 我們先從各模型自己的冷快取資料列推導輸入價格，再以命中資料列反推出快取費率。Opus 4.8 與 Haiku 4.5 的結果都是 0.10，與文件標示的倍數一致。
• TTL 為五分鐘，每次讀取都會免費刷新。 建立前綴快取後，分別在兩分鐘、四分鐘與六分鐘重新讀取，每次都成功命中。只要在每個五分鐘時窗內讀取一次，項目便會繼續存活，且不會產生額外寫入。
• 連鎖失效。 固定系統前綴並定義一項工具後，只修改工具說明，就會迫使位於其下方的整個系統快取重新寫入。修改工具定義會讓系統快取與訊息快取失效，與文件記載的階層一致。

測試也發現一項文件之間的衝突。某份第三方表格將 Claude Opus 的最低門檻列為 4,096 token；實測在 1,073 token 即可讀取，因此 Anthropic 自己公布的 1,024 才是正確數字。

開放權重系列通常完全沒有文件門檻

上述系列至少公布了一個可能不準確的數字。開放權重模型與中國實驗室的模型大多完全未公布最低門檻，只能靠實測確認。我們的供應商快取比較整理了命中後的實際費率與公布費率是否一致；此處只探討首次讀取出現時的長度。

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 個已快取 token。這個數字不會隨提示詞長度變化，即使路徑根本沒有執行快取也會出現，因此它只是模型自己的帳務紀錄，不能代表實際重用了多少內容。較新的 OpenAI 模型也從另一個方向反映同樣問題：usage 的 token 欄位可能與實際快取不一致。若節省金額很重要，應以 usage.cost 核對，而不是 token 數。

最新模型正在改變規則

在假設舊有行為會延續之前，有兩項文件層級的變更需要注意。對 GPT-5.6 系列而言，OpenAI 指南指出快取寫入費率是未快取輸入的 1.25x；較早的系列則可免費寫入。同一份指南將隱式快取描述為在最新訊息上設定中斷點。這與跨多輪對話、對穩定系統區塊進行前綴快取的方式不同。如果希望這些模型能在不同使用者輪次間重用穩定前綴，應明確標記中斷點，不要依賴隱式路徑。請逐一確認各模型的寫入倍數與最低門檻，因為兩者現在都會依系列而異，單一文件頁面看不出這些差異。

實務上該怎麼做

• 實測自己的有效門檻。 以自己的 token 為單位掃描提示詞長度，記錄首次回傳快取讀取的長度。不要假設命中會從文件標示的最低門檻開始。
• 把暖機成本納入預算。 對自動快取供應商，在成本模型中應將新前綴的前 2 到 8 次呼叫視為未快取。
• 供應商支援時，優先使用明確標記。 Claude 的 cache_control 提供準確且可測試的規格：最低門檻、讀取費率、TTL 與失效規則都明確可知。這種可預測性，比一個看似較低但無法依賴的文件門檻更有價值。
• 新模型系列上線時重新建立基準。 在這次研究期間，同一家供應商的不同系列就已改變最低門檻、寫入價格與中斷點行為。

這些門檻背後的讀取費率、TTL 與快取鍵規則，請參閱我們的提示詞快取指南，其中整理了各供應商的實作機制。

簡單說，文件標示的最低門檻只是具備快取資格的下限，不是實際命中門檻。對自動快取而言，兩者相差 1.4 到 2.4 倍。請用自己的 token 與實際流量，驗證真正影響帳單的數字。

← 返回部落格