slime

A LITTLE SLIME. A LOT OF POSSIBILITY.

Built for
scaling RL.

slime is an LLM post-training framework for RL scaling, providing two core capabilities:

  1. High-Performance Training ↘
  2. Flexible Data Generation ↘
Understand an RL run ↗Build my experiment ↓

Explore in your browser. Ready to run? Install slime →

01 / ↔

High-Performance Training

Supports efficient training in various modes by connecting Megatron with SGLang.

Megatron⇄SGLang
02 / ⌁

Flexible Data Generation

Enables arbitrary training data generation workflows through custom data generation interfaces and server-based engines.

Your data & environments→Data Buffer

Training, rollout, custom generation, rewards, verifiers, and environment interaction flow through the same training / rollout / Data Buffer path.

BUILT IN THE OPEN. USED AT SCALE.

From GLM-4.5 to GLM-5.3 & GLM-5.3-Flash.

slime has powered RL post-training across Z.ai’s GLM generations. Explore the model releases, then use the same core capabilities in your own experiment.

Z.ai × slime
GLM-4.5→GLM-4.6→GLM-4.7→GLM-5→GLM-5.1→GLM-5.2→GLM-5.3→GLM-5.3-Flash

Companion projects

straw

Durable queues and shared tensor storage for rollout and training data.

 sunabako

Linux sandboxes for agents to run code and tests, with support for multiple machines.
Your environment first. Your experiment next. ↓

00 / SET UP ONCE

Ready, set, slime.

Start with the prepared image, or build a conda environment. Then choose a model below and take your launch script with you.

  1. 01Install the environment
  2. 02Build your experiment
  3. 03Download, prepare, run
Environment details & other platforms →

Docker · A prepared stack

The image includes Megatron, SGLang and slime’s patches. On your Linux x86_64 GPU host, have Git, Docker and the NVIDIA driver ready, with NVIDIA Container Toolkit ↗.

1 / On the host
SLIME_IMAGE=slimerl/slime:latest-cu129
docker pull "$SLIME_IMAGE"
git clone https://github.com/THUDM/slime.git
cd slime
mkdir -p ../slime-data
docker run --rm -it --gpus all --ipc=host \
  --shm-size=16g --ulimit memlock=-1 --ulimit stack=67108864 \
  -v "$PWD:/root/slime" -v "$PWD/../slime-data:/data" \
  -w /root/slime "$SLIME_IMAGE" /bin/bash
2 / Inside the container
pip install -e . --no-deps
python -c "import slime, sglang, megatron.core; import torch; print('GPUs:', torch.cuda.device_count())"

Your checkout stays on the host. Models, data and checkpoints under /data persist in the sibling slime-data directory after the container exits. The builder uses /data by default.

Conda · Build with micromamba

The repository’s build_conda.sh creates a slime environment with Python 3.12, CUDA 12.9, Megatron, SGLang and the matching patches. It installs micromamba and compiles native dependencies.

Use a Linux x86_64 NVIDIA machine with Bash, Git, curl, patch, a C/C++ toolchain and a compatible GPU driver. The current script expects write access to /root. For B200/B300, use the CUDA 13 Docker image above.

1 / Clone & build
git clone https://github.com/THUDM/slime.git
cd slime
BASE_DIR=/root SHELL=/bin/bash bash build_conda.sh
2 / Activate in your Bash shell
source ~/.bashrc
micromamba activate slime
export CUDA_HOME="$CONDA_PREFIX"
python -c "import slime, sglang, megatron.core; import torch; print('GPUs:', torch.cuda.device_count())"

After the build finishes, activate the environment in each new shell. In the builder’s Files step, choose writable model, data and output paths; Megatron is at /root/Megatron-LM. Build script ↗

Environment ready?Build my first experiment ↓

01 / THE EXPERIMENT BUILDER

Make it yours.

A starting point?
Compare A / B

Save a complete snapshot as A; your working experiment is B. Undo / Redo changes B. Replacing A is a separate action. Exports below always use B.

03 / FOLLOW YOUR CURIOSITY

Go a little deeper.

The ideas, equations, and engineering behind your choices.

01The experiment field guideFrom checkpoint to first reward ↗ 02Inside the algorithmsGRPO · TIS · ICE-POP · R3 · SC ↗ 03Inside the systemPrecision, async, PD & HiCache ↗ 04The documentation libraryOrganized guides, APIs & debugging ↗

04 / WHEN YOU WANT TO GO FURTHER

A good experiment asks good questions.

Open a question. Find the next measurement, then the right tool.

01 / DEBUGThe reward looks wrong. Where do I start?＋

Inspect generated text, checkpoint loading, and the chat template first. Save a rollout, replay a fixed batch on the training side, then compare log-probs before changing the algorithm.

Debug & replay →Understand mismatch →
02 / PROFILETraining is slow. What am I waiting for?＋

Separate rollout, reward, weight transfer, and training time. Trace the critical path, then profile the busy engine. Use tools/profile_rollout.py to collect SGLang traces and inspect prefill/decode behavior.

Profiling →Timeline & tracing →Metrics →
03 / SCALEHow do I grow beyond one cluster?＋

Split GPU ownership, then choose a weight transport that matches the network. Add PD when prefill and decode need different resources; use persistent rollout storage when jobs need recovery.

External engines →Delta sync →Partial / distributed async →straw →Recovery →
04 / EXTENDMy agent needs its own world.＋

Start with a custom per-sample generation function and reward. Replace rollout orchestration only when your data scheduling or cross-step state needs it.

Agent RL →Extension interfaces →SGLang topology →

LEARN WITHOUT LOSING YOUR PLACE