Kimi K3 提示词缓存

自动触发：首次全价，重复才有折扣

缓存没有开关，也不需要任何参数：只要这次请求的开头（前缀）和之前某次请求完全一致，就会自动命中。有没有命中、命中了多少，看响应里的 usage.prompt_tokens_details.cached_tokens 字段就知道。

我们生成了一批从未发送给月之暗面的全新随机前缀，确保第一次调用之前不可能存在任何缓存——下文把这种第一次调用称作「冷调用」，重复发送称作「热调用」——然后把每个前缀原样发送两次：

// 第一次调用，全新的 12,504 token 前缀
"usage": {
  "prompt_tokens": 12504,
  "completion_tokens": 32
  // 完全没有 cached_tokens 字段
}

// 第二次调用，前缀逐字节相同，约 2 秒后
"usage": {
  "prompt_tokens": 12504,
  "completion_tokens": 32,
  "prompt_tokens_details": {"cached_tokens": 12288}   // 96 个 256 token 的块
}

从 1.3k 到 29k token，我们测过的每一个前缀，冷调用的缓存命中都是 0。第一次发送没有任何折扣，折扣从第二个请求起才存在——也就是说，前缀从不重复的业务永远享受不到，提示词再大也没用。

块大小是 256 token

缓存命中不是按单个 token 计算的。九组测试里，cached_tokens 每一次都是 256 的整数倍，凑不满一块的尾部（最多 255 token）不缓存：

未缓存的尾部永远凑不满一块

每个热前缀未缓存的 token 数 · 九组前缀，1.3k–29k · 实测于 2026-07-16

实际结论就是：缓存的收益与前缀大小成正比。一个 300 token 的前缀最多只有一个可缓存的块，外加最多 255 token 缓存不了的尾部——你提示词的大半都在按全价走。一个 50k 的前缀有将近 200 个块，尾部只是零头。小提示词就别为缓存命中做工程优化了。

prompt_cache_key：我们测不出任何效果

月之暗面的 API 文档里列了一个 prompt_cache_key 参数，描述是用于会话级缓存，多轮对话「推荐」使用。照这个描述，你会以为缓存要靠它才能开启。实测并非如此——至少对前缀复用来说不是。

我们做了一组干净的对照测试：全新前缀，第一次调用就显式带上 prompt_cache_key，然后再发一次完全相同的调用。结果和不带 key 的情况分不出任何差别：

冷调用同样未命中，热调用同样命中。该做的，自动前缀缓存已经全做了。重复前缀的业务不需要这个参数——如果你加了它并指望换来折扣，那折扣也不是它给的。

省钱但不省时间

这一条出乎我们意料。直觉上，缓存命中省掉了计算，理应更快。但对同一前缀比较冷、热两次调用，总耗时并没有稳定变快：

在这些规模下，批次间的随机波动完全淹没了缓存效应——别忘了 K3 每次调用都要花几秒推理，这才是耗时的大头。把提示词缓存当成计费优化，而不是延迟优化。要提速，看我们的延迟实测。

缓存能保持多久

一个预热的前缀在 210 秒后仍返回同样的 12,032 个缓存 token，在 30 秒、90 秒、210 秒三次探测中没有任何衰减。

这是下限，不是 TTL——我们探测到这里就停了。月之暗面没有公布 TTL、没有公布最小前缀长度，也没说缓存写入是否额外收费，我们不会替它编数字。能确定的是：几分钟内复用的前缀仍会命中缓存，这已经覆盖了最要紧的 agent 循环场景。

怎样稳定拿到缓存价

• 把稳定的字节放最前面。系统提示词、工具定义、长文档排在前头；每轮变化的用户输入放最后。缓存匹配的是前缀——靠前的一处改动会让它后面的全部失效。
• 别让会变的内容混进前缀。一个时间戳、一个请求 ID、一段键序被重排的重新序列化 JSON——任何一个都会改变字节，让你悄无声息地掉回 $3.00 / 百万 token。这是团队丢了折扣却毫无察觉的最常见方式。
• 同一个前缀的请求集中发。针对同一份文档的二十个问题，应该是一个热前缀加二十条短尾巴。
• 小提示词别做缓存工程。低于约 256 token 时没东西可缓存；低于约 1k 时，尾部就是账单的大头。
• 接受冷调用。每个冷周期的第一个请求都要付全价。把它算进预算，而不是想方设法绕开它。
• 在生产环境盯住 cached_tokens。这是确认命中率符合预期的唯一办法。字段没出现，就是没命中。

这个价差值多少钱

一个带 50,000 token 固定前缀的 agent，每天处理 200 个请求——日均 1,000 万输入 token：

按 2026-07-16 官方费率的算术推演，只算输入。便宜的那一行是理想化的——冷调用照付全价，尾部永远不缓存。输出无论如何都按 $15.00/1M 计费，而在这种负载下，推理 token 的开销可能超过你的全部输入账单。这是上下限，不是报价。