Techsy
聯絡我們
立即開始
回到部落格
guides

LLM 提示快取:降低 90% API 成本(涵蓋三大供應商)

作者: Mert Batur Gürbüz
Mar 25, 2026
4 分鐘閱讀
目錄
LLM 提示快取:降低 90% API 成本(涵蓋三大供應商)

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 秒內告訴你一切。

功能OpenAIAnthropicGemini
快取類型自動自動 + 明確指定隱式 + 明確指定
最小 Token 數1,0241,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_tokenscache_read_input_tokenscachedContentTokenCount
明確控制否是 (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 將從快取中提供。分歧點之後的所有內容都會重新計算。

這就是為什麼提示順序很重要。請像這樣建構你的提示:

  1. 工具定義(最靜態)
  2. 系統提示
  3. 靜態少樣本範例
  4. 檢索到的上下文(半動態)
  5. 對話歷史(每輪增加)
  6. 使用者查詢(總是不同)

靜態內容在前,動態內容在後。匹配快取前綴的 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 範例

python
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 範例

python
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 範例

python
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 中實作。直接比較開發者體驗。

python
# --- 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
python
# --- 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
python
# --- 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
方面OpenAIAnthropicGemini
設定複雜度無添加 cache_control 區塊先建立快取物件
快取控制僅自動自動或明確指定隱式或明確指定
快取讀取折扣50%90%~90%
最小 Token 數1,0241,0241,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(),快取鍵每秒都會改變。

python
# 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 或使用者偏好設定,每個使用者都會獲得獨特的前綴。

python
# 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)。你可以同時獲得兩者的好處:來自快取命中的更快預填充,加上來自串流的漸進式輸出交付。

這是一個啟用快取的串流範例:

python
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%,表示你的提示結構發生了變化,而你正在浪費金錢。

供應商特定的快取指標

供應商快取讀取欄位快取寫入欄位總輸入欄位
OpenAIusage.prompt_tokens_details.cached_tokensN/A(自動)usage.prompt_tokens
Anthropicusage.cache_read_input_tokensusage.cache_creation_input_tokensusage.input_tokens
GeminiusageMetadata.cachedContentTokenCountN/A(明確快取物件)usageMetadata.promptTokenCount

簡單的快取命中率記錄器

這是一個你可以放入任何專案的工具函數,用於 透過 API 回應欄位追蹤快取命中率:

python
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 設定中,你的系統提示和少樣本範例在所有查詢中都是靜態的。檢索到的文件每次都改變。建構你的提示以最大化快取前綴:

  1. 系統提示(已快取)
  2. 少樣本範例(已快取)
  3. 檢索到的文件(動態,放在最後)
  4. 使用者查詢(總是獨特)

使用 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%)Anthropic0.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對對話歷史進行自動前綴匹配
最適合代理/MCPAnthropic明確快取工具定義

提示快取是 LLM API 堆疊中努力最低、回報最高的最佳化。你不需要更改模型,不需要犧牲品質,實作範圍從「什麼都不做」(OpenAI)到「添加一個欄位」(Anthropic)再到「建立一個快取物件」(Gemini)。

從你當前供應商的自動快取開始。使用上面的記錄工具測量你的快取命中率。如果低於 70%,重構你的提示(靜態在前,動態在後)並消除反模式。大多數團隊在實施這些更改後的一天內就能看到 50-80% 的成本降低。

來源

  • Anthropic 提示快取文件
  • OpenAI 提示快取指南
  • Gemini 上下文快取文件
  • Anthropic 模型定價
  • Gemini API 定價
  • KV 快取解釋,Hugging Face 部落格
  • LiteLLM 提示快取文件

標籤

llm-prompt-cachingprompt-cachingllm-api-costsopenaianthropicgeminikv-cacheai-development

分享這篇文章

相關文章

更多「%s」主題文章 guides

guides
Jul 18, 2026

2026 年 LLM API 價格比較:所有主要模型定價一覽

2026 年完整 LLM API 價格比較 — Claude、GPT-5.6、Gemini、DeepSeek、Qwen、GLM 和 Mistral 並列比較每百萬 Token 的價格,數據直接來自官方定價頁面。

