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 價為 1× 計:
回本點:第 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 取整
cached_tokens 通常略小於你的穩定字首總長,是正常現象。
只能追加:改歷史即失效
同一段字首貼著連發,只改動其中一次:
實踐含義:穩定的東西放前面,易變的東西放後面。
最小可執行示例
同一段長字首發兩次不同問題,第一次自動寫入,第二次命中:cached 接近系統提示詞長度(按 128 取整),這部分按 0.25× 計費。
/v1/responses 端點同樣自動生效,欄位換成 usage.input_tokens_details.cached_tokens,機制完全一致。長對話在這個端點上還有額外優勢,見下文「長對話優先走 responses 鏈式」。怎麼判斷命中 —— 看 usage 欄位
判讀口徑:小值不算命中
不要只看「大於 0」。拿cached_tokens 和你的穩定字首長度做比:
實測冷啟動的首次呼叫也可能回顯一個一兩百的小值,別被它騙到 —— 那不代表你的字首被快取了。
對賬:控制台的快取計費詳情
後臺單條呼叫日誌裡會單列快取讀取的 token 數與對應的折扣倍率,可以直接和響應裡的cached_tokens 對上。需要精確核算某一次呼叫到底怎麼計費時,以那裡為準。
自檢三步:
- 構造一個千 token 以上的穩定字首,連續發 2 次請求
- 第 2 次響應應看到
cached_tokens明顯上千 - 後臺 呼叫日誌 裡對應請求出現「快取讀取」計費項,輸入費用明顯低於第 1 次
提高命中率
穩定字首工程化
- 長指令、few-shot 示例、工具定義放最前面;使用者輸入、時間戳放最後
- 工具定義的順序與 JSON 序列化方式保持固定(別讓序列化庫隨機排序欄位)
- 圖片輸入也參與字首比對,複用圖片時保持 base64 / URL 與引數一致
- 同一字首集中連續複用,不要拉開間隔
長對話優先走 responses 鏈式
這是 Grok 上一個容易被忽略的差別:
所以長對話、Agent 多步驟這類場景,優先用 Responses API 的鏈式接法:
關於 x-grok-conv-id
xAI 官方最佳實踐建議每次請求帶上 x-grok-conv-id 請求頭(UUID 或會話 ID)以提高命中率。我們在 API易 上做了對稱 A/B(帶與不帶各若干組獨立字首、各若干次複用),兩組的命中表現沒有可觀測的差異。帶上它無害,但不要把命中率的指望押在這個請求頭上。
命中率與預期管理
還有一點值得提前說清楚:快取的價值在成本,不在速度。實測命中與未命中的首字延遲差距只有百毫秒量級 —— 別指望靠快取把長上下文請求變快。最常見的踩坑
與其它通道的差異速查
全平臺快取支援總覽見 快取計費 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. 別押命中率
官方不保證命中,成本測算按無快取價打底,命中當作額外優惠。
相關連結
- 同組頁面:Grok 概覽 · 對話與推理 · 聯網搜尋與 X 搜尋 · 程式碼執行與 MCP
- 其它通道快取:OpenAI 快取計費 · Gemini 快取計費 · Claude 快取計費
- 全平臺總覽:快取計費 FAQ
- 獲取 / 管理令牌:
https://api.apiyi.com/token - xAI 官方文件:
docs.x.ai/developers/advanced-api-usage/prompt-caching