Prompt Caching 實戰

企業如何大幅降低 LLM API 費用

以 2026 年 7 月實測數據為準。Anthropic 如有靜默更新，實際行為可能有所變化。

問題的根源

不少香港企業在導入 LLM API 之後，發現每月帳單持續攀升，卻找不到明顯的優化空間。問題往往出在一個容易被忽略的地方：每一個對話回合，系統都在重新傳送完全相同的系統提示詞給模型，而每一個 token 都按全價計費。

以一個生產環境的對話系統為例，系統提示詞動輒超過四千個 token。每次對話、每個回合，這四千個 token 都在重複傳送、重複計費。這不是架構缺陷，而是大多數團隊未曾留意的計費盲點。

Anthropic 的 Prompt Caching 功能正是針對此問題而設。然而，它的實際運作方式與許多人的直覺判斷存在幾個關鍵落差，踩錯其中一個，cache 便會靜默失效——帳單照舊，開發者毫不察覺。

計費原理

Prompt Caching 的核心邏輯是將穩定的 token 序列在首次傳送時寫入快取，後續回合直接讀取，而非重新處理。計費公式如下：

總費用 = Cache Read × 0.1 + Cache Write × 1.25 + 未快取輸入 + 輸出

Cache Read 的費率是正常輸入價格的 10%；Cache Write 是 125%，屬一次性成本。首個回合寫入快取，第二個回合起即開始讀取，費用大幅下降。

以實測數據說明：第二個回合寫入 3,157 個 token，第三個回合讀取同樣的 3,157 個 token，單回合計費下降約 47%。對話越長，累積節省越顯著。根據生產系統的實測，短對話可節省約 54%，長對話則可達 80% 至 90%。

模型設有最低 token 門檻：Claude Sonnet 需達 1,024 tokens，Claude Haiku 需達 2,048 tokens。系統提示詞過短將無法觸發快取，這是另一個常見的認知落差。如需了解各模型的 API 定價，可參考2026 年 LLM API 定價比較。

哪些內容適合快取

適合放入快取的是「穩定內容」——每次對話都不會改變的系統提示詞靜態部分，例如角色定義、回應格式指引、固定的背景知識。這類內容結構清晰，長期不變，是快取命中率最高的候選項目。

不適合快取的是「動態內容」，包括每次查詢結果都不同的 RAG 記憶區塊，以及每個回合都在向前移動的對話歷史最後一條訊息。這類內容每回合都在變化，即使設置快取標記，快取 key 每次都不同，結果是每回合都在寫入而從不讀取。

這裡有一個關鍵的架構原則：穩定內容與動態內容必須分離。若將 RAG 查詢結果混入系統提示詞，系統提示詞便會因此在每個回合發生變化，快取永遠無法命中。這是生產系統中最常見、也最難被察覺的錯誤。

實際踩過的坑

快取本身並不複雜，但有幾個陷阱值得特別注意。

動態內容混入系統提示詞。如上所述，這是命中率歸零的最直接原因。解決方法是在架構層面明確分離 stablePart 與 dynamicPart，前者設置 cache_control，後者另行傳遞。

快取標記放在對話最後一條訊息。快取的邊界每個回合都在向前移，導致每次都是寫入而從不讀取。快取標記應設置在穩定的系統提示詞區塊，而非動態移動的訊息邊界。

加入 Streaming 後未重新驗證快取。Streaming 部署後，快取可能靜默失效。若未主動追蹤 cache_creation 與 cache_read 的回應數值，三個回合全部顯示 cache_creation: 0 才會被發現。

TTL 格式錯誤。正確格式為整數秒數（ttl: 300），而非字串（ttl: "1h"）。格式錯誤不會回傳 400 錯誤，API 正常接受請求、回應正常，只是快取靜默不生效。這類問題需透過刻意追蹤 billing log 才能察覺。

Anthropic 亦曾在未正式通知的情況下更新快取行為：2026 年 3 月，TTL 由 1 小時縮短至 5 分鐘，長對話的命中率因此下跌；2026 年 7 月，顯式 TTL 由可選變為必填，未設置者靜默失效。兩次變更均非透過 400 錯誤或文件更新通知，而是直接影響計費數字。定期核對 cache 命中數據，是生產系統的基本監控項目。

結語

Prompt Caching 本身的邏輯並不難，但它的效果完全取決於實作細節：穩定內容與動態內容是否分離、快取標記的位置是否正確、TTL 格式是否符合當前 API 規範。以上任何一點出錯，快取便會靜默失效，帳單照舊，而日誌裡不會出現任何錯誤提示。

對於已在生產環境使用 LLM API 的團隊，值得做的第一步是追蹤每個回合的 cache_creation_input_tokens 與 cache_read_input_tokens 數值。若 cache_creation 持續高於 cache_read，通常意味著架構中存在上述問題之一。找到問題、修正分離邏輯，節省效果往往立竿見影。