Gemini Context Caching適合在多次請求中重複使用同一段大型前綴，例如長System Instructions、產品規格、影片、文件集或Repository背景。快取命中後，重複Token會使用較低的Cached Input價格，但仍要支付新輸入、輸出、Thinking與部分模式下的Storage費用。
快取是否省錢，取決於重複前綴大小、請求次數、TTL、命中率與輸出成本。只建立Cache但很少重用，Storage可能高於節省；每次改動前綴順序，也會降低Implicit Cache命中。
重點快讀
- Implicit Caching在Gemini 2.5以上模型預設啟用，命中時自動反映成本。
- Interactions API目前只支援Implicit Cache。
- GenerateContent API可建立Explicit Cache物件並控制TTL。
- Implicit Cache需要固定大型前綴並在較短時間重複請求。
- Explicit Cache成本包含Cached Token與Storage Time。
- Break-even取決於未快取輸入價差、Cache大小、TTL與重用次數。
Implicit與Explicit Caching差在哪？
| 模式 | Implicit | Explicit |
|---|---|---|
| 啟用方式 | 支援模型自動啟用 | 先建立Cache Resource |
| API | Interactions與GenerateContent | GenerateContent |
| TTL控制 | 由平台管理 | 使用者設定與更新 |
| 命中方式 | 相同大型Prefix與時間接近 | 請求明確引用Cache名稱 |
| 適合 | 自然重複對話與短期工作 | 大量重用固定文件、影片與知識前綴 |
| 主要成本 | Cached Input | Cached Input加Storage |
Implicit Caching不需要建立物件。官方文件顯示，Gemini 2.5以上模型預設啟用，回應中的Usage欄位可查看命中的Cached Tokens。Explicit Cache則需要先建立Resource，後續請求以名稱引用。
Implicit Cache的最小Token
| 模型範例 | 官方最小Input Token |
|---|---|
| Gemini 3.5 Flash | 4,096 |
| Gemini 3.1 Pro Preview | 4,096 |
| Gemini 2.5 Flash | 2,048 |
| Gemini 2.5 Pro | 2,048 |
模型與門檻會更新，部署前應查看官方Caching頁。低於最小Token的短Prompt不適合期待快取效益，也不需要為了達到門檻刻意加入無關內容。
如何提高Implicit Cache命中？
- 把大型且固定內容放在Prompt最前面。
- 把每次變動的問題、日期與使用者資料放在後方。
- 保持System Instruction、文件順序與格式一致。
- 短時間內發送相似Prefix的請求。
- 避免在前綴插入Request ID、Timestamp與隨機字串。
- 透過Usage欄位追蹤實際Cached Tokens。
快取是Prefix Cache。即使內容相同，若順序、前段格式或Metadata頻繁變動，命中率仍會下降。Context Builder應把Invariant與Dynamic Context分開。
Explicit Cache適合哪些工作？
- 同一部長影片被反覆問不同問題。
- 大量請求共用大型產品手冊或政策。
- Repository分析使用固定Snapshot。
- 聊天機器人使用長System Instructions與Few-shot。
- 同一批文件進行分類、比較與報告。
- 評測大量任務共用相同Context。
資料會快速變動、請求量低或每次Context都不同時，不適合建立長TTL Cache。一般RAG或按需檢索可能更省，也更容易保持最新。
TTL與Storage成本
Explicit Cache會按Cached Token數量與保存時間計算Storage。TTL越長，不代表越划算。它應略長於實際請求波次，並在來源更新後建立新版本或刪除舊Cache。
- 短批次：使用小時級TTL。
- 工作日共用：根據實際活躍時段設定。
- 長期文件：先估請求量，再決定是否持續保存。
- 來源更新：使用新Cache ID，避免新舊內容混合。
- 任務結束：主動刪除不再使用的Cache。
Break-even公式
每次命中節省 =
Cache Token ÷ 1,000,000
×（一般Input單價 - Cached Input單價）
Storage成本 =
Cache Token ÷ 1,000,000
× 每小時Storage單價
× TTL小時
Break-even命中次數 =
Storage成本 ÷ 每次命中節省Explicit Cache通常建立時也會產生處理成本，正式試算需依官方模型價格加入建立、非快取Input、Output、Thinking與其他工具費用。
Gemini 3.5 Flash試算範例
以2026年7月官方標準價格為示範：一般Input每100萬Token 1.50美元、Context Cached Input 0.15美元、Storage每100萬Token每小時1美元。假設Cache為100,000 Token，TTL為1小時：
- 每次未快取輸入：0.1 × 1.50 = 0.15美元。
- 每次快取輸入：0.1 × 0.15 = 0.015美元。
- 每次命中節省：0.135美元。
- 1小時Storage：0.1 × 1 = 0.10美元。
- 不計建立成本時，約一次命中即可覆蓋Storage。
這個範例只說明方法。模型價格與處理層會變動，Batch、Flex與Priority也有不同單價。正式預算應使用當天官方Pricing和自己的Usage。
命中率如何影響成本？
有效快取節省 =
總請求數 × 命中率 × 每次命中節省
- Storage
- Cache建立與管理成本命中率低時，系統仍為一般Input付費。應追蹤每個Task與Cache ID的總請求、Cached Tokens、TTL與節省，不只看平台總帳。
Context Cache和RAG怎麼分工？
| 情境 | 建議 |
|---|---|
| 固定大型前綴反覆使用 | Context Cache |
| 大量文件只需少數相關段落 | RAG |
| 核心規則固定、證據動態 | Cache加RAG |
| 資料快速更新 | RAG與短TTL |
| 單次長文件分析 | 直接Context或分段，不一定建Cache |
Cache降低重複處理固定內容的成本；RAG降低每次載入的內容量。兩者可以組合，但都需要來源、版本與權限控制。
Batch與處理層
不需要即時回應的批量任務，可以進一步使用Batch或Flex等較低成本處理層。快取只降低重複Input，Batch則調整整體Input與Output價格。兩者是否能同時產生明顯效益，要依目前模型價格表計算。
高優先級即時請求使用Priority時，Cached Input價格也可能提高。不能只沿用Standard的Break-even。
快取版本與失效
- Cache ID連到Source Version與Checksum。
- 文件更新後建立新版本，不覆蓋舊內容。
- 請求Trace保存使用的Cache ID。
- 失效Cache停止新請求並依需要保留稽核。
- 權限撤銷時同步刪除Cache與衍生資料。
- 多租戶不得共用越權Context。
快取命中不能跨越資料權限。即使兩名使用者查詢相同文件，也要確認Tenant、Project與Scope是否允許共享。
監控指標
| 指標 | 用途 |
|---|---|
| Cached Token Ratio | 輸入中有多少實際命中 |
| Cache Hit Rate | 多少請求取得快取折扣 |
| Storage Hours | TTL是否過長 |
| Cost Saved | 相較未快取基線的節省 |
| Version Error | 是否使用過期Cache |
| Permission Error | 是否發生跨Scope存取 |
| Accepted Task Cost | 快取是否改善整體任務經濟性 |
整體TCO與ROI可閱讀AI Agent ROI怎麼算？；Context組裝與Token Budget可閱讀Context Engineering怎麼做？。
常見問題
Implicit Cache需要額外設定嗎？
支援模型預設啟用。要提高命中率，保持大型共同前綴在前方，並使用Usage欄位確認Cached Tokens。
TTL越長越省嗎？
不一定。Explicit Cache按保存時間收Storage。TTL應接近實際重用時段，否則可能增加成本與過期風險。
快取能降低Output成本嗎？
不能直接降低。快取主要降低重複Input價格，Output與Thinking仍按模型價格計算。
官方資料
Gemini Context Caching真正省錢的條件，是大型Prefix會在有效TTL內被多次重用，而且來源、版本與權限保持一致。沒有重用量，快取只會增加另一層管理與Storage。
發表迴響