為什麼這輪 Prompt Caching 值得關注
2024 年下半年，OpenAI、Anthropic 和 Google 相繼推出服務端 Prompt Caching，將不再是一個“自己用 Redis 搞個 KV 快取”的 DIY 玩法，而是變成了 API 原生的低成本特性。 核心變化在於：緩存命中不再需要你手動管理過期和哈希，而是在 API 層自動完成，按緩存命中量單獨計費（通常為完整 prompt 價格的 20%-50%）。 對於高頻調用同一段 system prompt 的 Agent loop 或 RAG 管道來說，延遲可以從 2-3 秒降到 200-400 毫秒，成本直接腰斬。
但這股熱潮里最容易被忽略的一點是：緩存不是“免費午餐”。 API 提供方對「哪些內容能緩存、緩存多久、何時失效」有嚴格約束。 不瞭解這些邊界，輕則緩存失效導致零加速，重則產生非預期的上下文洩漏。
它在真實工程流程里到底解決什麼問題
想像一個典型的 Agent 工作流：
- 使用者發消息“幫我查下上海明天的天氣”。
- Agent 呼叫函數（get_weather）並附上當前系統 prompt（內含角色定義、工具清單、輸出格式約束）。
- LLM 傳回 JSON 指令。
- Agent 解釋該 JSON，調用天氣 API。
- 將結果拼接成最終回復。
在這一過程中，第 2 步和第 3 步之間如果 system prompt 長達 2k token，每次迴圈都重新處理就是巨大的浪費。 **Prompt Caching 解決的核心問題是：對重複出現的 prompt 前綴（通常是 system prompt + 固定 few-shot）只計算一次 KV 快取，後續相同前綴的推理直接複用。 ** 在 Agent loop、多輪對話、A/B 測試中這類場景非常常見。
具體場景：客服機器人的緩存策略
一個常見客服機器人 system prompt 可能包含：
- 公司知識庫索引（1k tokens）
- 對話風格指令（0.5k tokens）
- 安全過濾規則（0.5k tokens）
假設每個用戶提問前系統都要拼接這 2k tokens，日請求 10 萬次，KV 緩存命中率可達 90% 以上。 按 price cache hit 計算，每日成本可從 $20 降到 $4（OpenAI 定價為例）。
最容易失敗的地方與錯誤理解
失敗點 1：系統提示或上下文前綴頻繁變動
如果 system prompt 裡帶了自定義變數（比如當前使用者所在國家）、時間戳、隨機授權碼等每次不同的內容，那麼 prompt 前綴就被污染了。 例如：
You are a helpful assistant. Today is 2025-04-07.
每次日期不同，缓存永远无法命中。解决方案是把易变字段放到前缀之后（比如用户消息里），并严格确保前 80% 的 token 保持稳定。
失败点 2：多用户共用一个 API Key 时的上下文泄漏
Prompt Caching 是按公共前缀匹配的，不是按会话隔离的。如果两个用户的对话 history 前几句相同（比如都是“你好”），则可能复用对方的缓存。第三方库 ]anthropic-python[ 的早期版本就曾因为自动拼接 assistant 前缀而意外触发跨会话缓存。解决方案是在每个用户请求中加入唯一标识 ]session_id[ 作为前缀的一部分（但不需要缓存它），例如在 prompt 最开头添加<session id="abc">，然后利用 API 提供的“前缀跳过”参数（如 Anthropic 的 `]prompt_caching' 配置）來避免緩存這些元數據。
錯誤理解：緩存一定省成本
實際上，如果緩存命中率低於 30%，成本反而高於無緩存——因為緩存命中的單次 token 價格雖然低，但緩存寫入本身通常不計費，但會佔用服務端資源，一些 API 會按緩存的 token 數量收取額外儲存費（如 Google Gemini 的 $0.10 / 1M tokens stored）。 對於對話長度極短（<100 tokens）或沒有固定前綴的應用，Prompt Caching 帶來的收益幾乎為零。
如果你現在就要落地，第一步應該怎麼做
- 審計你的 prompt：找出所有高頻調用的 API 調用，記錄它們的公共前綴長度和變化頻率。 優先對前綴穩定超過80%的端點啟用緩存。
- 檢查 API 文檔：OpenAI 要求 prompt 完全匹配且長度>=1024 tokens; Anthropic 只緩存前 1024 tokens; Google 支援任意前綴但按存儲量計費。 不同供應商的緩存策略差異巨大。
- 從單端點灰度：選一個非關鍵路徑（如後台分析報表生成），先啟用緩存並添加監控指標：緩存命中率、p50/p95 延遲、成本前後對比。
- 設置 fallback 開關：一旦命中率低於 20%，或出現非預期的上下文混淆（比如回復中出現了其他用戶的數據），立即降級為無緩存模式。
下面是遷移檢查清單（圖片見文內）：
- 確定可緩存的穩定前綴（長度 >= 1024 tokens）
- 修改 API 調用頭，添加 cache 啟用參數（如
"anthropic-beta": "prompt-caching-2025-03-17"） - 將易變字段移到前綴之後，或使用 skip 標記
- 在生產中運行 A/B 測試（50% 流量啟用快取）
- 監控快取命中率、錯誤率和用戶反饋
失敗時的回退方案
如果 Prompt Caching 始終無法獲得有意義的命中（比如平臺不支援、前綴太短、變動太頻繁），可以回退到：
- 本地 KV 快取：用 Redis 或 in-memory cache 快取 LLM 輸出（注意：只適用於完全相同的 prompt 和溫度，不同溫度輸出不同）。
- 語義緩存：對 prompt 進行 embedding，在 Redis 中搜索相似度 >0.95 的歷史請求，複用輸出（但需要做 hash 驗證，避免邏輯偏差）。
- 請求合併：同一 prompt 短時間內的重複請求可直接從記憶體返回結果（適合輪詢場景）。
這些方案需要你自行處理過期、衝突和隔離，不如 API 原生緩存省心，但勝在完全可控。
下一步：從工具使用者到系統設計者
如果你已經在考慮緩存命中率、跨會話洩漏、成本模型這些工程細節，說明你已經不滿足於“調 API”的層面。 真正的系統效率提升來自於對 Provider 特性的深度理解和組合設計——比如將 Prompt Caching 與 Agent 的迴圈控制流結合，或者在 MCP 工具調用中利用上下文復用。 這些系統化的知識無法在零散的文章碎片中閉環，需要成體系的課程和工程案例來補齊。
暫無評論，快來發表你的看法吧