veRL携手FlagOS推出硬件插件，打通RL后训练多硬件适配

这波大模型迭代里，RL后训练已经从“可选项”变成了“必选项”。不管是做推理增强还是Agentic RL，让模型通过和环境交互来改善策略，几乎都得在预训练之后再接一段强化学习。但你真上手跑过就会发现，RL后训练对底层训练框架和硬件的折磨，跟预训练完全不是一个画风。字节开源的veRL能在这一两年里快速被圈里人认可，靠的是把这套循环拆成了多引擎协作，在吞吐和灵活度上做了平衡。可veRL早期和大多数高性能训练框架一样，深度绑定NVIDIA GPU生态。这次veRL和FlagOS技术协同，推出verl-hardware-plugin，核心目标就是打通RL后训练的多硬件适配能力。这篇文章我从工程角度拆一下：它到底解决了什么问题，插件接口大概长什么样，怎么把你手头的RL训练任务迁移过去，以及会踩到哪些坑。适合正在研究veRL源码、或者手里有非NVIDIA加速卡集群想上RL后训练的同学。

1. RL后训练为什么比预训练更挑“硬件适配”

1.1 预训练和RL后训练是两种完全不同的计算形态

先把话说清楚：预训练和RL后训练在计算形态上差别非常大。预训练跑的是定长的稠密Transformer层，前向、反向、梯度同步，节奏稳定，只要并行策略和通信拓扑设计好，吞吐基本可以稳步推到很高。而RL后训练是“一个多进程协作的实时系统”：策略模型要不断做rollout采样，采样结果要交给reward模型打分，打分结果要攒成batch喂回策略更新。

这个过程里，加速卡不只是做张量计算，还要服务推理采样、KV cache管理、动态batch、多轮交互。veRL之所以受欢迎，就是因为它把这条链路上的几个角色拆成了专门的引擎：rollout引擎负责生成经验、reward引擎负责打分、actor引擎负责更新策略。引擎之间通过共享内存和异步队列交换数据，整个系统更像一个围绕模型展开的数据工厂，而不是单纯的矩阵乘法工厂。

但问题也恰恰出在这儿：任务形态越复杂，对底层硬件的依赖就越深。采样阶段需要低延迟的推理算子，更新阶段需要高吞吐的训练算子，两个阶段还会争抢显存和通信带宽。如果框架和硬件绑定死，换一块新加速卡，意味着这些算子、通信库、显存管理策略几乎全要重新适配。

1.2 “写一套代码，到处跑”为什么这么难

很多不做底层的人会想：不就是换个芯片嘛，上面都有编译器，不是能跑PyTorch就行？实测根本不是这么回事。PyTorch在一张新加速卡上能跑通，只代表tensor运算能出结果。到了RL训练这个规模，你要面对的是三个层面的适配问题。

• 算子层面：FlashAttention、MoE、各种fused kernel在NVIDIA生态下有大量手工优化版本，换到新硬件，要么厂商提供等价算子，要么你得退回到naive实现，性能直接断崖。
• 通信层面：NCCL是NVIDIA生态的集体通信库，all-gather、reduce-scatter机制在别的加速卡上有各自的实现，它们的拓扑感知、消息调度行为都不一样。
• 调度层面：FSDP的sharding策略、Megatron的tensor并行，都需要和具体的设备拓扑、显存大小、高速互联带宽深度耦合。一个参数不对，性能能差出好几倍。

veRL本身选择的是FSDP和Megatron混合并行，FSDP负责算法灵活度，Megatron负责高吞吐训练。这个混合结构一开始就是按CUDA生态调优的，要做多硬件适配，不能简单把CUDA替换成别的SDK，得在框架层留出“可变点”，再针对每个硬件的特性去实现。

1.3 FlagOS在协同里的位置：给加速卡一个“统一资源视图”

FlagOS这个项目的思路，圈子里听到的定位是“AI基础设施的操作系统层”。你可以把它类比成Linux的设备模型：应用不直接操作各种外设硬件，而是通过统一的设备节点和驱动接口访问能力。FlagOS要做的，就是把不同加速卡的计算单元、显存、通信链路抽象成标准化的资源描述和能力接口。

这恰好补上了veRL这类训练框架最缺的一环。框架开发者不需要为每一款加速卡单独写一套底层适配，而是面对FlagOS提供的统一接口。硬件厂商只需要在FlagOS这套体系里实现自己的驱动和算子库对接，上层框架就能“看见”并调度这些硬件。verl-hardware-plugin的名字说明了一切：它不是把veRL改写成一个多硬件分支的大杂烩，而是用插件机制把“非NVIDIA加速卡”的实现挂载到veRL的既有执行路径上。

