Skip to main content
API易 的 Gemini 通道自動啟用隱式上下文快取（implicit caching）：請求字首命中時按官方折扣計費，cached_content_token_count 欄位原樣回吐，零程式碼改動。 先說結論：Gemini 快取”有，但別指望” —— 隱式快取的命中行為由上游控制，實際命中率明顯不如 OpenAI 和 Claude。把它當作”有則更好”的額外優惠，做成本測算時一律按無快取價格估算。 本頁基於 Google 官方文件整理（ai.google.dev/gemini-api/docs/caching，2026年6月資料）。

​
機制一句話

請求開頭部分（字首）與近期請求相同且達到最小長度時，上游自動複用快取：命中部分按官方折扣計費（官方口徑最高可省 90%），無需打任何標記。

​
觸發條件

注意 Gemini 的起緩閾值（4096）比 OpenAI（1024）高不少 —— 短系統提示詞在 Gemini 上基本不會命中，這是”Gemini 快取體感差”的原因之一。

​
怎麼判斷命中

看 usage_metadata.cached_content_token_count：
命中部分在後臺賬單中按折扣倍率單列計費項；REST 響應裡的對應欄位為 usageMetadata.cachedContentTokenCount。

​
儘量提高命中率

方法論和 OpenAI 一致（詳細解釋見 OpenAI 快取計費指南）：
  • 穩定內容放前面：長系統指令、文件、few-shot 示例在前；使用者輸入、時間戳在後
  • 字首做長：不足 4096 tokens（Gemini 3 系）的字首永遠不會命中
  • 短時間內集中複用：批次任務連續發，不要拉開間隔
  • 多輪對話天然是追加式字首，相對容易命中
即便全部做對，也不保證命中 —— 隱式快取是 best-effort 的，這點和 OpenAI/Claude 的確定性行為不同。

​
顯式快取（cachedContents）

Google 官方還有顯式快取 API（cachedContents，建立一個有 TTL 的快取物件再引用）。該介面是有狀態的服務端資源，API易 通道暫不支援，請使用隱式快取。

​
與其它通道對比

快取敏感的高頻長字首業務（Agent、RAG、批次文件），建議優先選 OpenAI 或 Claude 通道。 全平臺快取支援總覽見 快取計費 FAQ。

​
相關連結