Composer 2.5 现已在 Cursor 中上线。

与 Composer 2 相比，它在智能和行为表现上都有显著提升。它更擅长在长时间运行的任务中持续工作，更可靠地遵循复杂指令，协作起来也更顺畅。

我们通过扩大训练规模、构建更复杂的 RL 环境，并引入新的学习方法，改进了 Composer。

除了让 Composer 2.5 在更高难度的任务上接受训练外，我们还改进了模型在沟通风格和投入级别校准等行为层面的表现。现有基准测试难以很好地衡量这些维度，但我们发现，它们对实际使用中的实用性至关重要。

Composer 2.5 基于与 Composer 2 相同的开源检查点构建，即 Moonshot 的 Kimi K2.5。

我们正与 SpaceXAI 一起，从零开始训练一个规模大得多的模型，使用的总算力是此前的 10 倍。凭借 Colossus 2 的百万 H100 等效算力，以及我们共同积累的数据和训练技术，我们预计这将带来模型能力的一次重大飞跃。

#训练 Composer 2.5

Composer 2.5 在我们的训练技术栈上实现了多项改进。这些改动同时提升了模型智能和易用性。

#结合文本反馈的定向 RL

随着 rollout 的长度可能达到数十万个 token，RL 中的 credit assignment 正变得越来越困难。当 奖励 是基于整个 rollout 计算时，模型往往很难判断究竟是哪个具体决策促成了结果，或对结果造成了负面影响。尤其是在我们想要抑制某种局部行为时，这一问题会更加突出，比如错误的工具调用、令人困惑的解释，或不符合风格规范的输出。最终 奖励 可以告诉我们哪里出了问题，但对于具体是在哪一步出的问题，它只是一个噪声很大的 signal。

为了解决这个问题，我们使用定向文本反馈训练了 Composer 2.5。¹其核心思路是在模型本可以表现得更好的轨迹节点上直接提供反馈。对于目标模型消息，我们会构造一条描述期望改进的简短提示，将其插入局部上下文，并将得到的模型分布作为 teacher。我们将原始上下文下的 policy 作为 student，并加入 on-policy distillation KL loss，使 student 的 token 概率向 teacher 靠拢。这样一来，我们既能为想要改变的行为提供局部训练 signal，又能保留覆盖完整轨迹的更广泛 RL 目标。

为了说明文本反馈的过程，可以考虑一个较长的 rollout，其中包含一次工具调用错误：模型试图调用一个不可用的工具。在 rollout 过程中，模型会收到“未找到工具”的错误提示，然后继续进行其他有效的工具调用。在数百次工具调用中只出现这一处错误，对最终 奖励 的影响会非常小。

借助文本反馈，我们可以通过在有问题的轮次上下文中插入提示来针对这一具体错误，例如“提醒：可用工具……”并附上可用工具列表。这条提示会改变 teacher 的概率分布，降低错误工具的概率，并提高有效替代工具的概率。随后，我们只针对该轮次更新 student 的权重，使其朝这些新概率靠拢。

在 Composer 2.5 的 run 期间，我们将这种方法应用到了多种模型行为上，从 coding 风格到模型 communication。

#合成数据

在 RL 训练过程中，Composer 的编程能力显著提升，逐渐能够正确完成大多数训练任务。为了继续提升模型智能，我们会在整个训练过程中动态筛选并生成更难的任务。Composer 2.5 使用的合成任务数量是 Composer 2 的 25 倍。

我们采用了多种方法来创建基于真实代码库的合成任务。例如，其中一种方法是功能删除。在这类任务中，智能体会拿到一个带有大量测试的代码库，并被要求删除部分代码和文件，同时确保代码库仍可正常运行，只是移除了特定的可测试功能。随后，合成任务就是重新实现该功能，而这些测试则作为可验证的奖励信号。

大规模生成合成任务的一个后果是，它可能引发意想不到的奖励作弊。随着模型越来越熟练，Composer 2.5 能够找到越来越复杂的变通办法来完成当前任务。在一个案例中，模型发现了一个残留的 Python 类型检查缓存，并通过逆向分析其格式找到了一个已删除的函数签名。在另一个案例中，它找到了 Java 字节码并将其反编译，从而重建了一个第三方 API。我们借助智能体监控工具发现并诊断了这些问题，但这也表明，在大规模 RL 中必须更加谨慎。

#分片 Muon 与双网格 HSDP

在持续预训练中，我们使用带分布式正交化的 Muon。形成动量更新后，我们会按模型的自然粒度运行 Newton-Schulz：注意力投影按每个注意力头处理，堆叠的 MoE 权重则按每个专家处理。

主要开销在于对专家权重做正交化。对于分片参数，我们会将形状相同的张量打包处理，通过 all-to-all 把分片重组为完整矩阵，运行 Newton-Schulz，然后再通过 all-to-all 将结果发回原始分片布局。这些传输是异步的：当一个任务在等待通信时，优化器运行时会继续推进其他 Muon 任务，从而让网络通信与计算重叠进行。这相当于完整矩阵 Muon，但能让分片组持续忙碌；在 1T 模型上，优化器步骤耗时为 0.2 秒。

这也与我们在 MoE 模型中使用 HSDP 的方式密切相关。HSDP 会形成多个 FSDP 副本，并在对应分片之间对梯度执行 all-reduce。我们为非专家权重和专家权重使用了不同的 HSDP 布局：非专家权重相对较小，因此其 FSDP 组可以保持较窄，通常局限在单个节点或机架内；而专家权重承载了大部分参数和大部分 Muon 计算，因此使用更宽的专家分片网格。

将这些布局分开，还能让彼此独立的并行维度相互叠加：CP=2 和 EP=8 可以在 8 个 GPU 上运行，而不是在单一共享网格中需要 16 个 GPU。这样既避免了小规模非专家状态上的大范围通信，又能把专家优化器的工作分摊到更多 GPU 上。

#试试 Composer 2.5

Composer 2.5 的价格为每百万输入 token $0.50、每百万输出token$2.50。

此外，还有一个智能相同但速度更快的变体，价格为每百万输入 token $3.00、每百万输出token$15.00，成本低于其他前沿模型的快速方案。与 Composer 2 类似，fast 是默认选项。完整详情请参阅我们的模型文档。

Composer 2.5 在第一周提供双倍用量。