verl支持哪些后端引擎？FSDP/vLLM/SGLang全解析-开发者社区

verl支持哪些后端引擎？FSDP/vLLM/SGLang全解析

verl 不是一个“只跑得动”的训练框架，而是一个真正为生产级 LLM 后训练打磨的系统级 RL 工程平台。它的核心竞争力，不在于算法本身有多新，而在于它如何把算法、调度、计算和推理——这四股原本各自为政的力量，拧成一股高效、灵活、可扩展的合力。

其中最关键的一环，就是它对后端引擎的开放支持策略：训练归训练，推理归推理，各司其职，自由组合。你不必为了用 vLLM 做 rollout 就放弃 FSDP 的训练稳定性；也不必因为选了 Megatron 就被锁死在特定推理路径里。这种解耦设计，正是 verl 能在吞吐上实现 1.53×–20.57× 提升的底层原因。

本文将彻底拆解 verl 支持的三大类后端引擎：FSDP（训练主力）、vLLM（推理首选）和SGLang（推理新锐），不讲抽象概念，只说它们在 verl 中怎么装、怎么配、怎么协同、怎么避坑——全部基于真实配置、源码路径与运行逻辑。

1. 训练引擎：FSDP 是默认主力，Megatron 是超大规模选项

verl 的训练引擎层，负责模型参数更新、梯度计算与反向传播。它不自己造轮子，而是深度集成业界最成熟的分布式训练方案。目前官方明确支持两类：PyTorch FSDP和Megatron-LM。其中，FSDP 是绝大多数用户开箱即用的首选，而 Megatron 则面向千亿级 MoE 模型或极致通信优化场景。

1.1 FSDP：轻量、稳定、易调试的训练基石

FSDP（Fully Sharded Data Parallel）是 PyTorch 原生提供的分布式训练方案，以“参数、梯度、优化器状态三者分片”为核心，兼顾显存效率与开发友好性。在 verl 中，FSDP 并非简单封装，而是通过3D-HybridEngine实现了训练与 rollout 阶段间的智能重分片（reshard）——这是 verl 性能跃升的关键。

为什么 verl 选 FSDP 作默认？
它天然适配 verl 的 HybridFlow 编程模型：每个训练 step 只需声明“我要更新 actor”，FSDP 自动处理跨 GPU 的参数同步与梯度规约，无需用户手动管理进程组或通信原语。调试时，你可以像单卡一样打印中间张量；上线时，它又能无缝扩展到数百卡集群。

FSDP 在 verl 中的配置位置
所有 FSDP 相关参数都集中在actor_rollout_ref.actor.fsdp_config这一嵌套命名空间下。常见配置项包括：

actor_rollout_ref.actor.fsdp_config: param_offload: false # 是否启用 CPU offload（小模型通常关） optimizer_offload: false # 优化器状态是否卸载到 CPU sharding_strategy: "FULL_SHARD" # 默认，也可设为 "HYBRID_SHARD" mixed_precision: "bf16" # 混合精度类型，bf16 是当前主流选择

这些配置最终会传入torch.distributed.fsdp.FullyShardedDataParallel构造函数，由 verl 的TrainingEngine统一封装调用。

FSDP 与 GRPO 的协同要点
GRPO 不训练 critic，因此训练负载集中在 actor 上。此时 FSDP 的param_offload=false是推荐设置——避免频繁 CPU-GPU 数据搬移拖慢训练节奏。同时，sharding_strategy=FULL_SHARD能最大化显存利用率，尤其在actor_rollout_ref.actor.ppo_mini_batch_size=256这类中等批量场景下表现稳健。
源码定位
FSDP 的封装实现在verl/engine/training/fsdp.py，核心是FSDPActorEngine类。它接管了actor_rollout_ref.actor.model的初始化、前向/反向钩子注册及梯度同步逻辑。你可以在verl/trainer/main_ppo.py的build_actor_engine()函数中看到它如何被条件加载。

