THUDM/slime: An SGLang-Native RL Post-Training Framework Built Around Megatron
slime is an LLM post-training framework for RL Scaling.
At a glance
- What is it?
- slime wires Megatron training and SGLang rollout into one dataflow instead of abstracting over several inference engines. The trade-off is a narrow backend choice and an argument surface that belongs to the upstream engines.
- Who is it for?
- Adopt slime if your post-training stack is already Megatron for training and SGLang for serving, and you want RL rollout, reward and verifier data to move through one buffer rather than a set of glued services. Do not adopt it if you need vLLM or TensorRT-LLM as a rollout backend, or if you want a framework that hides engine arguments behind its own config schema; slime deliberately does neither.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem slime targets: rollout and training that drift apart
Most RL post-training stacks are assembled, not designed. A trainer sits on one side, an inference server on the other, and between them a script that shuttles prompts out and completions back, recomputes rewards, and hopes the weights it just updated are the weights the server is actually serving. Every new capability (a sandbox, a verifier, a multi-turn agent) tends to arrive as another process with its own lifecycle. The README describes slime's goal as making training and data generation reinforce each other "without turning the system into a heavy stack of disconnected trainers, rollout services, and agent frameworks." That is the specific failure slime is aimed at: not slow kernels, but a dataflow split across services that no single component can reason about.
The audience is narrow and identifiable. This is for teams doing large-scale RL post-training who already run Megatron for training and are willing to run SGLang for generation. The README lists the model families exercised through the loop: Qwen3.6, Qwen3.5, Qwen3Next, Qwen3MoE, Qwen3 and Qwen2.5; DeepSeek V3, V3.1 and R1; Llama 3; plus the GLM releases. If your model is not in that set, you are on your own path. If your team has not run either engine before, slime is not a gentle entry point, because it exposes both engines' arguments rather than translating them.
How the dataflow is arranged: one buffer, two engines, no wrapper layer
The architecture the README describes is a single path. Megatron training, SGLang rollout, custom data generation, reward computation, verifier feedback and environment interaction all flow through the same training, rollout and Data Buffer route. That is the whole design thesis. A rollout produces samples, the buffer holds them, the trainer consumes them, and the updated weights go back to the serving side. Because the buffer is shared rather than a network hop between independent jobs, the project can offer separate rollout-only and train-only debugging paths, which the README frames as a correctness measure since "RL bugs are often silent."
The integration style is pass-through, and this is the part worth understanding before adopting. slime does not define its own abstraction over the inference engine. Every argument supported by the installed SGLang is reachable with a `--sglang-` prefix; the README's example is passing `--mem-fraction-static` as `--sglang-mem-fraction-static`. Megatron arguments are read directly, so parallelism, optimizer, checkpointing and model options stay available without wrapper code. The stated benefit is that upstream engine improvements remain accessible as the engines evolve. The cost is equally clear: slime's configuration surface is partly the union of two other projects' configuration surfaces, and version drift between them becomes your problem rather than something a translation layer absorbs.
Running it: prefixed arguments, YAML overrides, and disaggregated serving
Startup follows from the pass-through design. You launch a training job with Megatron-style arguments, and any SGLang setting you need is expressed by adding the prefix, as in `--sglang-mem-fraction-static`. There is no separate slime config dialect for the common case; the arguments you already know from each engine are the arguments you pass.
Above that, the repository documents an optional YAML layer, described as SGLang Config, for topology-specific control. The README names the cases it covers: separate prefill, decode or EPD-style settings, heterogeneous server groups, multi-model serving, and per-group SGLang overrides. Related documents in the tree cover PD disaggregation for multi-turn and agentic workloads where prefill and decode have different resource needs, router policies such as session affinity for multi-turn agents, and delta weight sync for training and inference disaggregation.
For deployments where serving is managed outside the training job, the README points to external rollout engines. In that mode the SGLang side can run in an independent environment, and with disk transport it can run on different GPU models or vendors, using a full-checkpoint update from disk or a delta update over a shared filesystem. That is the most concrete escape hatch in the documentation for heterogeneous clusters, and it is worth reading the external-rollout-engines page before assuming the default colocated layout applies to your hardware.
Where the single-backend bet can hurt
slime chooses SGLang as its only rollout backend, and the README defends this openly: multi-backend frameworks often abstract over the common subset of several engines, which can hide the strongest features of each. The reasoning is sound, and it is why slime can use SGLang-specific serving, routing, caching, disaggregation and weight-sync behavior directly. But it also means the framework is the wrong tool the moment your organization has standardized on a different inference server, or has a serving fleet you cannot change. There is no documented path to swap the rollout engine while keeping the rest of slime; the external rollout engines feature moves where SGLang runs, not what it is.
The second limitation is the flip side of pass-through. Because slime reads Megatron arguments directly and forwards SGLang arguments by prefix, the framework's behavior is coupled to the versions of both engines it was built against. The README does not state a compatibility matrix in the material available here, so the pinned versions in the repository are the thing to check rather than assume. A team that upgrades SGLang aggressively for a new serving feature may find that slime's RL dataflow has not been exercised against that build, and the project's own CI scope (dense and MoE models, Megatron training paths, SGLang deployment configurations, checkpointing, numerical precision, async rollout, OPD, PPO-style workflows, and debug rollout-then-train replay) is the boundary to compare against your upgrade.
How it differs from a general-purpose RL library
The obvious alternative for a team that wants RL post-training without committing to Megatron and SGLang is a library that treats the trainer and the inference engine as interchangeable components, for example a single-controller RL framework that ships its own rollout worker and swaps in a serving backend through an adapter. The difference in approach is structural, not cosmetic. An adapter-based framework owns the abstraction: it defines what a rollout is, what a weight update is, and which engine features it can express, then maps each backend onto that shape. slime does the opposite. It declines to own the abstraction, forwards arguments to the engines, and spends its own code on the RL loop, the dataflow, synchronization and correctness checks.
That choice determines what you get. With an adapter framework you can change inference engines without rewriting your training job, and you accept that the least common denominator is what you can use. With slime you get direct access to SGLang's disaggregation, routing and caching behavior and to Megatron's parallelism and checkpointing options, and you accept that changing engines means changing frameworks. Neither is a defect. They are answers to different questions, and slime's answer only makes sense if you have already decided on the Megatron plus SGLang pair.
Maintenance, releases and the licence position
The release cadence visible in the material is steady rather than frantic: v0.3.0 in May 2026, v0.3.1 in August 2026, and v0.3.2 later the same month, with the last push to the default branch in early September 2026. That rhythm matters for the upgrade cost described above, because each release can move the Megatron and SGLang surfaces you are passing through. The README also points to reproducibility and fault tolerance documents, which is where the project puts its expectations about long runs and restarts. Treat those pages as part of the upgrade procedure, not as background reading.
slime is Apache-2.0. That is a permissive licence, and it is the same licence family as much of the surrounding ecosystem, which simplifies redistribution and modification questions at the repository level. It says nothing about the licences of Megatron or SGLang themselves, or about the terms attached to any model weights you train or serve with the framework. Those are separate questions with separate answers, and this article is not legal advice; check the licence files of every component in your actual stack.
What to verify before you commit a training cluster
The README's strongest claim is validation through complete training loops behind named model releases, and it explicitly distinguishes that from isolated examples. Read it that way: it is evidence that the full path (large-scale training, high-throughput rollout, weight synchronization, reward and verifier data, checkpointing, debugging, long-running stability) has been driven end to end by the people who wrote it. It is not evidence that your configuration will behave the same on your interconnect, your checkpoint format, or your reward pipeline.
So the first thing to verify is version alignment: which Megatron and SGLang revisions the current slime release is built and tested against. The second is whether your workload matches a documented path, meaning a model in the supported list and a serving topology covered by the SGLang Config or PD disaggregation documents rather than a custom arrangement. The third is whether you can run the separate rollout-only and train-only paths, since those are the debugging surface slime offers when a run goes wrong, and a silent RL bug is exactly the case the project claims to design against. If all three check out, the framework's narrowness is an advantage: fewer moving parts between a rollout and the gradient step that consumes it.
Editorial conclusion
Adopt slime if your post-training stack is already Megatron for training and SGLang for serving, and you want RL rollout, reward and verifier data to move through one buffer rather than a set of glued services. Do not adopt it if you need vLLM or TensorRT-LLM as a rollout backend, or if you want a framework that hides engine arguments behind its own config schema; slime deliberately does neither. Before committing, verify the pinned Megatron and SGLang versions in the repository, confirm your model family appears in the supported list (Qwen, DeepSeek V3, Llama 3 and the GLM releases), and read docs/en/advanced/fault-tolerance.md and docs/en/advanced/reproducibility.md to see what the project expects of a long run.
Community notes