Kimi新模型提供百万上下文窗口

Kimi K3.1 Pro 最值得程序员关注的，是它把长任务编程、更低的 API 价格和 1M token 上下文放到了一起。按 MarkTechPost 转述的 Moonshot 自报成绩，它在部分编程测试中接近甚至超过闭源对手，但科学类终端任务仍有明显差距。

先分清一个状态：原文称权重预计在 2026 年 11 月发布，目前可用的是在线产品和 API。下面的成绩、价格与接入限制均来自所给原文，不能把厂商测试直接当成自己项目的效果保证。

104B 激活参数，不代表普通机器能部署

Kimi K3.1 Pro 是 Kimi K3 经更大规模后训练得到的版本。总参数为 2.8T，属于 3T 级模型；采用混合专家架构（MoE），每次计算激活约 104B 参数，上下文窗口为 1M token。

它沿用 K3 的 Kimi Delta Attention（KDA）和 Attention Residuals（AttnRes），通过 Stable LatentMoE 从 896 个专家中激活 16 个。可以把专家理解为分工不同的计算模块，每次只调用其中一部分，但部署仍需要容纳庞大的模型权重。

原文引用的是 K3 的部署建议：64+ 加速器组成的超级节点，权重使用 MXFP4，激活值使用 MXFP8。这不是 K3.1 Pro 已公布的精确配置，却足以提醒我们，它距离单卡本地运行很远。

训练侧，Moonshot 在数百个下游领域联合做强化学习，并优化 RL 框架、长上下文推理、沙箱基础设施和 rollout 调度，也就是训练期间生成任务执行轨迹的安排。原文没有给出这些改动各自贡献多少收益。另有 Kimi K3.1 Pro Highspeed，官方声称速度达到普通版的 2 到 3 倍，但这里没有具体测试条件。

编程成绩接近头部，为什么还不能直接换主力

原文列出的成绩均由 Moonshot 自报，采用最高推理强度，大部分使用 Claude Code harness。这里的 harness 指组织任务、调用工具、管理执行过程的测试框架，成绩并不只取决于模型本身。

在 Terminal-Bench 4.0 中，K3.1 Pro 得分 65.7%，Claude Opus 5.5 为 66.4%，相差 0.7 个百分点。SWE-Marathon 上，它以 51.7 超过 Opus 5.5 的 46.3。内部测试 Kimi Code Bench 3.0 Long-horizon 则从 K3 的 55.95 提升到 61.2。

这些结果支持把它放进编程 Agent 候选名单，但不能证明所有开发任务都占优。Terminal-Bench Science 0.1 上，它只有 38.1，而 GPT-6 Astra 为 68.1，Opus 5.5 为 63.3，差距超过 25 分。

擅长执行软件工程任务，不等于同样擅长科学类终端任务。

其他成绩也需要连同条件看：BenchCAD 使用工具时，它为 92.7，低于 Opus 5.5 的 96.2 和 GPT-6 Astra 的 95.9；不用工具时为 72.8，接近 Opus 5.5 的 73.0。金融方面，OfficeQA Pro v2 为 64.4，原文称达到最佳水平；Frontier Finance 为 58.6。内部金融测试中，建模和研究分别比 K3 提升 7.2、11.6 分。

幻觉改善同样来自内部测试。Kimi Hallu Bench Hard 中，按单条事实声明统计的幻觉率从 23.4% 降至 8.3%，相对下降约 65%；同一测试里 GPT-6 Astra 为 5.5%。它说明了厂商测得的改进，不能直接换算成业务回答的可靠率。

API 更便宜了，接入却不只是替换模型名

原文列出的入口包括 Kimi.ai、Kimi Work、Kimi Code 和 Kimi API。API 兼容 OpenAI，模型 ID 是 kimi-k3.1-pro 和 kimi-k3.1-pro-highspeed。

普通版每百万 token 输入 $2.00、输出 $10.00，缓存命中 $0.20；K3 原价为输入 $3.00、输出 $15.00。Highspeed 则为输入 $4.00、输出 $20.00。普通版单价下降，但更长的推理和输出仍可能增加单任务成本。

接入前要核对这些约束：

• Thinking mode 始终开启，推理强度支持 low、high、max，默认 max。
• temperature 固定为 1.0，top-p 固定为 0.95，现有应用的采样配置不能照搬。
• 默认输出上限为 131,072 token，最高可设为 1,048,576；输出上限与 1M 上下文是不同指标，原文没有解释两者如何共同计入额度。
• 最低充值 $1 后解锁访问；API 支持文本、图片和视频，但视觉输入不接受公开图片 URL，需要 base64 或上传后的 file ID。

还有一个容易影响 Agent 的细节：K3 曾提示，执行框架丢弃推理历史会导致输出不稳定；K3.1 Pro 文档也要求回传完整 assistant message。前端或 Node 项目中的消息存储层如果只保留可见文本，就需要检查是否丢失了必要字段。

我的判断

我认可它值得进入长任务编程的对比测试：SWE-Marathon 和终端编程成绩提供了理由，普通版价格也有吸引力。但原文没有独立复测，没有相同任务下的延迟、总成本和重试次数对照，内部测试的领先只能作为候选信号。

1M 上下文也不能直接理解为「整个仓库塞进去就能准确处理」。原文没有展示长上下文检索、跨文件修改或上下文接近上限时的可靠性数据。和检索相关文件、压缩历史等常见做法相比，扩大窗口提供了另一种选择，尚不能证明可以省掉上下文管理。

安全部分也有明确取舍。Moonshot 为计划开放权重的版本移除了中期训练和 RL 中的网络安全相关数据。内部 xdev-bench-hard 上，未过滤检查点的 pass@3 为 90.5%，发布版为 81.0%；pass@3 表示最多尝试三次的通过情况。这是能力变化的自报证据，不能单独证明整体安全性。

最后，预计开放权重与已经能够自部署，是两个阶段。许可证、部署成本和实际吞吐，原文都没有交代清楚。

能拿来做什么

• 选取真实仓库里的跨文件修复或长流程任务，将 kimi-k3.1-pro 与现用模型对比，同时记录完成质量、重试次数和总费用。
• 检查 Node Agent 的消息序列化与历史裁剪逻辑，确认能够回传完整 assistant message，再评估压缩历史的影响。
• 做截图分析等视觉功能时，将图片处理为 base64 或上传后的 file ID，不要直接沿用公开图片 URL 的传参方式。
• 分别测试普通版和 Highspeed 在自己任务中的耗时与费用，再决定是否为更高速度支付双倍输入、输出单价。