1.2 Megatron-LM：面向超大规模模型的终极选择

当你的目标模型是 DeepSeek-V2 236B、Qwen2.5-72B 或 MoE 架构时，FSDP 的通信模式可能成为瓶颈。此时，Megatron-LM 的张量并行（TP）+ 流水线并行（PP）+ 数据并行（DP）三级混合并行架构，就展现出不可替代的优势。

Megatron 在 verl 中的角色定位
verl 并未重写 Megatron，而是将其作为可插拔的TrainingEngine实现之一。它要求用户预先准备好符合 Megatron 接口的模型定义（如megatron.core.models.gpt.GPTModel），然后通过actor_rollout_ref.actor.training_engine=megatron显式启用。

关键配置差异
Megatron 的配置粒度更细，需明确指定并行维度：

actor_rollout_ref.actor.megatron_config: tensor_model_parallel_size: 4 # TP 维度，决定每层权重切几块 pipeline_model_parallel_size: 2 # PP 维度，决定模型按层数切几段 data_parallel_size: 8 # DP 维度，即总 GPU 数 / (TP × PP) sequence_parallel: true # 是否开启序列并行，降低单卡显存压力

注意：这些值必须严格满足tensor_model_parallel_size × pipeline_model_parallel_size × data_parallel_size = 总GPU数，否则启动即报错。

适用场景判断建议
- 模型参数量 > 30B 且 batch size > 64 → 优先考虑 Megatron
- 需要极致吞吐且集群网络带宽 ≥ 200Gbps → Megatron 的 all-reduce 通信更高效
- 团队已有 Megatron 微调经验或模型已做适配 → 无缝迁移成本最低
源码定位
Megatron 封装位于verl/engine/training/megatron.py，MegatronActorEngine类负责初始化ParallelTransformer并注入 verl 的 rollout/reward 数据流。其与 FSDP 引擎共享同一套Trainer主循环，仅在build_actor_engine()分支中切换。

1.3 训练引擎选择决策树

场景	推荐引擎	理由
单机 8×A100，训练 Qwen2.5-7B/14B	FSDP	启动快、调试易、显存占用低、无需额外依赖
多机 64×H100，训练 DeepSeek-V2-236B	Megatron-LM	TP+PP 拆分大模型，避免单卡显存溢出，通信更可控
需要与 HuggingFace 生态强绑定（如 LoRA 加载）	FSDP	HF`transformers`模型可直接传入，Megatron 需转换权重格式
实验阶段快速验证 GRPO 算法效果	FSDP	配置项少，出错率低，日志信息更贴近 PyTorch 原生风格

重要提醒：FSDP 与 Megatron 不能混用。一个训练任务只能选择其一。但二者均可与任意 rollout 引擎（vLLM/SGLang）自由组合——这正是 verl “解耦”哲学的体现。

2. 推理引擎：vLLM 是成熟之选，SGLang 是性能先锋

如果说训练引擎决定了你能走多远，那么推理引擎（Rollout Engine）就决定了你每一步能迈多快。在 verl 中，rollout 阶段负责根据 prompt 生成多条响应（trajectory），这是 RLHF/GRPO 数据流的源头。vLLM 和 SGLang 是目前 verl 官方完整支持的两大高吞吐推理后端，它们在架构理念、适用场景和配置方式上各有千秋。

2.1 vLLM：工业级稳定与生态兼容的标杆

vLLM 是当前开源推理引擎中事实上的标准。其 PagedAttention 内存管理机制，让长上下文生成的显存占用近乎线性增长，极大提升了 GPU 利用率。在 verl 中，vLLM 不仅是“能用”，更是“深度定制”。

