SuperAPI AI Directory
Partner with us中文AI newsFavorites
All toolsAI developer platformsslime

slime

slime is an LLM post-training framework developed by THUDM, designed for scaled reinforcement learning (RL) training. By connecting Megatron with SGLang, it provides two core capabilities: high-performance training and flexible data generation, and unifies training, rollout, data buffering, reward computation, verifier feedback, and environment interaction into a single path. The framework has been used for the release training of models such as GLM-5.3-Flash, GLM-5.3, GLM-5.2, GLM-5.1, GLM-5, GLM-4.7, GLM-4.6, and GLM-4.5, while also supporting model families such as Qwen, DeepSeek, and Llama 3. The design goal of slime is to let training and data generation reinforce each other, without having to cobble together a heavy tech stack composed of fragmented trainers, rollout services, and agent frameworks. As a result, it is small in size, easy to understand and extend, and yet validated through a complete training loop.

Open website

About this tool

Purpose

slime is an LLM post-training framework for RL Scaling, primarily serving the reinforcement learning post-training pipeline for large language models. Its goal is to combine high-performance training with flexible data generation, avoiding a system that degenerates into a stack of mutually fragmented trainers, rollout services, and agent frameworks.

Main capabilities

slime provides two core capabilities:

  1. High-performance training: By connecting Megatron with SGLang, it supports efficient training in multiple modes.
  2. Flexible data generation: Through a custom data generation interface and a server-based engine, it supports arbitrary training data generation workflows.

In slime, Megatron training, SGLang rollout, custom data generation, reward computation, verifier feedback, and environment interaction all flow through the same training / rollout / Data Buffer path.

The module breakdown is as follows:

  • training (Megatron): Responsible for the main training process, reading data from the Data Buffer and synchronizing parameters to the rollout module after training.
  • rollout (SGLang + router): Generates new data (including reward / verifier outputs) and stores it in the Data Buffer. A custom generate function can wrap multi-turn loops, tool calls, environment / sandbox interaction, and verifier-based rewards around it.
  • data buffer: A bridging module that manages prompt initialization, custom data, and rollout generation methods (including agent workflows that produce samples through the same interface).

The default payload transport method is the Ray object-store; when selecting --rollout-data-transport straw , straw is used on shared JuiceFS storage to handle persisted prompt tasks, rollout continuations, and training batches. Ray carries control messages and references, while generation and training processes directly read and write packaged payloads.

Usage

Engine configuration and deployment

Megatron parameters can be used directly for parallelism, optimizer, checkpoint, and model configuration; installed SGLang parameters need to be prefixed with --sglang- , for example --mem-fraction-static should be written as --sglang-mem-fraction-static.

More complex deployment methods include:

  • SGLang Config: YAML configuration for server groups, multiple models, and per-group overrides.
  • PD Disaggregation: Separating prefill and decode resources.
  • Delta Weight Sync: Sending changed weight bytes through shared storage.
  • External Rollout Engines: Connecting to service processes managed outside the training job, including disk-based updates across different GPU clusters.

Parameter categories

slime parameters are divided into three categories:

  1. Megatron parameters: Read directly, and Megatron can be configured through parameters such as --tensor-model-parallel-size 2 .
  2. SGLang parameters: Pass through all parameters of the installed SGLang, and must be prefixed with --sglang- .
  3. slime-specific parameters: See slime/utils/arguments.py.

For complete usage instructions, refer to the Usage Documentation. To get started quickly, follow the Quick Start Guide, which covers environment setup, data preparation, and running training for the first time.

Code Reading Path

Start from the training loop and dive into the call chain as needed. On the first pass, you can treat slime/utils/arguments.py as the configuration entry point;slime/backends/sglang_utils/ the deployment details in , and the slime/backends/megatron_utils/update_weight/ weight synchronization implementation under it can be reviewed later when you need to modify the related areas. Before submitting an issue or PR, please read the contribution guide and use pre-commit to ensure consistent code style.

Correctness and Reliability

CPU tests cover core behavior and customization contracts; GPU tests cover dense and MoE training, rollout deployment, checkpoints, precision, fully asynchronous rollout, distillation, and debug replay. Engineering guides include debugging, reproducibility, fault tolerance, tracing, and performance analysis.

Applicable Scenarios

slime supports multiple types of example workflows:

  • Agent RL examples:examples/multi_agent implements multi-agent generation in the standard rollout loop through --custom-generate-function-path ;examples/search-r1 implements search / RAG-style multi-turn generation;examples/fully_async is suitable for fully asynchronous rollout for long-tail agent generation (where some samples take much longer than others);examples/coding_agent_rl trains a Qwen3.8-27B coding agent RL on Xiaomi MiMo SWE data, using the sunabako sandbox, official test rewards, and token-correct trajectories.
  • Ecosystem projects: Dressage, Miles, vime, Relax, OpenClaw-RL, P1, RLVE, TritonForge, APRIL, qqr, ART, etc. are built on slime for model post-training, agent RL, domain applications, and rollout research.

Supported Models

In addition to the GLM series, slime supports Qwen (Qwen3.8, Qwen3.6, Qwen3.5, Qwen3-Next, Qwen3 MoE, Qwen3, Qwen2.5), DeepSeek (V3, V3.1, R1), and Llama 3. For model configurations, see scripts/models, and for training examples, see examples.

Limitations

The materials do not provide specific system resource requirements, installation commands, version compatibility details, or performance benchmark data. For related in-depth deployment and tuning parameters, refer to the Usage Documentation and the continuously updated repository documentation.

Related tools

Browse category