作者/机构: Prime Intellect Team (Sami Jaghouar, Justus Mattern, Jack Min Ong, Jannik Straube, Manveer Basra, Aaron Pazdera, Kushal Thaman, Matthew Di Ferrante, Felix Gabriel, Fares Obeid, Kemal Erdem, Michael Keiblinger, Johannes Hagemann)
核心问题与研究目标
- 核心问题: 传统的强化学习(RL)训练通常是中心化的,需要大型、集中部署的GPU集群和高速互联网络,这限制了其可扩展性和可及性。
- 研究目标: 本文旨在展示一种范式转变,证明强化学习本质上更具异步性,非常适合去中心化、全球分布式的计算环境。研究团队进行了首个大规模实验,通过一个无需许可、全球分布的贡献者网络,协同使用强化学习训练了一个320亿参数的语言模型(INTELLECT-2)。
创新点与主要贡献
1. 全球首个去中心化RL训练的大模型: 成功训练了INTELLECT-2,这是一个320亿参数的推理模型,其训练过程是首次在全球范围内,通过一个动态、异构、无需许可的贡献者群体,以完全异步的强化学习方式完成的。
2. 为去中心化训练构建的全套基础设施: 为了支持这种独特的训练模式,团队从头构建了多个关键组件:
* PRIME-RL: 一个专为分布式异步强化学习设计的训练框架。
* TOPLOC: 一种用于验证来自不受信任的推理工作节点的计算结果(rollouts)的新颖组件。
* SHARDCAST: 一种能够高效地将策略权重从训练节点广播到推理工作节点的组件。
huggingface.co/PrimeIntellect/INTELLECT-2 和 github.com/PrimeIntellect-ai/prime-rl 找到。为了训练INTELLECT-2,我们引入了以下关键的开源基础设施组件:
* PRIME-RL:一个专为去中心化训练设计的完全异步的强化学习框架。它通过解耦rollout生成、模型训练和权重广播,实现了在异构、不可靠的网络上的训练。
* SHARDCAST:一个用于通过基于HTTP的树状拓扑网络分发大文件的库,它能有效地将更新后的模型权重传播到去中心化的推理工作节点。
* TOPLOC 【29,Toploc: A locality sensitive hashing scheme for trustless verifiable inference,2025】:一种用于高效可验证推理的局部敏感哈希方案。它能检测模型推理中的篡改或精度变化,并在不确定的GPU硬件上可靠工作。
* 协议测试网:提供基础设施来聚合和协调全球计算资源。
如图1所示,使用这些组件构建的INTELLECT-2基础设施围绕三个主要角色进行组织:使用当前策略生成推理轨迹的推理rollout工作节点;验证这些rollout完整性的TOPLOC验证器;以及聚合已验证数据、使用GRPO算法更新策略并通过SHARDCAST分发新权重的GRPO训练工作节点。
这种去中心化的RL训练设置提供了几个关键优势:
* 无通信开销:通过利用异步强化学习,新策略权重的广播与正在进行的推理和训练完全重叠——消除了通信瓶颈。
* 支持异构节点:贡献者可以使用各种硬件按自己的节奏生成rollout;节点之间没有统一速度的要求。
* 低资源要求:在此设置中构成大部分计算能力的推理工作节点,可以在消费级GPU上运行。
* 高效验证:TOPLOC执行验证的速度远快于生成。
PRIME-RL框架的设计理念。我们开发了一个新框架PRIME-RL,以支持强化学习的训练和推理工作负载。与verl【36,Hybridflow: A flexible and efficient rlhf framework,2024】和TRL【41,Trl: Transformer reinforcement learning,2020】等在同一进程中顺序执行训练和推理的现有框架不同,PRIME-RL原生支持训练和推理的异步执行。这种解耦使得模型更新可以在受信任的中心化节点上计算,而rollouts则可以在不受信任的去中心化节点上独立生成。
PRIME-RL的架构优势。PRIME-RL的架构将训练和推理组件完全分离到不同的可执行文件中,它们仅在交换数据和检查点时进行通信。这种清晰的分离消除了对像Ray【27,Ray: A distributed framework for emerging ai applications,2018】这样的中心化协调器的需求,我们的两步异步设计有效地隐藏了通常与数据传输相关的延迟,从而创建了一个高效的分布式强化学习流水线。
训练过程中的内存优化与数据交换。为了在训练期间减少GPU内存需求,我们使用PyTorch FSDP2【45,Pytorch fsdp: Experiences on scaling fully sharded data parallel,2023】将模型权重、梯度和优化器状态分片到多个GPU上,其策略类似于ZeRO-3【31,Zero: Memory optimizations toward training trillion parameter models,2020】。我们从远程存储加载训练数据,rollout数据则通过Parquet文件在推理工作节点和训练器之间交换。
异步rollout生成的处理方式。rollout生成的异步特性对训练器是透明的,因为我们在优化步骤开始时使用当前的策略计算对数概率,而不是使用生成原始轨迹的策略。这一设计选择与我们用作参考的verl【36,Hybridflow: A flexible and efficient rlhf framework,2024】中的实现相符。
PRIME-RL的功能实现。在其当前形式下,PRIME-RL实现了GRPO训练,以及辅助的KL和熵损失。
推理生成与采样机制。为了生成rollouts,我们使用vLLM【16,Efficient memory management for large language model serving with pagedattention,SOSP 2023】,并以bfloat16精度加载模型。对于每个批次,我们使用确定性种子随机抽样输入问题,以防止推理工作节点选择简单的样本,具体细节在2.3.3节中阐述。
TOPLOC证明构造的优化。为了支持TOPLOC证明的构造,我们通过在logits处理器中设置一个钩子来捕获最终的隐藏状态。我们不是存储整个序列的激活值,而是在每32个token的间隔内增量地存储和哈希它们,这减少了证明构造的内存开销。为了减少阻塞开销,证明构造在CPU上与GPU前向传播并行异步执行。这些优化共同将证明生成的开销限制在仅约1%的每秒token吞吐量下降。
推理工作节点的同步机制。为了使推理工作节点与训练的其余部分保持同步,我们托管了一个步骤计数器端点,该端点返回rollouts不足的最小步骤。推理工作节点轮询此端点,并为指定的步骤生成rollouts。这种设计允许工作节点动态地加入或离开计算池,而不会中断训练过程。
验证环境的实现。PRIME-RL使用SYNTHETIC-1【23,Synthetic-1: Two million collaboratively generated reasoning traces from deepseek-r1,2025】中引入的GENESYS模式,这使得实现新的奖励环境变得容易。在我们最初的实验中,我们支持用于数学的符号验证器和用于基于python的编程竞赛问题的单元测试执行。为此,我们采用了来自【21,Deepscaler: Surpassing o1-preview with a 1.5b model by scaling rl,2025】和【8,Process reinforcement through implicit rewards,2025】的现有实现。
代码执行的安全性考量。需要注意的是,在当前阶段,LLM生成的代码是在推理节点上执行的,我们在这些节点上已经应用了沙盒和代码清理。对于当前使用的简单算法挑战,这种方法提供了足够的隔离。对于更复杂的编码任务(例如,需要文件系统访问的任务),将有必要进一步加强隔离机制。
核心挑战。在去中心化环境下的异步分布式强化学习(RL)中,一个关键挑战是确保最新的策略权重能迅速传递给推理工作节点。
SHARDCAST的解决方案。为此,我们利用一个中继服务器网络,将检查点从主训练服务器分发到客户端推理工作节点,类似于内容分发网络(CDN)。为了最小化延迟,检查点文件被分片并以流水线方式流式传输,允许推理工作节点在中继服务器上完整检查点可用之前就开始下载分片。中继服务器只保留最后五个检查点版本,以避免磁盘空间耗尽。这个限制在功能上也是可取的,因为使用过时检查点生成的rollouts通常会被拒绝或丢弃。
安全防护措施。我们使用nginx作为我们的HTTP服务器,因为它具有稳健性和广泛的行业应用。为了保护中继服务器免受可能发出过多请求的恶意推理工作节点的影响,我们为nginx服务器配置了基于IP的速率限制。此外,我们在中继服务器上动态配置UFW防火墙规则,仅接受来自计算池中已知的、当前活跃的推理节点的流量。这减少了攻击面,并使我们能够在检测到行为不当的节点时迅速将其列入黑名单。
负载均衡策略。如果每个客户端总是选择最快的中继服务器,将会导致竞争和带宽抖动。为了缓解这个问题,客户端会根据从每个中继服务器请求的预期吞吐量,从一组中继服务器中进行抽样。
具体实现。我们的实现首先让每个客户端从所有中继服务器请求一个虚拟文件,以初始化带宽和成功率的估计值。然后,客户端根据以下比例选择服务器:
预期吞-吐量 ∝ 成功率 × 带宽
这些估计值通过指数移动平均(EMA)不断更新,这既能平滑瞬时波动,又能对实际变化保持响应。EMA中还包含一个“修复因子”,以鼓励定期探索未充分利用的服务器,确保系统能有效适应不断变化的条件。
策略优势。即使在没有竞争的情况下,这种概率性抽样策略也优于贪婪地选择当前最快的中继服务器,因为它能够利用到不同中继服务器的多个连接,这些连接的总带宽将高于任何单个到中继服务器的连接。
必要性。推理节点如果提交了使用不正确模型权重生成的rollouts,将面临被惩罚的风险。为避免这种情况,确保只使用经过验证的、正确的权重进行推理至关重要。
完整性验证方法。为了确保模型权重的完整性,每个推理工作节点在从分片下载并重构检查点后,会计算组装后检查点的SHA-256校验和。然后,将此校验和与训练节点生成的参考校验和进行比较,参考校验和与检查点元数据一起广播到所有中继服务器。
错误处理。如果计算出的校验和与预期值不匹配,推理节点会丢弃损坏的检查点,并尝试下载下一个可用的检查点。我们避免重试同一个检查点,因为在检查点变得陈旧或无关紧要之前,重新下载不太可能完成。
关于P2P传输的考量。虽然验证下载分片完整性的机制可以实现无需信任的点对点(P2P)权重传输,但我们选择不为INTELLECT-2部署这样的系统。主要原因是将推理工作节点相互暴露会增加复杂性和安全风险。在P2P设置中,推理工作节点的IP地址将对等节点可见,需要额外的加固以防止池内的恶意行为或拒绝服务攻击。鉴于这些担忧,我们选择通过受信任的中继服务器来集中分发权重。
背景与方法。因为我们依赖于不受信任的计算节点进行推理,所以无法保证推理节点会忠实地执行推理。为了确保可验证的合规性,我们的验证器使用了几种检查:计算检查、抽样检查和数据健全性检查,我们将在以下各节中详细描述。
模型计算正确性证明。如图3所示,为确认推理是使用正确的模型权重执行的,每个推理工作节点都会为每个生成的序列生成一个TOPLOC证明【29,Toploc: A locality sensitive hashing scheme for trustless verifiable inference,22025】。这些证明作为解码过程中产生的最终隐藏状态的加密承诺。一个受信任的验证器节点随后使用预填充(prefill)重建这些激活,并与提交的承诺进行比较以确认一致性。使用TOPLOC生成的证明对GPU的非确定性、不同的张量并行配置具有鲁棒性,并且能够可靠地检测何时使用了量化或恶意的模型版本。
终止检查。生成的序列有两个有效的终止标准:达到模型的最大上下文长度或生成序列结束(EOS)标记。由于较长的序列会产生更大的计算成本,推理提供者可能会有动机提前终止序列。为防止这种情况,我们检查序列是否达到最大模型长度或以EOS标记结束。如果序列因生成EOS标记而终止,我们确保EOS标记的概率超过0.1,以防止通过不太可能的EOS生成进行操纵。
令牌抽样检查。从logits中进行适当的抽样应该产生一个类似于指数分布的分布,其众数在1附近。如果使用较小的模型生成令牌,而仅使用较大的模型进行预填充(以通过TOPLOC检查),则生成的分布会变为双峰,众数在1和0附近。我们检查logit分布以检测此类不一致性。
固定数据抽样。允许推理工作节点选择自己的样本可能导致挑选简单或已完成的示例。为防止这种情况,每个节点根据一个种子确定性地选择样本,该种子的计算方式为:seed = hash(step_number + node_address)。然后,我们通过从该种子重现抽样过程来验证是否使用了正确的样本。
值边界检查。所有报告的标量值——如奖励和优势——必须落在预定义的边界内,以确保它们是合理的并与预期结果一致。
Parquet格式检查。我们还确保parquet文件具有正确的模式,并且其格式可以被我们的训练数据加载器加载。这确保了我们不会接受任何会在训练器中引发异常的文件。
协议概述。Prime Intellect协议通过一个模块化的、去中心化的协调层来协调无需许可的节点。它赋予模型训练者检查所有节点健康状况、查看日志和分发新任务的能力,类似于一个去中心化的SLURM。整个代码库是开源的,可在GitHub上找到。
架构组成。如图4所示,该系统由多个组件组成,所有组件均用Rust实现。除工作节点和去中心化账本外,所有组件都托管在Kubernetes集群中。所有API端点均受Cloudflare保护。
去中心化账本(Decentralized Ledger)。去中心化账本用于存储有关当前训练运行、训练运行所有权以及工作节点贡献的信息。这些工作负载被组织成“计算池”,所有这些池都属于一个更广泛的“计算域”。每个计算域代表一类特定的人工智能任务——如预训练、合成数据生成、分布式强化学习等。账本维护每个池的详细信息,包括所有权细节和工作节点贡献。每个贡献者以及计算池所有者都有一个用于签署交易和证明所有权的加密地址,这保障了API交互的安全性并确保了计算资源的正确归属。
工作节点软件(Worker Software)。工作节点软件的核心任务是向中央协调器通信心跳和指标,并配置和管理本地Docker环境以执行任务。附加功能包括日志导出和运行中容器的重启能力,以及Docker容器本身与工作节点之间基于Unix套接字的连接。后者可用于触发工作节点软件上的操作,例如从Docker卷上传文件。
发现服务(Discovery Service)。发现服务是一个简单的API,允许节点上传工作节点元数据信息。它将这些数据存储在Redis数据库中,并允许其他授权组件(如协调器)检索已注册节点的信息。这确保了工作节点的IP仅对协调器可见,从而降低了拒绝服务攻击的风险。
协调器(Orchestrator)。协调器的核心任务包括分发任务和根据去中心化工作节点的心跳观察其生命周期。它使模型训练者能够通过Web API与基础设施进行交互,从而暴露有关所有当前活动节点的信息、一个用于创建和调度新任务的API,以及对每个节点的当前指标和日志的洞察。此外,由于每个节点上的容器可能会失败,每个节点的工作负载都可以重新启动。
节点注册与发现。计算贡献者在其机器上安装并启动工作节点软件。它会自动检测系统组件(GPU、可用RAM和存储)并检查其兼容性。还会执行额外的软件和连接上行检查,并在日志中告知用户任何可能使节点与训练运行不兼容的配置错误或系统问题。一旦系统硬件和软件确认无误,节点会自动将其元数据(包括硬件信息和IP)上传到发现服务。同时,节点还会向去中心化账本发送注册调用。成功注册后,工作节点启动一个Web服务器并等待邀请——这一安全措施确保工作节点无需预先知道协调器的端点,从而保护协调器免受潜在的拒绝服务攻击。协调器会定期检查发现服务以寻找新创建的节点,并向工作节点的HTTP服务器发送邀请以开始贡献。此邀请包含一个加密签名,该签名结合了节点的地址以及当前计算池的ID和域。该邀请在去中心化账本上进行验证,使工作节点成为活跃的计算贡献者。发送邀请后,协调器将节点信息存储在本地Redis存储中,并等待传入的心跳。
节点健康与心跳。每个节点都维持一个持续的心跳循环,以保持与协调器的通信。这些心跳作为从节点发送回协调器的简单信号,使其能够跟踪节点是否仍然活跃。协调器将这些心跳存储在Redis中并设置过期时间,因此可以自动检测节点何时停止响应。一个单独的状态更新循环通过计算丢失的心跳来定期检查每个节点的健康状况。如果丢失了太多心跳,该节点将被标记为死亡,其工作节点将从去中心化账本中移除。如果节点重新上线,它会尝试重新注册并更新发现服务,以便可以被重新邀请回池中。
任务调度与执行。任务由协调器通过POST API创建,并异步地在所有健康节点之间调度。协调器不是推送任务,而是在响应节点的心跳请求时分发它们,这实现了一种反应式且容错的拉取式模型。一旦收到任务,工作节点会与Docker守护进程通信,将任务规范转换为一个运行中的容器——这包括设置卷、管理容器生命周期以及应用特定于任务的设置,如环境变量和自定义启动命令。开发过程中的一个关键见解是引入了一个共享卷,用于存储持久性数据,如模型权重。没有这个共享卷,重启任务会触发冗余下载,减慢执行速度并增加资源使用。
推理验证。如图5所示,推理工作节点将生成rollouts并使用签名的URL将其上传到远程文件夹。然后会生成一个链上事件,触发验证器开始对新文件进行验证。根据第2.3节中描述的检查结果,文件被接受或拒绝。接受的文件随后被训练节点的数据加载器读取。被拒绝的文件会导致创建它们的节点被惩罚(slashed)并从计算池中驱逐。
中心化与去中心化。协调器和发现服务目前是中心化的,这简化了协调工作,但也造成了潜在的单点故障并限制了水平可扩展性。这种设计还引入了信任假设,可能不适用于更分布式或无需许可的环境。为了解决这个问题,我们计划转向使用分布式哈希表(DHT)的完全点对点架构,这将消除对中央协调的需求,并实现更具弹性的、去中心化的节点发现。
部署环境限制。另一个关键限制在于工作节点的部署方式。目前,它只能在裸机或可直接访问Docker守护进程的虚拟机上运行。这排除了像Kubernetes这样的环境,在这些环境中,对Docker的访问被抽象化或不可用。为了解决这个问题,我们正在开发一个可以作为容器本身运行的工作节点版本,使其与容器编排平台兼容。
INTELLECT-2的目标是训练一个在数学和编码领域具备推理能力的模型。此外,我们旨在通过允许用户在任务提示中指定所需的思考token数量来控制模型的思考预算。我们使用QwQ-32B【40,Qwq-32b: Embracing the power of reinforcement learning,2025】作为基础模型,并主要遵循Deepseek-R1【9,Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning,2025】基于GRPO和可验证奖励的训练方法。
在本节中,我们将详细描述我们的RL配方以及导致该配方的消融实验,内容涵盖从训练数据和奖励函数实现到对原始GRPO目标的修改以提高训练稳定性。
双重目标训练。我们使用双重目标训练INTELLECT-2:我们既包含了鼓励模型提高其在数学和编码任务上推理能力的任务奖励,也包含了长度奖励,以便教会模型遵守提示中提供的思考预算。
数据集构成与来源。遵循现有的最先进开放推理模型【9,Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning,2025】、【40,Qwq-32b: Embracing the power of reinforcement learning,2025】,我们整理了一个由数学和编码任务组成的训练数据集,这些任务可以通过符号验证/字符串匹配和单元测试执行来验证。为此,我们从NuminaMath-1.5【18,Numinamath,2024】和Deepscaler【24,Deepscaler: Holistic autoscaling for microservices based on spatiotemporal gnn with adaptive graph learning,ASE 2023】中选择了高质量的数学问题,以及先前为SYNTHETIC-1【22,SYNTHETIC-1 Release: Two Million Collaboratively Generated Reasoning Traces from Deepseek-R1,2025】整理的编码任务,这些任务也曾用于DeepCoder【20,Deepcoder: A fully open-source 14b coder at o3-mini level,2025】等先前工作中。我们的完整数据集包含28.5万个任务,包括2.6万个基于python的算法编码挑战和25.9万个数学问题。该数据集可在Huggingface上找到。
奖励函数设计。我们的数学和代码奖励函数都实现了二元奖励,正确响应赋值为1,错误响应赋值为0。虽然这对于数学任务来说是显而易见的选择,但我们明确不对通过部分(但非全部)单元测试的编码问题给予部分奖励,以阻止奖励 hacking(例如,通过记忆公共测试用例)。
实现思考预算控制。除了解决任务的奖励外,我们还加入了长度奖励,使用户能够在任务提示中指定INTELLECT-2的思考预算;在此,我们主要遵循L1【1,L1: Controlling how long a reasoning model thinks with reinforcement learning,2025】的方法。
总奖励计算公式。具体来说,对于训练批次中的每个问题,我们采样一个目标长度$l_{target}$,并通过模板“Think for $l_{target}$ tokens before giving a response.”将其包含在我们的提示中。随后,一个表示实际响应长度与目标长度之差的长度惩罚,乘以一个权重因子$\alpha$,与任务奖励相结合。设$y$为给定提示的模型输出,$l_y$为其token长度,$r_{task}$为任务奖励函数,则总奖励可计算如下:
$$r_{\text {total }}\left(y, l_{\text {target }}\right)=r_{\text {task }}(y)-\alpha *\left|l_{\text {target }}-l_{y}\right|$$与L1方法的区别及验证。与L1的设置不同,L1中的$l_{target}$是从一个连续范围内均匀采样的,我们从一个小的离散目标长度集合(例如,2000, 4000, 6000 tokens)中采样,以简化目标并使我们的模型更容易学习。为了验证这种方法,我们使用500, 1000, 2000和3000的目标长度以及4000的最大序列长度复现了L1。
异步RL的采用。如第2节所述,我们使用异步强化学习来利用专用的推理和训练节点,以最小化GPU空闲时间。这种方法在先前的工作中【13,Cleanba: A reproducible and efficient distributed reinforcement learning platform,2023】、【28,Asynchronous rlhf: Faster and more efficient off-policy rl for language models,2025】已被证明是有效的,并且也被用于大型LLM训练,如Tülu 3【17,Tulu 3: Pushing frontiers in open language model post-training,2025】和Llama 4【38,The llama 4 herd: The beginning of a new era of natively multimodal ai innovation,2025】。
去中心化异步RL的特点。在具有快速连接速度的中心化异步RL训练设置中,专用训练节点上更新的策略权重会同时用于获取下一个RL步骤的rollouts。而在去中心化设置中,更新后的策略权重不能立即提供给推理工作节点,因为权重广播需要时间,这就是为什么我们使用不是上一步,而是两步或更多步之前的权重来执行rollouts,具体取决于权重广播的持续时间。图6中可以找到这些差异的图形化概述以及与同步RL的比较。
异步RL的有效性验证。在开始INTELLECT-2训练运行之前,我们进行了消融实验以验证异步RL训练不会损害我们模型的性能。为此,我们使用2048个token的上下文长度复制了Deepscaler对DeepSeek-R1-Distill-Qwen-1.5B的同步RL训练运行结果,并将其与基于PRIME-RL的不同异步程度的异步RL进行了比较。这些运行的结果可以在图7中找到。
实验结论。如图表所示,即使异步程度高达四步,我们模型的奖励轨迹也与同步基线的轨迹相匹配,这表明在略微离策略的数据上进行训练不会损害RL训练的性能。
数据过滤的重要性。在我们的消融实验中,我们发现根据难度过滤我们的数据集对训练性能有显著影响。我们在开始训练运行前采用离线过滤,并在训练过程中采用在线过滤来选择性地从我们的rollouts中挑选训练样本。
过滤效果的发现。在尝试使用Deepscaler数学数据集【21,Deepscaler: Surpassing o1-preview with a 1.5b model by scaling rl,2025】训练DeepSeek-R1-Distill-Qwen-7B时,我们发现从训练集中过滤掉太容易或太难的问题至关重要。如图8所示,在原始数据集上训练时,我们的奖励几乎没有提高。在过滤掉基础模型pass@8率高于50%和低于12.5%的问题后,奖励显著提高。因此,我们也使用DeepSeek-R1-Distill-Qwen-7B来预过滤我们用于INTELLECT-2的训练数据集。
在线过滤的动机。像GRPO【35,Deepseekmath: Pushing the limits of mathematical reasoning in open language models,2024】和RLOO【15,Buy 4 REINFORCE samples, get a baseline for free!,2019】这样的训练算法依赖于基于组的相对奖励来计算优势。如果单个问题的所有完成都获得相同的奖励(对于二元奖励,要么是0要么是1),这意味着所有这些样本的优势都为零,除了KL或熵损失等辅助损失外,没有提供训练信号。
在线过滤的实现与优势。为了缓解这个问题,我们采用在线过滤,并继续从我们的推理工作节点中采样响应,直到我们有一个完整的、具有非零优势的样本批次,然后才执行训练步骤。这样做很方便地增加了每个训练步骤需要执行的推理量,使我们能够接纳和利用更多的去中心化推理节点。
训练不稳定的问题。在训练过程中,我们面临损失和由此产生的梯度范数尖峰,这些尖峰导致了不稳定性,甚至模型崩溃,尤其是在我们的模型变大时。经检查,我们发现不稳定的一个主要原因是GRPO和类似PPO【34,Proximal policy optimization algorithms,2017】的训练目标中采用的单边令牌概率比率裁剪。
原始GRPO目标的问题。回顾原始的GRPO目标:对于每个提示或问题$q$,GRPO从旧策略$\pi_{\theta_{old}}$中采样一组输出${o_1, o_2, ..., o_G}$,并根据它们在该组中的相对奖励计算优势。不含KL惩罚的优化目标由下式给出:
$$ \mathcal{J}_{\text{GRPO}}(\theta) = \mathbb{E}_{q \sim P(Q), \{o_i\}_{i=1}^G \sim \pi_{\theta_{\text{old}}}(O|q)} $$其中$\hat{A}{i,t}$表示每个采样组内的优势,$\epsilon$是用于裁剪令牌概率比率以避免过大损失值和梯度更新的参数。请注意,在负优势值的情况下,由于min操作,此裁剪将不被应用,因为鼓励进行大的更新以使策略远离不良的rollouts【34,Proximal policy optimization algorithms,2017】。然而,如果$\frac{\pi\theta(o_{i,t}|q, o_{i,<t})}{\pi_{\theta_{old}}(o_{i,t}|q, o_{i,<t})}$取值很大,这可能会导致巨大的损失值和梯度更新。
改进的GRPO目标。为了缓解这个问题,我们引入了一个额外的超参数$\delta$,在负优势的情况下为令牌概率比率增加了一个上限:
$$\mathcal{J}_{\text{GRPO}}(\theta) = \mathbb{E}_{q \sim P(Q), \{o_i\}_{i=1}^G \sim \pi_{\theta_{\text{old}}}(O|q)} \left[ \frac{1}{G} \sum_{i=1}^G \frac{1}{|o_i|} \sum_{t=1}^{|o_i|} \left[ \min \left( {\color{red}\min} \left( \frac{\pi_{\theta}(o_{i,t}|q, o_{i,<t})}{\pi_{\theta_{\text{old}}}(o_{i,t}|q, o_{i,<t})}, {\color{red}\delta} \right) \hat{A}_{i,t}, \text{clip} \left( \frac{\pi_{\theta}(o_{i,t}|q, o_{i,<t})}{\pi_{\theta_{\text{old}}}(o_{i,t}|q, o_{i,<t})}, 1-\varepsilon, 1+\varepsilon \right) \hat{A}_{i,t} \right) \right] \right]$$ <p>$\delta$的值应高于$1 + \epsilon$,以便仍然允许进行大的更新以远离不良的rollouts,但避免出现一百或更高的巨大令牌概率比率。通过这一改变,训练稳定性显著提高,正如在同期工作【25,Minimax-01: Scaling foundation models with lightning attention,2025】中也报告的那样。大规模训练中的新挑战。虽然上述双边GRPO裁剪机制显著减少了大的损失和梯度尖峰,但在使用更大模型时,我们观察到了其他类型的训练不稳定性。这些不稳定性与大规模预训练中遇到的问题有相似之处【43,Small-scale proxies for large-scale transformer training instabilities,2023】、【5,Palm: Scaling language modeling with pathways,2022】、【26,A theory on adam instability in large-scale machine learning,2023】、【6,Adaptive gradient methods at the edge of stability,2024】。
梯度范数不断升级。随着训练的进行,我们观察到梯度范数逐渐但持续地增加,即使在没有即时尖峰的情况下也是如此。这一现象似乎与模型大小相关,如9a所示,在我们的较大架构中变得更加明显。与【43,Small-scale proxies for large-scale transformer training instabilities,2023】中的发现类似,我们发现梯度范数的增长往往先于更严重的不稳定事件,是潜在训练崩溃的早期预警信号。
梯度裁剪作为缓解措施。我们发现,采用激进的梯度裁剪(阈值低至0.05-0.1)能有效缓解稳定性问题,而不会显著阻碍收敛,从而在稳定性和训练效率之间提供了一个有利的权衡。虽然这种方法不能完全消除不稳定性问题,但它显著延迟了梯度增长阶段,并推迟了潜在的稳定性崩溃,延长了我们模型的有效训练期。激进的梯度裁剪也已在同期训练QwQ-32B的工作中成功应用【2,Multi-turn training for cuda kernel generation】。
令牌概率裁剪比率升级。除了梯度范数和熵的不稳定性,我们还观察到在训练过程中令牌概率裁剪比率持续增加,如图9b所示。这种增加与梯度范数的上升直接相关,因为裁剪比率有效地跟踪了连续优化器步骤之间logits的差异。
熵损失模式。在训练过程中,我们发现了一个独特的熵损失模式,如图10所示。在最初下降后,熵损失开始再次呈上升趋势。这种熵的复苏通常预示着灾难性的训练失败,导致模型完全崩溃。增加KL惩罚的权重因子能够延迟这种崩溃,但也会导致学习变慢,因此不是一个有效的缓解策略。
QwQ模型的不稳定性。我们注意到,在QwQ之上进行训练的稳定性比DeepSeek-R1-Distill-Qwen-32B差,尽管两者都基于相同的预训练模型(Qwen 2.5)。我们推测这种差异源于QwQ已经经历了一个使用可验证奖励的强化学习阶段。这种先前的RL训练似乎使模型更容易受到后续优化不稳定性的影响,这表明模型在经过多轮奖励优化后,可能会变得越来越难以稳定地进行微调。
torch.compile导致的不稳定性。我们观察到,使用torch.compile导致了我们训练后期阶段的灾难性崩溃,无论我们的模型大小如何(见图11)。尽管问题可能源于torch.compile生成的单个有问题的内核,我们最终决定在整个代码库中禁用它以确保训练稳定性。这个决定带来了内存使用略有增加的代价。
在为期两周的时间里,我们使用我们的设置运行了多次训练,该设置包括一个受信任的训练集群和验证器节点,以及不受信任的、社区贡献的异构推理工作节点。在本节中,我们报告了我们进行的实验以及相应的结果。
模型:
数据集:
训练配置:
硬件配置:
软件配置:
我们报告了两个主要实验的结果:TARGET-SHORT,这是一个目标长度为{1000, 2000, 3000, 4000}的实验性运行,旨在训练一个高效的推理模型;以及TARGET-LONG,这是我们的主要运行,目标长度更长,为{2000, 4000, 6000, 8000, 10000}。
计算资源利用率:
奖励轨迹 (见图12):
分布式训练的必然性。随着近年来大语言模型计算需求的数量级增长,跨数据中心的分布式训练变得越来越重要。除了为协作式开源开发提供一条经济上可持续的路径外,训练这些模型所需的纯粹计算能力和能源很快将超过世界上最大的数据中心。
新的扩展维度。到目前