Prompt Caching 是什麼?AI API 費用怎麼省一半以上

內容目錄 隱藏

4.1 Prompt Caching 到底在快取什麼

4.2 三大家怎麼做:Anthropic、OpenAI、Google Gemini、AWS Bedrock

4.3 怎麼設計 Prompt 才吃得到快取

4.4 跟 RAG、Context Window 差在哪

⚡ 站長快讀:核心重點

文章屬性:AI 概念解析
核心結論:Prompt Caching(提示詞快取)是把 AI 對話裡「每次都一樣」的那段內容存起來重複讀取,不用每次都花錢重新運算,Anthropic、OpenAI、Google、AWS Bedrock 四家都支援,但觸發門檻、快取時間與實際省下的比例差很多
適用對象:自己串 AI API 的開發者、想搞懂 AI 帳單為什麼忽然變便宜(或變貴)的人、對 LLM 運作原理好奇的讀者

📌 快速答案

一句話答案:Prompt Caching(提示詞快取)把提示中重複不變的內容快取起來,下次直接讀快取不必重算,官方數據顯示費用最高可省下九成。

🔍 為什麼你要在乎這件事

如果你自己串過 Claude、GPT 或 Gemini 的 API 做客服機器人、程式碼助理或知識庫問答,一定遇過這種情況:同一份落落長的 system prompt、同一份文件、同一組 few-shot 範例,每一次呼叫都要原封不動地再送一次給模型——模型也乖乖地把它重新「讀」一次、重新算一次,你也乖乖地為這些完全沒變過的內容再付一次全額費用。一個幾千字的系統提示,如果一天呼叫上萬次,光是重複運算這段不變的內容,就可能吃掉帳單裡一大塊冤枉錢。

Prompt Caching 解決的正是這個問題:把「重複出現、內容不變」的前綴存起來,下一次呼叫時直接讀快取、跳過重新運算,官方數據顯示費用最高可以省到只剩一成、延遲也明顯下降。三大家都支援,但多數人根本沒認真檢查過自己的 prompt 結構到底吃不吃得到快取——設計錯一個小地方,快取形同虛設,帳單一毛都省不到。

🧪 原理拆解

Prompt Caching 到底在快取什麼

白話講,Prompt Caching 快取的不是「答案」,而是模型處理輸入內容過程中產生的中間運算結果(可以想成模型「讀完」這段文字後的內部狀態)。下次請求如果前面那段內容一字不差,模型就能直接接著算,不用從頭「重讀」一遍。這跟快取網頁圖片的概念類似:第一次要整包下載,之後只要內容沒變,瀏覽器直接讀本地存的版本。

關鍵在於「一字不差」——這是逐字比對(exact match),不是語意相近就算數。系統提示裡多一個空白、時間戳記換一秒、工具定義改個字,都會讓比對失敗,變成重新寫入一次快取(還要多付一點寫入費),而不是讀取。

三大家怎麼做:Anthropic、OpenAI、Google Gemini、AWS Bedrock

四家的做法差異頗大,這也是最多人搞混的地方:

Anthropic(Claude):提供「自動快取」與「手動斷點」兩種模式。自動模式只要在請求最上層加一個 cache_control 欄位,系統會自動把快取斷點往前推到最後一個可快取的區塊;手動模式則是在個別內容區塊上標記 cache_control,一次請求最多可放 4 個斷點,適合系統提示、工具定義、對話內容各自獨立快取。預設快取存活 5 分鐘,可額外付費延長到 1 小時。計費方式:5 分鐘快取寫入是基礎輸入價的 1.25 倍、1 小時寫入是 2 倍,快取命中(讀取)只要基礎價的 0.1 倍——換算下來命中一次省 90%。以現行 Claude Sonnet 5 為例(2026 年 8 月 31 日前價格),基礎輸入 $2/百萬 token,快取寫入(5 分鐘)$2.50、命中只要 $0.20;Claude Opus 4.8 基礎輸入 $5/百萬 token,命中只要 $0.50。可快取的最短長度依模型而定,Sonnet 5 與 Opus 4.8 是 1,024 token 起跳。系統會回看最多 20 個內容區塊找可用的快取,找不到才整段重寫。

