主流 LLM RL 后训练框架的系统设计对比

LLM RL 后训练里真正有意思的问题，已经不只是“该用哪个 objective”。PPO、GRPO、GSPO、DAPO、RLOO 以及各种变体当然重要，但到了 frontier 规模，系统往往在别的地方决定成败：rollout 吞吐、训练权重到推理侧的移动、长尾样本调度、stale policy 数据治理，以及围绕 policy 搭出来的 serving topology。

如果把比较范围严格限定为大规模 RL 后训练的系统工程，四个开源框架呈现出四条很清楚的设计路线。

• verl 是通用抽象路线：宽 worker/engine 模型、默认偏同步主路径、以及实验性的 fully async recipe。
• SLIME 是 backend-native 路线：Megatron + SGLang 深度耦合，把 router、PD disaggregation、delta weight sync、partial rollout、dynamic sampling、speculative decoding 都做成一等系统工具。
• AReaL 是 async-first 路线：rollout 与 training 完全解耦，rollout 可中断，trainer 持续消费 replay buffer，controller 显式治理 staleness。
• ms-swift 是产品平台路线：把 RL 吸收到完整模型生命周期平台里，提供 vLLM colocate/server mode、Megatron-Ray 编排、LoRA-only sync、mismatch diagnostics 和广泛模型覆盖。

我的结论不是某一个框架绝对胜出。更可能成为标准的是一种 bounded-async disaggregated architecture：AReaL 的 fully async 总体方向，叠加 SLIME 的 backend-native rollout 优化、verl 的 backend 抽象，以及 ms-swift 的产品级 mismatch correction、adapter sync 和 orchestration。

对比总表

几个框架的高层 topology 用图看更直观：

verl：先做通用抽象

verl 的核心系统思想来自 HybridFlow：RLHF/post-training 是分布式 dataflow 问题，不是单个 trainer script。HybridFlow 用 hybrid single-controller / multi-controller orchestration 协调 distributed training 与 distributed generation，3D-HybridEngine 则专门处理 train-generate phase switch：actor 参数 resharding、避免冗余显存、减少通信。

在公开框架里，这套思想落到 engine-worker abstraction 上。ActorRolloutRefWorker 可以共置 actor、rollout 与 optional reference；critic、reward、standalone reference 可是独立 TrainingWorker。这让默认部署既能 colocate，也能做 disaggregated worker groups，同时保持统一心智模型。

默认 loop 仍是同步味道：rollout 产出 batch，reward/ref/critic 计算完成，PPO/GRPO update 运行，然后 actor 权重 export 或 reload 到 rollout engine。新的 fully_async_policy recipe 改变了这一点：Rollouter 生成样本并写入 MessageQueue；Trainer 按 require_batches * ppo_mini_batch_size 连续消费；训练推进后由 ParameterSynchronizer 做权重同步；staleness_threshold 限制旧样本比例。

关键在于，verl 的 async 路径不是重写框架，而是 worker abstraction 的扩展。这既是优势也是限制。它给研究团队一条从稳定同步训练迁移到 bounded async 的路径，但 async semantics 还没有像 AReaL 那样成为默认契约。

Partial rollout 是 verl 最近很值得看的系统能力。公开 recipe 在 parameter synchronization 周围使用 sleep() / resume()：未完成 rollout 可被暂停，权重同步后继续生成。这直接针对长尾样本 latency。Caveat 是公开支持最清晰的路径仍是 Megatron/FSDP + vLLM server；SGLang rollout 已存在，但 SGLang partial rollout 和 server-based RL 的公开成熟度较低。

当研究面很宽时，verl 是很好的选择：FSDP 或 Megatron，vLLM 或 SGLang，PPO/GRPO/GSPO/RLOO，colocate 或 disaggregate。它的限制也是通用性的代价：如果团队已经确定要最深的 SGLang-native rollout topology，SLIME 暴露更多 serving internals；如果团队想要 async-first governance，AReaL 更果断。

SLIME：Backend-native 深优化

SLIME 的出发点不同：大规模 RL 的高性能主路径是 Megatron training + SGLang rollout，中间用 data buffer 连接。它不试图抽象掉 Megatron 和 SGLang，而是直接拥抱它们。

Data-buffer-centered 设计很关键。Training 从 buffer 消费样本；rollout 把生成数据和 reward/verifier feedback 写回 buffer；custom workflow、prompt initialization、tool use、agentic feedback 都可以接进去，而不需要把 trainer 改造成 serving system。

Rollout 侧明确是 serving-shaped。--sglang-config 可以把 actor、reference、reward 放到不同 router 或 server group。只有 update_weights: true 的 group 接收训练更新，reference/reward 可以 frozen。Placeholder groups 可以预留 GPU。PD disaggregation 可以拆 prefill 和 decode worker，并按 group 覆盖 TP、chunked_prefill_size、mem_fraction_static。