提醒一句：下面关于插件接口的一些命名和流程细节，是根据这类插件架构的工程惯例做的推演，具体以仓库文档和实际版本为准。工程方向不变，细节各家会有出入。

2. verl-hardware-plugin的架构拆解：到底把什么“插件化”了

2.1 核心设计原则：算法层与执行层解耦

你要理解verl-hardware-plugin，得先看veRL的代码分层。最上层是RL算法层，比如PPO、GRPO的实现，负责计算advantage、更新策略；中间是数据流和状态管理层，负责rollout经验的处理和buffer管理；底层是设备执行层，负责真正的tensor计算、显存管理和分布式通信。

veRL原来的问题在于，底层执行层默认只认CUDA这一套生态。某种程度上这不是字节的问题，绝大多数高性能训练框架都这样，因为CUDA生态太成熟，开发时天然会先绑死一个平台。verl-hardware-plugin做的事情，就是在“中间层”和“设备执行层”之间切开一个明确的接口面，也就是常说的SPI。所有和硬件强相关的操作，插件通过实现这个SPI来挂载。

按这套插件架构通常的切法，主要会涉及这么几类接口：

只要这些接口在新硬件上被实现出来，veRL的RL算法和数据流逻辑不需要改动，就能把训练跑起来。这也是插件化最大的价值：算法工程师不需要关心某块加速卡底层长什么样，硬件工程师也不需要理解PPO的advantage怎么计算。

2.2 通信层是这副牌里最难啃的骨头

这几类接口里，我最想单独说的是通信接口。做分布式训练这些年，我见过太多“算子能用、通信崩盘”的案例。veRL本身对通信要求很高：FSDP的sharding需要频繁做all-gather和reduce-scatter，Megatron的tensor并行需要在关键Transformer层做通信，rollout阶段还有跨引擎的tensor和batch数据分发。

在不同硬件生态里，这些通信原语不是一个“函数改个名”就能对齐的。NCCL是基于NVIDIA的NVLink和PCIe拓扑做了深度调优的，消息调度、ring和tree算法选择都很讲究。别的加速卡厂商提供的集合通信库，底层互联拓扑可能是自研高速总路线，行为跟NCCL并不一致。verl-hardware-plugin在通信层的处理策略应该是：先定义一套veRL需要的集合通信语义，再通过FlagOS的抽象去适配各个硬件的实际实现。遇到实在对不齐的，宁可退化成多段朴素实现，也要保证语义正确，然后再针对具体硬件逐步做拓扑感知优化。

我特别想强调一点：通信适配千万不要一上来就追求性能对齐。先把语义跑对，再调性能。因为通信库的行为差异会导致死锁、hang、数据错位这类非常难查的问题，性能问题至少还能靠profile定位，死锁问题真的能让人怀疑人生。

2.3 与FlagOS协同的分工：框架管编排，FlagOS管能力

我理解这个协同的分工逻辑是这样：veRL扮演“懂RL的框架”，负责整个训练流程的编排、rollout生成、状态管理、checkpoint；FlagOS扮演“懂硬件的地基”，负责把加速卡暴露成统一的资源视图和原语集合；verl-hardware-plugin是两者之间的翻译层和实现层，它既要知道veRL某个接口调用背后是想干什么，也要知道FlagOS能提供什么能力，然后选择最高效的路径去完成。

这种分工比“每家硬件厂商给veRL提PR改代码”要可持续得多。硬件厂商不需要理解GRPO的baseline怎么设计，它们只需要在FlagOS这一层把自己的硬件能力暴露好；veRL社区也不需要为每款加速卡维护一份fork，只需要维护好SPI和插件的公共框架逻辑。说句实在话，AI infra发展到今天，这种“OS抽象”思路早晚要出现，因为AI硬件的多样性已经是长期事实，不是短期过渡状态。

3. 实操：把veRL训练迁移到非NVIDIA加速卡上的完整流程

3.1 先说清楚：这个流程能帮你省下哪些事

我写这节的目的，是让已经熟悉veRL在NVIDIA上跑的同学，能快速把手头那套PPO或GRPO配置迁移到别的加速卡上。先说边界：verl-hardware-plugin并不是让所有算子都能白嫖到极致性能，它解决的是“能不能跑、跑起来能不能收敛、性能能不能逐步调优”这三件事。如果一款加速卡本身的算子库和通信能力拉胯，插件只能保证不把框架层变成新的瓶颈，硬件层的差距是绕不过去的。

