slime vs verl
THUDM's RL post-training framework behind the GLM releases — Megatron training plus SGLang rollouts with native arg pass-through, and pluggable reward, verifier and agentic data-generation workflows. — versus — ByteDance's RL post-training library (HybridFlow): PPO/GRPO dataflows in a few lines, FSDP/Megatron training with vLLM/SGLang rollouts, production-proven at frontier scale.
Same job — large-scale RL post-training. verl bets on multi-backend flexibility (FSDP/Megatron × vLLM/SGLang) where slime hard-commits to Megatron+SGLang; pick verl when your infra is vLLM- or FSDP-shaped.
| slime | verl | |
|---|---|---|
| Stars | 7.5k | 22k |
| Forks | 1.1k | 4.2k |
| Language | Python | Python |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | today |
| Topics | training | training |
| Curated connections | 4 | 4 |
slime — the curator's take
One of the few open RL stacks proven on frontier releases (GLM-4.5 through 5.2, with Qwen/DeepSeek/Llama support): the Megatron+SGLang-only bet keeps the dataflow explicit and upstream engine features usable instead of flattened behind a multi-backend abstraction, and rollout-only/train-only debug paths take RL's silent-bug problem seriously. NOT an afternoon tool — you need Megatron-scale GPU infrastructure and RL literacy; for single-node SFT or LoRA use a lighter trainer. And if your rollout engine must be vLLM, this is the wrong framework by design.
verl — the curator's take
The community default for open RL post-training: the hybrid-controller model expresses PPO/GRPO/DAPO dataflows in a few lines, and the backend matrix (FSDP or Megatron for training, vLLM or SGLang for rollouts) means it fits infrastructure you already have. Proven on real frontier runs and the most-forked codebase in the space. NOT an afternoon tool — multi-GPU distributed debugging is table stakes; for single-node SFT/LoRA use TRL instead, and know the tradeoff slime calls out: multi-backend abstraction can lag upstream engine features.