一句話解釋

Prompt Caching 是讓 AI API 把重複使用的 prompt 前綴暫存起來，下次呼叫時不需要重新計算，藉此降低費用和回應時間。

白話解釋

每次你呼叫 AI API，模型都要「讀」一次你送進去的所有文字。如果你的 System Prompt 有 3000 個 token（大約 2000 個中文字），每次呼叫模型都要花錢重新處理這 3000 個 token。如果你一天呼叫 10 萬次，光 System Prompt 就被重新計算了 10 萬次。這裡面有大量的重複計算被浪費了。

這就像你每天去同一家早餐店，每次都要重新自我介紹、重新說明你不吃蛋、重新確認要去冰。如果老闆能「記住」你的固定需求，就只需要聽你今天要加點什麼。你們之間的溝通會變快，老闆也不用每次都花腦力記你的偏好。

Prompt Caching 就是讓 AI 的伺服器「記住」你每次都一樣的那段 prompt。第一次呼叫時正常計算並存起來，之後同樣的前綴直接從快取讀取，不用重算。你只需要付快取讀取的費用（通常是正常價格的 10% 左右）。這個機制對於有大量重複 prompt 內容的應用來說，省錢效果非常顯著。

舉一個具體的例子。假設你開發了一個法律諮詢的 AI 助手，System Prompt 裡面包含了 5000 個 token 的法律知識、回答格式要求和角色定義。每一次使用者提問的時候，這 5000 個 token 都要重新處理一次。如果每天有 2 萬次使用者提問，那就是 2 萬次 × 5000 tokens = 1 億個 token 的重複計算。有了 Prompt Caching，第一次正常計算之後，後面的 19,999 次都只需要付快取讀取的費用。

Prompt Caching 怎麼運作

技術上，LLM 在處理 prompt 時會把文字轉成一連串的內部狀態（叫做 KV cache，Key-Value cache）。KV cache 是 Transformer 架構在做注意力計算（attention）時產生的中間結果。每一個 token 在通過模型的每一層時，都會產生一組 Key 和 Value 向量，這些向量在後續的 token 生成過程中會被反覆使用。計算這些 KV 向量的過程佔了大量的計算資源，特別是當 prompt 很長的時候。

Prompt Caching 把這個內部狀態存起來，下次遇到相同的 prompt 前綴時，直接載入已經算好的 KV cache，跳過重新計算的步驟。這樣模型只需要處理 prompt 中「新的」部分（也就是使用者這次的輸入），大幅減少計算量。

觸發條件：你的 prompt 需要有一段「前綴」在多次呼叫之間完全一樣。所謂完全一樣是指每一個字、每一個空格、每一個換行都相同。改了任何一個字，快取就失效了。這是因為快取是根據 token 序列的 hash 值來匹配的，任何微小的改變都會導致不同的 hash 值。

常見的可快取內容包含：

System Prompt（通常不會變）。這是最常見的快取目標，因為 System Prompt 在同一個應用的所有請求中通常完全相同。

Few-shot examples（固定的範例）。如果你在 prompt 中提供固定的輸入輸出範例，這些範例可以被快取。

RAG 檢索到的長文件（同一份文件可能被多次引用）。例如使用者針對同一份報告連續問了好幾個問題，那份報告的文字就可以被快取。

工具定義（Function Calling 的函式描述）。如果你定義了 10 個工具，每個工具的定義大約 200-500 tokens，這些定義在每次呼叫中都一樣，非常適合快取。

使用者的當次輸入通常是變動的，所以放在 prompt 的最後面，讓前面的固定部分都能被快取。這是使用 Prompt Caching 時最重要的設計原則——把不變的內容放前面，會變的內容放後面。

Prompt 排列的最佳實務

要最大化 Prompt Caching 的效果，prompt 的排列順序很重要。以下是建議的排列方式：

1. System Prompt（角色定義、規則、格式要求）  ← 最不常變動
2. 工具定義（Function Calling 的函式清單）    ← 很少變動
3. Few-shot 範例                              ← 偶爾更新
4. RAG 檢索結果（文件內容）                   ← 每次可能不同
5. 對話歷史                                   ← 每次都不同
6. 使用者當次輸入                             ← 每次都不同

