The 259,213-line codebase coordinates training and rollout
Our checkout contained 1,650 files and about 259,213 lines of source in 17.7 MB. verl sits between an RL algorithm and the systems that train and sample from a language model. Its hybrid-controller design separates control flow from distributed computation, letting one job connect FSDP, FSDP2, or Megatron training with vLLM, SGLang, or Hugging Face rollouts. The result is a framework for running post-training dataflows rather than a packaged model or hosted service.
The v0.9.0 README lists PPO, GRPO, ReMax, REINFORCE++, RLOO, DAPO, multimodal RL, tool calling, and supervised fine-tuning. Reward logic can be model-based or a function, which covers verifiable math and coding tasks as well as learned scoring. Model placement can spread actors, critics, reference models, and rollout engines across different GPU sets. This flexibility is the appeal, but each additional backend adds its own versions, memory behavior, and failure modes.
The quickstart requires at least 24 GB of GPU memory
The GSM8K quickstart requires a GPU with at least 24 GB HBM. It downloads the dataset, starts with Qwen2.5-0.5B-Instruct, defines a rule-based reward, and launches one-node PPO through Ray. The example exposes batch sizes, prompt and response lengths, learning rates, checkpoint frequency, and GPU memory utilization. That is useful because the first working job is still a real training configuration, not a hello-world import.
The main install path requires Python 3.10 or newer and CUDA 12.8 or newer. Its uv workflow is narrower: Linux, Python 3.12, and either x86_64 or aarch64. Training and inference arrive as selected extras, with one rollout engine paired to FSDP or Megatron. AMD ROCm and Ascend follow separate images. Our installed environment reached 6,096 MB before model weights, a dataset, checkpoints, or experiment logs occupied any space.
What happened when we ran it
Our sandbox installed commit 84e014b in 94 seconds, adding 171 Python packages and using 6,096 MB on disk. The build completed successfully in 6 seconds. Those results came from an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The successful build shows that the package could be assembled in that environment; it does not show that a documented GPU training job can run there.
The test command ended with exit 137 after 74 seconds. Its last lines reached 9% progress and displayed groups of passing dots alongside F, E, and s markers for failures, errors, and skips. No final summary or counts appeared, so we cannot say how many tests passed or name a single cause. The defensible result is that the full invoked suite did not complete and had already recorded failing and erroring cases before termination.
Pip-audit reported 1 known vulnerability in the installed environment. The repository scan found 46 CI workflow files and a tests directory, strong evidence that maintainers exercise many configurations elsewhere. It found no root Dockerfile, while the current install guide points to several backend-specific files under docker/. None of those signals overrides our run: commit 84e014b built, but its broad test command did not produce a passing result in the stated sandbox.
v0.9.0 changes the trainer and backend floor
Release v0.9.0 was published on August 14, 2026. It makes the V1 PPO trainer the default for synchronous and asynchronous modes, deprecates vanilla mBridge in favor of Megatron-Bridge, and removes support for vLLM older than 0.18.0. It also adds hardware plugins and changes checkpoint and trainer interfaces. Those are material upgrade conditions. A team moving from v0.8.0 should read the breaking-change section before reusing launch commands or configuration strings.
The project tries to control recipe drift with explicit version files. Optional recipes moved to a separate repository in January 2026, and each recipe directory is meant to record a verl tag, fixed commit, or rolling commit reference. That is a sensible response to a fast-moving stack. Use those pins. A copied GRPO or DAPO command can cross library, recipe, model, CUDA, and rollout-engine boundaries that changed between the June v0.8.0 and August v0.9.0 releases.
The 1,216-item open queue reflects scale and noise
GitHub showed 23,288 stars and 1,216 combined open issues and pull requests: 585 issues and 631 pull requests in separate searches. The repository was pushed on September 4, 2026, and several issues and pull requests were updated that same day. This is active maintenance at high volume, not an abandoned queue. It still means adopters should search by exact backend, model, trainer generation, and commit instead of treating the open count as one undifferentiated quality score.
Open issue 7656 reports the standard quickstart hanging on a node with 8 or fewer CPU cores when its placement group requests more workers than the node can schedule. The reporter traced the wait and confirmed a one-storage-unit workaround on that setup. This does not establish a universal quickstart failure. It does show the sort of distributed-resource diagnosis verl can demand even when the visible symptom is simply that logs stop after configuration.
Forty-six CI workflows do not make adoption automatic
The 46 CI workflows, current v0.9.0 release, and same-day development make verl a serious option for teams already operating distributed LLM training. Its backend coverage saves them from writing every training-to-rollout handoff themselves. The 6,096 MB environment, 24 GB quickstart floor, breaking changes, and unfinished sandbox suite set the other side of the decision. This is a platform to evaluate with a pinned model and recipe, measured GPU capacity, and a team that can debug Ray placement and backend compatibility.