Kimi K3.1 Pro 价格：Token、推理与缓存成本

Kimi K3.1 Pro 将普通输入、输出、缓存读取和缓存写入分别计费。 Moonshot 官方 Pro 费率为每百万输入 token $2、每百万输出 token $10。缓存读取每百万 token $0.20；缓存写入按 5 分钟档收取 $2，或按 1 小时档收取 $4。这些官方价格核查于 2026 年 10 月 25 日。通过 SeedRouter 发送请求时，请使用下方实时价格表。^[1]

可见回答只是输出的一部分。Kimi K3.1 Pro 始终推理，推理 token 也计入输出用量。在输入侧，缓存读取与写入属于提示词的一部分，并非额外复制的内容。这两点解释了为何仅凭最终回答长度估算费用可能出错。

Kimi K3.1 Pro 模型页汇集 Playground、当前费率和接入示例。本指南说明如何结合已完成请求的用量解读这些费率。

在这里使用 Kimi K3.1 Pro 多少钱？

SeedRouter 请求请按下方当前费率计算。这些费率从生效的计费设置中读取，并非写死在文章中。

每份估算都应标明模型 ID 和费率来源。模型官方标准价与特定服务上的请求价格不一定相同。仅凭相似模型名称，也不足以证明某个费率适用。本文讨论的公开模型为 kimi-k3.1-pro。

不应将小提示词按占满整个上下文窗口计费。Kimi K3.1 Pro 支持 1,048,576 个上下文 token；计算采用的是实际输入用量。上下文容量表示一次请求可容纳多少材料，并不代表固定购买一百万 token。^[2]

应该计算哪些 token？

Kimi K3.1 Pro 的三种原生格式使用不同的用量字段名。对于 Chat Completions，可从以下划分开始：

未缓存的剩余部分等于总输入减去缓存读取和写入。这些类别互不重叠。如果先将完整提示词按普通输入费率计费，再加缓存费用，就会重复计算相同的 token。^[3]

费率单位为每百万 token 时：

uncached input = total input - cache reads - cache writes

cost = (
  uncached input × input rate
  + cache reads × cache-read rate
  + 5-minute writes × 5-minute write rate
  + 1-hour writes × 1-hour write rate
  + output × output rate
) / 1,000,000

例如，一次用于说明计算的请求有 5,000 个输入 token，其中 1,000 个为缓存读取、500 个为缓存写入，因此普通输入为 3,500 个 token。如果还使用了 2,000 个输出 token，就将这五类相关用量分别乘以当前费率。这是计算示例，并非宣称的基准测试或实测响应。

为什么 Kimi K3.1 Pro 回答很短，费用却可能超出预期？

Kimi K3.1 Pro 的输出预算同时覆盖推理和可见回答。模型可能先消耗 token 分析问题，再给出简短结论。只统计界面上展示的文字，会漏掉这些推理用量。

根据任务选择 low、high 或 max 推理强度，默认 max。对于简单查询或范围明确的转换，可评估 low 强度是否通过检查。对于复杂调试，更大的推理预算可能有帮助。请按验收标准衡量结果，不要假设回答越短或越长就越好。^[2]

token 上限过小也可能导致模型尚未生成有用回答就停止。请检查结束原因或响应终止状态，再判断被截断的结果是否完整。即使用量面板逐条展示请求，重复尝试也应计入整个工作负载的成本。

请求一小时缓存，就证明实际使用了吗？

不能。Kimi K3.1 Pro 可以保留缓存前缀的原始有效期。命中会刷新该有效期，在已有条目过期前，新追加的材料也可能沿用同一个已锁定 TTL。更改请求的 TTL 不能可靠证明当前写入采用了不同费率。^[4]

如需让重复上下文保持可缓存条件，请使用稳定的缓存键和对话前缀，再检查实际用量。不要假设文本相同就一定命中，也不要仅凭发送的设置为写入定价。

不同原生格式提供的证据不同。Chat 官方用量响应头区分 5 分钟和 1 小时写入。Responses 可返回实际采用的缓存选项。Messages 在 usage.cache_creation 下提供独立计数。如果收集的记录缺少这些证据，应将本地估算标为不完整，而不是编造 TTL。

Responses 和 Messages 如何影响计算？

Responses 的 usage.input_tokens 是输入总数，input_tokens_details 包含缓存类别。输出为 usage.output_tokens。计量原则与 Chat 相同：先扣除缓存部分，再对普通输入应用费率。^[5]

Messages 的输入口径不同。其 usage.input_tokens 不包含缓存读取与写入。恢复总上下文时，应加上 cache_read_input_tokens 和 cache_creation_input_tokens。计算费用时，对未缓存的输入数直接应用普通费率，再单独计算各缓存类别。不要从已经排除缓存的数值中再次减去缓存类别。^[6]

比较 SDK 或在不同格式间迁移接入时，这一区别很重要。应用日志中同名的“input”可能代表不同数量。请将原生格式与原始 usage 对象一同记录，再统一转换为报表口径。

如何进行首次费用核对

从一个可核验结果的 Kimi K3.1 Pro 任务开始。明确设置输出上限，记录推理强度，并保留完整的返回用量。工具工作流还需包含返回工具结果的后续请求；首次调用并非整个任务。

将计算出的 token 费用与请求用量记录比较。保持费率单位一致，区分总上下文和未缓存输入，并记录缺失的缓存有效期证据。这个小案例核对一致后，再将方法应用于自己具有代表性的任务集。

请求字段和媒体约束请查阅 Kimi K3.1 Pro API 文档，也可返回 Playground检查原生响应。SeedRouter 上失败的请求不收费。

常见问题

会按整个输出上限收费吗？

输出限制只是上限。token 费用按已完成请求报告的输出计算，其中包括推理。上限为 2,000 token 不代表每个回答都消耗 2,000 token。请将 usage 对象与回答一同保留，以便核对实际数量。

缓存命中免费吗？

不免费。缓存读取有独立费率。一次请求也可能同时包含缓存前缀、未缓存的新输入和输出，各自单独收费。请使用上方实时缓存读取费率与返回的缓存 token 数；不要因为部分内容复用，就将整个提示词视为已缓存。

可以沿用 Kimi K3 的费用估算吗？

请针对 kimi-k3.1-pro 重新计算。模型名称相关，不代表价格或用量字段相同。应将模型 ID、原生请求格式和适用费率与 token 数一同记录，尤其是在比较旧接入和新接入时。

参考资料

1. Moonshot：模型价格，核查于 2026 年 10 月 25 日。
2. Moonshot：Kimi K3.1 Pro 快速开始。
3. Moonshot：Chat Completions。
4. Moonshot：上下文缓存。
5. Moonshot：Responses。
6. Moonshot：Messages。