迁移前你要准备几样东西：一台或多台安装了目标加速卡驱动和runtime的服务器、Python环境（veRL一般要求3.10+）、PyTorch的目标硬件版本（这个很关键，后面细说）、以及FlagOS runtime和verl-hardware-plugin的安装包。

3.2 安装与初始化：三步踩通环境

第一步是装PyTorch的硬件适配版。这一条是很多初学者翻车的地方：如果你装的是标准PyTorch，它默认只认CUDA。目标加速卡通常有自己的PyTorch分支或插件包，比如通过FlagOS托管的torch后端，这步等于是给PyTorch换一个“设备后端”。装完之后，用torch.cuda.is_available()这类验证就不适用了，得用对应设备后端的is_available()，或者直接创建一个小的tensor，在设备间搬移一下看能不能跑通。

第二步是安装veRL和verl-hardware-plugin。veRL建议装到独立执行环境里，不推荐改源码式硬装。插件的安装一般是一条pip命令，装完后可以用插件自带的smoke test脚本验证：它会启动一个极小的PPO训练，在目标设备上跑几十步，确认前向反向、通信、checkpoint保存都能工作。

第三步是设置设备可见性和通信拓扑。这一步和NVIDIA上用CUDA_VISIBLE_DEVICES很像，但要注意不同硬件的设备编号规则和NUMA拓扑不太一样。在FlagOS体系里，一般会提供类似topo查询的工具帮你打印当前节点的设备拓扑，建议先跑一下，确认通信拓扑识别正确，再做后续并行策略配置。我见过有人跳过这步直接上大任务，结果一个8卡节点里4张卡走高速互联、另外4张走PCIe，集合通信拓扑识别错了，性能直接腰斩。

3.3 一个可复现的GRPO训练配置示例

为了让迁移过程有抓手，我贴一个示例配置，它在veRL的标准配置基础上做了最小改动。假设场景是做数学推理任务的GRPO训练，策略模型是7B规模。

# 训练配置关键片段（示意） model: path: /your/path/to/policy_model type: huggingface actor_rollout: strategy: fsdp tensor_parallel_size: 1 fsdp_config: sharding_strategy: FULL_SHARD mixed_precision: bf16 rollout_provider: type: custom backend: verl-hardware-plugin max_prompt_length: 1024 max_response_length: 2048 reward_model: type: rule_based # 数学任务用规则奖励，减少迁移期变量 algorithm: algo: grpo kl_coef: 0.04 trainer: max_steps: 600 global_batch_size: 64 lr: 1e-6

这个配置里最关键的一行是rollout_provider.backend，它告诉veRL：rollout阶段的采样和推理，不要走默认的CUDA路径，走插件的多硬件路径。tensor_parallel_size设成1是最保守的起步配置，先把功能跑通，再尝试加大。奖励模型我故意选了rule_based，这样迁移初期少一个模型加载的变量，出了问题更好定位。

启动命令和原生veRL差不多，只是额外指定插件环境变量：

python -m verl.trainer.main_generation_trainer \ --config_path ./my_grpo_config.yaml \ --plugin-version flagos-0.2 \ --device-type custom_accelerator

启动后建议先观察日志里的三个东西：显存占用曲线是否平缓、各rank的通信耗时是否均衡、rollout吞吐和理论算力估出来的参考值差距多大。这三个都正常，再放心跑长任务。

3.4 从GRPO扩展到Agentic RL的注意点

最近圈里很热的Agentic RL，和传统的GRPO在数据流上有本质区别：环境交互变复杂了，action可能是工具调用，observation要分多轮返回，reward也不再是单一规则能算完的。veRL这边已经有agentic RL的接口，但多硬件适配下，你要额外关注两个地方。

第一个是动态batch的显存峰值。Agentic RL的序列长度极度不稳定，工具调用可能让某几个样本的KV cache暴涨。在非NVIDIA卡上，显存管理的灵活性、碎片回收策略可能不如CUDA生态成熟，建议把max_response_length设保守一点，并且开启插件的显存预分配选项。第二个是rollout和actor引擎之间的数据搬运。工具调用的observation通常存在CPU侧，再拷回设备端，多硬件环境下这些搬运路径未必有NVIDIA平台那么好用，性能瓶颈可能藏在这里。建议用插件的profile工具看一下引擎之间数据通道的耗时，再决定是否加大预取batch。

4. 常见问题与排障实录

4.1 一启动就报“设备不支持/算子不存在”