vLLM 在 verl 中的集成深度
verl 并未简单调用 vLLM 的LLM.generate()API，而是通过vLLMActorEngine类，直接复用其AsyncLLMEngine核心，并注入 verl 特有的 rollout 控制逻辑：
- 支持n > 1的组采样（group sampling），这是 GRPO 的刚需；
- 可精确控制log_prob_micro_batch_size_per_gpu，避免因并发请求过多导致 OOM；
- 与3D-HybridEngine协同，在 rollout 结束后自动触发 actor 模型从 FSDP 分片态重分片为 vLLM 所需的tensor_parallel_size形态。

核心配置项详解
vLLM 的配置集中在actor_rollout_ref.rollout下，关键参数如下：

actor_rollout_ref.rollout: name: vllm # 必填：启用 vLLM 引擎 tensor_model_parallel_size: 2 # vLLM 的 TP 维度，需与模型权重匹配 gpu_memory_utilization: 0.6 # 显存占用上限，0.6 是安全起始值 n: 5 # 每个 prompt 生成 5 条候选，构成 GRPO 的“组” max_num_seqs: 256 # vLLM 请求队列最大长度，影响并发吞吐 dtype: "bfloat16" # 推理精度，bf16 是速度与精度平衡点

其中n=5是 GRPO 的标志性配置——没有它，就不是真正的 GRPO 训练。

vLLM 与 FSDP 的协同工作流
1. Trainer 启动时，FSDP 初始化 actor 模型为FULL_SHARD分片态；
2. 进入 rollout 阶段，3D-HybridEngine将模型动态重分片为tensor_parallel_size=2的 vLLM 兼容形态；
3. vLLM 引擎执行 5 轮并发生成，返回包含 logprobs 的完整轨迹；
4. rollout 结束，3D-HybridEngine再次将模型重分片回 FSDP 态，准备反向传播。
  这一过程全自动，用户无感知，却消除了传统方案中“训练态/推理态切换需重新加载模型”的巨大开销。
源码定位
vLLM 封装实现在verl/engine/rollout/vllm.py，VLLMActorEngine类继承自BaseRolloutEngine。其generate()方法内部调用self.llm_engine.add_request()并轮询结果，确保与 verl 的异步调度模型一致。

2.2 SGLang：低延迟、高并发的新一代推理引擎

SGLang 是由加州大学伯克利分校推出的新兴推理框架，主打“编程语言级”的提示词编排能力（如fork/join控制流）和极致的请求吞吐。在 verl 中，SGLang 的定位是 vLLM 的高性能补充，尤其适合需要极低首 token 延迟或复杂多步推理链的场景。

SGLang 的独特优势
- 更低的 P99 延迟：SGLang 的连续批处理（continuous batching）与 KV Cache 管理比 vLLM 更激进，对短 prompt、高并发请求更友好；
- 原生支持多 step rollout：例如，先生成思考链（CoT），再基于 CoT 生成答案，SGLang 可用fork语法在一个请求内完成，而 vLLM 需两次独立调用；
- 更细粒度的资源控制：可通过--max-total-tokens精确限制全局 KV Cache 容量，避免突发流量打爆显存。

SGLang 在 verl 中的配置方式
启用 SGLang 仅需两处改动：

actor_rollout_ref.rollout: name: sglang # 替换为 sglang tensor_model_parallel_size: 1 # SGLang 当前默认不支持 TP，设为 1 sglang_host: "localhost" # SGLang runtime 服务地址 sglang_port: 30000 # SGLang runtime 服务端口 n: 5 # 同样支持组采样

注意：SGLang 需要独立启动 runtime 服务（sglang serve --model Qwen/Qwen3-8B --tp 1），verl 的 rollout 引擎作为 client 连接它，而非内嵌。

何时该选 SGLang？
- 你的 reward 函数依赖极低延迟（如实时对话评分）；
- 你需要在 rollout 阶段执行多跳推理（例如：检索→摘要→重写）；
- 你已在集群中部署了 SGLang 服务，希望复用基础设施；
- 你正在压测集群极限吞吐，vLLM 的 P99 延迟成为瓶颈。
但需注意：SGLang 对模型权重格式要求更严格（需 HF 格式且 tokenizer 兼容），且tensor_parallel_size > 1的支持尚在完善中。
源码定位
SGLang 封装位于verl/engine/rollout/sglang.py，SGLangActorEngine类使用requests.post()与 SGLang HTTP API 交互，核心是构造符合SGLangGenerateRequestSchema 的 JSON payload。

