Composer 2.5 现已在 Cursor 中推出。

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

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

除了让 Composer 2.5 在更高难度的任务上训练之外，我们还改进了模型在沟通风格和投入级别校准等行为层面的表现。这些维度很难通过现有基准充分反映，但我们发现，它们对实际使用效果非常重要。

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

我们正与 SpaceXAI 合作，从零开始训练一个规模显著更大的模型，使用 10 倍的总计算资源。借助 Colossus 2 的 100 万个 H100 等效算力，以及我们整合的数据与训练技术，我们预计这将带来模型能力的一次重大飞跃。

#体验 Composer 2.5

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

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

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

#训练 Composer 2.5

Composer 2.5 对我们的训练栈进行了多项改进。这些变化同时聚焦于模型智能和易用性。

#基于文本反馈的定向 RL

随着 rollout 可能跨越数十万个 token，RL 中的信用分配正变得越来越困难。当奖励是基于整个 rollout 计算时，模型往往很难判断究竟是哪个具体决策让结果变好或变坏。当我们想抑制某种局部行为时，这一点尤其受限，比如错误的工具调用、让人困惑的解释，或风格不符合要求。最终奖励可以告诉我们出了问题，但对于具体是在什么地方出错，它只是一个噪声很大的信号。

为了解决这一问题，我们用定向文本反馈训练了 Composer 2.5。¹ 核心思路是在轨迹中模型本可以表现得更好的位置，直接提供反馈。对于目标模型消息，我们构造一条描述期望改进的简短提示，将这条提示插入局部上下文中，并将由此得到的模型分布作为教师。我们将原始上下文下的策略作为学生，并添加一个 on-policy 蒸馏 KL 损失，使学生的 token 概率向教师的分布靠拢。这样，我们既能为想要改变的行为提供局部化的训练信号，同时又保留贯穿完整轨迹的更广泛 RL 目标。

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

借助文本反馈，我们可以通过在有问题那一轮的上下文中插入一条提示，来针对这一具体错误，例如“Reminder: Available tools...”，并附上可用工具列表。这条提示会改变教师模型的概率分布，降低错误工具的概率，并提高某个有效替代项的概率。仅针对这一轮，我们再将学生模型的权重更新得更接近这些新概率。

在 Composer 2.5 的训练过程中，我们将这种方法应用于多种模型行为，从编码风格到模型沟通。

#合成数据

在 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 上。