越不常變動的內容放越前面，這樣即使後面的內容改變，前面的部分仍然可以命中快取。如果你把使用者輸入放在 System Prompt 前面，那整個 prompt 的快取就無法命中了。

另一個常見的錯誤是在 System Prompt 中加入時間戳記或隨機的 session ID。例如在 System Prompt 的開頭加上「現在時間是 2026-07-23 14:32:05」，這樣每一秒鐘的快取都不同，等於完全沒有快取效果。如果你需要讓 AI 知道當前時間，建議把時間放在使用者訊息中，而不是 System Prompt 裡。

各家服務商的實作

Anthropic（Claude）的做法。2024 年推出，快取自動觸發。當你的 prompt 前綴超過 1024 個 token，系統自動快取。快取命中時，被快取的 token 費用降為原本的 10%。快取存活時間是 5 分鐘，5 分鐘內有新的呼叫就會延長。第一次建立快取時，會額外收取 25% 的寫入費用，但這個成本在後續的快取命中中很快就能回本。

Anthropic 的 API 回應中會明確告訴你有多少 token 是快取命中的（cache_read_input_tokens）和有多少是新寫入快取的（cache_creation_input_tokens），方便你監控快取效率。在 Claude Code 這類工具中，Prompt Caching 是預設啟用的，因為 Claude Code 每次呼叫都會帶入大量的上下文資訊（專案檔案、對話歷史等），非常適合快取。

適合的場景：有長 System Prompt 的應用、Claude Code 這類需要反覆傳送大量上下文的工具、即時對話中每次都帶入完整對話歷史的場景。

OpenAI（GPT）的做法。2024 年底推出。同樣是自動觸發，不需要額外設定。最小快取前綴是 1024 個 token。命中時費用打 5 折。快取存活時間比較長（分鐘到小時不等，OpenAI 未公開確切時間）。OpenAI 的 Prompt Caching 不收取額外的寫入費用，但折扣幅度（50%）不如 Anthropic（90%）。

OpenAI 的快取對同一個組織（Organization）下的所有請求共享。這代表如果你的組織有多個應用都使用類似的 System Prompt，它們之間可以互相受益於快取命中。

Google（Gemini）的做法。叫做 Context Caching。跟前兩家不同，Google 的版本需要你手動建立快取。你呼叫一個 API 明確說「我要把這段文字存成快取」，拿到一個快取 ID，之後每次呼叫帶上這個 ID。快取有儲存費用（按時間計費），但使用時的 token 費用大幅降低。

你可以指定快取的過期時間（從 1 分鐘到幾天都可以）。手動管理的好處是你可以精確控制快取的生命週期和內容，壞處是需要額外的程式碼來管理快取。適合需要長時間反覆引用同一份大文件的場景，比如法律文件分析、長篇程式碼 review。Google 的最小快取大小是 32,768 tokens，比其他家高很多，所以只有 prompt 很長的場景才適用。

比較項目 Anthropic OpenAI Google
觸發方式 自動 自動 手動建立
最小前綴 1024 tokens 1024 tokens 32,768 tokens
費用折扣 90% off 50% off 依模型不同
存活時間 5 分鐘（可延長） 不固定 自己設定
儲存費用 寫入時加收 25% 無 按時間計費
回應中快取資訊 有（詳細） 有（基本） 有
適用場景 高頻短對話 一般用途 長文件反覆分析

什麼時候該用 Prompt Caching

適合用的情況：

你的 System Prompt 很長（超過 1000 字）。很多企業應用的 System Prompt 包含公司政策、角色定義、回答格式要求、禁止事項，加起來好幾千 token。這些每次都一樣，很適合快取。台灣的金融業和保險業 AI 助手通常有很長的合規要求和產品說明，System Prompt 動輒 5000-10000 tokens，是 Prompt Caching 的理想場景。

你做 RAG 的時候每次帶入同一份文件。如果使用者針對同一份報告問了十個問題，那份報告的文字可以被快取，每次追問只需要付一次完整費用。這在文件分析的場景中非常常見。

