事件与背景

10 月 23 日，Moonshot AI 发布 Kimi K3.1 Pro 与 Kimi K3.1 Pro Highspeed。这不是又一个「又强了一点」的版本迭代，官方给出的坐标很明确：3T 级参数、1M token 上下文、由 Kimi K3 后训练而来（后训练算力大幅加码，在数百个下游领域做联合 RL），完整模型权重将在 11 月 4 日前放出。发布当天它在 Hacker News 首页拿到 1000 分以上、六百多条讨论，但讨论重心并不在跑分上，而在下面那节「主动削弱」上。

跑分上最硬的一条是 Terminal-Bench 4.0（在资源受限的真实终端环境里跑编码 agent，用任务级测试判分）：K3.1 Pro 得 65.7%，Claude Opus 5.5 是 66.4%，GPT-6 Astra 是 58.2%。也就是说，开放权重与最强闭源之间的差距被压到了 0.7 个百分点。3D/CAD 方向（BenchCAD，带工具）拿到 92.7%，对比 Opus 5.5 的 96.2%、GPT-6 Astra 的 95.9%——有差距，但已经是同一档。官方内部基准 Kimi Code Bench 3.0 Long-horizon 为 61.2%，上一代 K3 是 55.95%。

第三方锚点来自 Artificial Analysis：智能指数 55 分，在 215 个模型里排第 4；价格 $2 / 百万输入 token、$10 / 百万输出 token，缓存命中折扣 90%，跑完一轮智能指数平均每个任务 $2.11；输出速度 73.5 tok/s，低于中位数 82；但极其啰嗦——同一套评测吐出 1.5 亿 token，中位数是 8700 万。

来源（均已用 curl 验证返回 200）：

• Introducing Kimi K3.1 Pro — Moonshot AI 技术博客，2026-10-23
• Kimi K3.1 Pro — Artificial Analysis 独立评测页（智能指数、价格、吞吐）
• Model Configuration — Kimi Code 官方文档（模型 ID、thinking-only、迁移注意事项）
• Terminal-Bench 官方榜

为什么现在重要

1. 「开源模型落后闭源一代」这个默认假设，在这一档参数上已经失效。 0.7 分的差距落在评测噪声范围内，而这还是在 Moonshot 自己搭的 Claude-Code harness 上测的——用它自己的 harness 反而没能拉开差距，说明这不是基准挑选的问题。影响：做模型选型的团队再拿「开源差一档」当默认前提，就是在为一个已经消失的溢价付钱。

2. 真正的成本变量不是单价，而是啰嗦程度。 $2/$10 看起来比顶级闭源便宜，但 AA 测出它跑同一套任务用了 1.5 亿 token，是中位数的 1.7 倍；再叠上 73.5 tok/s 的偏低吞吐，端到端时间和账单都会偏离「按单价估算」的直觉。影响：必须按「完成一个任务的总成本 + 墙钟时间」比价，按 token 单价做的预算表会系统性低估。

3. 厂商把「能力塑形」变成了发布规格的一部分，而不只是免责声明。 官方写明：网络安全相关内容原本混在 mid-training 语料里、相关任务也混在 RL 环境里；不处理的话漏洞研究能力会显著上升。他们在两个阶段都做了识别与移除，然后用自建的 xdev-bench-hard（针对 Linux 内核、Node.js、JavaScriptCore、Exim、VirGL 等真实已披露漏洞，要求拿到任意代码执行并取回 flag，pass@3 计分）做了对照：未做风险削减的 checkpoint 解出 90.5%，最终发布版是 81.0%。同一段里还给了两条原则：不放出会「扩展绝对前沿」的开放权重；但会逐步提高开放权重里的 cyber 能力。影响：这是「梯度释放」（graded release）第一次被写成可量化的动作，而不是一句「我们重视安全」。

4. 这条声明同时暴露了它的边界：删的是数据，不是能力路径。 90.5% 那个 checkpoint 证明了——同一套流水线、不改架构，只要把数据放回去就能到 90.5%。影响：任何把「开放权重版只有 81%」当作攻击面上限的威胁模型，都是错的；真正的门槛是算力和数据获取，不是模型文件。

5. 独立第三方评测正在变成唯一可横比的坐标系。 官方博客里 K3.1 Pro 的成绩横跨自建 benchmark（Kimi Code Bench、Kimi Hallu Bench、xdev-bench-hard）、他人系统卡（Opus 5.5、GPT-6 Astra）、以及官方榜单，不同模型的 harness 也不统一（Claude Code / Kimi Code / Codex 混用）。影响：内部基准适合看趋势，跨厂商比较只应引用第三方复现的数字，AA 的 55 分是目前唯一能放进同一张表的锚点。

工程师/产品人今天能做什么

1. 别信跑分，自己跑 20 个任务。 从你仓库里挑 20–50 个真实 issue（有测试、可自动判分的那种），对 K3.1 Pro、Opus 5.5、GLM-5.3 各跑一遍，记录 通过率 / 总 token / 墙钟时间三项。Terminal-Bench 的题型就是「给终端任务 + 严格测试」，照着这个形状设计你的私有集最省事。
2. 接 Kimi Code 时先改三个默认动作（官方文档明确要求）：保持 thinking 开启（K3.1 Pro 只支持 thinking 模式，关闭会被直接拒绝）；不要在已有 K3 / K2.8 / K2.7 会话里切换模型（会掉质量、掉缓存命中），要新开会话；走原生 Responses / chat completion / message API，别用协议转换代理，否则行为会漂。
3. 把缓存当成架构决策。 90% 的缓存折扣意味着「长 system prompt + 稳定前缀」的收益远大于换更便宜的模型；反过来说，频繁改 prompt 结构的分支策略会在 K3.1 Pro 上被双重惩罚（贵 + 慢）。
4. 自托管的账要提前算清楚，别等 11 月 4 日。 3T 级权重不是「下载下来跑 llama.cpp」的量级，实际受益者是有集群的推理服务商和大厂；中小团队的现实选择是 API 或第三方托管。如果你的合规要求必须自托管，现在就该确认量化方案与最小可用集群规模，而不是赌权重发布后一周能上线。
5. 做安全产品的，把 81% 当作「官方愿意公开的数字」而不是能力上限。 对内做红队评估时，按 90.5% 那档建模；对外采购「AI 漏洞挖掘」能力时，问供应商的第一个问题是 harness 和 pass@k 定义，而不是总分。
6. 企业采购清单加两条：Kimi Enterprise 里 K3.1 Pro 默认关闭，需管理员显式开启；API 侧提供 Zero Data Retention 选项——这两条决定了它能不能进你的数据合规白名单。

待观察

• 11 月 4 日的权重是否按期、以什么许可证放出。 官方博客只写「by Nov 4, 2026」，正文与脚注里没有找到 license 说明；许可证条款（尤其商用与再分发）会直接决定它能不能进产品。
• 第三方能否复现 65.7%。 这个数字用的是 Claude-Code harness，官方榜单尚未独立验证；同样待观察的是 AA 目前仍把该模型标为 Proprietary（权重未发布），权重放出后其吞吐与智能指数是否变化。
• cyber 能力的「逐步提高」节奏没有时间表。 官方承诺会逐步放开开放权重中的 cyber 能力，但既没给版本节点也没给上限；这条承诺的实际执行力，比任何单一跑分都更值得跟踪。
• Hallu Bench 的自报改善需要外部对照。 声明级幻觉率从 23.4% 降到 8.3%，但这是内部压力测试集，官方自己也注明「不代表日常使用错误率」；金融、法务这类场景仍应自建抽样核验。