Cursor Composer 2分布式RL训练技术解析

从应用公司到基础模型公司

Cursor最近发布了Composer 2——一个面向长时间编码任务的智能体模型，引发了业界广泛关注。这不仅是一次产品升级，更标志着Cursor从纯应用公司向基础模型公司的转型。在Sequoia Capital的播客中，Cursor研究负责人Federico和Fireworks的Dima深入分享了Composer 2训练背后的技术细节。

Federico解释了训练自有模型的核心逻辑："你可以把模型想象成一个存储驱动器，它的权重中能存储有限的信息位。我们只关心一个任务——在Cursor内部进行软件工程。如果我们把所有信息位都分配给这一个任务呢？"这种极致专注使得Composer的运行成本比Opus低了一个数量级。

训练架构：中期训练+大规模强化学习

Composer 2基于Kimi 2.5（1万亿参数的MoE模型，30B活跃参数）构建，采用了双阶段推进策略。

关于MoE架构：混合专家模型（Mixture of Experts，MoE）是一种稀疏激活的神经网络架构。与传统密集模型不同，MoE在每次前向传播时只激活部分参数——通过一个路由层（Router）动态选择最相关的"专家"子网络处理输入。Kimi 2.5的1万亿总参数中，每次推理只有约30B参数被激活，这使得计算成本大幅降低，同时保留了超大规模模型的知识容量。这种架构的代价是路由决策的不确定性：微小的数值扰动可能导致路由层选择完全不同的专家组合，在分布式训练中引发严重的一致性问题——这也是后文将重点讨论的核心工程挑战之一。

中期训练（Mid-training）

第一阶段是接近预训练规模的代码续训。中期训练（Mid-training）是介于预训练和微调之间的训练阶段，近年来随着领域专用模型的兴起而受到重视。预训练在海量通用语料上建立基础能力，而中期训练则在特定领域的大规模数据上继续进行下一个token预测，目标是将领域知识"压入"模型权重，而非通过提示词在推理时临时注入。对于代码模型，这意味着在GitHub代码库、技术文档、代码审查记录等数据上进行持续预训练，使模型对代码库结构、API调用模式、常见bug类型等形成深度内化的"直觉"。这为后续RL阶段提供了更宽广的策略搜索空间——模型需要先"知道"各种可能的解法，才能通过RL学会选择最优解法。这类似于Cursor的Tab自动补全模型所做的工作——纯粹的下一个token预测。

强化学习（RL）

第二阶段是大规模强化学习，这是Composer 2的核心创新所在。与预训练不同，RL需要让模型在真实环境中执行完整的智能体会话（Rollout），可能包含50个回合的工具调用、代码生成和环境交互，最终根据结果分配奖励信号。

在大语言模型的强化学习训练中，Rollout指模型在环境中完整执行一次任务序列的过程。与监督学习不同，RL不依赖人工标注的"正确答案"，而是让模型自主探索并根据最终结果获得奖励信号。对于编码智能体，一次Rollout可能包含：读取代码文件、调用终端命令、修改代码、运行测试、根据报错迭代修复等数十个步骤。Cursor在离线RL阶段使用了GRPO（Group Relative Policy Optimization）算法——这是DeepSeek提出的一种RL算法变体，通过对同一问题采样多个输出并进行组内相对比较来估计优势函数，避免了传统PPO算法需要单独训练价值网络的开销，特别适合长序列推理任务。

分布式RL基础设施：核心工程挑战

异步流水线设计

RL训练面临一个根本性的效率问题：如果训练器在等待rollout完成时闲置，GPU利用率将大幅下降。Cursor和Fireworks采用了异步流水线方案——训练和推理像工厂的两条产线持续运转。Rollout始终使用最新模型版本生成新会话，训练器则持续消化新产生的结果并更新权重。

这种方案的代价是引入了"陈旧性"（staleness）：当某个rollout完成时，模型权重可能已经更新了几步。但实践证明，这几个百分点的算法损失远不及GPU满载运行带来的效率提升。

全球分布式推理与权重同步

Composer 2的训练使用了全球四个集群。训练集中在一个高速互联的集群上，而推理组件则分布在世界各地的小型集群中——甚至在用户流量低谷时借用生产环境的推理GPU来加速训练。

这带来了一个关键的系统问题：Kimi模型每个训练步产生约1TB的权重快照，每5-15分钟一次。如何快速将其同步到全球各地？

解决方案是增量压缩。由于RL训练中每步只有少量权重发生变化，通过只传输Delta（差异部分），数据量可缩小20倍。配合分片上传下载以充分利用带宽，权重交换通常在一分钟内完成，推理服务仅需暂停约30秒。

MoE模型的数值对齐难题

浮点运算的非确定性是分布式RL训练中一个被严重低估的问题。IEEE 754浮点标准允许处理器在满足精度要求的前提下以任意顺序执行运算，这导致A+B+C与C+B+A可能产生不同的结果——差异通常在小数点后十几位，但在深度神经网络中经过数十亿次累积运算后会被显著放大。在分布式训练中，不同GPU节点的运算顺序差异、不同精度格式（FP16/BF16/FP8）之间的转换，以及All-Reduce通信中的归约顺序，都是数值不一致的来源。

对于MoE模型，问题更加严重：路由层通常使用softmax后取top-k的方式选择专家，当两个专家的得分极为接近时，隐藏状态的微小数值差异就可能翻转选择结果（比如选择专家7而非专家9），从而激活模型的不同部分。如果推理时激活了专家7，但训练时却试图更新专家9，训练就会崩溃。

解决方案包括：手写GPU kernel确保运算顺序一致、使用"路由重放