Prompt Caching 成本指南：Cache Hits、Prefixes 與實際 API 支出

Prompt Caching（提示詞快取）的成本取決於三個變數：你的提示詞中有多少比例是可重複使用的前綴、該前綴在快取的有效視窗內重複出現的頻率，以及特定供應商如何定價快取寫入（write）與快取命中（hit）。只要掌握這三個數字，快取就能顯著降低重複性工作負載的輸入 Token 帳單；但若弄錯了，你可能會因為一個從未被重複使用的快取而支付額外的寫入溢價。

本指南將區分供應商的文件內容、你可以在公開 API 介面上驗證的資訊，以及在將生產環境支出投入快取策略前應進行的測試。

重點摘要

• Prompt Caching 成本包含兩個部分：寫入成本（通常在建立新的快取項目時收取）與命中成本（通常在請求重複使用該項目時收取）。Anthropic 的文件明確描述了這種寫入與命中的區別；在建立支出模型前，請務必先確認文件頁面上的當前倍率。
• 快取命中要求在定義的斷點（breakpoint）之前，必須進行精確或近乎精確的前綴匹配。若在該斷點之前重新排列系統指令、工具定義或少樣本（few-shot）範例，將導致快取失效並強制重新寫入。
• 快取項目會在供應商定義的存活時間（TTL）後過期。如果針對特定前綴的請求量過於稀疏，無法落在該視窗內，你將支付重複的寫入成本，而非累積命中帶來的節省。
• OpenRouter 的文件指出，Prompt Caching 的行為與定價會因底層供應商與模型而異，因此在一個後端上能節省成本的快取策略，並不一定能自動轉移到另一個後端。在根據預期節省金額進行流量路由之前，請先檢查各模型的支援情況。

Prompt Caching 實際收費項目

Prompt Caching 允許 API 供應商儲存提示詞前綴的處理表示形式，以便後續共享該前綴的請求可以跳過冗餘計算。由此產生的計費模式並非「快取 Token 是免費的」，而是更接近「快取 Token 在重複使用時較便宜，但首次寫入的成本高於標準輸入 Token」。

Anthropic 的 Prompt Caching 文件直接列出了這種結構：建立新快取項目的請求，其計費方式與命中現有項目的請求不同。確切的倍率會隨時間與模型而變，因此請將你在部落格文章（包括本文）中看到的任何數字視為需要對照當前文件進行驗證的參考，而非固定的常數。

其實際意義在於，Prompt Caching 是一場關於「重複使用」的賭注。如果你的系統提示詞、工具架構或檢索到的上下文區塊只發送一次且從不重複，快取只會增加寫入溢價，而沒有任何抵銷的命中節省。如果同一個區塊在快取的有效視窗內被發送了數百次，那麼命中帶來的節省將遠遠超過寫入成本。

快取命中如何運作：前綴、前綴與斷點

快取命中是基於前綴的，而非模糊意義上的基於內容。提示詞的快取部分必須與傳入請求的 Token 完全一致，直到快取邊界（有時稱為斷點）設定的位置。Anthropic 的文件將此描述為一種明確的機制，開發者在其中標記提示詞的哪一部分符合快取資格，通常是系統指令、工具定義以及在呼叫之間不會變更的大型參考文件。

這產生了一個直接的工程後果：你在快取斷點之前放置的任何內容，都必須在請求之間保持位元組相同（byte-identical），包括空格和順序。一個常見的錯誤是在快取邊界之前的系統提示詞中穿插每個請求的變數（如時間戳記或使用者 ID）。該單一變數會導致整個前綴的快取失效，你將在每次呼叫時支付寫入成本，而非累積命中次數。

解決方法很簡單：將真正靜態的內容（工具定義、內部風格指令、大型參考文件）保留在快取的「前綴」中，並將任何請求特定的內容推送到非快取的「後綴」中，通常是使用者訊息。

快取存活時間（TTL）與前綴設計同樣重要。Anthropic 的文件描述了以分鐘為單位的預設快取持續時間，並為有需要的負載提供了更長持續時間的選項。如果你的流量模式是每隔幾分鐘才發送一次共享前綴，短效快取可能會在下一個請求到達前過期，最終導致你重複支付寫入成本。高頻負載（聊天對話、代理迴圈、連續執行的批次處理管線）比低頻、零星的呼叫更適合使用快取。

模擬實際 API 支出：實作方法

與其斷言節省百分比，不如使用以下結構來模擬你自己的工作負載。此範例從概念上說明了請求結構；在實作之前，請務必檢查供應商文件中的確切欄位名稱與當前定價。

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

系統區塊上的 cache_control 標記表示此內容為快取候選項目。會話中的第一次呼叫會支付該區塊的寫入成本。在快取有效視窗內，任何重複使用相同前綴的後續呼叫，都將支付命中率費用，而非這些 Token 的完整輸入費率。

若要評估這是否值得為你的服務實作，請從你的日誌中收集四個數字：