这是迁移初期最最常见的报错。通常不是框架的问题，而是某个算子在目标设备上还没有对应实现。我排障的第一原则：先区分是veRL代码调用的算子，还是三方库引入的算子。把报错堆栈往上翻，看是attention还是transformers的某个模块，还是veRL自己的fused kernel。如果是三方库的算子，优先升级目标硬件版PyTorch或对应的算子库；如果是veRL自研算子，去检查插件是不是包含了这个算子的实现版本。还有一个土办法：暂时把attention后端从flash_attn切到eager，能快速确认是不是attention算子的锅。

4.2 训练能跑，通信耗时高得离谱

能跑但慢，一般是通信库的拓扑感知没生效。集合通信库需要知道当前节点里加速卡互联的真实拓扑，才能选对通信路径。插件通常会默认注册一个拓扑，但如果你在一个多机互联混布的集群上，默认拓扑很可能就是错的。排查起来很简单：用插件工具打印每个rank实际走的通信路径，再和硬件拓扑图对比。我见过最夸张的案例，all-gather耗时差了30倍，就是因为集合通信库把走自研高速总线的设备当成了普通PCIe设备来调度。

4.3 同样的配置，loss曲线和NVIDIA上对不上

精度对齐是迁移里最折磨人的事。多硬件场景下，浮点计算顺序、算子融合策略、reduce的精度都可能不一样，这在预训练里通常没什么事，但RL对策略更新很敏感，如果日志里KL或advantage的数值和NVIDIA上有系统性偏差，别怀疑是代码逻辑错了，先检查这三处：混合精度的缩放策略是不是一致、RMSNorm的eps是否被某个硬件SDK悄悄改过、通信库的reduce是否默认用了低精度。把它们逐一锁到和CUDA生态一致的配置，loss基本就能对齐。

4.4 显存峰值比NVIDIA高一大截

我遇到的情况是，非NVIDIA卡的显存分配粒度比CUDA大，导致碎片率偏高。veRL本身有KV cache复用和offload机制，但默认参数是按CUDA生态调的。迁过去之后，建议把KV cache的预分配比例调小一点，同时开启actor的activation checkpointing。还有一个细节：FSDP在非NVIDIA设备上的sharding粒度可能不一样，sharding_strategy可以先从FULL_SHARD退到SHARD_GRAD_OP，对比一下显存和吞吐的取舍，再决定要不要加回更激进的sharding。

5. 多硬件适配这件事，对RL训练基础设施的长期影响

5.1 插件化不是妥协，是让框架活得久的正确姿势

这次veRL和FlagOS的协同，技术上最值得关注的不是某个算子怎么实现，而是“框架-插件-OS”这种分工模式。训练框架的核心价值应该在算法、调度和数据流上，而不是绑死在某个硬件SDK上。把硬件差异隔离在插件层，意味着框架的迭代不必等硬件适配，硬件的升级也不必等框架改动。对团队来说，这还降低了一个隐性成本：你不再需要为了跑一款加速卡而维护一个长期偏离上游的fork。跟着上游版本走，插件层面的适配可以由专门团队或硬件厂商自己维护，这种模式会让训练框架的社区生态健康很多。

5.2 给正在选型团队的几条实在建议

如果你也在评估“要不要把RL后训练放到非NVIDIA加速卡集群上”，我建议按这个顺序做判断：先跑通一个最小PPO或GRPO任务，确认功能完整性；再用你的真实数据规模和模型尺寸压一轮，看吞吐和稳定性；最后重点盯通信和显存两个指标，因为它们是绝大多数迁移翻车的地方。不要一开始就追求把整条Agentic RL流水线搬过去，先把基础的RL循环跑稳，再加上工具调用、多轮observation这些复杂度。

还有一点提醒：RL后训练和预训练不太一样，它的瓶颈经常不在纯算力上，而在采样、reward计算、数据搬运这些“边角料”环节。所以评估时要看端到端的step时间，而不是单看某个引擎的吞吐。verl-hardware-plugin如果能把这些边角料环节的硬件适配也接住，对想用多硬件集群跑RL的团队来说，价值比单纯提升某个fused kernel的算力要大得多。

工作里我踩过的最深的一个坑，是拿到新硬件集群后，团队第一周全在折腾环境，第二周才开始跑真实模型，结果发现三维并行配置完全要重调。现在我的习惯是先花半天做一次全链路的minimal测试，把所有算子和通信路径都点亮，再开始正经调参。verl-hardware-plugin这套要是能把这半天再压缩成十分钟，那才是真正帮到一线的人了。