你用 Few-shot 範例。固定的 5-10 組範例放在 prompt 前面，每次呼叫都一樣，很適合快取。例如你要做情感分析，每次都帶入 8 組「句子→情感標籤」的範例，這些範例可以被快取。

你的應用有高頻呼叫。如果一天只呼叫幾十次，省不了多少錢。但如果一天幾萬次，Prompt Caching 可能幫你把 AI API 費用砍掉一半以上。高頻呼叫也讓快取更容易保持「活躍」，減少快取過期的機率。

你使用 Function Calling 且定義了很多工具。每個工具定義佔 200-500 tokens，如果你定義了 20 個工具，就是 4000-10000 tokens 的固定開銷。這些工具定義在每次呼叫中完全相同，快取命中率接近 100%。

不適合的情況：

每次 prompt 都完全不同（沒有固定前綴）。純聊天場景，每次的上下文都是新的對話歷史，快取命中率很低。不過即使在聊天場景，如果你的 System Prompt 夠長，System Prompt 的部分還是可以命中快取。

prompt 很短（低於 1024 tokens）。低於最小快取門檻，不會觸發快取。如果你的 System Prompt 只有幾百個 token，Prompt Caching 對你幫助不大。

請求頻率很低。如果你一天只呼叫幾十次 API，快取可能在兩次呼叫之間就過期了（特別是 Anthropic 的 5 分鐘存活時間）。在這種情況下，快取寫入的額外費用可能反而讓你花更多錢。

實際省錢的例子

一個台灣電商的客服機器人。System Prompt 有 2000 tokens（包含產品目錄摘要、退貨政策、語調要求、常見問題處理流程）。另外定義了 8 個 Function Calling 工具（查詢訂單、查詢庫存、退貨申請等），工具定義共約 3000 tokens。每天 5 萬次呼叫。

沒有快取：每次都要計算 5000 tokens（2000 System Prompt + 3000 工具定義）的輸入費用。 以 Claude Sonnet 的定價計算，input $3/MT，每天光固定部分就花 5000 × 50000 / 1M × $3 = $750。

有快取：第一次正常計算並寫入快取（加收 25%），之後快取命中只花 10%。 寫入成本可以忽略（只有第一次），快取命中部分：$750 × 10% = $75。每天省 $675，一個月省約 $20,000。

這還只是固定 prompt 的部分。如果使用者連續問多個問題（對話歷史也能被快取），省更多。

另一個例子是台灣的法律科技公司。他們的 AI 助手會把整部法律條文（大約 30,000 tokens）放進 prompt 中，讓 AI 根據法條回答使用者的法律問題。使用 Google 的 Context Caching，他們把法條快取了一個月，期間所有的使用者查詢都能命中快取，token 費用降低了 75%，每月省下約 $5,000 的 API 費用。

如何監控快取效果

要知道 Prompt Caching 有沒有在省錢，你需要監控幾個指標：

快取命中率（Cache Hit Rate）。用快取命中的 token 數量除以總 input token 數量。好的應用應該有 70% 以上的命中率。如果命中率低於 30%，你的 prompt 設計可能需要調整。

每次請求的平均成本。比較啟用快取前後的平均成本。如果成本沒有明顯下降，可能是快取頻繁失效或 prompt 結構不適合快取。

快取失效的頻率。監控有多少請求觸發了快取寫入（cache_creation）而非快取讀取（cache_read）。如果寫入比例太高，代表快取經常失效。

Anthropic 的 API 回應中直接提供這些數據。你可以在程式碼中記錄每次呼叫的 cache_read_input_tokens 和 cache_creation_input_tokens，定期匯總分析。OpenAI 的 usage 欄位中也有類似的快取統計資訊。

安全與限制

快取是共用的嗎？不同使用者的快取不會互相影響。每個 API key 和 prompt 內容的組合都是獨立的。使用者 A 的快取不會被使用者 B 讀到。這是因為快取的匹配是基於 token 序列的精確比對（或 hash），不同的內容不可能命中同一份快取。不過，同一個 API key 下的不同請求，如果有相同的 prompt 前綴，是會共享快取的。這在多租戶應用中需要注意——如果你的 System Prompt 對所有使用者都一樣，那麼所有使用者的請求都可以命中同一份快取，這是好事。但如果不同使用者有不同的 System Prompt（例如包含使用者專屬的設定），那麼每個使用者版本的 System Prompt 都需要各自建立快取。

