Prompt Caching：用前綴快取砍掉成本與延遲¶

整理自 Anthropic 官方文件與廠商文件（見文末），2026-06-20。重複送幾乎一樣的長 prompt（system、few-shot、檢索脈絡、工具定義）時，prompt caching 能把那段的成本砍到約 1/10、並降低首字延遲。本頁講原理、怎麼擺、與會悄悄失效的坑。

實證標記：〔Anthropic〕= 出自 Anthropic 官方文件；〔廠商〕= 出自模型供應商文件；〔實務〕= 業界慣例或本人整理。預設 under-claim。具體數字依供應商，且會變。

原理：重用前綴的 KV，跳過重算¶

LLM 處理 prompt 時，prefill 階段會把每個 token 算成 KV 張量。prompt caching 的作法是：當多次請求共用相同的開頭（前綴），就把那段 prefill 的 KV 快取起來重用，跳過重算 → 同時省成本與首字延遲（TTFT）。〔廠商〕

唯一鐵律：這是「前綴比對」¶

快取是 exact prefix match——前綴裡任何一個 byte 改變，從那個位置之後全部失效。〔Anthropic〕

由此推出唯一的擺放原則：靜態內容放前面、變動內容放後面。 - Anthropic 的渲染順序是 tools → system → messages；把穩定的（凍結的 system prompt、固定順序的工具清單）放前段，把變動的（時間戳、每請求 ID、當次問題）放最後一個快取斷點之後。〔Anthropic〕

兩家供應商的做法¶

	Anthropic	OpenAI
觸發	開發者明確標記 `cache_control` 斷點	自動（超過最小 token 門檻即啟用）
控制	可指定快取哪段、可設 TTL	自動、exact prefix match
省幅（廠商自報）	快取讀 ~0.1× 基礎輸入價（該段約省 90%）	約 50% 成本下降

〔廠商〕兩家都靠「相同前綴」，所以靜態在前、變動在後這條原則對兩家都適用。

Anthropic 的精確數字〔Anthropic〕¶

快取讀：約 0.1× 基礎輸入價（命中時超便宜）。
快取寫：5 分鐘 TTL 為 1.25×、1 小時 TTL 為 2× 基礎輸入價。
損益平衡：5 分鐘 TTL 約 2 次請求就回本（1.25×+0.1× < 2×）；1 小時 TTL 因寫入貴，約需 3 次。
TTL：預設 5 分鐘，可選 1 小時（適合有間隔的爆量流量，但寫入成本翻倍要更多次讀才划算）。
最小可快取前綴（依模型）：Opus 4.8/4.7/4.6/4.5、Haiku 4.5 = 4096 tokens；Fable 5、Sonnet 4.6 = 2048；Sonnet 4.5 = 1024。前綴太短會「悄悄不快取」（無錯誤，cache_creation_input_tokens = 0）。
每請求最多 4 個 cache_control 斷點。

驗證命中：看 usage，別猜〔Anthropic〕¶

回應的 usage 是唯一真相： - cache_read_input_tokens：這次從快取讀的 token（付 ~0.1×）。 - cache_creation_input_tokens：這次寫入快取的 token（付 ~1.25×）。 - input_tokens：只是沒快取的剩餘——總前綴 = 三者相加，別只看這一個欄位就以為 prompt 很短。

若重複送相同前綴但 cache_read_input_tokens 一直是 0 → 有東西在悄悄破壞前綴。

會悄悄破壞快取的坑〔Anthropic〕〔實務〕¶

掃 prompt 前綴裡有沒有這些：

樣態	為何破壞
`datetime.now()` / `Date.now()` 進 system prompt	前綴每次都變
`uuid4()` / request ID 放前段	同上，每請求唯一
`json.dumps()` 沒 `sort_keys`、或迭代 `set`	序列化非決定性、前綴 bytes 不同
把 session/user ID 插進 system prompt	變成 per-user 前綴、跨使用者不共享
條件式 system 段落（`if flag: system += ...`）	每種 flag 組合都是不同前綴
每使用者不同的工具集	工具在位置 0，整段都無法跨使用者快取

修法：把動態片段移到最後一個斷點之後、讓序列化決定性化、或刪掉非必要的。

Agent 特有：別在中途打斷快取〔Anthropic〕¶

長流程 agent 要特別小心三件會讓整段前綴失效的事： 1. 中途改 system prompt → 改用「在 messages 末尾追加 system 訊息」的方式（支援的模型），保留已快取前綴。 2. 中途換模型 → 快取是 per-model；子任務要換便宜模型，改用 subagent，別在主迴圈換。 3. 中途增刪工具 → 工具在位置 0，一動全失效；用 tool search 之類「附加而非置換」的機制。

這也呼應 Context Engineering 實作篇：caching 與 context budget 是同一枚硬幣。

落地檢查清單〔實務〕¶

靜態在前、變動在後——先把 prompt 組裝順序排對，再談斷點。
斷點放「共享前綴的結尾」，不是整段結尾（否則每請求各寫一份、永遠讀不到）。
凍結 system prompt——別把日期/模式/使用者名插進去。
確認過最小前綴門檻（Opus 4.8 要 ≥4096 tokens 才會快取）。
用 usage.cache_read_input_tokens 驗證，不要靠感覺。

延伸閱讀（本站）¶

Context Engineering 實作篇 — caching 與 context budget 的關係
Caveman：壓縮 Agent 輸出 Token — 從輸出端省 token
Agent Observability — 用 cost 訊號驗證快取效益