OpenAI(GPT 系列):走全自動路線,不用改任何程式碼。只要提示長度超過 1,024 token,系統自動用 128-token 為單位快取最長的相同前綴,命中直接打五折(省 50%),延遲最高可降 80%。快取通常在閒置 5~10 分鐘後清除,最長 1 小時內一定會清掉,不同組織間的快取互不共用。

Google Gemini:分成「隱性快取」與「顯性快取」兩種。隱性快取是 Gemini 2.5 之後的模型自動啟用,系統會偷偷比對最近的請求,命中就自動打折,但官方不保證一定省到錢(要看命中率);顯性快取則是自己呼叫 API 建立一個有 TTL(存活時間,預設 1 小時)的快取物件,之後的請求指定這個快取 ID 就能保證省錢,但要另外付一筆儲存費。想提高隱性快取命中率,官方建議把大量重複的內容放在提示最前面、並在短時間內送出前綴相似的請求。

AWS Bedrock:概念跟 Anthropic 直接 API 類似,用「快取檢查點」標記要快取的連續前綴,Claude 系列模型一次最多 4 個檢查點,門檻依模型而定(例如 Claude 3.7 Sonnet 是 1,024 token,較新的 Opus 4.5、Sonnet 4.5、Haiku 4.5 則要 4,096 token),多數模型預設 5 分鐘 TTL,部分新模型也支援 1 小時。Bedrock 也提供「簡化快取管理」,只要放一個斷點,系統自動往回找最多約 20 個區塊的相符前綴,機制上跟 Anthropic 官方 API 的自動快取幾乎一致。Amazon Nova 模型則預設就有自動快取延遲效益,但官方建議明確啟用「顯性快取」才能穩定拿到成本上的節省。

怎麼設計 Prompt 才吃得到快取

四家做法雖然不同,但有一個共同的黃金原則:把不會變的內容放最前面,會變的內容放最後面。系統提示、工具定義、長文件、few-shot 範例這些「每次呼叫都一樣」的東西擺在提示開頭,使用者當下的問題、時間戳記、對話中新增的那一句放在最後。

Anthropic 官方文件特別點出一個工程師很容易踩的地雷:如果把快取斷點下在「每次都會變」的區塊上(例如一個含時間戳記的區塊),那麼每次請求的內容雜湊值都不一樣,快取永遠對不上——結果是每次都在付「重新寫入」的費用,卻一次「讀取折扣」都拿不到。正確做法是把斷點下在「最後一個維持不變的區塊」,而不是「最後一個區塊」。這個細節很小,但直接決定你到底有沒有真的省到錢。

跟 RAG、Context Window 差在哪

這幾個概念常被搞混,但解決的是不同層次的問題:

RAG(檢索增強生成)解決的是「模型不知道的事」——即時去外部資料庫撈資料塞進提示,讓模型有根據可以回答;Prompt Caching 解決的是「同一段內容重複出現」的成本問題。兩者其實互補:你可以把 RAG 撈回來的長文件也一併快取,同一份文件被反覆提問時就不用每次整份重新算。

Context Window(上下文視窗)講的是「這個對話最多能塞多少 token」的容量上限;Prompt Caching 不會讓這個上限變大,而是讓「重複送進這個視窗裡的內容」變便宜、變快——一個是容量問題,一個是成本問題,維度完全不同。

用推理模型(Reasoning Model)串多輪 agent 流程時還有個眉角:根據 Anthropic 官方文件,思考(thinking)區塊本身不能直接標記快取,但在後續請求把它跟著工具結果一起送回去時,仍會被當作對話內容的一部分快取、讀取時一樣算入 token 用量——用推理模型堆多輪對話的人,這個細節會影響你怎麼估算快取到底幫你省了多少。