2.3 推理引擎对比与选型指南

维度	vLLM	SGLang
成熟度与稳定性	（生产环境广泛验证）	（快速发展中，新特性迭代快）
长上下文支持	（PagedAttention 专为此优化）	（支持良好，但极端长度下 cache 管理略逊）
组采样（n>1）支持	（原生、稳定、可精确控制 batch）	（支持，但需确保 runtime 配置足够并发）
多 step 推理支持	（需多次 API 调用，状态需外部维护）	（`fork/join`语法原生支持）
启动与运维复杂度	（一行命令启动，集成度高）	（需单独部署 runtime，端口/健康检查需自行管理）
与 verl 3D-HybridEngine 协同	（重分片逻辑完整，文档详尽）	（支持，但 TP 重分片路径待完善）

实践建议：
入门与通用场景：无脑选 vLLM，配置简单、文档全、问题社区响应快；
追求极致 P99 延迟或需多 step rollout：在 vLLM 验证通后，尝试迁移到 SGLang，重点关注sglang_host/port连通性与max-total-tokens设置；
不要混用：一个 rollout 阶段只能启用 vLLM 或 SGLang 之一，但可随时在不同实验中切换。

3. 引擎协同全景图：一张图看懂 verl 的数据流

理解 verl 后端引擎的价值，不能孤立看 FSDP 或 vLLM，而要把它放在整个 RL 训练闭环中观察。下图展示了 verl 在一次标准 GRPO 训练 step 中，各引擎如何分工协作：

[Configs/Launcher] │ ▼ [Trainer 主循环] ── 调 Ray & HybridFlow → 安排任务图 │ ├── 用 [Rollout Engine: vLLM/SGLang] 生成轨迹 │ ├─ 输入：一批 prompts（data.train_batch_size=1024） │ ├─ 动作：每个 prompt 调用 rollout.n=5 次 → 生成 5120 条响应 │ └─ 输出：含 logprobs 的完整 trajectories（经 3D-HybridEngine 重分片） │ ├── 调 [Reward] 计算奖励 │ └─ 输入：trajectories + reward model → 输出 scalar rewards per response │ ├── 调 [Algorithms] 做优势/损失（GRPO） │ └─ 输入：rewards → 按组（每 5 条）计算 relative advantage → 输出 loss │ └── 用 [Training Engine: FSDP/Megatron] 反向更新 ├─ 输入：loss + actor model（已重分片回 FSDP 态） └─ 输出：更新后的 actor 参数（显存中自动同步）

这个流程揭示了 verl 的三个核心设计智慧：

HybridFlow 调度层是“大脑”：它不关心 rollout 是用 vLLM 还是 SGLang 实现，只认RolloutEngine.generate()这一统一接口；同样，它也不在意训练是 FSDP 还是 Megatron，只调用TrainingEngine.step()。这种抽象，让引擎替换变得像改一个字符串一样简单。
3D-HybridEngine 是“关节”：它让 actor 模型能在 FSDP（训练态）、vLLM TP（推理态）、SGLang（单卡态）之间零拷贝、低开销地动态切换。没有它，每次 rollout 后都要torch.load()重新加载模型，吞吐将断崖式下跌。
Ray 是“血管”：它把 rollout worker、reward worker、learner worker 分布到不同节点，实现真正的异步流水线。例如，当 A 节点的 rollout 正在生成第 3 组响应时，B 节点的 reward worker 已在计算第 1 组的奖励，C 节点的 learner 正在更新第 0 组对应的梯度——这才是 verl 高吞吐的真正来源。

