Slime is a high-performance framework designed for reinforcement learning (RL) tuning scenarios after large language model (LLM) training is completed. It has opened up the capabilities of Megatron (efficient training engine) and SGLang (data generation tool), and has provided underlying support for top models such as GLM-4.7, Qwen3, DeepSeek V3, and Llama 3.
With this framework, you can build an efficient and flexible intensive learning workflow. Its built-in customizable data tools can effectively shorten training time and improve model accuracy. It is suitable for both scientific research scenarios and production environments; it can also save computing power resources to help achieve breakthrough results in the physical field, agent development, code generation, etc.
If we draw a simple line for the development of the current large model, we will find that the stage where the gap really opens is no longer in “pre-training” but in “post-training”. The scale of the model itself is getting closer and closer, and what really determines the upper limit of ability is the post-training stage-especially the reinforcement learning (RL) level. The slime launched by THUDM is an engineering framework built around this stage.
It is not an “AI application tool” in the common sense, nor is it a simple collection of data generation scripts. Slime is more like a broken pipeline that connects the most critical things in post-training of a large model: where the data comes from, how to generate it efficiently, how to participate in training, and how to continuously improve model capabilities in the loop. Many people will think it is like a “data generation tool” at first glance, but if we just stop here, we will actually underestimate its positioning.
In slime’s design, data is not a stand-alone asset, but is part of the training process. By connecting to high-performance distributed training engines like Megatron and efficient reasoning and generation tools like SGLang, it builds a closed loop: the model generates data, which goes through screening or reward mechanisms into training, and in turn improves model capabilities, and then generates higher-quality data. This cycle itself is the core of the so-called RL scaling.
Because of this, slime seems to have two “qualities” at the same time. On the one hand, it does provide very flexible data generation capabilities, allowing you to customize pipelines, build different types of training data, and even expand the generation capabilities through server-based methods; on the other hand, these capabilities are not simply to “produce data”, but serve the reinforcement learning process in the post-training stage. In other words, it does not hand over data to other systems for training, but directly embeds data generation into the training system.
The changes brought about by this design are very direct at the engineering level. In traditional processes, data, training, and evaluation are often decentralized, but slime is more like trying to regroup these links into a unified framework. The result of this is not just “more convenient”, but rather gives the model the ability to continuously improve itself: data is no longer a one-time resource, but can be iterated over time with the model’s capabilities.
As for those common descriptions, such as “supporting GLM, Qwen, DeepSeek, Llama and other models”, a more reasonable understanding is that it has the ability to adapt to mainstream large model systems, rather than these models being “built based on it.” Similarly, the terms of “improving accuracy and saving computing power” are essentially a result-oriented description of this closed-loop training method, rather than a direct guarantee provided by the framework itself.
If you must use one sentence to summarize slime, an expression closer to its actual positioning should be: It is a system built around the post-training stage of the large model, integrating data generation with reinforcement learning training, and using an engineering approach. Support the continuous improvement of model capabilities. Rather than “making a smarter model,” it is more like solving another problem-how to make models continue to become smarter.
Github：https://github.com/THUDM/slime
Oil tubing: