A focused engine for a difficult training loop
slime connects two demanding systems: Megatron trains the model, while SGLang produces the responses used for reinforcement learning. A shared data buffer carries prompts, generated samples, rewards, verifier results, and custom metadata between them. After each training step, updated weights return to the rollout side. Ray places the workers across GPUs and nodes. The result is one loop for sampling, scoring, optimization, evaluation, checkpointing, and weight synchronization.
That sounds like plumbing, but it is the product. Large-scale language-model RL often becomes a collection of trainers, serving processes, routers, sandboxes, and reward scripts with unclear ownership. slime keeps the flow explicit while allowing custom generation and reward functions to control the interesting part. Its examples cover search, multi-agent rollouts, fully asynchronous generation, and coding-agent training with sandboxed tools and test-based rewards.
The project has credible production evidence. Its README identifies slime as the framework behind several GLM post-training runs and lists support for Qwen, DeepSeek V3, and Llama 3 families. Independent projects also build on it for agent training and alternative rollout designs. That matters more than a synthetic speed chart, because it shows the checkpoint, rollout, synchronization, and failure-recovery paths have been exercised together.
SGLang is the advantage and the lock-in
slime deliberately supports one rollout backend. Every installed SGLang argument can pass through with an --sglang- prefix, so users retain direct access to its memory controls, routing, caching, and deployment features. The framework also supports prefill and decode disaggregation, session affinity, external rollout engines, and delta weight synchronization. Megatron arguments pass through directly on the training side. Experienced operators do not have to wait for a wrapper to expose every upstream switch.
The cost is obvious: this is not a neutral orchestration layer. A team standardized on vLLM must change frameworks or use vime, a related project that swaps slime's rollout backend. A team wanting TensorRT-LLM or another server cannot expect an adapter. That focus can produce better integration, but it also ties upgrades and bugs to a moving combination of slime, SGLang, Megatron, PyTorch, CUDA, Ray, and model-specific kernels.
Release v0.3.1 demonstrates both sides. It improved memory use in colocated training, external engine support, checkpoint saving, weight updates, rollout alignment, and PPO log-probability computation. It also internalized model-conversion components and removed Megatron Bridge. The release notes recommend Miles when broader model support matters. slime is best understood as an opinionated training kernel, not a universal compatibility layer.
The quick start is a cluster recipe
The documentation says the guide can get a user started within an hour, but that assumes the right hardware and familiarity. The recommended path pulls a large Docker image, launches with access to all GPUs and a 16 GB shared-memory allocation, downloads model and dataset assets, and converts Hugging Face weights into Megatron's torch_dist format. Larger models may require multi-GPU or multi-node conversion before training even begins.
Model scripts do not eliminate judgment. Megatron cannot infer every training parameter from a checkpoint, so the user sources a model-specific shell script and must verify values such as rotary settings against the exact model. The guide warns that embedding conversion can require a manually supplied vocabulary size. A bad checkpoint path can produce garbled output, while incorrect stop tokens can make rollout appear to hang. These are documented traps, but they are still traps.
Resource planning is just as hands-on. In the disaggregated example, four GPUs train and four more serve rollout. Colocation shares eight GPUs, then requires careful SGLang memory fractions and training offload. Batch equations must balance generated and consumed samples. Long responses, dynamic batching, tensor parallelism, context parallelism, and KV-cache precision all change memory pressure. The FAQ's advice on stuck Ray placement, OOM errors, port conflicts, illegal memory access, and NaN gradients is useful because these failures are normal parts of operating the stack.
Flexibility lives in data generation
Once the base system works, slime becomes more attractive. A custom rollout function can implement multi-turn tools, search, sandboxes, environments, or several collaborating agents without forking the training kernel. Reward functions can use built-in math-oriented scoring or custom logic. Structured metadata travels with samples, which helps an environment keep session identifiers, profiles, tool definitions, and other state. Fully asynchronous rollout addresses workloads where some trajectories take far longer than others.
Correctness receives more attention than in many research repositories. The project documents reproducibility, debugging, tracing, profiling, and fault tolerance. Its tests include CPU checks and GPU end-to-end paths for dense and mixture-of-experts models, checkpoints, numerical precision, asynchronous rollout, and PPO-style workflows. H100 and H200 Megatron paths get the strongest stated CI protection. The quick start says B-series GPUs are usable but lack that CI coverage, and AMD operation follows a separate path.
Open issues show why those distinctions matter. Issue #2253 reports full-vocabulary FP32 logits exhausting memory in long, large-vocabulary training. Issue #2209 describes NaN weights during delta synchronization on a large Qwen mixture-of-experts model. Issue #2201 isolates nonfinite gradients in a GLM-5.2 TileLang backward kernel despite finite inputs. These are specialized configurations, not proof that ordinary runs fail, but they are exactly the silent or expensive errors a training team must be equipped to reproduce.
Health and who should adopt it
The repository was pushed on August 16, 2026, ten days after v0.3.1. GitHub reported 421 open issues and pull requests combined, and entries were updated throughout August. The large queue reflects both heavy development and a wide support surface. Apache 2.0 licensing is friendly to commercial work, and the English README links to a parallel Chinese version plus a substantial documentation site.
Choose slime when SGLang and Megatron are already strategic choices, custom agent rollouts matter, and the team can debug distributed numerical failures. In that setting, the narrow architecture is a strength. For a first post-training experiment, a small lab, or a team seeking model and backend portability, its operational cost is too high. slime is serious infrastructure for people already doing serious training, not a shortcut into it.