Skip to main content
用 gpt-5 系列跑 Agent、多輪對話、批次文件處理,Prompt Caching 能把命中部分的輸入賬單打到 1 折 —— 而且什麼程式碼都不用改,快取是全自動的。 本頁基於 OpenAI 官方文件整理(developers.openai.com/api/docs/guides/prompt-caching,2026年6月資料),並按 API易 的接入方式給出可直接複製的示例。

一句話理解

只要請求的開頭部分(字首)和最近一次請求完全相同且不短於 1024 tokens,伺服器就自動跳過重複處理:命中部分按 0.1× 計費,延遲最多降 80%。 和 Claude 快取最大的兩個區別:
  • 不用打標記:沒有 cache_control,達到條件自動快取
  • 沒有寫入費:Claude 寫入要付 1.25× / 2×,OpenAI 寫入免費

為什麼要用 —— 看賬單倍率

以模型原始輸入 token 價為 計: 回本點:第 2 次請求就淨省。 沒有寫入成本要攤,同一字首只要被複用一次,省下的就是純收益 —— 這比 Claude(先付 1.25× 寫入費、複用 2 次才回本)更無腦。 按 API易 在售價格換算(每 1M tokens):

適合場景

  • 同一份長系統提示詞 + 工具定義被反覆呼叫(Agent、客服機器人)
  • 多輪對話(每加一輪,前面的歷史自動命中)
  • 批次處理同一份文件(一份合同問 50 個問題)
  • RAG 把穩定的文件塊放在 prompt 前部

不適合場景

  • 每次請求從第一個字開始就不一樣
  • 整個 prompt 不足 1024 tokens(到不了起緩閾值)

觸發命中的三個硬條件

缺一不可。

1. 字首不短於 1024 tokens

短於 1024 tokens 的請求永遠不會被快取(不報錯,靜默不生效)。超過 1024 之後,命中長度按 128 token 增量延伸:實際命中量是 1024、1152、1280……這樣的臺階值,所以 cached_tokens 通常略小於你的穩定字首總長,正常現象。

2. 字首逐位元組相同

快取按字首匹配:從請求第一個字元開始逐位元組比對,遇到第一處不同就停止。任何變化 —— 時間戳、使用者名稱、JSON 欄位順序 —— 都會讓後面的內容全部按原價計費。 實踐含義:穩定的東西放前面,易變的東西放後面。

3. 在保留期內再次請求

  • 基礎保留:閒置 5–10 分鐘後逐出,最長不超過 1 小時
  • 2026年5月29日起,gpt-5.1 及之後模型(含 pro 變體)對非 ZDR 組織預設啟用 24 小時擴充套件保留prompt_cache_retention: "24h"),價格不變 —— 也就是說當天內的複用基本都能命中

最小可執行示例

同一段長字首發兩次不同問題,第一次自動寫入,第二次命中:
期望看到的輸出:
第 2 次 cached 接近系統提示詞長度(按 128 取整),這部分只按 1 折計費。
/v1/responses 端點同樣自動生效,欄位為 usage.input_tokens_details.cached_tokens。官方內部測試顯示 Responses 端點的快取利用率比 Chat Completions 還要高 40%–80%,多輪 Agent 場景建議優先走 原生呼叫

怎麼判斷命中沒命中 —— 看 usage 欄位

cached_tokens > 0 就在省錢:這部分按 0.1× 計,剩餘的 prompt_tokens - cached_tokens 按原價計。

提高命中率的進階手段

prompt_cache_key 固定路由

快取命中要求請求落到同一臺快取機器上。預設按字首雜湊路由已經夠用,但當多個使用者共享相似字首或併發較高時,顯式傳 prompt_cache_key 可以明顯提高命中率:
同一個”字首 + prompt_cache_key”組合的請求超過約 15 次/分鐘 時會溢位分流到其他機器,命中率反而下降。高併發場景應按使用者或會話拆分多個 key,不要全域性共用一個。

穩定字首工程化

  • 工具定義的順序、JSON 序列化方式保持固定(別讓序列化庫隨機排序欄位)
  • 圖片輸入也參與字首比對,複用圖片時保持 URL / base64 和 detail 引數一致
  • 要按場景啟用不同工具時,用 allowed_tools 限定子集,而不是改動 tools 列表本身 —— 前者不破壞快取字首

多輪對話天然命中

追加式的 messages 陣列天然滿足字首穩定:每一輪的歷史就是上一輪的完整字首,自動命中,無需任何處理。

最常見的踩坑

與 Claude 快取的差異速查

Claude 側的完整玩法見 Claude 快取計費指南

API易 關於快取的說明

API易 的 OpenAI 通道支援快取命中。 請求原樣轉發上游,響應裡的 cached_tokens 原樣回吐,後臺賬單將命中部分按官方 0.1× 倍率單列”快取讀取”計費項 —— 程式碼無需為中轉層做任何適配。
如何自檢:
  1. 構造一個不少於 1024 tokens 的穩定字首,連續發 2 次請求
  2. 第 2 次響應應看到 cached_tokens > 0
  3. 後臺呼叫日誌中對應請求的輸入費用明顯低於第 1 次

要點回顧

1. 全自動

不用打標記、沒有寫入費,達到條件自動快取,第 2 次複用就是純省錢。

2. 夠長度

字首不少於 1024 tokens 才會起快取,命中按 128 token 臺階計。

3. 穩字首

穩定內容在前、易變內容在後;時間戳和隨機 ID 別放開頭。

4. 看 usage

cached_tokens > 0 才說明真的命中了,這部分按 1 折計費。

相關連結