slime vs trl
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 — Hugging Face's post-training library: SFT, DPO, GRPO, KTO and reward-model trainers on top of Transformers — from a Colab LoRA run to multi-GPU deployments.
The lighter trainer slime's own docs point you toward: single-node SFT/LoRA/DPO on the HF stack instead of Megatron-scale RL infrastructure. Same goal — a post-trained model — at opposite ends of the infra spectrum.
| slime | trl | |
|---|---|---|
| Stars | 7.5k | 19k |
| Forks | 1.1k | 2.8k |
| Language | Python | Python |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | today |
| Topics | training | training |
| Curated connections | 4 | 5 |
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.
trl — the curator's take
The on-ramp for post-training: if your model is on the Hub and your job fits SFT/DPO/GRPO/KTO, a Trainer class gets you a running job in an afternoon — and nothing else scales down to a free Colab as gracefully. PEFT/LoRA, quantized training and accelerate multi-GPU come along for free. NOT for frontier-scale RL dataflows (that's verl/slime territory — no Megatron, no disaggregated rollout engines), and the trainer abstraction that makes it easy also hides the loss mechanics: when results surprise you, read the trainer source before blaming the data.