SLIME 的 async 要分层理解。基础层仍是 batched rollout/training。train_async.py 通过 Ray async 重叠当前训练和下一轮 rollout。Fully async example 用后台 AsyncRolloutWorker 跨 rollout boundary 保持 in-flight queue。这更像 pipeline 和 scheduling optimization，而不是 AReaL 那种形式化 staleness-controlled replay system。

Partial rollout 是 SLIME 主路径的一等能力。如果 dynamic sampling 或 reward filter 提前终止大量样本，--partial-rollout 会保存半生成样本并在下一轮恢复。自定义 --buffer-filter-path 可决定如何选择缓存样本。当 accepted prompt groups 足够时，也可以 early stop 当前 sampling round，不再等待慢样本或无用样本。这些细节对 invalid、overlong、zero-variance group 很多的 RL workload 很重要。

Caveat 是 fully async example 尚未完全共享同一套恢复语义。对于 ABORTED trajectory，公开文档描述的是重新入队，而不是 fully wired partial-rollout-style resume。因此准确评价是：主路径支持 partial rollout；fully async demo 还没和它完全统一。

SLIME 的 rollout optimization surface 是四者里最深的。它暴露 dynamic sampling、partial rollout、PD disaggregation、session-affinity routing、speculative decoding、BF16 training + FP8 inference、FP8 KV cache、SGLang-native 参数透传。Session affinity 对 multi-turn agents 尤其重要，因为同一 session_id 固定到同一 worker，可提升 prefix cache locality。Speculative decoding 路径也考虑 RL 中 draft/target distribution drift 会侵蚀收益，因此在线训练 draft model 或 MTP layers 也成为系统故事的一部分。

最有辨识度的是 Delta Weight Sync。它不是每步广播全模型，而是保留上次 broadcast 的 pinned-CPU snapshot，只传 changed byte positions 和 values。它支持 NCCL 与 disk transport，也考虑跨数据中心共享文件系统这类极端 disaggregated 场景。355B 级例子里约 3% delta density、约 5GB update 的量级说明了一点：训推物理解耦后，权重移动就是一等瓶颈。

SLIME 的强项也是边界。组织已经选择 Megatron + SGLang、想把 rollout serving 推到很深时，它非常合适；如果平台必须 backend-neutral，就没 verl 舒服。

AReaL：Fully Async 作为系统契约

AReaL 是 async 方向最明确的系统表达。它的起点是同步 RL 的两个结构性瓶颈：generation 必须等待 batch 中最长序列；把 generation 分摊到更多设备后，每 GPU decode batch 可能变小，进而掉到 memory-IO-bound。AReaL 的答案是完全解耦 generation 与 training。

系统有四个核心组件：Rollout Controller、Interruptible Rollout Workers、Reward Service、Trainer Workers。Rollout workers 持续生成；reward services 打分；controller 把 trajectories 写入 replay buffer 并管理请求提交；trainer 攒够数据就更新，然后把新权重推回 rollout workers。

关键 primitive 是 update_weights。新参数到来时，rollout worker 可以中断正在进行的 generation，丢弃旧权重下的 KV cache，用新权重重新 prefill，再继续 decode 未完成样本。因此 AReaL 的 partial rollout 不是调度小技巧：一条 trajectory 可以跨多个 policy version，staleness/off-policyness 成为系统级不变量。

AReaL 的 async control 是显式的。rollout.max_head_offpolicyness > 0 启用 async，=0 回到 sync。Controller 跟踪 policy version 和生成样本，训练时优先消费旧 trajectory，并在新请求会违反 staleness limit 时拒绝提交。这不是简单“用上一轮模型样本训练”；queue submission、data consumption order、update cadence 都参与 freshness governance。

公开 benchmark 也很完整：最高 2.77x speedup，最高 2.57x effective throughput，近线性 scaling 到 512 GPUs，dynamic batching 约 30% gain，interruptible generation 在 1.5B/7B 上有 12%/17% gain。端到端训练小时数也具体：1.5B math 从 33.6h 到 14.8h，7B 从 52.1h 到 25.4h，14B coding 从 44.4h 到 21.9h，32B coding 从 46.4h 到 31.1h。8-GPU academic setup 中 effective throughput 从 27.1k 到 52.0k。

AReaL 还超出了普通 offline RL job。Online proxy 允许外部 agents、annotators 或 OpenAI-compatible clients 通过 gateway 交互；token-level interaction data 被收集进 RL buffer；数据足够后触发训练；updated model 再加载回 inference。这更接近 continuous RL service，而不是 batch training script。

Serving backend 足够成熟但还不完整。AReaL 支持 SGLang 和 vLLM，论文里大量使用 SGLang，部分大规模 setting 用 vLLM。权重更新默认 NCCL，OOM 时可 disk fallback。但稳定 PD disaggregation 还不像 SLIME 那样核心。成本是复杂度：采用 AReaL 也意味着采用 replay governance、staleness policy、interruption semantics 和更重的 control plane。

ms-swift：RL 系统能力的平台化吸收

