Kimi K3.1 Pro 双版本上线

Kimi 在 K3 发布三个月后继续加码

**月之暗面于 2026 年 10 月 23 日发布 Kimi K3.1 Pro，并同步推出 K3.1 Pro Highspeed 高速版本。**这是 Kimi K3 在今年 7 月正式上线之后的又一次旗舰迭代，也意味着 Kimi 开始把同一代高端模型拆成标准服务与高速服务两条产品线。

**Kimi K3.1 Pro 是本次官方发布页列出的 K3 系列专业版本。**Kimi K3.1 Pro Highspeed 则是与其配套的高速版本，核心卖点不是更大的参数量，而是用更高的生成吞吐和更短的等待时间改善编程、研究与 Agent 任务体验。

截至发稿，官方已确认两个版本发布，但现有公开材料没有完整披露 K3.1 Pro 的总参数量、激活参数量、训练数据规模、逐项基准成绩、官方 token 单价以及 Highspeed 的稳定输出速度。换句话说，这次发布已经明确了产品定位，却还没有给出一张足以完成横向复盘的完整参数表。

**这次升级最重要的信号，是 Kimi 正在把模型能力与推理速度分开销售和优化。**对于普通聊天，标准版与高速版可能只表现为文字出现得快一些；对于需要连续读文件、修改代码、执行命令和处理错误的 Agent，输出速度会直接影响每轮工具调用何时启动，进而影响整项任务能否在可接受时间内完成。

K3.1 Pro 不是一次孤立更新

**K3.1 Pro 的技术起点是今年 7 月发布的 Kimi K3，但不能在官方确认前把 K3 的全部规格直接等同于 K3.1。**Kimi K3 是月之暗面于 2026 年 7 月 17 日发布的旗舰模型，总参数量为 2.8 万亿，采用 KDA 混合线性注意力与 Attention Residuals，原生支持视觉理解，并提供最高 100 万 token 上下文窗口。

**KDA 是 Kimi Delta Attention 的缩写，是一种把线性注意力效率与传统注意力表达能力结合起来的混合注意力机制。**它试图解决超长上下文模型最现实的成本问题：上下文越长，传统全注意力需要处理的计算和显存开销越高，而线性注意力虽然便宜，复杂检索和精确回看能力又可能受损。

**Attention Residuals 是 K3 用来改善深层网络信息传递的注意力残差技术。**如果把普通残差连接理解为给信息修了一条直达深层网络的旁路，那么注意力残差更强调让模型在不同层之间保留和复用关键注意力信息，以降低超大规模模型训练时的信息损耗。

**100 万 token 上下文是 K3 家族面向代码仓库和知识工作的核心规格。**这一容量理论上可以装入大型项目的多批源码、长篇研究资料、会议记录和历史对话，但窗口容量只代表“能放进去多少”，不等于模型一定能在百万 token 尾部准确找出早期细节。

K3 当时还从监督微调阶段引入量化感知训练，采用 MXFP4 权重与 MXFP8 激活，以降低超大参数模型的部署成本。官方同时建议在 64 个或更多加速器组成的 supernode 上部署 K3，这说明 2.8 万亿参数带来的系统复杂度并没有消失，而是被转移到了专家并行、跨卡通信、缓存管理和推理调度层。

**K3.1 Pro 更可能是一次后训练、推理策略和服务工程的组合升级，而不是简单堆高参数。**原因很直接：从 K3 发布到 K3.1 Pro 上线只有约三个月，重新训练一个规模明显更大的 3 万亿级基础模型需要高昂算力和较长周期，而通过强化学习、工具使用训练、长程任务数据和推理基础设施优化提升产品表现，迭代速度要快得多。

不过，参数是否保持 2.8 万亿、是否继续采用相同的专家结构、100 万 token 是否对所有入口开放，以及视觉能力是否同步升级，目前都应以 K3.1 Pro 后续技术报告和模型卡为准。把上一代规格不加区分地复制到新版本上，会制造一种看似完整、实际未经证实的参数表。

Highspeed 可能比“Pro”更有实际意义

**Highspeed 版本的价值在于降低生成阶段的等待，而不是自动缩短所有任务耗时。**一项 Agent 任务通常由提示词预填充、模型思考、文本生成、文件读取、代码执行、网络检索和多轮工具调用组成，高速版本主要能够直接加速其中的模型输出部分。

