LLM 提示快取：計算省下的費用，而不重複計算 token
作者：Nicho
提示快取可以降低重複傳送相同指令或上下文給 LLM 的成本。實際省下的金額取決於快取是否命中、供應商的計費類別，以及快取內容在到期前被重複使用的頻率。
快取讀取價格低只是計算的一部分。寫入可能有另外的價格，輸出 token 仍然要付費，而回報的輸入總量可能已經包含快取的 token。本指南說明如何建立實用的估算，並對照用量紀錄檢查。文中範例使用的是明確假設的價格，不是實測的應用結果，也不是供應商的報價。
確認供應商實際快取什麼
提示快取通常針對可重複使用的輸入上下文。不應與應用程式直接回傳先前儲存的答案、完全不呼叫模型混為一談。
DeepSeek 的上下文快取文件說明的是比對持久化的提示前綴單元。這項功能預設啟用，但採盡力而為的方式運作。看起來相似的請求不保證命中，而快取輸入也不代表會直接回傳先前的答案。
對你的應用程式而言，請區分三種機制：
- 供應商提示快取： 推論服務重複使用符合條件的輸入處理，並回報自己的用量類別。
- 應用程式回應快取： 你的應用程式直接提供已儲存的結果，可能完全避免呼叫模型。
- 檢索或文件快取： 你的應用程式避免重複進行擷取或檢索工作，但仍可能將產生的文字傳送給模型。
請分別衡量這三者。否則文件檢索的變更可能被誤認為推論折扣，或回應快取命中被計為供應商快取命中。
將輸入拆成互不重疊的類別
請從所選端點的用量結構開始，而不是憑空猜測的公式。DeepSeek 會回報 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens。其他 API 可能提供不同欄位或巢狀細分。
如果回應回報總輸入 10,000 token，其中包含 8,000 個快取 token，則其餘未快取的輸入是 2,000。將全部 10,000 以未快取費率計費，再加計 8,000 的快取費率，會重複計算請求的一部分。
對於分別有命中與未命中費率的服務，基本的模型 token 估算式為：
cost = miss_tokens / 1M × miss_rate + hit_tokens / 1M × hit_rate + output_tokens / 1M × output_rate
只有在該公式符合供應商定義時才使用。如果服務另外回報快取建立或儲存，請先對齊這些類別再相加其費用。快取寫入價格可能取代另一個類別，也可能是額外費用；費率表必須釐清這個差異。
請在計算旁保留幣別、單位、model ID、供應商與日期。以每千 token 報價的數字，不能原封不動放進以每百萬 token 計算的公式。
納入第一次寫入與生命週期
Kimi 的推論計費指南依存續時間區分 K3 的快取寫入，分為五分鐘與一小時兩類。它的快取命中輸入以命中價格計費，不會再收一次快取寫入費用。那些是直接平台本身的規則，不能證明閘道採用相同的計算方式。
一個有用的問題是：在快取項目仍符合資格期間，某個前綴會被重複使用幾次。設想以下針對一百萬 token 前綴的假設計費方案：
| 費用 | 假設價格 |
|---|---|
| 不使用快取處理前綴 | 每次使用 $1.00 |
| 第一次快取寫入，取代一般輸入計費 | $1.25 |
| 之後每次快取讀取 | $0.10 |
不使用快取五次要花 5 美元。一次寫入加上四次讀取要花 $1.65，在這個前綴上省下 67%。若只使用一次，走快取路線反而更貴：$1.25 而不是 $1.00。
「寫入取代一般輸入計費」這個假設至關重要。如果真實供應商是額外收取寫入費用，公式就會改變。這些價格只是用來說明方法，並非 Kimi 或 cheapaimodel 目前的報價。
對於這種取代式方案，請比較 write_cost + (uses − 1) × read_cost 與 uses × ordinary_cost。然後針對實際存續時間內預期的使用次數，重複這項計算。如果每個請求都在項目到期後才送達，再便宜的讀取也幫不上忙。
計算整個請求省下多少
輸入折扣不等於最終帳單上的相同百分比折扣。假設某個未使用快取的工作負載有 10 美元的輸入費用與 20 美元的輸出費用。假設其中 80% 的輸入變成快取命中，讀取費用是普通輸入費率的 10%，且沒有額外的寫入費用。
新的輸入費用是未命中 2 美元加上命中 $0.80，也就是 $2.80。總額變成 $22.80 而不是 $30：整體省下 24%，儘管快取部分的費率打了 90% 的折扣。
較長的回答、推理輸出、工具呼叫、重試與儲存都可能進一步改變總額。請採用端點回報的可計費用量，而不是只計算看得見的最終答案。若要查目前模型價格，請先看價格比較，再套用你自己的用量組合。
設計一套有用的量測方式
蒐集足夠資訊，才能做同類相比：
- 模型與供應商路由、請求時間，以及相關設定。
- 總輸入、快取命中、快取未命中、快取建立，以及有回報的輸出。
- 另行計費的服務，以及帳號記錄的費用。
- 結果是否符合應用程式的驗收標準。
計算以 token 加權的命中占比：總命中 token 數除以總符合資格的輸入 token 數。當一個很小的請求和一個很大的請求權重相同時，把每個請求的百分比平均起來可能會誤導判斷。
在調整任務專屬內容之前，先保留穩定的指示與可重複使用的脈絡，只要這樣的安排符合供應商文件所述的前綴規則。不要只為了追求更高的命中率而重新排列安全指示或移除必要的脈絡。變更提示結構後，請驗證輸出品質。
擴大規模前先對帳
將一小筆用量記錄樣本與供應商的計費檢視畫面比對。在假設帳單有誤之前，先調查缺少的分類、四捨五入、不同的計價期間，以及寫入或工具費用。
cheapaimodel 在其定價頁面公布輸入、輸出與快取讀取費率。在把三欄小計視為完整帳單之前，請先確認適用模型的寫入與其他計費規則。關於 K3 的特定差異，請參閱 Kimi API 指南。
有用的結果是降低每個可接受成果的成本。單靠快取 token 數量增加，並不能證明應用程式變得更便宜或更有效。