4. 实战配置：一份可直接运行的 FSDP + vLLM GRPO 脚本解析

理论终须落地。以下是一份经过 verl 官方镜像hiyouga/verl:ngc-th2.6.0-cu126-vllm0.8.4-flashinfer0.2.2-cxx11abi0验证的完整 GRPO 训练脚本，我们逐行解析其引擎配置含义：

# Tested successfully on the hiyouga/verl:ngc-th2.6.0-cu126-vllm0.8.4-flashinfer0.2.2-cxx11abi0 image. # It outperforms the Qwen2 7B base model by two percentage points on the test set of GSM8K. set -x python3 -m verl.trainer.main_ppo \ algorithm.adv_estimator=grpo \ # 【算法层】启用 GRPO 优势估计器 data.train_files=$HOME/data/gsm8k/train.parquet \ # 【数据层】训练数据路径 data.val_files=$HOME/data/gsm8k/test.parquet \ # 【数据层】验证数据路径 data.train_batch_size=1024 \ # 【数据层】全局 prompt 批大小 data.max_prompt_length=512 \ # 【数据层】防 OOM 的 prompt 截断 actor_rollout_ref.model.path=Qwen/Qwen3-8B \ # 【模型层】HF 模型 ID actor_rollout_ref.actor.optim.lr=1e-6 \ # 【训练层】学习率 actor_rollout_ref.actor.fsdp_config.param_offload=False \ # 【训练引擎】FSDP 关闭 offload actor_rollout_ref.rollout.name=vllm \ # 【推理引擎】启用 vLLM actor_rollout_ref.rollout.tensor_model_parallel_size=2 \ # 【推理引擎】vLLM TP=2 actor_rollout_ref.rollout.gpu_memory_utilization=0.6 \ # 【推理引擎】vLLM 显存上限 actor_rollout_ref.rollout.n=5 \ # 【推理引擎】GRPO 组采样：每个 prompt 生成 5 条 actor_rollout_ref.ref.fsdp_config.param_offload=True \ # 【参考模型】ref 模型可启用 offload（节省显存） trainer.n_gpus_per_node=8 \ # 【调度层】单节点 GPU 数 trainer.nnodes=1 \ # 【调度层】单机训练 trainer.total_epochs=15 \ # 【调度层】总训练轮数 $@

关键引擎配置总结：

训练引擎：fsdp_config.param_offload=False表明 actor 训练全程驻留 GPU，保障速度；ref.fsdp_config.param_offload=True则让参考模型部分参数卸载到 CPU，为 rollout 腾出显存。
推理引擎：rollout.name=vllm+tensor_model_parallel_size=2明确指定 vLLM 且启用 2 路张量并行；n=5是 GRPO 的灵魂参数。
协同证据：actor_rollout_ref.rollout.n=5与algorithm.adv_estimator=grpo必须同时存在，否则 verl 会在启动时校验失败——这正是框架强制保证引擎与算法语义一致性的体现。

将此脚本保存为train_grpo.sh，修改data.train_files和model.path后，即可在 verl 镜像中一键启动。你将在日志中清晰看到：

[Rollout] Starting vLLM engine with TP=2, n=5...
[Training] FSDP actor initialized with FULL_SHARD strategy...
[HybridEngine] Resharding actor from FSDP to vLLM TP=2...
—— 这些日志，就是 verl 引擎协同正在工作的无声证明。

5. 总结：引擎选择的本质，是工程权衡的艺术

verl 支持 FSDP、Megatron、vLLM、SGLang，并非为了堆砌技术名词，而是为了解决一个根本矛盾：LLM 后训练既要求算法创新，又要求工程极致。FSDP 代表了开发效率与调试友好的平衡点；Megatron 代表了超大规模下的确定性与可控性；vLLM 代表了工业级推理的成熟与稳定；SGLang 代表了未来低延迟与编程灵活性的方向。

选择哪个组合，没有标准答案，只有具体场景下的最优解：