Kimi Code 文档已经专门提醒过，工具和脚本耗时不会因为切换高速模型而减少。如果一项任务共耗时 100 秒，其中模型生成占 30 秒、测试和构建占 70 秒，即使把生成阶段提速到原来的 3 倍，总耗时也只是从 100 秒降到 80 秒，端到端降幅只有 20%。

**高速模型必须同时观察输出速度、首 token 延迟和首个有效答案延迟。**输出速度回答的是模型开始生成后每秒能吐出多少 token；首 token 延迟回答的是请求发出后多久看到第一个 token；首个有效答案延迟则把隐藏推理或等待阶段也计算在内，更接近深度推理模型的真实体感。

以第三方 Artificial Analysis 对上一代 Kimi K3 Max 的测试为参照，K3 Max 的输出速度约为 42.1 token/s，Gemini 3.1 Pro Preview 约为 134.2 token/s，后者约是前者的 3.19 倍。K3 Max 的首 token 延迟约为 3.60 秒，但首个答案 token 时间达到 51.12 秒，说明“很快返回连接”与“很快给出可读答案”不是一回事。

**Kimi 过去已经证明自己能把特定代码模型推到更高吞吐。**官方模型列表显示，Kimi K2.7 Code Highspeed 的典型输出速度约为 180 token/s，短上下文场景最高可达 260 token/s。不过，这组数字属于 K2.7 Code Highspeed，不能直接当作 K3.1 Pro Highspeed 的性能承诺。

| 模型或版本 | 已公开定位 | 上下文 | 已知输出速度 | 适合场景 | 当前信息边界 | |---|---:|---:|---:|---|---| | Kimi K3 | 2.8 万亿参数旗舰模型 | 最高 1M token | 第三方测试约 42.1 token/s | 长程编程、知识工作、视觉理解、深度推理 | 2026 年 7 月发布的基础版本 | | Kimi K3.1 Pro | K3 系列专业版本 | 尚待本次版本文档确认 | 尚未完整披露 | 高难推理、复杂代码和端到端知识任务 | 不应直接套用 K3 的全部规格 | | Kimi K3.1 Pro Highspeed | K3.1 Pro 高速服务版本 | 尚待确认 | 尚未完整披露 | 交互式编程、多轮 Agent、低等待任务 | 需要实测端到端耗时与限流策略 | | Kimi K2.7 Code Highspeed | 上一代高速代码模型 | 256K token | 约 180 token/s，短上下文最高 260 token/s | 高频代码生成和修改 | 速度不能外推至 K3.1 Pro Highspeed | | Gemini 3.1 Pro Preview | 闭源通用旗舰模型 | 以官方版本说明为准 | 第三方测试约 134.2 token/s | 多模态、推理与 Agent | 测试条件可能与官方服务不同 |

**Highspeed 最适合需要大量短回合的交互式任务。**例如在 IDE 中生成一个函数、根据报错立刻修改、连续确认多个补丁，模型每轮快 2 秒，20 轮就能减少约 40 秒等待；但在一次性生成长篇研究报告时，用户往往更在意事实准确性、引用质量和总成本，纯速度优势未必排在第一位。

开发者要防止“选了高速版，实际仍跑标准版”

**模型名称、产品入口和底层模型 ID 不是一回事。**Kimi 既有面向网页和客户端的产品名称，也有开放平台模型名称，还有 Kimi Code 订阅体系中的专用模型 ID；开发者不能仅凭界面上的 Highspeed 字样推断请求已经落到高速服务。

Kimi Code 现有文档曾提示，高速版在相关编程客户端中需要选择 kimi-for-coding-highspeed，如果模型 ID 填错，系统可能回退到 kimi-for-coding，而且不一定明确报错。开放平台中的 K2.7 高速模型则使用 kimi-k2.7-code-highspeed，两套命名对应不同产品表面，不能混用。

**K3.1 Pro 与 K3.1 Pro Highspeed 的准确模型 ID 应以本次正式文档为准。**在官方模型列表完成更新前，团队不应根据旧命名规律自行拼接 ID，更不应把 K2.7 Code 的高速模型名称当成 K3.1 Pro Highspeed 使用。

实际验收时，开发团队至少应记录以下四项指标：

1. 首个 token 延迟：判断交互是否迅速开始；
2. 稳定输出速度：排除开头快、后续降速的情况；
3. 端到端任务时间：把工具执行、测试和重试全部计入；
4. 单位成功任务成本：总费用除以最终通过验收的任务数量。

