Kimi K3 API 价格实测：关掉「常驻」推理
目录
Kimi K3 的文档说思考无法关闭，reasoning_effort 只接受 "max"。但我们实测发现，API 照样接受 "none"，而且真的生效：同一个简单问题，默认推理下要花 $0.00179，关掉后只要 $0.000285，相差 6.3 倍。K3 于 2026-07-16 发布，输入每百万 token 收费 $3，输出每百万 token 收费 $15，是国产实验室开出的最贵标价，和 Claude Sonnet 5 的价签一样。在这个输出价位下，模型默认花掉的推理 token 就是账单本身，所以这个没写进文档的开关值得精确摸清楚。
TL;DR
- 默认设置下，Kimi K3 有 69%-93% 的输出 token 花在推理上；一段 120 词的段落计费 2,289 个输出 token，$0.0346。
- 尽管文档说不行，
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 实测，该模型已按 Moonshot 的标价上线 Synthorai 网关。为了绕过响应缓存，重复的 prompt 都做了加盐处理，行为层面的结论也在第二条独立的请求路径上做了交叉验证。每个数字背后都有原始用量记录支撑。
Kimi K3 默认设置下每次回答的成本是多少？
在我们测试的所有任务形态里，账单都被 reasoning 主导，连那些根本不需要推理的任务也不例外。按默认设置，每次回答的开销如下：
| 任务 | 输出 token | reasoning 占比 | 每次回答成本 |
|---|---|---|---|
| 简单算术（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 会自适应推理（简单题和事实题上 thinking token 为零，数学和写作上为 65-70%），Claude Sonnet 5 默认关闭 thinking，而 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 倍。税率跟其他中国推理模型差不多，税单可不是。
还有两个默认模式下值得纳入预算的事实。第一，thinking 模式会给每个请求塞进约 67 token 的隐藏前缀：同样一条一个词的消息，开启 reasoning 时计费 86 个 prompt token，关闭时只有 19 个。这就是早期测试者注意到的“隐藏 system prompt”，关掉 reasoning 它就消失了。第二，K3 目前很慢：我们的简单问答请求，开启 reasoning 时端到端大约要 19-24 秒，关闭时 3-8 秒，这已经算上了发布首周的服务负载。别只算钱，也要把延迟算进预算。
能关掉 Kimi K3 的推理吗？
能——文档说不能，但实际能关。官方API 文档写着 K3“始终开启思考”，且 reasoning_effort 只接受 "max"。但实测中，接口接受了 "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 数暗示的那么大。用 streaming 跑同一道题、覆盖所有 effort 档位，首字节时间在 6-24 秒之间，各档位的区间重叠严重；即便是 none，明明没什么可想的，也等了 12-13 秒，说明在这个任务规模下，首 token 时间主要取决于服务本身。这个开关真正改变的，是首字节到第一个答案 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。这些数字（含发布首周的服务表现）比起如今任何对话式场景，更适合异步和批处理形态。
回传的推理内容会被当成输入重新计费吗？
会，一个 token 都不少。Kimi 的文档要求你把每一轮 assistant 消息里的 reasoning_content 原样保留在消息历史中。我们实测了这样做的代价：带上第一轮思维链发送的第二轮请求，prompt token 计费为 599；去掉后完全相同的请求只计费 198。两者相差 401 个 token，几乎正好等于第一轮的 402 个 reasoning token。也就是说，保留下来的思考内容会以完整的 $3/M 输入价格重新进入后续每一次请求，一段长对话每一轮都在为累积的推理内容反复付费。
不过丢掉它也不一定就更便宜。没有了前一轮的思维链，K3 会把追问从头重新推理一遍：第二轮的 reasoning 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 个；153 token 的 prompt 反复尝试都从未命中）。缓存输入按 $0.30/M 计费，相对 $3/M 的全新价格是固定的 90% 折扣，我们发起的任何调用都没有 cache-write 溢价。预热需要两到五次相同调用才会出现首次命中，所以单次重试说明不了任何问题，要多次测量。
作为参照，这个门槛只有 OpenAI 文档里 1,024 token 最低值的四分之一，块大小也比我们在别处测到的 64 token 粒度更粗。生命周期是尽力而为，而非固定的 TTL：我们探测中的缓存条目挺过了 4 分钟和 15 分钟的空闲间隔，却有一次 8 分钟的间隔没命中。所以把过期当成随负载变化的驱逐来看待，每次调用都要核对缓存拆分。还有一个值得算一算的价格事实：1M token 的上下文窗口是统一定价的，价目表上没有长上下文的分档。一个用满的窗口每次调用是 $3.00 的全新输入，前缀预热后是 $0.30。所以大上下文的工作负载生死取决于缓存，而不是标价。如果你的流量复用一个哪怕只有几百 token 的 system prompt，K3 的缓存就会开始生效，而大多数提供商此时还没起步。缓存机制以及如何从 usage 验证命中，可以看我们的 prompt caching 指南 和缓存最低门槛实测研究。
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 的一半。它的短板是日文，比其他开源权重模型贵 16-24%。我们还确认了整个系列的 tokenizer 没变：K3、K2.7-code 和 K2.5 在全部 23 个对齐样本上给出的 token 数完全一致，所以为 K2 建立的各语言预算可以直接沿用。tokenizer 密度如何与九种语言的单 token 价格叠加，可以看我们的 各语言最便宜 LLM 研究。
FAQ
Kimi K3 的开源权重什么时候发布？
Moonshot 承诺在 2026 年 7 月 27 日前以 Modified MIT 许可证发布完整权重；截至本文发布时，K3 仍仅提供 API。所谓”史上最大开放权重模型”的说法只是一项承诺，目前还不是可供下载的链接。这些权重即将加入的开放权重生态系统中，缓存的行为方式已在面向开放权重 LLM 的提示缓存中作了梳理。
和 K2 系列相比，K3 到底有什么新东西？
在账单上，我们实测到三点：价格（K3 是 $3/$15，K2.7-code 是 $0.95/$4，涨了 3.2-3.75 倍）、始终开启的思考（K2.5 完全不推理，K2.7-code 带一个开关），以及别无其他——在我们全部 23 个对齐样本上，K3、K2.7-code 和 K2.5 的 tokenizer 逐字节相同，所以 K2 时代的 token 预算可以直接沿用。在规格表上，据 Moonshot 所说：全新的 2.8T 参数 MoE（896 个专家，每 token 激活 16 个），采用 Kimi Delta Attention，1M token 上下文窗口（K2.7-code 是 256K），并原生支持图像输入。我们实测的是计费方面的说法，不是架构方面的。
Kimi K3 支持结构化输出吗？
支持。我们的测试中，带 json_schema 的 response_format 返回了一个合法且符合 schema 的对象。注意底层仍然在推理：那次抽取调用的 97 个输出 token 里有 66 个是 reasoning，所以受 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 记录为准核对。