
LLM 提示快取:降低 90% API 成本(涵蓋三大供應商)
LLM 提示快取(Prompt Caching) 讓你能夠在多次 API 呼叫中重複使用先前處理過的 token,將輸入成本降低高達 90%,並將首個 token 生成時間(TTFT)減少高達 85%。如果你在每次請求中都發送相同的系統提示、工具定義或少樣本(few-shot)範例,你其實是在為 GPU 已經完成的工作支付全額費用。
本指南涵蓋 OpenAI、Anthropic 和 Gemini,並在所有三個 SDK 中實作相同的聊天機器人,這是其他指南所沒有的特色。我們還將探討 Anthropic 於 2026 年 2 月推出的自動快取更新、包含實際美元金額的生產環境成本情境,以及那些會悄悄破壞你快取命中率的反模式。
<!-- IMAGE: KV cache reuse flow diagram showing prompt prefix matching, cache hit path (fast, cheap), and cache miss path (standard processing) -->快速總結:一次看清三大供應商
在深入實作細節之前,以下是完整的比較表。如果你已經知道要使用哪個供應商,可以直接跳轉至該章節。如果你正在評估,這張表格能在 10 秒內告訴你一切。
| 功能 | OpenAI | Anthropic | Gemini |
|---|---|---|---|
| 快取類型 | 自動 | 自動 + 明確指定 | 隱式 + 明確指定 |
| 最小 Token 數 | 1,024 | 1,024(大多數模型) | 1,024(Flash)/ 4,096(Pro) |
| 存活時間 (TTL) | 5-10 分鐘(延長可達 24 小時) | 5 分鐘或 1 小時 | 可設定(預設 1 小時) |
| 快取寫入成本 | 1x(無額外費用) | 1.25x(5 分鐘)/ 2x(1 小時) | 1x(無額外費用) |
| 快取讀取折扣 | 輸入價格減半 (50% off) | 輸入價格降低 90% | 輸入價格降低約 90% |
| 快取隔離範圍 | 組織 (Organization) | 工作區 (Workspace) | 專案 (Project) |
| 串流支援 | 是 | 是 | 是 |
| 快取命中回應欄位 | cached_tokens | cache_read_input_tokens | cachedContentTokenCount |
| 明確控制 | 否 | 是 (cache_control) | 是 (命名快取物件) |
| 最新重大更新 | 2024 年 10 月 | 2026 年 2 月 (自動快取) | 2026 年 (隱式快取) |
關鍵結論: OpenAI 最簡單(零設定,50% 折扣)。Anthropic 提供最深的折扣(90%)和最多的控制權。Gemini 提供可設定的 TTL,並在 2.5+ 模型上提供隱式快取,其折扣力度與 Anthropic 相當。
LLM 提示快取是如何運作的?
你不需要理解 Transformer 的內部運作就能有效使用提示快取。但你確實需要理解一個概念:前綴匹配(prefix matching)。
60 秒了解 KV Cache
當 LLM 處理你的提示時,它會為每個 token 計算注意力狀態(鍵值對,即 key-value pairs)。這些 KV cache 條目是昂貴的部分,它們消耗 GPU 記憶體和計算時間。提示快取會儲存這些已計算的狀態,以便下一個具有相同前綴的請求可以完全跳過重新計算。
關鍵詞是 前綴。快取從提示的 開頭 向前匹配。如果前 2,000 個 token 與快取條目匹配,但第 2,001 個 token 不同,那麼前 2,000 個 token 將從快取中提供。分歧點之後的所有內容都會重新計算。
這就是為什麼提示順序很重要。請像這樣建構你的提示:
- 工具定義(最靜態)
- 系統提示
- 靜態少樣本範例
- 檢索到的上下文(半動態)
- 對話歷史(每輪增加)
- 使用者查詢(總是不同)
靜態內容在前,動態內容在後。匹配快取前綴的 token 越多,節省的成本就越大。
提示快取 vs 語意快取 vs 回應快取
這三個術語經常被混淆。提示快取(本指南涵蓋的內容)在 GPU 層級重用相同 token 前綴的已計算 KV 狀態,準確度零損失,輸出與未快取時相同。語意快取 使用嵌入相似度為「足夠相似」的查詢返回先前生成的回應,速度更快但可能返回錯誤答案。回應快取 儲存確切的輸入-輸出配對並原樣返回快取的回應,僅適用於真正相同的請求。
提示快取是唯一「免費的最佳化」,它在沒有任何準確度權衡的情況下降低成本和延遲。關於 KV 快取背後的深度 Transformer 數學原理,Hugging Face 的技術解釋 測量出在 T4 GPU 上约有 ~5.21 倍的速度提升。
OpenAI 如何處理提示快取?
OpenAI 的提示快取是完全自動化的。 自 2024 年 10 月起,每個擁有 1,024+ 輸入 token 的 API 呼叫都會自動受益於快取。你無需選擇加入,無需添加標頭,也無需更改程式碼。
OpenAI 自動快取的工作原理
當你發送至少 1,024 個 token 的請求時,OpenAI 會檢查前綴是否與你組織最近的請求匹配。快取命中的成本為標準輸入 token 價格的 50%。在初始的 1,024-token 門檻之後,快取以 128-token 增量 進行匹配。
在正常使用期間,快取存活時間為 5-10 分鐘,在非高峰時段透過延長保留機制可持續長達 24 小時。它的範圍是按組織劃分的,因此同一組織內的不同專案可以受益於共享快取。
支援的模型包括 GPT-4o、GPT-4o-mini、GPT-4.1、o1、o3-mini 以及所有更新的模型。
OpenAI Python SDK 範例
from openai import OpenAI
client = OpenAI()
# This system prompt is ~2,000 tokens -- well above the 1,024 minimum
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""
def chat(user_message: str) -> str:
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": user_message},
],
)
# Check if caching kicked in
usage = response.usage
cached = usage.prompt_tokens_details.cached_tokens
total_input = usage.prompt_tokens
print(f"Cached: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")
return response.choices[0].message.content
# First call: cache miss (full price)
chat("Review this async function for race conditions...")
# Second call within 5-10 min: cache hit (50% off on cached tokens)
chat("Now optimize the same function for throughput...")第一次呼叫以全價處理所有內容並填充快取。第二次呼叫以半價重用已快取的系統提示 token。你在輸出中會看到類似 Cached: 1920/2048 tokens (94%) 的內容。
結論:OpenAI 最容易上手,零設定,快取自動發生。 雖然 50% 的折扣是三大供應商中最低的,但其簡便性無可比擬。
Anthropic/Claude 如何處理提示快取?
Anthropic 提供 兩種模式:自動快取(自 2026 年 2 月起預設啟用)和帶有 cache_control 斷點的明確快取。這個數字難以忽視:快取讀取的成本僅為標準輸入價格的 10%,即 90% 的折扣。
自動 vs 明確快取(2026 更新)
截至 2026 年 2 月 5 日,Anthropic 為所有符合條件的提示預設啟用自動快取。你不再需要舊版的 beta 標頭。系統會自動確定最佳的快取斷點。
当你想要細粒度控制時,仍然可以使用明確快取。你在特定的內容區塊上放置 cache_control: {"type": "ephemeral"} 以精確標記快取邊界的位置。當你的提示具有特定結構且你想保證某些部分被快取時,這非常有用。
存在兩種 TTL 選項:
- 5 分鐘快取(預設):寫入成本為基礎輸入價格的 1.25x,讀取成本為 0.1x。只需 1 次快取命中即可回本。
- 1 小時快取:寫入成本為基礎輸入價格的 2x,讀取成本為 0.1x。需 2 次快取命中才能回本。適用於 Claude 4.5+ 模型。
自 2026 年 2 月 5 日起,快取隔離從組織層級變更為 工作區層級。這意味著同一組織內的不同工作區維護獨立的快取。
在使用 Anthropic 的快取時,建構提示以優化快取 很有幫助,將靜態內容放在動態內容之前在這裡更加重要,因為你需要支付寫入溢價。
Anthropic Python SDK 範例
import anthropic
client = anthropic.Anthropic()
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""
def chat(user_message: str) -> str:
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[
{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}, # Explicit breakpoint
}
],
messages=[
{"role": "user", "content": user_message},
],
)
# Read cache metrics from the response
usage = response.usage
created = usage.cache_creation_input_tokens
read = usage.cache_read_input_tokens
standard = usage.input_tokens
print(f"Cache write: {created}, Cache read: {read}, Standard: {standard}")
return response.content[0].text
# First call: cache_creation_input_tokens = ~1920 (write at 1.25x)
chat("Review this async function for race conditions...")
# Second call: cache_read_input_tokens = ~1920 (read at 0.1x -- 90% off!)
chat("Now optimize the same function for throughput...")理解快取寫入 vs 快取讀取定價
Anthropic 的定價在這裡變得有趣。以 Claude Sonnet 4.5(基礎輸入 $3/MTok)為例:
- 標準輸入: 每百萬 token $3.00
- 快取寫入(5 分鐘): 每百萬 token $3.75(1.25x),你第一次需要支付更多
- 快取讀取: 每百萬 token $0.30(0.1x)-- 每次後續命中便宜 90%
5 分鐘快取僅需 1 次讀取 即可回本。1 小時快取($6.00/MTok 寫入)需 2 次讀取 回本。如果你每分鐘使用相同前綴發出超過幾次請求,數學計算絕對對你有利。
結論:Anthropic 提供最深的折扣(90%)和最多的控制權。最適合高流量、對成本敏感的工作負載。
Google Gemini 如何處理提示快取?
Gemini 採用不同的方法,擁有 兩種截然不同的快取機制:明確上下文快取(你建立並引用的命名快取物件)和隱式快取(自動、零設定,於 2026 年為 Gemini 2.5+ 模型添加)。
明確上下文快取(命名快取)
與 OpenAI 和 Anthropic 的透明快取不同,Gemini 的明確快取要求你先建立一個 命名快取物件,然後在後續請求中引用它。Gemini Flash 模型的最小 token 門檻為 1,024 個 token,Pro 模型為 4,096 個 token。TTL 是可設定的,預設為 1 小時,但你可以根據需要進行設定。
Gemini 2.5 Pro 上的快取 token 定價為 $0.125/MTok,而標準輸入價格為 $1.25/MTok,即 90% 的折扣。此外,Pro 模型還有每百萬 token 每小時 $4.50 的儲存成本,Flash 模型為 $1.00。
Gemini 2.5 中的隱式快取(2026)
從 Gemini 2.5 Pro 和 Flash 開始,Google 添加了 隱式快取,這是一種類似 OpenAI 方法的自動快取。無需設定。將大型、常見的內容放在提示的開頭,並快速連續地發送具有相似前綴的請求。系統會自動檢測符合快取條件的內容並傳遞節省的成本。
Gemini Python SDK 範例
from google import genai
from google.genai import types
client = genai.Client()
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""
# Step 1: Create a named cache object
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
display_name="python-review-guidelines",
system_instruction=SYSTEM_PROMPT,
ttl="3600s", # 1 hour
),
)
print(f"Cache created: {cache.name}, expires: {cache.expire_time}")
# Step 2: Use the cache in requests
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Review this async function for race conditions...",
config=types.GenerateContentConfig(
cached_content=cache.name,
),
)
# Check cache usage in the response
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")明確方法有一個巨大的優勢:你可以精確控制 TTL。如果你知道批次作業運行 4 小時,設定 4 小時的 TTL 可以避免在處理過程中快取過期。
結論:Gemini 的可設定 TTL 和雙重快取模式(明確 + 隱式)使其具有多功能性。最小門檻現在與其他供應商相當,且快取讀取的 90% 折扣與 Anthropic 匹配。
並列程式碼比較:相同用例,三大供應商
以下是使用已快取系統提示的相同聊天機器人,在所有三個 SDK 中實作。直接比較開發者體驗。
# --- OpenAI: Zero config, just call the API ---
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": SYSTEM_PROMPT}, # Cached automatically
{"role": "user", "content": user_message},
],
)
cached = response.usage.prompt_tokens_details.cached_tokens# --- Anthropic: Explicit cache_control breakpoint ---
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}, # Mark cache boundary
}],
messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens# --- Gemini: Named cache object ---
from google import genai
from google.genai import types
client = genai.Client()
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
system_instruction=SYSTEM_PROMPT,
ttl="3600s",
),
)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=user_message,
config=types.GenerateContentConfig(cached_content=cache.name),
)
cached = response.usage_metadata.cached_content_token_count| 方面 | OpenAI | Anthropic | Gemini |
|---|---|---|---|
| 設定複雜度 | 無 | 添加 cache_control 區塊 | 先建立快取物件 |
| 快取控制 | 僅自動 | 自動或明確指定 | 隱式或明確指定 |
| 快取讀取折扣 | 50% | 90% | ~90% |
| 最小 Token 數 | 1,024 | 1,024 | 1,024 (Flash) / 4,096 (Pro) |
| 開發者體驗結論 | 最簡單 | 最多控制權 | 最靈活的 TTL |
如果你想要零努力的節省,選擇 OpenAI。如果你想要最深的折扣和細粒度控制,選擇 Anthropic。如果你需要可設定的快取壽命或已經在使用 Google Cloud,選擇 Gemini。
生產環境成本計算器:規模下的實際節省
抽象的百分比無法驅動決策。美元金額才可以。以下是三個生產環境情境,使用 Claude Sonnet 4.5(輸入 $3/MTok)、GPT-4o(輸入 $2.50/MTok)和 Gemini 2.5 Pro(輸入 $1.25/MTok)的實際成本估算。
定價驗證於 2026 年 3 月。請查看 Anthropic 定價、OpenAI 定價 和 Gemini 定價 以獲取當前費率。
假設:80% 快取命中率(對於結構良好的提示來說是現實的),排除輸出 token,因為快取僅影響輸入成本。
| 情境 | 無快取(每月) | 使用 OpenAI 快取 | 使用 Anthropic 快取 | 使用 Gemini 快取 |
|---|---|---|---|---|
| 業餘聊天機器人:100 次請求/天,2K 系統提示 | OpenAI: $15 / Anthropic: $18 / Gemini: $7.50 | $12 (省 $3) | $5.40 (省 $12.60) | $2.25 (省 $5.25) |
| 成長型 API:10K 次請求/天,8K 快取前綴 | OpenAI: $600 / Anthropic: $720 / Gemini: $300 | $360 (省 $240) | $144 (省 $576) | $60 (省 $240) |
| 企業級管道:100K 次請求/天,10K 快取前綴 | OpenAI: $7,500 / Anthropic: $9,000 / Gemini: $3,750 | $4,500 (省 $3,000) | $1,800 (省 $7,200) | $750 (省 $3,000) |
在成長型層級,儘管 Anthropic 的基礎價格高於 OpenAI,但 Anthropic 快取每月仍可節省 $576。在企業規模下,使用 Anthropic 每月可節省 $7,200,即每年 $86,400。這相當於透過一項設定變更節省了一名資深工程師的成本。
模式很明顯:請求量越高,靜態前綴越長,快取節省的成本就越多。Anthropic 的 90% 折扣在規模上佔主導地位,但考慮到總成本時,Gemini 較低的基礎價格使其具有競爭力。
提示快取反模式:何時不該快取
快取看起來很簡單,直到你的快取命中率神秘地停留在 0%。以下是會悄悄破壞提示快取的錯誤,以及如何修復它們。
破壞快取的錯誤(附修復方法)
系統提示中的時間戳,這是最常見的錯誤。如果你的系統提示包含 datetime.now(),快取鍵每秒都會改變。
# BAD: Cache misses every single request
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""
# GOOD: Move the timestamp to the user message
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""
user_message = f"[Current time: {datetime.now().isoformat()}]\n{user_query}"靜態內容之前的使用者特定內容,如果你在開頭放置 session_id 或使用者偏好設定,每個使用者都會獲得獨特的前綴。
# BAD: Unique prefix per user = zero cache reuse
messages = [
{"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
{"role": "user", "content": query},
]
# GOOD: Static content first, user context at the end
messages = [
{"role": "system", "content": GUIDELINES}, # Same for all users -> cached
{"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]| 反模式 | 為何破壞快取 | 修復方法 |
|---|---|---|
| 系統提示中的時間戳 | 前綴每秒改變 | 將時間戳移至使用者訊息 |
| 前綴中的 Session/使用者 ID | 每個使用者的前綴獨特 | 將使用者上下文移至靜態內容之後 |
| 輪換的少樣本範例 | 不同的範例 = 不同的前綴 | 使用固定的範例集 |
| 動態工具定義 | 改變工具 = 前綴不匹配 | 保持工具 schema 靜態 |
| 短提示(低於最小值) | 快取根本不會觸發 | 合併上下文以超過 1,024 個 token |
| 系統提示中的每請求個人化 | 系統提示每次呼叫都改變 | 使用共享系統提示 + 使用者特定的使用者訊息 |
提示快取真正無助益的情況
即使你完美地建構了提示,某些情境也不會從快取中受益:
- 一次性提示:如果每個請求都有完全獨特的上下文且沒有共享前綴,則沒有什麼可快取的。
- 非常短的提示:低於 1,024 個 token(OpenAI/Anthropic)或 4,096 個 token(Gemini Pro),快取不會啟動。
- 不頻繁的請求:如果請求間隔數小時,快取會在第二次請求到達之前過期。OpenAI 的 5-10 分鐘視窗和 Anthropic 的 5 分鐘預設 TTL 意味著你需要穩定的流量。
提示快取是否支援串流?
是的。提示快取和串流是獨立的,快取作用於輸入 token,串流影響輸出交付。 它們在請求生命週期的不同階段解決不同的問題。
快取處理 預填充階段(prefill phase)(處理你的輸入提示)。串流處理 解碼階段(decode phase)(逐步生成並發送輸出 token)。你可以同時獲得兩者的好處:來自快取命中的更快預填充,加上來自串流的漸進式輸出交付。
這是一個啟用快取的串流範例:
import anthropic
client = anthropic.Anthropic()
with client.messages.stream(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}],
messages=[{"role": "user", "content": "Explain Python's GIL..."}],
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True)
# After streaming completes, check cache metrics
usage = stream.get_final_message().usage
print(f"\nCache read: {usage.cache_read_input_tokens} tokens")實際上,串流時快取帶來的 TTFT 改進 最為明顯。沒有快取時,你必須等待完整的預填充才能開始串流第一個 token。有了快取,預填充幾乎是瞬間完成的,因此 token 幾乎立即開始流動。
如何在生產環境中監控快取命中率
設定快取只是戰鬥的一半。知道它是否真正運作是另一半。如果你的快取命中率低於 50%,表示你的提示結構發生了變化,而你正在浪費金錢。
供應商特定的快取指標
| 供應商 | 快取讀取欄位 | 快取寫入欄位 | 總輸入欄位 |
|---|---|---|---|
| OpenAI | usage.prompt_tokens_details.cached_tokens | N/A(自動) | usage.prompt_tokens |
| Anthropic | usage.cache_read_input_tokens | usage.cache_creation_input_tokens | usage.input_tokens |
| Gemini | usageMetadata.cachedContentTokenCount | N/A(明確快取物件) | usageMetadata.promptTokenCount |
簡單的快取命中率記錄器
這是一個你可以放入任何專案的工具函數,用於 透過 API 回應欄位追蹤快取命中率:
import logging
logger = logging.getLogger("cache_monitor")
def log_cache_metrics(provider: str, usage: dict) -> float:
"""Extract and log cache metrics from any provider's response. Returns hit rate."""
if provider == "openai":
cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0)
total = usage.prompt_tokens
elif provider == "anthropic":
cached = usage.cache_read_input_tokens
created = usage.cache_creation_input_tokens
total = cached + created + usage.input_tokens
elif provider == "gemini":
cached = getattr(usage, "cached_content_token_count", 0)
total = usage.prompt_token_count
else:
raise ValueError(f"Unknown provider: {provider}")
hit_rate = (cached / total * 100) if total > 0 else 0
logger.info(f"[{provider}] Cache hit rate: {hit_rate:.1f}% ({cached}/{total} tokens)")
if hit_rate < 50:
logger.warning(f"[{provider}] Low cache hit rate! Check prompt structure.")
return hit_rate健康的生產系統應維持 70-90% 的快取命中率。如果低於 50%,請回顧反模式章節。你也可以將其與 自動化評估指標 整合,以捕捉提示管道中的回歸問題。
真實世界用例中的提示快取
上述聊天機器人範例說明了機制,但提示快取在特定的架構模式中真正發光。
RAG 管道
在 RAG 設定中,你的系統提示和少樣本範例在所有查詢中都是靜態的。檢索到的文件每次都改變。建構你的提示以最大化快取前綴:
- 系統提示(已快取)
- 少樣本範例(已快取)
- 檢索到的文件(動態,放在最後)
- 使用者查詢(總是獨特)
使用 5,000-token 的系統提示和 3,000-token 的少樣本範例,每次請求就有 8,000 個 token 被快取。在 Anthropic 上每天 1,000 次請求,僅快取前綴每天就可節省約 $6.50。當你 檢索並快取上下文區塊 時,確保檢索輸出來自靜態前綴之後。
多輪聊天機器人
多輪對話是提示快取的甜蜜點。每一輪都會增加對話歷史,但整個之前的對話已經從先前的輪次中快取。快取效益會複合,到了第 10 輪,你可能有 15,000 個 token 的已快取歷史,而最新使用者訊息只有 200 個新 token。
代理系統和 MCP 工具定義
如果你正在建構使用工具的代理,你的工具定義是每次 API 呼叫都重複的靜態 JSON schema。典型的代理可能有 20+ 個工具,總計 3,000-5,000 個 token 的定義。這是極佳的快取材料。
這對於基於 MCP 的架構尤其相關,因為 伺服器工具定義會在每次呼叫時發送。使用 Anthropic 的明確 cache_control,你可以標記 tools 陣列進行快取,並保證這些 token 被重用。
你應該選擇哪個供應商?
| 如果你需要... | 最佳選擇 | 原因 |
|---|---|---|
| 零設定,只想節省成本 | OpenAI | 自動快取,無需更改程式碼 |
| 最大成本降低(90%) | Anthropic | 0.1x 快取讀取價格,最深折扣 |
| 細粒度快取控制 | Anthropic | 明確斷點 + 可設定 TTL(5 分鐘或 1 小時) |
| 長文件分析 | Gemini | 具有明確命名快取物件的可設定 TTL |
| 多輪聊天簡便性 | OpenAI | 對增長的對話歷史進行自動前綴匹配 |
| 帶有工具定義的代理系統 | Anthropic | 使用 cache_control 明確快取工具定義 |
| 多供應商靈活性 | LiteLLM | 跨所有供應商的統一快取語法 |
如果你已經在使用某個供應商,從那裡開始,提示快取不需要切換。LiteLLM 作為代理層 規範了跨供應商的快取參數,這在你將請求路由到多個模型時非常有用。
FAQ:LLM 提示快取
什麼是 LLM 中的提示快取?
提示快取儲存先前處理過的提示前綴的已計算注意力狀態(KV cache)。當後續請求以相同的 token 序列開始時,供應商會重用這些儲存的狀態而不是重新計算它們,從而降低成本和延遲,且對輸出品質零影響。
提示快取能節省多少 API 成本?
節省範圍從 50% 到 90% 不等,取決於供應商。OpenAI 提供快取輸入 token 50% 的折扣。Anthropic 提供高達 90% 的折扣(快取讀取為基礎價格的 0.1x)。Gemini 在快取讀取上提供約 90% 的折扣。實際節省取決於你的快取命中率、提示長度和請求頻率。
OpenAI 提示快取是自動發生的嗎?
是的,自 2024 年 10 月起。任何具有 1,024+ 輸入 token 的 API 呼叫都會自動受益於快取。無需選擇加入,無需標頭,無需更改程式碼。快取從提示開頭匹配 token 前綴。
提示快取和語意快取有什麼區別?
提示快取在 GPU 層級匹配確切的 token 前綴,沒有準確度損失,輸出與未快取請求相同。語意快取使用嵌入相似度來尋找「足夠接近」的先前查詢並返回快取的回應,速度更快但可能返回不正確或過時的答案。它們解決 fundamentally 不同的問題。
提示快取持續多久?
因供應商而異。OpenAI:5-10 分鐘(延長保留可達 24 小時)。Anthropic:5 分鐘(預設)或 1 小時(適用於 Claude 4.5+ 模型,寫入成本為 2x)。Gemini:可設定,明確快取預設為 1 小時。隱式快取 TTL 由 Google 自動管理。
提示快取的最小 token 長度是多少?
OpenAI:1,024 個 token。Anthropic:大多數當前模型為 1,024 個 token。Gemini:Flash 模型為 1,024 個 token,Pro 模型為 4,096 個 token。低於這些閾值的提示不會啟動快取,這是最常見的「它不起作用」的陷阱。
提示快取是否適用於串流回應?
是的。快取和串流運作於請求的不同階段。快取加速輸入預填充階段;串流逐步交付輸出 token。兩者同時運作,而且啟用串流時你實際上會更明顯地注意到 TTFT 的改進。
何時不應使用提示快取?
當你的提示低於最小 token 閾值、在系統提示中包含時間戳或 session ID、在呼叫之間輪換少樣本範例,或請求過於不頻繁以致於在快取過期前無法命中(OpenAI/Anthropic 為 5-10 分鐘視窗)時,避免依賴快取。
我可以將提示快取與 LangChain 或 LiteLLM 一起使用嗎?
可以。LangChain 透過其 API 包裝器傳遞供應商特定的快取參數。LiteLLM 提供統一的快取語法,規範了 Anthropic、OpenAI、Gemini、Vertex AI 和 Bedrock 之間的 cache_control,對於多供應商設置特別有用。
什麼是快取命中 vs 快取未命中?
快取命中 表示供應商在記憶體中找到匹配的前綴并重用了儲存的 KV 狀態,你支付折扣後的快取 token 費率並獲得更快的 TTFT。快取未命中 表示未找到匹配項,因此以標準定價從頭開始處理完整提示。檢查 API 回應中的 cached_tokens(OpenAI)、cache_read_input_tokens(Anthropic)或 cachedContentTokenCount(Gemini)欄位以查看發生了哪種情況。
最終結論
| 類別 | 獲勝者 | 關鍵原因 |
|---|---|---|
| 最容易設定 | OpenAI | 自動,零設定 |
| 最深折扣 | Anthropic | 快取讀取降低 90%(0.1x 基礎) |
| 最多控制權 | Anthropic | 明確斷點 + 5 分鐘或 1 小時 TTL |
| 最適合長文件 | Gemini | 具有命名快取物件的可設定 TTL |
| 最適合多輪聊天 | OpenAI | 對對話歷史進行自動前綴匹配 |
| 最適合代理/MCP | Anthropic | 明確快取工具定義 |
提示快取是 LLM API 堆疊中努力最低、回報最高的最佳化。你不需要更改模型,不需要犧牲品質,實作範圍從「什麼都不做」(OpenAI)到「添加一個欄位」(Anthropic)再到「建立一個快取物件」(Gemini)。
從你當前供應商的自動快取開始。使用上面的記錄工具測量你的快取命中率。如果低於 70%,重構你的提示(靜態在前,動態在後)並消除反模式。大多數團隊在實施這些更改後的一天內就能看到 50-80% 的成本降低。