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