Cursor 推出 Composer 2.5

# 推出 Composer 2.5 来源：https://cursor.com/blog/composer-2-5 Composer 2.5 现已在 Cursor 中可用。 相比 Composer 2（https://cursor.com/blog/composer-2），它在智能性和行为方面有显著提升。它在长时间任务上的持续工作能力更强，更可靠地遵循复杂指令，并且协作体验更愉快。 Composer 2.5 基准测试结果 Composer 2.5 基准测试结果 我们通过扩大训练规模、生成更复杂的强化学习环境以及引入新的学习方法，改进了 Composer。 除了在更困难的任务上训练 Composer 2.5，我们还改进了模型的沟通风格和精力校准等行为方面。这些维度难以通过现有基准测试充分捕捉，但我们发现它们对实际应用至关重要。 Composer 2.5 精力曲线 Composer 2.5 精力曲线 Composer 2.5 与 Composer 2 基于相同的开源检查点——Moonshot 的 Kimi K2.5（https://cursor.com/blog/composer-2-technical-report）。 Composer 2.5 训练 Composer 2.5 训练 我们与 SpaceXAI（https://cursor.com/blog/spacex-model-training）合作，从零开始训练一个规模显著更大的模型，总计算量增加了 10 倍。借助 Colossus 2 的百万 H100 等效算力以及我们结合的数据和训练技术，我们预计这将是模型能力的一次重大飞跃。 ## https://cursor.com/blog/composer-2-5#training-composer-25 训练 Composer 2.5 Composer 2.5 对我们的训练栈进行了多项新改进。这些改进同时针对模型智能和可用性。 ### https://cursor.com/blog/composer-2-5#targeted-rl-with-textual-feedback 基于文本反馈的定向 RL 在 RL 中，随着轨迹展开可能长达数十万个 token，信用分配正变得越来越具有挑战性。当奖励在整个轨迹上计算时，模型很难判断是哪个具体决策帮助或损害了结果。当我们希望阻止某个局部行为（例如错误的工具调用、令人困惑的解释或风格违规）时，这一点尤其受限。最终奖励可以告诉我们出了什么问题，但对于问题出在哪里，它是一个有噪声的信号。 为了解决这个问题，我们使用定向文本反馈训练了 Composer 2.5。¹（https://cursor.com/blog/composer-2-5#fn-1）其思想是直接在轨迹中模型本可以表现得更好的地方提供反馈。对于目标模型消息，我们构建一个描述所需改进的简短提示，将该提示插入局部上下文，并将得到的模型分布用作教师。我们使用原始上下文的策略作为学生，并添加一个在线策略蒸馏 KL 损失，将学生的 token 概率推向教师的概率。这为我们想要改变的行为提供了一个局部训练信号，同时仍然保留整个轨迹上的更广泛 RL 目标。 作为文本反馈过程的一个示例，考虑一个包含工具调用错误的长轨迹，其中模型尝试调用一个不可用的工具。在轨迹过程中，模型将收到一个“工具未找到”错误，并继续发出其他有效的工具调用。它在数百次工具调用过程中遇到一个错误的事实对其最终奖励的影响微乎其微。 借助文本反馈，我们可以通过在问题轮次的上下文中插入一个提示来针对这一具体错误，例如“提醒：可用工具...”以及可用工具列表。该提示会改变教师的概率，降低错误工具的概率，并增加有效替代工具的概率。仅在该轮次，我们然后将学生权重更新为新的概率。 在 Composer 2.5 训练过程中，我们将此方法应用于多种模型行为，从编码风格到模型通信。 Composer 2.5 文本反馈 Composer 2.5 文本反馈 ### https://cursor.com/blog/composer-2-5#synthetic-data 合成数据 在 RL 训练过程中，Composer 的编码能力显著提升，开始能解决大部分训练问题。为了继续提高智能性，我们在整个训练过程中动态地选择并创建更困难的任务。Composer 2.5 使用的合成任务数量是 Composer 2 的 25 倍。 我们使用一系列方法来创建基于真实代码库的合成任务。例如，一种合成方法是特征删除。对于这些任务，代理被赋予一个带有大量测试的代码库，并被要求删除代码和文件，使得代码库在保持功能的同时，特定可测试特征被移除。合成任务是重新实现该特征，而测试则用作可验证的奖励。 大规模合成任务创建的一个下游后果是可能导致意外的奖励破解。随着模型变得越来越熟练，Composer 2.5 能够找到越来越复杂的变通方法来完成任务。在一个示例中，模型找到了一个遗留的 Python 类型检查缓存，并逆向工程其格式以找到被删除的函数签名。在另一个示例中，它能够找到并反编译 Java 字节码以重构第三方 API。我们能够使用代理监控工具发现并诊断这些问题，但这表明了大规模 RL 所需的日益谨慎。 Composer 2.5 合成数据 Composer 2.5 合成数据 ### https://cursor.com/blog/composer-2-5#sharded-muon-and-dual-mesh-hsdp 分片 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 上。 ## https://cursor.com/blog/composer-2-5#try-composer-25 尝试 Composer 2.5 Composer 2.5 定价为 $0.50/M 输入 token 和 $2.50/M 输出 token。 还有一个**智能水平相同但速度更快的变体**，定价为 $3.00/M 输入 token 和 $15.00/M 输出 token，低于其他前沿模型的快速层级。与 Composer 2 类似，快速是默认选项。请参阅我们的模型文档（https://cursor.com/docs/models/cursor-composer-2-5）以获取完整详情。 Composer 2.5 在第一周包含双倍用量。