💡 總結:站長的實務觀察

站長我這幾年幫不少小型團隊和個人開發者看過 AI API 串接的架構,最常見的一個認知落差就是:大家都知道「快取可以省錢」,卻很少人真的打開 API 回傳的 usage 欄位,檢查 cache_read_input_tokens 跟 cache_creation_input_tokens 這兩個數字,確認自己的 prompt 到底吃不吃得到快取。如果每次呼叫都是「寫入」沒有「讀取」,代表你的提示結構有問題(通常就是把會變動的內容放太前面),快取形同白設定。

實務上我會建議:先從最簡單的自動快取模式開始用(Anthropic、OpenAI 都提供全自動選項),觀察一週的用量數據,確認命中率穩定之後,再考慮要不要手動切多個斷點做更細緻的控制。至於要不要加購 1 小時的延長 TTL,關鍵在你的請求頻率——如果同一段內容平均每 5 分鐘內就會再被呼叫一次,預設的 5 分鐘快取本來就會不斷自動續命,沒必要多付延長費;只有請求間隔常常拉長到 5 分鐘以上、又不到 1 小時的場景,才值得換算一下划不划算。以上內容依 Anthropic、OpenAI、Google、AWS 官方文件於 2026-07-09 查證撰寫,實際費率與門檻請以當下官方頁面為準,四家都改過好幾次規則,以後也大機率還會再調。

❓ 常見問題

Q:Prompt Caching 會不會讓 AI 的回答變得不準確或打折?

不會。根據 Anthropic 官方文件明確說明,Prompt Caching 只影響「輸入」的處理方式,不影響模型產生答案的過程——你拿到的輸出跟沒開快取時完全一樣。快取讀取是逐字比對(exact match),不是語意相近的近似記憶,也不是打折版的摘要。

Q:一般人用 ChatGPT、Claude、Gemini 的訂閱版(不是自己接 API)感受得到 Prompt Caching 嗎?

感受得到「變快」但看不到「變便宜」。訂閱版是固定月費,Prompt Caching 省下來的是 API 端的運算成本與延遲,一般使用者體感通常只有「長對話或重複貼同一份文件時,AI 回得比較快」;帳單本身不會因為快取而改變,除非你是用量計費的 API 使用者。

Q:Claude、ChatGPT、Gemini 的快取是同一套東西嗎?

底層概念相同(重複前綴不用重算),但門檻與機制不一樣:OpenAI 全自動免設定、固定省 50%;Anthropic 自動與手動斷點都能選,命中最高省 90%,但要留意 5 分鐘/1 小時的存活時間與 20 個區塊的回看範圍;Google 分「隱性」(自動、不保證省錢)與「顯性」(手動建立、保證省錢但要付儲存費)兩種模式。細節差異見上文對照。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Prompt caching — Claude Platform Docs — 2026-07-09 查證
Prompt caching — OpenAI API 官方文件 — 2026-07-09 查證
Context caching — Gemini API 官方文件 — 2026-07-09 查證(頁面標註最後更新 2026-03-24)
Prompt caching for faster model inference — Amazon Bedrock 官方文件 — 2026-07-09 查證

📖 第二級|業界案例佐證:

How We Cut LLM Costs by 59% With Prompt Caching — ProjectDiscovery Blog — 2026-07-09 查證(第三方實務案例,非官方數據,僅供參考)

⚠️ 本文核心事實(定價、門檻、TTL)以第一級官方文件為準,第二級為實務案例補充。

📅 本文查證戳記:2026-07-09 依據 Anthropic、OpenAI、Google、AWS 官方文件撰寫。API 定價與快取門檻各家不定期調整(例如 Claude Sonnet 5 基礎定價將於 2026-09-01 起調整),使用前請以官方當下頁面為準。