ms-swift 首先是完整大模型平台，而不只是 RL systems framework。它覆盖 training、inference、evaluation、quantization、deployment，支持 600+ LLM、400+ MLLM 以及大量 preference/RL 方法。缩小到 RL 系统视角，它更像 HF/TRL trainer + vLLM rollout acceleration + Megatron parallelism + Ray orchestration。

两个关键 deployment mode 是 colocate/internal 与 async external/server。Colocate mode 中 training 和 vLLM inference 共享 GPU，依靠 sleep_level、offload_model、offload_optimizer、vllm_gpu_memory_utilization 缓解显存压力。External mode 中，swift rollout 启动 vLLM server，training 连接它。Megatron-Ray 进一步用声明式方式配置 train、rollout、teacher 资源。

ms-swift 的 Ray 设计很务实。文档明确说，因为复用了许多 transformers 和 trl 实现，把所有东西拆成 veRL/ROLL 式 Ray roles 会不自然，也会让非 Ray workflow 被迫围绕 Ray 组织。因此它使用 decorator/function-level dispatch。结果是 RL service graph 没那么干净，但更容易接入现有训练平台。

它的 async 语义是保守的。async_generate 使用上一轮更新后的模型采样，引入的是一步 staleness，而不是宽 replay-buffer controller。该模式也不支持 multi-round scenarios。为了补偿 mismatch，ms-swift 暴露 importance_sampling_level、rollout_importance_sampling_mode、rollout_importance_sampling_threshold，以及 KL、PPL、chi-square、ESS 等 rollout_correction 指标。如果 AReaL 在 controller 层控制 freshness，ms-swift 更像在训练 objective 与 diagnostics 层暴露 mismatch。

Rollout 优化方面，ms-swift 更像参数丰富的生产平台，而不是系统论文。它提供 dynamic_sample、max_resample_times、overlong_filter、steps_per_generation、multi-turn scheduler、vLLM prefix caching、GPU sleep/offload、通过 vllm_enable_lora 做 adapter-only sync、router replay，以及新 Megatron GRPO/GKD 路径里的 LoRA-only sync。我没有在公开 RL 文档里看到可与 SLIME/AReaL 相比的 first-class partial rollout。

Backend 边界也要分清。平台层面，ms-swift 支持 vLLM、SGLang、LMDeploy 做 inference/deploy/eval。当前 RL rollout cluster support 中，vLLM 是主 external backend。所以如果问题是 SGLang-native RL rollout topology，ms-swift 不是最强答案；如果问题是把 RL 产品化到包含 Megatron、Ray、LoRA、多模态和部署的模型平台里，它就很有吸引力。

演进时间线

这条时间线说明，系统正在从同步 batch loop 走向 disaggregated、freshness-governed、backend-aware 的 RL 架构。

Async Rollout 技术路线

到 2026 年中，这个设计空间已经比较清楚。

纯 synchronous colocate 不会消失。它仍会作为 baseline、debug mode 和小规模实验路径存在。但它很难成为 frontier 长期标准，因为样本长度分布正在变得更重尾。长 CoT、tool use、代码验证、多轮 agent 都会让 batch barrier 越来越贵。

研究前沿更可能走向 AReaL 式 fully async，并带严格 staleness/buffer governance。更广义的开源生态可能采用折中版本：训练与 rollout 物理解耦；允许有限 staleness；支持 partial/interruption/resume；推理引擎暴露 router/cache/PD/spec-decode controls；权重同步支持 full/delta/adapter-only；训练侧有 mismatch diagnostics；资源编排覆盖 Ray/Slurm/local。

Open Questions

几个边界仍然要写清。第一，公开 benchmark surface 不均衡。AReaL 的系统 benchmark 最完整。verl 报告 HybridFlow 与 fully async recipe 收益，但没有统一 tokens/s dashboard。SLIME 与 ms-swift 有强 examples、features、profiling 资料，但标准化 benchmark 表较少。

第二，每个框架都有边界。AReaL 的 serving-side deep optimization，尤其稳定 PD disaggregation，还在演进。SLIME 的 fully async example 尚未把 ABORTED trajectory resume 与主 partial-rollout semantics 完全统一。verl 的 fully async 仍是 recipe 形态。ms-swift 的 RL rollout 路径仍以 vLLM 为中心，尽管平台层面支持更多 inference backend。

第三，在这组框架里，我没有看到 TensorRT-LLM 作为 first-class public RL rollout backend。它未来可能重要，但目前不应算作这四者的主流公开设计面。

总结

真正有用的比较不是“哪个框架实现了 GRPO”，而是哪个框架让哪种系统契约变得容易：通用抽象、backend-native rollout、async control，还是平台化落地。最可能成为标准的是 bounded async disaggregation：足够 async，能逃离 rollout barrier；但也足够受控，让 policy freshness、weight movement 和 distribution mismatch 始终可见。

最终胜出的 LLM RL stack，不会只靠一个漂亮 trainer，而是要把 rollout、freshness 和权重移动作为同一个系统管起来。