12 min read 分鐘閱讀
繼續閱讀
guides
Apr 12, 2026

Surfer SEO 2026 指南:內容編輯器、NLP 評分與 AI 搜尋

一份實用的 Surfer SEO 指南,涵蓋內容編輯器工作流程、NLP 評分系統、用於 GEO 優化的 AI Tracker 以及 API 自動化。基於對 50 多篇文章的測試經驗。

14 min read 分鐘閱讀
繼續閱讀
guides
Apr 12, 2026

2026 Semrush 指南:詳解所有工具(附實例)

一份實用的 Semrush 指南,涵蓋關鍵字研究、網站審計、競爭對手分析、AI 可見度追蹤以及 MCP 伺服器設定。包含來自真實 SEO 工作流程的程式碼範例與操作流。

14 min read 分鐘閱讀
繼續閱讀
查看全部文章
啟動專案

準備好創造點什麼了嗎 非凡體驗?

讓我們將你的願景化為現實。團隊已準備好,助你打造真正有影響力的軟體。

預約 30 分鐘需求討論查看作品

精選上架

Claude 技能

查看全部
  • New Post

    Full SEO blog pipeline: research, brief, write, validate, image, translate, publish to Sanity. Autonomous from start to finish.

  • Content Refresh

    Audit a stale post, find decay drivers, and ship a SERP-aligned refresh without losing existing rankings.

  • SEO Audit

    Site-wide SEO audit with prioritized fix list: technical, on-page, and EEAT signals.

AI 自動化作業

查看全部
  • Security Auditor

    Weekly SCA + IaC scan with prioritized fix PRs.

  • Cold Email Writer

    Generates first-touch emails grounded in one specific public detail.

  • Lead Research Agent

    Enrich an email into a profile, score fit, alert in Slack.

精選上架

Claude 技能

查看全部
  • New Post

    Full SEO blog pipeline: research, brief, write, validate, image, translate, publish to Sanity. Autonomous from start to finish.

  • Content Refresh

    Audit a stale post, find decay drivers, and ship a SERP-aligned refresh without losing existing rankings.

  • SEO Audit

    Site-wide SEO audit with prioritized fix list: technical, on-page, and EEAT signals.

AI 自動化作業

查看全部
  • Security Auditor

    Weekly SCA + IaC scan with prioritized fix PRs.

  • Cold Email Writer

    Generates first-touch emails grounded in one specific public detail.

  • Lead Research Agent

    Enrich an email into a profile, score fit, alert in Slack.

服務項目

  • 企業級解決方案
  • 手機應用程式
  • 網頁應用

解決方案

  • CRM 系統
  • AI 整合應用
  • ERP 整合系統
  • 語音助理代理
  • 工作流程自動化
  • 網路資安

資源庫

  • 部落格
  • 專案作品

社群

  • AI 自動化作業
  • Claude 技能

工具

  • 手機應用程式開發費用計算器
  • OpenAI / LLM API 費率計算器
  • MVP 開發費用計算器
  • 語音 AI 助理費用計算器

關於 TECHSY

  • 瀏覽
  • 合作夥伴
  • 聯絡我們

法律聲明

  • 私隱政策
  • 服務條款
  • Cookies說明

服務項目

  • 企業級解決方案
  • 手機應用程式
  • 網頁應用

解決方案

  • CRM 系統
  • AI 整合應用
  • ERP 整合系統
  • 語音助理代理
  • 工作流程自動化
  • 網路資安

資源庫

  • 部落格
  • 專案作品

社群

  • AI 自動化作業
  • Claude 技能

工具

  • 手機應用程式開發費用計算器
  • OpenAI / LLM API 費率計算器
  • MVP 開發費用計算器
  • 語音 AI 助理費用計算器

關於 TECHSY

  • 瀏覽
  • 合作夥伴
  • 聯絡我們
法律聲明私隱政策服務條款Cookies說明
TECHSY
© 2026 Techsy.保留所有權利。