**单位成功任务成本比单纯的 token 单价更有决策价值。**一个模型即使每百万 token 更便宜，如果经常需要重复解释需求、修复无效补丁或重跑测试，最终完成一个任务的成本仍可能更高。

此前第三方按 7:2:1 的缓存命中、输入和输出比例估算，K3 Max 每 100 万综合 token 成本约为 2.31 美元，Gemini 3.1 Pro Preview 约为 1.74 美元，后者低约 24.7%。这不是两家统一口径的官方目录价格，但能说明高速版若附带明显溢价，就必须用更低延迟或更高任务成功率证明价值。

百万上下文仍然是 Kimi 的差异化筹码

**Kimi K3 家族真正拉开差异的能力，仍是百万级上下文与超大规模模型的组合。**很多模型能够提供较长上下文，但在真实代码仓库中，关键问题不是一次塞进多少文件，而是能否跨越数十万 token 维持约束、定位引用关系，并在多轮修改后不破坏早期需求。

K3 对传统 prefix caching 的适配也值得关注。Prefix caching 是复用重复提示词前缀计算结果的缓存技术，在代码仓库、系统提示词和长文档保持不变时，可以避免每轮请求都重新处理完整上下文，从而降低首轮之后的延迟与成本。

**KDA 给传统前缀缓存带来了新的实现难题。**月之暗面此前表示已向 vLLM 社区贡献相应实现，使带 prefill cache 的 KDA 能够在大模型与长上下文条件下工作。对 K3.1 Pro Highspeed 而言，真正决定速度上限的可能不是单个 GPU 的解码能力，而是缓存命中、专家路由、跨卡通信与请求调度能否协同。

**高速版在长上下文场景下是否仍能保持高吞吐，是后续评测最值得追踪的问题。**很多模型在短提示词下可以给出漂亮的 token/s 数据，但当输入增长到 128K、256K 乃至 1M token 后，预填充时间和显存压力会迅速上升，短上下文跑分无法代表代码仓库级任务体验。

K3.1 Pro 的竞争对象已经变了

**Kimi K3 发布时仍被官方定位为落后于最强闭源模型、但领先其他多数模型的开源旗舰。**到了 K3.1 Pro 阶段，竞争重点不再只是模型榜单分数，而是能否在代码 Agent、深度研究和企业知识任务中，以更低成本完成可验证结果。

模型能力的竞争正在从“回答一道题”转向“完成一件事”。编程场景要求模型理解仓库、修改多个文件、运行测试并处理失败；研究场景要求模型读取大量资料、排除冲突信息并给出可追溯结论；企业场景还要考虑权限、稳定性、并发和数据治理。

**K3.1 Pro Highspeed 是一个方向正确但需要数据兑现的版本。**Kimi K3 的主要短板之一就是长时间任务中的输出吞吐和端到端等待，高速服务若能在保持推理质量的同时，把约 42 token/s 的上一代第三方测试水平提升到 100 token/s 以上，交互体验会发生明显变化；若只是短提示词峰值很高、长上下文迅速降速，产品价值就会打折。

**这次发布是否成功，要等四类信息补齐后才能下结论。**第一是 K3.1 Pro 相比 K3 的独立基准成绩；第二是 Highspeed 在不同上下文长度下的持续吞吐；第三是两个版本的正式价格和限流规则；第四是开放权重、模型卡与技术报告的发布安排。

在这些数据出现之前，最稳妥的判断是：K3.1 Pro 代表 Kimi 对旗舰能力的持续打磨，Highspeed 则代表它开始认真解决模型“足够聪明但不够快”的产品化问题。对开发者而言，后者可能比一次小幅榜单提升更重要，因为 Agent 真正消耗的是人的等待时间，而不是发布页上的模型名称。

参考来源

• Moonshot AI 的 Hugging Face 官方主页：用于查看月之暗面公开模型、模型卡与权重更新。
• MoonshotAI 的 GitHub 官方组织页：用于查看 Kimi 相关开源项目、推理实现及社区协作进展。

本文同时依据 2026 年 10 月 23 日 Kimi 官方发布页《Kimi K3.1 Pro and K3.1 Pro Highspeed》、Kimi K3 官方发布说明、Kimi Code 模型配置文档及 Kimi 开放平台模型列表整理；按照指定域名范围，未在参考来源中附上对应站外链接。