1. 前綴大小：你打算快取的靜態內容（系統提示詞、工具架構、參考文件）的 Token 數量。
2. TTL 視窗內的呼叫頻率：在快取的有效持續時間內，有多少請求重複使用了該確切前綴。
3. 寫入與命中費率：從當前的供應商文件中取得，而非憑記憶假設。
4. 後綴變異性：提示詞中非快取部分的比例相對於快取部分是否較小，因為節省幅度取決於總提示詞中有多少比例位於快取斷點之後。

如果你的前綴很大、TTL 視窗內的呼叫頻率很高，且後綴很小，那麼快取很可能會降低支出。如果這三個條件中任何一個較弱，請在全面推廣快取之前進行並行的成本比較。TokenLab 關於削減 AI API 成本的指南探討了除快取之外更廣泛的槓桿，包括模型選擇與批次處理，網址為 /blog/cut-ai-api-costs-30-percent。

決策表：Prompt Caching 何時划算

工作負載模式	快取是否有幫助	備註
在會話中多次呼叫重複使用的長系統提示詞或工具架構	是	典型案例；寫入成本透過多次命中分攤
在短時間內重複詢問問題時重複使用的大型檢索文件	是，若呼叫落在 TTL 內	在假設重複使用視窗前，請對照當前文件確認 TTL
沒有重複流量的一次性提示詞	否	只有寫入溢價，沒有命中來抵銷
「穩定」部分不斷變更的高變異性提示詞	否	斷點前的任何變更都會使快取失效
在多輪對話中重複工具定義的代理迴圈	是	工具架構是快取的首選候選項目
間隔超過快取 TTL 的低頻批次作業	否	快取在重複使用前過期；每次都要支付寫入成本
僅部分後端支援快取的多供應商路由	需視模型而定	不要假設快取支援可在供應商之間轉移

請將此表作為初步檢查清單，而非最終答案。請針對你計畫使用的特定模型，對照供應商文件確認 TTL、寫入/命中定價以及斷點機制，因為這些細節會隨模型系列而變動。

在投入前應驗證的供應商差異

Prompt Caching 並非在所有地方的實作方式都相同，如果你在多個供應商或模型之間路由流量，這一點至關重要。OpenRouter 關於 Prompt Caching 最佳實踐的文件指出，快取支援與行為會因底層供應商而異，這意味著針對某個模型快取機制調整的策略，在切換模型或透過不同後端路由時並不一定適用。

如果你的架構使用模型路由來控制成本（例如，將常規分類任務發送給成本較低的模型，如 DeepSeek V4 Flash、GLM-5.2 或 Gemini 3.5 Flash，同時將 Claude Sonnet 5 或 GPT-5.5 保留給較困難的推理任務），你需要為路由表中的每個模型獨立檢查快取支援。針對一個模型文件驗證過的快取策略，不能安全地假設適用於另一個模型。TokenLab 的排名頁面追蹤了模型層級的差異，你可以將其作為初步參考點，網址為 /models/rankings；而路由基準分析 /blog/ai-model-routing-benchmark-cost-per-task 則涵蓋了路由決策如何與每項任務的成本互動，這會與快取決策產生疊加效應，而非取代它們。

本分析的限制

本指南描述了截至上述觀察日期，由 Anthropic 記錄並由 OpenRouter 引用的 Prompt Caching 一般機制。它不包含確切的寫入/命中倍率、確切的 TTL 持續時間或各模型的定價，因為這些數據會隨模型而變動與不同。在為生產環境流量建立成本模型之前，請直接從上述連結的供應商文件中取得當前數據，而非依賴第三方內容（包括本文）中引用的任何固定數字。針對推理導向模型、多模態提示詞以及超長上下文視窗的快取行為，可能也與此處描述的一般前綴快取模式有所不同；請務必針對你計畫使用的特定模型查閱文件。

常見問題 (FAQ)

Prompt Caching 是否總是能減少 API 支出？ 不一定。只有當穩定的前綴在快取的有效視窗內被足夠頻繁地重複使用，以抵銷寫入成本時，它才能減少支出。零星或高度變異的提示詞在啟用快取後，成本往往比不啟用時更高。

什麼會導致快取命中失敗？ 快取斷點之前的提示詞內容發生任何變更，包括空格、Token 順序，或是在原本靜態的系統提示詞中插入單一變數。匹配必須在斷點之前完全一致。

所有供應商的 Prompt Caching 實作方式都相同嗎？ 不。Anthropic 記錄了一種具有明確寫入與命中定價的快取控制機制。OpenRouter 的文件指出，快取支援與定價會因底層供應商與模型而異，因此你應該針對每個模型驗證支援情況，而非假設它可以轉移。

如果你正在評估 Prompt Caching、模型路由或兩者的組合是否適合你的流量模式，請開始使用 TokenLab 來比較模型選項與成本結構，再投入生產環境支出。