Gemini API 的 Context Caching 會把重複使用的大型 context 暫存起來，後續請求只需付每小時 $0.31/M tokens 的儲存費與原 input 價 25% 的讀取費；以 250,000 tokens 的公司知識庫每天處理 100 次客服問答估算，月成本可從約 $953 降到約 $304，節省約 68%，但前提是 context 至少 4,096 tokens、會被多次使用且內容不常變動。
發布 2026-05-19 · 最後更新 2026-09-27 · 作者 賴家榮 Andy Lai
Context Caching 是 Gemini API 最被低估的功能。用對能讓您的 API 帳單砍 75%——這篇用實測數據與程式碼帶您懂。
Context Caching 是什麼？
當您每次請求都附帶同一份「大 context」（例如公司知識庫、長 PDF、固定系統指令），Gemini 會重複處理一樣的內容。Context Caching 就是把這份 context 暫存起來，後續請求只需付：
- 儲存費（每小時 $0.31/M tokens）
- 命中讀取費（原 input 價的 25%）
什麼時候該用？
三個必要條件：
- Context 至少 4,096 tokens（小檔案不適用）
- 同一份 Context 會被多次使用（不只一次性）
- Context 在多次請求間不變動（變動就要重建 cache）
實測對比
場景：1MB 公司知識庫（約 250,000 tokens）每天處理 100 次客服問答
無 Cache：
Input：100 × 250,000 × 30 = 750M × $1.25 = $937.5
Output：100 × 500 × 30 = 1.5M × $10 = $15
月成本：約 $953（NT$28,600）
有 Cache：
Cache 儲存：250K × 24h × 30 × $0.31 / 1,000,000 = $55
Cache 讀取：100 × 250K × 30 × $1.25 × 25% / 1,000,000 = $234
Output：$15
月成本：約 $304（NT$9,100）
節省：$649/月 = 約 NT$19,500/月 = 68%
程式碼範例（Python）
from google import genai
from google.genai import types
client = genai.Client(api_key="YOUR_KEY")
# 1. 建立 cache
cache = client.caches.create(
model='gemini-2.5-flash',
config=types.CreateCachedContentConfig(
display_name='company_knowledge',
system_instruction='你是 XX 公司的客服...',
contents=[
types.Content(
role='user',
parts=[types.Part.from_text(
text=open('company_docs.txt').read()
)]
)
],
ttl='3600s' # 1 小時後過期
)
)
# 2. 使用 cache 發送請求
response = client.models.generate_content(
model='gemini-2.5-flash',
contents='請問退換貨政策？',
config=types.GenerateContentConfig(
cached_content=cache.name
)
)
print(response.text)
常見錯誤
- Cache 太小：< 4,096 tokens 會被拒絕
- TTL 設太短：1 小時內沒命中夠多次反而虧
- Cache 內容變動頻繁：每次都要重建，反而貴
TTL 最佳值估算
公式：TTL = 預期請求間隔 × 3
- 每 1 分鐘有人問問題 → TTL 設 5 分鐘
- 每小時 10 次請求 → TTL 設 6 小時
- 夜間批量 → 用 Batch Mode 而非 Cache
哪些場景最值得做 Caching？
- 客服 RAG（固定知識庫 + 用戶問答）
- 長文件問答（每次問同一本書）
- 有大量範例的 Few-shot Prompt
- 多用戶共用同一系統指令
常見問題
Gemini 的 Context Caching 是什麼？
Context Caching 是把每次請求都會附帶的同一份大 context（例如公司知識庫、長 PDF、固定系統指令）暫存起來，避免 Gemini 重複處理相同內容。後續請求只需付儲存費（每小時 $0.31/M tokens）與命中讀取費（原 input 價的 25%）。
什麼情況適合使用 Context Caching？
要同時滿足三個條件：context 至少 4,096 tokens，小檔案不適用；同一份 context 會被多次使用，不是一次性；context 在多次請求間不變動，變動就要重建 cache。最值得做的場景是客服 RAG、長文件問答、大量範例的 Few-shot Prompt，以及多用戶共用同一系統指令。
Context Caching 實際能省多少 API 費用？
文章以 1MB 約 250,000 tokens 的公司知識庫、每天處理 100 次客服問答估算：無 cache 月成本約 $953（NT$28,600），有 cache 後儲存費 $55、讀取費 $234、輸出 $15，月成本約 $304（NT$9,100），每月節省 $649 約 NT$19,500，相當於 68%。
Cache 的 TTL 該設多久？
作者提供的公式是 TTL 等於預期請求間隔乘以 3。例如每 1 分鐘有人問問題就設 5 分鐘，每小時 10 次請求就設 6 小時。若是夜間批量處理，建議改用 Batch Mode 而不是 Cache。TTL 設太短，1 小時內沒命中夠多次反而會虧。
使用 Context Caching 常見的錯誤有哪些？
三個常見錯誤：cache 太小，低於 4,096 tokens 會被拒絕；TTL 設太短，命中次數不夠反而虧；cache 內容變動頻繁，每次都要重建反而更貴。使用前先確認 context 夠大、會重複使用且內容穩定。