Kimi K3 API 实测定价：关闭“始终开启”的推理
目录
Kimi K3 的文档称思考无法关闭，reasoning_effort 也只接受 "max"。但实测发现，API 同样接受 "none"，而且确实有效：同一道简单问题，使用默认推理时花费 $0.00179，关闭后只需 $0.000285，相差 6.3 倍。K3 于 2026-07-16 发布，输入和输出每百万 token 分别为 $3 和 $15。这是中国实验室推出过的最高标价，与 Claude Sonnet 5 相同。按这一输出价格计算，模型默认消耗的推理 token 才是账单的大头，因此有必要弄清这个未写入文档的关闭方式。
TL;DR
- 使用默认设置时，Kimi K3 的推理 token 占输出 token 的 69-93%；生成一段 120 词的文本会按 2,289 个输出 token 计费，共 $0.0346。
- 尽管文档另有说明，API 仍接受
reasoning_effort: "none"。简单查询的成本可降低 6.3 倍，但多步算术题的正确率会从 3/3 降至 0/6。 - Kimi K3 的 prompt cache 从约 256 个共享前缀 token 开始命中，以 256 个 token 为单位计数，缓存读取价格为 $0.30/M。
- 中文是 K3 成本最低的 CJK 语言：每 100 个字符净计 52 个 token，低于 GLM-5.2 和 DeepSeek 的 58 个。
以下数据均于 2026-07-20 在 kimi-k3 上测得。该模型已接入 Synthorai 网关，并按 Moonshot 标价计费。重复 prompt 均加入了随机内容，以避免命中响应缓存；行为相关结论也通过另一条独立请求路径交叉验证。每项数据都有原始 usage 记录支撑。
Kimi K3 默认每次回答要花多少钱？
我们测试了多种任务，包括完全不需要推理的任务，账单大头始终是推理。默认设置下，每次回答的成本如下：
| 任务 | 输出 token | 推理占比 | 每次回答成本 |
|---|---|---|---|
| 简单算术（17×23） | 99 | 84% | $0.0018 |
| 单句事实问答 | 80 | 79% | $0.0015 |
| 小型代码函数 | 119 | 69% | $0.0009 |
| 多步应用题 | 139 | 87% | $0.0025 |
| 120 词文本 | 2,289 | 93% | $0.0346 |
图表重点在于不同模型之间的差异。GPT-5.6 会自适应推理：简单算术和事实问答不消耗思考 token，数学和写作任务则占 65-70%。Claude Sonnet 5 默认关闭思考。GLM-5.2 的相对推理占比甚至高于 K3。但 GLM 的输出价格是 $4.40/M，K3 则是 $15/M。因此，同一道 17×23 的题，在 GLM-5.2 上收费 $0.00078，GPT-5.6 为 $0.00027，Sonnet 5 为 $0.0001，K3 则是 $0.0018。输出越长，差距越大：同一段 120 词文本在 K3 上花费 $0.0346，GLM-5.2 为 $0.0186，GPT-5.6 为 $0.0072，Sonnet 5 只有 $0.0024。即使是这组任务中最普通的一项，成本也相差 15 倍。K3 的推理 token 占比与其他中国推理模型接近，但最终账单完全不是一个量级。
使用默认模式时，还有两点需要纳入预算。第一，思考模式会在每个请求中加入约 67 个 token 的隐藏前导内容。同一条单词消息，开启推理时按 86 个 prompt token 计费，关闭后只有 19 个。这就是早期测试者注意到的“隐藏 system prompt”，关闭推理后它也会消失。第二，目前 K3 的速度较慢。开启推理后，我们的简单问题从请求到结束大约需要 19-24 秒；关闭后为 3-8 秒，其中也包含发布首周的服务状况。预算时不能只看金额，还要考虑延迟。
能否关闭 Kimi K3 的推理？
可以，尽管文档称不行。官方 API 参考文档 表示，K3“始终启用思考”，且 reasoning_effort 只接受 "max"。实际调用中，endpoint 会正常接受 "none"、"low"、"medium" 和 "high"，不会报错，设置也确实生效。我们还通过一条独立请求路径确认了相同行为。在多步应用题上，这些档位有效，但区分度不高：
reasoning_effort | 推理 token（平均） | 正确率 |
|---|---|---|
none | 0 | 0/6 |
low | 78 | 3/3 |
medium | 94 | 3/3 |
high | 105 | 3/3 |
max / 默认 | 100-121 | 3/3 |
这里有两个明显结论。首先，中间档位非常接近：从 low 到 max，这项任务的 token 数量相近，正确率也完全相同。因此真正有意义的是开和关，而不是中间档位。其次，none 会带来明显的准确率断崖。要求 K3 简短回答一道多步算术题后，它连续六次全部答错，而且错误答案各不相同，并非某一种固定错误。如果不强制简短格式，模型有时会忽略简洁要求，直接在可见回答中写出计算步骤。这种情况下答案正确，但 token 只是从 reasoning 字段转移到了 text 字段，并未真正减少。
延迟变化没有 token 数量显示得那么明显。我们以不同 effort 档位对同一道题进行 streaming 测试，首字节时间在 6-24 秒之间，各档位区间高度重叠。即使是无需思考的 none，也要等待 12-13 秒。对于这种规模的任务，首 token 延迟主要受服务端处理影响。effort 档位真正改变的是首字节与首个答案 token 之间的间隔，也就是用户实际等待模型思考的时间。
实际使用时，none 确实可以降低检索、格式转换或单步任务的成本，但对任何需要中间步骤的任务都很危险。文档没有保证该参数会一直有效。应将其视为实测行为，在自己的 usage 字段中验证，并做好准备：文档更新后，它可能会被正式支持，也可能被移除。
Agent 工作负载应在什么情况下保留推理？
我们用 K3 测试了五种典型 agent 场景，分别采用默认设置和 reasoning_effort: "none"。两种配置都完整通过了同一组简单任务：
| 场景 | 思考占比（默认） | 使用 none 的成本变化 | 使用 none 的 TTFT 变化 |
|---|---|---|---|
| 工具调用循环 | 8% | −10% | −35% |
| RAG 问答 | 71% | −37% | −53% |
| 结构化工具调用 | 29% | −16% | −31% |
| 批量抽取 | 80% | −15% | −11% |
| 长对话（15 轮） | 34% | −13% | −25% |
第一行最出人意料。即使使用默认设置，K3 在工具调用循环中也几乎不思考，推理占比只有 8%，因此节省空间很小。模型选择工具时更像是直接反应，而非审慎推理。节省最明显的场景，是思考占比高但任务本身机械化的 RAG 查询和批量抽取，而这恰恰是不应固定征收推理成本的地方。对于真正需要多步规划的 agent，上一节提到的准确率断崖仍然存在，应保留推理并接受相应的 token 成本。
尽管单次调用波动很大，规模化运行后的延迟差异仍然明显。在这些场景中，默认设置的首 token 到达时间为 10-19 秒，使用 none 后为 8-13 秒。对于有实质内容的输出，生成速度中位数为每秒 35 个 token。这些数据包含发布首周的服务表现。目前来看，K3 更适合异步和批处理任务，不太适合对话式场景。
将推理内容传回后，会再次按输入计费吗？
会，传回多少 token，就重新计费多少 token。Kimi 的文档要求在消息历史中原样保留每个 assistant 轮次的 reasoning_content。我们实测了它的成本：第二轮请求带上第一轮的思维链时，按 599 个 prompt token 计费；不带时，同一请求为 198 个。两者相差 401 个 token，与第一轮的 402 个推理 token 几乎完全一致。因此，保留的思考内容会在后续每次请求中按 $3/M 的完整输入价格重新计费。对话越长，每一轮就会重复支付此前积累的全部推理内容。
但删除它不一定更便宜。没有上一轮思维链时，K3 会从头重新推理后续问题，第二轮的推理 token 增加了 31%，从 343 上升至 449。输入价格为 $3/M，输出价格为 $15/M。按这个价格比例计算，在我们的测试中，保留 CoT 的总成本反而更低。这说明文档的建议不仅有利于质量，在成本上也成立。真正有效的优化手段是下一节介绍的 prompt cache。保留的历史记录属于稳定前缀，而稳定前缀无需一直按全价计费。
Kimi K3 是否缓存 prompt？最低需要多少 token？
K3 会自动使用 prompt cache，门槛也很低：共享前缀达到约 256 个 token 后开始命中，并以 256 个 token 为单位递增。一个 303-token 的 prompt 会缓存 256 个 token；一个 153-token 的 prompt 多次重复请求后始终没有缓存。缓存输入按 $0.30/M 计费，相比 $3/M 的新输入固定优惠 90%。我们发送的所有调用都没有额外的缓存写入费用。首次命中前需要用完全相同的内容预热两到五次，因此单次重试无法证明缓存是否生效，应连续测量多次。
相比之下，这一门槛只有 OpenAI 文档所列 1,024-token 最低门槛的四分之一；其分块大小则比我们在其他模型上测得的 64-token 粒度更粗。缓存生命周期采用 best-effort 机制，不是固定 TTL。测试中，缓存条目在闲置 4 分钟和 15 分钟后仍然命中，但有一次闲置 8 分钟后未命中。因此，应将过期理解为由负载决定的淘汰机制，并在每次调用中检查缓存 token 的拆分数据。价格方面还有一点：价目表没有长上下文分级，1M-token context window 始终采用统一价格。上下文用满时，每次调用的新输入成本为 $3.00；前缀预热后则是 $0.30。对于大上下文工作负载，成本能否成立主要取决于缓存，而不是标价。如果流量会复用哪怕只有几百个 token 的 system prompt，K3 的缓存就已经开始生效，而大多数供应商此时还没达到最低门槛。具体机制和如何通过 usage 验证命中，可参考我们的 prompt 缓存指南 和 缓存最低门槛实测。
Kimi K3 的中文成本真的更高吗？
不会。相较其他模型，K3 的 tokenizer 对中文效率最高，这也回答了发布首周讨论中反复出现的问题。以下数据来自语义对齐的文本，已扣除请求封装开销，单位为每 100 个字符的净 token 数：
| 模型 | en | zh | ja | ko | hi | Python |
|---|---|---|---|---|---|---|
| kimi-k3 | 19.7 | 51.9 | 87.5 | 83.2 | 62.8 | 26.5 |
| glm-5.2 | 19.7 | 58.4 | 75.7 | 76.9 | 91.3 | 25.6 |
| deepseek-v4-flash | 19.7 | 58.4 | 70.6 | 69.2 | 60.7 | 26.7 |
| claude-sonnet-5 | 32.3 | 114.3 | 94.1 | 106.3 | 70.9 | 41.1 |
K3 的中文每 100 个字符计 52 个 token，比 GLM-5.2 和 DeepSeek 低 11%，还不到 Sonnet 5 的一半。它的弱项是日文，token 数比其他 open-weight 模型高 16-24%。我们还确认了整个系列使用相同的 tokenizer：K3、K2.7-code 和 K2.5 在全部 23 个对齐样本上得到的 token 数完全一致，因此按 K2 制定的各语言预算可以直接沿用。关于 tokenizer 密度与单 token 价格如何共同影响九种语言的成本，可参阅我们的 各语言最便宜 LLM 研究。
常见问题
Kimi K3 的开放权重何时发布？
Moonshot 承诺在 2026 年 7 月 27 日前，以 Modified MIT 许可证发布完整权重。截至本文发布时，K3 仍仅提供 API。“史上最大的开放权重模型”目前是一项承诺，还不是可用的下载链接。关于该权重将加入的开放权重生态，以及其中不同模型的缓存行为，可参阅 开放权重 LLM 的 prompt 缓存。
与 K2 系列相比，Kimi K3 到底有哪些变化？
从实测账单来看有三点：价格上涨，K3 为 $3/$15，K2.7-code 为 $0.95/$4，涨幅达到 3.2-3.75 倍；K3 始终开启思考，K2.5 完全不推理，K2.7-code 则提供开关；除此之外没有变化。K3、K2.7-code 和 K2.5 在全部 23 个对齐样本上的 tokenizer 结果逐字节一致，因此 K2 时代的 token 预算仍可沿用。规格方面，Moonshot 称 K3 使用新的 2.8T 参数 MoE 架构，包含 896 个 expert，每个 token 激活 16 个，并采用 Kimi Delta Attention；context window 从 K2.7-code 的 256K 扩展至 1M token，同时原生支持图像输入。我们实测了计费相关结论，并未验证架构声明。
Kimi K3 是否支持结构化输出？
支持。测试中，带有 json_schema 的 response_format 返回了有效且符合 schema 的对象。但底层仍会执行推理：该次抽取调用共产生 97 个输出 token，其中 66 个是推理 token。因此，受 schema 约束的调用与其他调用一样要支付思考成本，除非同时设置 reasoning_effort: "none"。
关闭推理后，可见内容会变化吗？
会。使用默认设置时，K3 会在 reasoning_content 中返回完整思维链，文档也建议在多轮历史中原样传回。设置 reasoning_effort: "none" 后，该字段会完全消失，约 67 个 token 的思考前导内容也不再计入 prompt 账单。
数据于 2026-07-20 在 kimi-k3 上测得，采用发布首周标价（输入 $3/M、缓存输入 $0.30/M、输出 $15/M）。重复 prompt 均加入了随机内容，避免命中响应级缓存；正确率统计采用答案唯一且可验证的任务；行为相关结论通过另一条独立请求路径复现。随着版本逐渐稳定，价格和行为可能发生变化。依赖本文任何数据前，请先根据自己的 usage 记录验证。