Skip to main content
用 Grok 跑 Agent、長系統提示詞、多輪對話時,Prompt Caching 能把命中部分的輸入賬單打到 0.25×(省 75%),而且什麼程式碼都不用改——快取是全自動的。 先把預期說在前面:xAI 官方明確快取條目可能因負載、重啟、路由變化被驅逐,不保證 100% 命中。把緩存摺扣當作「有則更好」的額外優惠,做成本測算時按無快取價格打底 本頁基於 xAI 官方文件(docs.x.ai/developers/advanced-api-usage/prompt-caching)整理,並以 2026-08-19 在 API易 閘道上對 grok-4.6 的實測為準(124 次呼叫,逐條與後臺賬單核對)。

一句話理解

只要請求的開頭部分(字首)與近期某次請求逐字相同,上游就自動跳過重複處理:命中部分按 0.25× 計費,不需要任何引數、不需要打標記。 和另外兩家的差別:
  • 對比 Claude:不用打 cache_control 標記,達到條件自動生效
  • 對比 OpenAI:同樣全自動、同樣沒有寫入費,但 Grok 沒有 prompt_cache_key 這類由你控制路由的手段

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

以模型原始輸入 token 價為 計: 回本點:第 2 次請求就淨省。 沒有寫入成本要攤,同一字首只要被複用一次,省下的就是純收益。 grok-4.6 的掛牌價換算(每 1M tokens,兩個上下文件位): 其餘 Grok 型號的分檔與快取讀取價見 Grok 概覽的階梯計費表

適合場景

  • 同一份長系統提示詞 + 工具定義被反覆呼叫(Agent、客服機器人)
  • 批次處理同一份文件(一份合同問 50 個問題)
  • RAG 把穩定的文件塊放在 prompt 前部
  • 多輪對話(注意:Grok 上 chat 與 responses 兩種接法的效果差別很大,見下文)

不適合場景

  • 每次請求從第一個字開始就不一樣
  • 整個 prompt 在千 token 量級以下——實測這種請求反覆呼叫也形不成可複用的快取

兩個端點、流式與非流式都已核對

/v1/chat/completions/v1/responses,各自的流式與非流式,四種組合我們於 2026-08-19 逐條核對過後臺賬單,命中部分均按快取價單列計費:
程式碼無需為中轉層做任何適配。 快取相關行為原樣轉發上游,cached_tokens 原樣回吐,後臺賬單把命中部分單列為「快取讀取」計費項。

觸發條件

命中量按 128 token 取整

兩輪實測都吻合:8802 token 的字首命中 8704(= 68 × 128),更早一輪 2735 token 的字首命中 2688(= 21 × 128)。所以 cached_tokens 通常略小於你的穩定字首總長,是正常現象。

只能追加:改歷史即失效

同一段字首貼著連發,只改動其中一次: 實踐含義:穩定的東西放前面,易變的東西放後面。

最小可執行示例

同一段長字首發兩次不同問題,第一次自動寫入,第二次命中:
期望看到的輸出:
第 2 次的 cached 接近系統提示詞長度(按 128 取整),這部分按 0.25× 計費。
/v1/responses 端點同樣自動生效,欄位換成 usage.input_tokens_details.cached_tokens,機制完全一致。長對話在這個端點上還有額外優勢,見下文「長對話優先走 responses 鏈式」。

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

判讀口徑:小值不算命中

不要只看「大於 0」。cached_tokens 和你的穩定字首長度做比 實測冷啟動的首次呼叫也可能回顯一個一兩百的小值,別被它騙到 —— 那不代表你的字首被快取了。

對賬:控制台的快取計費詳情

後臺單條呼叫日誌裡會單列快取讀取的 token 數與對應的折扣倍率,可以直接和響應裡的 cached_tokens 對上。需要精確核算某一次呼叫到底怎麼計費時,以那裡為準。 自檢三步:
  1. 構造一個千 token 以上的穩定字首,連續發 2 次請求
  2. 第 2 次響應應看到 cached_tokens 明顯上千
  3. 後臺 呼叫日誌 裡對應請求出現「快取讀取」計費項,輸入費用明顯低於第 1 次

提高命中率

穩定字首工程化

  • 長指令、few-shot 示例、工具定義放最前面;使用者輸入、時間戳放最後
  • 工具定義的順序與 JSON 序列化方式保持固定(別讓序列化庫隨機排序欄位)
  • 圖片輸入也參與字首比對,複用圖片時保持 base64 / URL 與引數一致
  • 同一字首集中連續複用,不要拉開間隔
方法論與 OpenAI 一致,展開解釋見 OpenAI 快取計費指南

長對話優先走 responses 鏈式

這是 Grok 上一個容易被忽略的差別: 所以長對話、Agent 多步驟這類場景,優先用 Responses API 的鏈式接法:
端點差異詳見 Grok 概覽的端點一覽

關於 x-grok-conv-id

xAI 官方最佳實踐建議每次請求帶上 x-grok-conv-id 請求頭(UUID 或會話 ID)以提高命中率。我們在 API易 上做了對稱 A/B(帶與不帶各若干組獨立字首、各若干次複用),兩組的命中表現沒有可觀測的差異。帶上它無害,但不要把命中率的指望押在這個請求頭上。

命中率與預期管理

快取命中不保證。 xAI 官方文件寫明快取條目可能因記憶體壓力、服務重啟、請求被路由到另一臺伺服器而失效。實測在穩定字首 + 連續複用的場景下多數請求能命中,但確實存在抖動,且抖動來自上游側、無法由呼叫方控制。做成本測算請一律按無快取價格打底,把命中當作額外優惠。
還有一點值得提前說清楚:快取的價值在成本,不在速度。實測命中與未命中的首字延遲差距只有百毫秒量級 —— 別指望靠快取把長上下文請求變快。

最常見的踩坑

與其它通道的差異速查

全平臺快取支援總覽見 快取計費 FAQ
本頁資料基於 grok-4.6(2026-08-19 實測)。 xAI 官方稱全部 Grok 語言模型都支援字首快取,其餘型號我們未逐一實打;塊粒度、短 prompt 行為等細節以你自己用例上的實測為準。若你發現同一字首下的賬單與上面的口徑明顯不符,請帶上響應頭裡的 request-id 聯絡客服。

要點回顧

1. 全自動

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

2. 只能追加

從 messages 開頭逐字匹配,改歷史即作廢;命中量按 128 token 臺階取整。

3. 長對話走鏈式

chat 多輪只複用最初的靜態字首;responses + previous_response_id 的命中量隨輪次增長。

4. 別押命中率

官方不保證命中,成本測算按無快取價打底,命中當作額外優惠。

相關連結