快取失效的風險。如果你修改了 System Prompt（哪怕只是加一個空格），快取就會失效，下一次呼叫會以完整費用重新計算。在更新 prompt 的時候要注意這個成本衝擊。建議在更新 System Prompt 之前，先計算快取失效造成的短期成本增加，選擇在低流量時段更新。

延遲不一定總是降低。第一次寫入快取時，延遲可能比正常呼叫稍高（因為要多做一步儲存）。只有快取命中時延遲才會降低。Anthropic 報告快取命中時的延遲可以降低到原來的 85%。如果你的 prompt 前綴頻繁變動，可能反而增加延遲（因為每次都在寫入新的快取但從來不命中）。

不是所有模型都支援。各家服務商通常只在較新的模型上支援 Prompt Caching。使用前確認你選的模型版本有支援。例如 Anthropic 的 Prompt Caching 在 Claude 3.5 Sonnet 之後的模型才支援。

快取中的隱私考量。雖然快取在技術上是安全的，但如果你的 prompt 包含敏感資訊（例如客戶的個人資料），這些資訊會暫時存在服務商的快取中。對於有嚴格資料合規要求的台灣企業，需要確認這是否符合《個人資料保護法》的規定。建議避免在 System Prompt 中直接放入客戶個資，改用 ID 或代號來參照。

常見問題

Prompt Caching 需要改程式碼嗎？

看服務商。Anthropic 和 OpenAI 是自動觸發，你不需要改任何程式碼，只要 prompt 前綴夠長就會自動命中。Google 的 Context Caching 需要額外呼叫 API 建立快取，管理快取 ID 和過期時間，程式碼改動比較大。如果你從 Anthropic 或 OpenAI 開始，可以零改動就享受快取的好處。

快取內容會被用來訓練模型嗎？

不會。快取跟訓練是完全不同的機制。快取只是暫存你的 prompt 的計算結果（KV cache），過期後就刪除了。它不會進入任何訓練流程。這一點在各家服務商的隱私政策中都有明確說明。

我怎麼知道快取有沒有命中？

API 回應裡通常會標示。Anthropic 的回應會告訴你有多少 token 是從快取讀取的（cache_read_input_tokens），以及有多少是新寫入快取的（cache_creation_input_tokens）。你可以用這些數據來監控快取命中率。建議在應用的監控儀表板中加入快取命中率的指標，定期檢視。

Prompt Caching 和 Fine-tuning 哪個更省錢？

解決的問題不同。Fine-tuning 是把知識「烤」進模型裡，之後 prompt 可以變短，因為模型已經「知道」了那些規則和範例。Prompt Caching 是讓長 prompt 的重複部分不用重算，prompt 長度不變，但計算成本降低。如果你的 System Prompt 長是因為有大量範例和規則，兩種方法都能省錢，但 Prompt Caching 不需要訓練時間和額外的訓練成本。一般來說，先用 Prompt Caching（零成本導入），如果還是太貴，再考慮 Fine-tuning。

多人同時使用會互相搶快取嗎？

不會。Prompt Caching 是按照 prompt 內容做 hash 來辨識的。同一個 prompt 前綴不管哪個使用者送的，都能命中同一份快取。這代表同一個應用的多個使用者反而互相幫助提高命中率——使用者 A 的請求建立了快取，使用者 B 馬上就能受益。使用者越多、請求頻率越高，快取的效益越大。

對話場景中的 Prompt Caching 效果如何？

在多輪對話場景中，Prompt Caching 的效果取決於 prompt 的結構。每一輪對話都會把之前的對話歷史帶入 prompt，而之前的歷史在下一輪不會改變（因為它已經發生了），所以可以被快取。例如一個 10 輪對話，第 10 輪的 prompt 中包含前 9 輪的完整歷史，而這些歷史在第 11 輪也完全一樣，可以命中快取。不過 Anthropic 的 5 分鐘快取時間限制代表使用者如果超過 5 分鐘沒有發新訊息，快取就會失效。

相關文章

參考資料