长序列场景下"Qwen3-235B+verl+DAPO"RL后训练的昇腾调优实践
发表于 2026/01/09
强化学习（Reinforcement Learning, RL）已成为大模型训练与对齐过程中的关键核心技术，尤其在人类偏好对齐、推理能力强化、工具使用、智能体决策等前沿方向发挥着不可或缺的作用。业界开源的verl框架，凭借其在大模型 RL 领域的高泛用性脱颖而出，全面支持 PPO、GRPO、DAPO、SPPO、OPO 等主流算法。而基于 NPU 硬件平台的verl强化学习训练性能优化，也成为了广大开发者高度关注的焦点，本文介绍在昇腾NPU上，基于verl框架对 Qwen3-235B-A22B-Thinking-2507 模型开展 DAPO 强化学习后训练，在长序列场景下的性能调优实践。
MoE模型长序列场景下的RL挑战
模型挑战
（1）算力“木桶效应”：由于长序列导致的计算延迟
MoE模型涉及长序列：通常长序列（如 128k 或 256k）包含高度连续的逻辑或特定主题（如一份超长的代码文件或法律合同）。Qwen3-235B-A22B-Thinking-2507 作为 2025 年 8 月开源的千问系列模型，其在长上下文理解能力升级：将上下文窗口拓展至 256K，可更好地处理长文本输入。长序列训练是构建高性能大语言模型的核心技术之一。它能够帮助模型突破短上下文的局限，有效捕捉文本的全局结构与长距离依赖关系，进而显著提升模型在复杂长文本理解、深度推理、连贯生成等场景下的性能，已成为当前大语言模型技术竞争的关键赛道。可以说，长序列训练能力是衡量现代大语言模型核心实力的重要指标，尽管该技术面临着严峻的计算与工程挑战，但相关技术的快速迭代正在持续突破序列长度的上限。
MoE 模型在处理每个 Token 时，Router（路由器）会将 Token 分配给特定的专家。这种内容的高度局部性会导致某些特定领域的专家（Expert）被频繁调用，而其他专家处于闲置状态。在并行计算中，整组集群必须等待最慢的那个“繁忙专家”完成计算。由于长序列的 Token 数量庞大，这种等待时间会线性累积，导致整体计算吞吐量（MFU）大幅下降，甚至出现严重的流水线气泡（Pipeline Bubble）。
（2）“专家崩塌”与训练不稳定性 (Expert Collapse)
在强化学习过程中，如果模型发现某几个专家在处理长逻辑推理时效果较好，Router 就会倾向于给这些专家分配更多 Token。这会导致“专家崩塌”——即只有少数专家得到了充分训练，而大部分专家（235B 总量中的绝大多数）变得平庸化、未被激活。对于 Qwen3 而言，这会直接削弱其作为 MoE 模型本应具备的“专家深度”，使其退化为一个实际容量更小的模型。
（3）显存压力与通信开销的权衡 (Memory vs. Communication)
Qwen3-235B 的显存占用极高，即便激活参数仅 22B，但全量 235B 的参数仍需常驻显存。首先会有显存占用高，在长序列 RL 训练中，需要同时保存策略模型、参考模型、奖励模型和价值模型。即使使用
verl 的价值等效优化，在 128K上下文下，KV Cache 也会消耗惊人的空间。其次通信开销大，MoE 依赖 All-to-All 通信来交换专家间的 token，这个过程被称为EP通信，在 235B 的参数规模下，这种全局通信的开销可能占到训练时间的 30%-50%，严重抵消了稀疏激活带来的计算加速。
RL强化学习挑战
RL强化学习流程复杂，在特性优化的同时，需要兼顾端到端流程功能保持正常、整体性能不下降以及精度效果达标，主要面临以下问题：
(1) RL训练端到端跑通挑战大：RL涉及多个流程且指标需对齐，优化改动可能牵一发可能动全身。首先RL涉及Rollout、Reward、Advantage、UpdateActor等多个流程，任何优化修改最后均需端到端跑通验收；其次全流程验收难，对齐业界设备的验收至少端到端跑完一轮甚至多轮，耗时在3h起步（一轮），导致在特性开发验证、性能验收耗时耗资源，全流程验收比较困难；另外，Rollout、Reward等各阶段涉及不同的精度、性能指标，以及整体性能和下游任务效果，且需与业界设备对齐。其中特别精度问题，任何优化修改均有可能引起精度问题，最终集成端到端验收时发现精度，需要大量工作返工排查分析，以及重新修改适配。
(2) 训推异步分离暂不可用：首先，DAPO算法是on-policy策略，训推异步并不一定适用，精度可能存在影响；其次，项目启动阶段verl框架对于One Step Off Policy Async Trainer 和 fully async 特性暂不支持；另外，训推异步对于适配工作量与资源利用率收益并无实际的验证结果，结果不确定性对于项目实际交付挑战较大。
(3) 量化手段不可用：RL 推理阶段（ Rollout ）需要采用bf16高精度权重，保持训练精度，量化等关键推理优化手段无法使用。
(4) 训推强耦合：verl框架共卡模型，训练与推理同进程，部分优化参数（ HCCL_BUFFERSIZE 、PYTORCH_NPU_ALLOC_CONF、TASK_QUEUE_ENBALE等）与特性（绑核、内存回收等），会形成相互干扰。
RL长序列场景下的昇腾优化方案和实验结果
显存申请碎片问题优化，降低内存峰值约5G
问题说明：
因为无法开启torch的虚拟内存优化技术，verl在compute_log_prob和update_actor阶段申请的显存由于显存碎片化导致在物理上地址非连续，因此部分显存无法被即时释放。随着时间推移，无法被释放的显存堆积，最后导致推理侧OOM的问题。
现象说明：
以Qwen3-30B为例，从rollout结束到完成compute_log_prob后，显存占用一共增加了3.74 + 1.07 = 4.81GB，而显存只释放了4.26GB，可以看到有4.81 - 4.26 = 0.55GB显存没有被释放，因此推断Qwen3-235B对应有7-8GB的显存没有释放。
优化方案：
设置了max_split_size_mb参数，大于该设定值的内存块在使用过程中不会被切分，有助于减少内存碎片。测试了1GB, 2GB, 6GB等参数设置。可以看到和不设置该环境变量相比，前3步每步可以节省大约500MB到1GB左右的显存占用。
完整数据不提前加载到NPU，dataloader取数据时再加载所需数据，能有效降低device内存峰值约5G和缓解内存碎片问题，该修改已原生合入verl
显存优化合入verl社区的PR链接：
PR链接1：https://github.com/volcengine/verl/pull/3051/
PR链接2：https://github.com/volcengine/verl/pull/3227
使用MC2融合算子，单步时长减少6.7%
问题说明：
前期为了不阻塞功能调测和精度对齐，是先切换使用all2allv方案，精度对齐后，为了提高rollout性能使用MC2算子提高性能，使用MC2算子16机器拉起验证时稳定复现MoeDistributeDispatchV2_ND_ND_BF16_BF16_high_performance_10000，算子超时报错问题。
现象说明：
这个算子作用是混合专家模型（MoE）分布式张量分发通信算子，其实现目的为多节点间的专家权重的动态分配与高效通信。该算子需要等到所有节点的所有device都处于同一状态才会继续往下进行计算。如果整个集群有一张卡未进行通信，则所有卡会同时间等待18分钟。当前我们部署是双实例，所以在16机情况下，每个实例有8机64卡，我们使用pystack的方式重新抓取每张卡的pystack日志，逐一进行分析，其中有1个实例的7个节点都报了16个算子超时错误。只有一个节点--节点10，中的两张卡为出现算子超时报错，这两张卡的栈日志在报算子超时错误前5分钟卡死在了ALL2ALL通信算子处
至此我们可以大概率确定问题出现在推理时PD混部时，有两张卡在general-sqe阶段走了all2all通信算子造成的。由于all2all通信算子和mc2通信算子并不能进行算子间的相互通信，最终会导致mc2在单个实例内一直缺少两张卡的通信信息导致剩下62张卡出现超时现象。
解决方案：
通过给MC2单独起了一个通信域来避免避免发生DP混部时造成通讯错误。
合入社区的PR链接：
https://github.com/vllm-project/vllm-ascend/pull/1711/
https://github.com/vllm-project/vllm-ascend/pull/1831
测试结果：
从单步时长来看。未使用mc2方案第一步时长为6400s，使用mc2方案第一步时长为6000s，总体性能提升6.67%。
数据负载均衡(Databalance)，性能提升1倍
问题说明：
30B 16机在长跑时出现HCCL 通信超时，定位到不同vLLM推理实例完成时间存在较大差距，超过2小时，导致推理结束后实例间统计数据时超时
现象说明：
verl框架原生实现中，Rollout阶段之前的数据重复逻辑默认是按照序列顺序（interleave=True），比如在prompt 列表 [p1, p2, p3]，生成 2 responses（n=2）时，生成的数据顺序为[p1, p1, p2, p2, p3, p3], 同一个prompt连续出现会被分配到同一个实例处理，这样就会导致难题堆积在相同实例处理超时。
优化方案：
引入Databalance特性，将数据重复逻辑改为按序列交错(interleave=False)，对于 prompt 列表[p1, p2, p3]，生成 2 responses（n=2）时生成的数据顺序为[p1, p2, p3, p1, p2, p3]，这样同一个难题的prompt会被分布到不同实例。
测试结果：
在Qwen3-235B，2推32k情况下，3个小时减少到1个半小时，性能提升一倍。
大规模专家并行（Large-scale EP），端到端性能是业界设备的2倍
问题说明：
昇腾大规模专家并行方案在强化学习的推理阶段也能够系统级的优化支持更大吞吐，更低decode时延，提升性能
测试结果：
Qwen3-235B 专家数量为128，在设置了EP为128情况下, 2k推34k，开启think模式，输出平均长度20-25k，dapo filter 平均推理5轮， gbs 128 推 16，16机，单step后期约12小时。
业界设备和NPU都不开EP，e2e性能约0.8x，NPU单独开EP，端到端性能约2.0倍以上业界设备。
长序列master节点内存优化，消除内存OOM问题
问题说明：
verl在update阶段会有数据collect操作，32机在2推64K情况下，会出现master节点OOM问题。
现象说明：
当内存不足时，ray的处理机制有两种：
（1）当对象的引用次数为1时，ray会触发spill机制，使用磁盘辅助申请临时空间；
（2）当对象的引用次数不为1时，ray不会触发spill机制；
而old_log_probs、entropy对象在work节点和master节点都有引用，这就导致会全部使用CPU内存，而此时容器内存2T，这就导致在64K，32机场景下会申请超过2T的内存，这个时候就OOM了。
在这个情况下CPU内存的的计算我们通过源码将内存计算简化为length * gbs * rollout.n * world_size * (old_logp, entropy) * fp32，通过这个公式可以计算出64k，GBS512，rollout.n=16, 32机情况下占用用的内存64* 1024 * 512 * 16 * 512 * 2 * 4 / (1024 * 1024 * 1024)=2T。
当序列长度升至64K以上时，verl原生即存在master节点内存溢出问题，verl社区没有充分验证235B+长序列+大规模集群场景。为了解决这个问题，我们是通过修改GBS 为 256来减少内存占用。
测试结果：
在输入64K情况下，GBS设置为256， 128K情况下GBS设置为64，能够保证master节点内存满足要求，以下是测试的结果
结语
在强化学习后训练中，短推长场景下性能瓶颈确实已经从单纯的计算开销转向了显存容量限制（Memory Bound）与计算长尾效应（Tail Latency/Load Imbalance），针对显存进行优化是一大方向，另外性能低的另一个重要原因是负载不均，观察显存可以发现推理过程中大多数卡都推完的情况下，只在等少数卡完成推理，造成了大量的拖尾时间，后续对强化学习的优化手段也主要从这两个方向出发。
为应对长序列场景下的强化学习后训练的诸多挑战，多机长序列场训练景下verl的master节点内存当前的解决方案是通过修改GBS大小来减少内存占用，若不愿意修改GBS，可以通过实现Transfer Queue，主控和worker间传递ref，worker间点对点传输。昇腾联合verl社区共同设计开发“Transfer Queue异步高性能流式数据引擎”[1]等技术，解决大规模集群长序列下（128K 64机）内存OOM问题，同时优化传输速率，扩宽verl在实际场景中的应用范围。
了解和体验更多昇腾强化学习技术，欢迎通过以下方式进行讨论：
https://mp.weixin.qq.com/s/TnilRFlpGQkfGQFBDX-wYw
昇腾开源微信小助手：ascendosc
[1]- Transfer Queue异步高性能流式数据引擎开源仓：https://gitcode.com/Ascend/TransferQueue
[1]- Transfer Queue相关论文：https://arxiv.org/abs/2507.01663