Prompt Cache 能省多少錢？原理、真實命中率與三個寫法

很多用戶第一次看賬單都會問：為什麼同樣的模型，我的成本和別人差這麼多？答案八成在 prompt cache（提示詞緩存）。這篇講清它的計費原理、真實世界的命中水平，以及怎麼寫提示詞才能吃滿折扣。

計費原理：緩存命中的輸入按折扣價計

大模型 API 的輸入計費分兩種：首次處理的 token 按標準價；命中緩存的前綴部分按大幅折扣價（以 Claude 為例，緩存讀取價是標準輸入價的十分之一）。也就是說，你的會話前綴越穩定，重複部分越長，實際輸入成本越低。

真實世界的命中率

從我們網關側的觀察看：Claude Code、AI Chat 這類會話式工具，由於每輪都攜帶系統提示與歷史消息，健康會話的緩存命中比例普遍能到六成以上；而寫法糟糕的整合——比如每次請求都往系統提示裡塞時間戳——命中率可以直接歸零，成本翻好幾倍。

讓命中率翻倍的三個寫法

1. 把「不變的」放前面，「變化的」放後面。緩存按前綴匹配：系統提示、工具定義、few-shot 示例放最前；用戶輸入、檢索結果放最後。前綴中間插一個動態欄位，後面的緩存全部作廢。
2. 別在提示裡放會變的東西。時間戳、隨機 ID、「今天是幾號」這類內容是緩存殺手。真需要時間，放在消息末尾的用戶輪裡。
3. 會話要「續」不要「重開」。同一個任務的多輪交互保持在同一會話裡累積；每輪都新起會話等於每輪都全價。

怎麼驗證自己吃到了折扣

控制台的用量明細裡，每條請求都分開展示標準輸入、緩存寫入與緩存讀取的 token 數。改完提示詞組織後跑幾輪，對比緩存讀取佔比的變化即可——優化是否生效，數據一眼可見。

緩存不是玄學，是前綴匹配。把提示詞當「不可變前綴 + 可變後綴」來組織，賬單會誠實地回報你。