slime adds lossless delta weight sync for Megatron ↔ SGLang RL disaggregation (PR #1806)

TL;DR

The slime team (THUDM) announces that lossless delta weight sync has landed in the slime RL post-training framework via PR #1806, with both disk and NCCL transports. The motivation, explicitly attributed to FireworksAI and Cursor, is that at frontier RL scale the trainer↔rollout weight-update step dominates wall-clock — shipping the per-step delta between training-version weights instead of broadcasting the full checkpoint cuts that cost. slime brings this capability to OSS for the Megatron-train ↔ SGLang-rollout disaggregation path it is already built around.

Key claims

Lossless delta weight sync now ships in slime with two transport backends — disk and NCCL — covering both checkpoint-style asynchronous reload and in-band collective sync paths [tweet body, PR #1806 title “delta weight sync (disk + nccl transports)”].
The named motivating prior art for the delta-sync pattern is FireworksAI and Cursor’s RL training stacks, both of which had previously argued that delta-compressed weight sync is the bottleneck primitive at frontier RL scale [tweet body, “highlighted why delta-compressed weight sync matters for RL at frontier scale”].
The integration target is the Megatron ↔ SGLang disaggregation that slime is already organized around — i.e., the same train-side / rollout-side split that AReaL, Forge, and Composer 2 all implement, with weights flowing one direction at every trainer version bump [tweet body, “slime brings this capability to OSS: lossless delta sync for Megatron ↔ SGLang disaggregation”].
The framing is “ship deltas, not full checkpoints,” explicitly positioned as a step toward a “fully [disaggregated]” training/serving stack [tweet body, “ship deltas, not full checkpoints. This is another step toward a fully”].

Method

Per the linked PR title and the slime README’s “Delta Weight Sync” entry under Native Engine Pass-Through and SGLang Deployment, the feature is exposed as a slime-native pathway between the Megatron trainer state and the SGLang rollout engine. Two transport backends are provided:

Disk transport — write the per-step delta to a shared filesystem and have SGLang rollout workers reload it; fits the asynchronous-rollout pattern where the rollout engine can swap weights at task boundaries.
NCCL transport — broadcast deltas directly via collective ops, fits the synchronous / in-band update pattern where the trainer pushes weights to rollout workers without going through storage.

The PR is filed under slime’s broader “training/inference disaggregation and large-model update efficiency” path documented in docs/en/advanced/delta-weight-sync.md. The slime README also lists PD Disaggregation (prefill/decode separation) as the sibling primitive for multi-turn agentic workloads where prefill and decode have different resource needs. Detailed numerical and protocol-level specifics (compression scheme, delta encoding, bandwidth measurements) are not in the tweet — the PR description and the linked doc are the source of record.

Results

The tweet is a release announcement and provides no benchmarks. Context the slime project provides separately: slime is documented as the RL framework behind GLM-5.1, GLM-5, GLM-4.7, GLM-4.6, and GLM-4.5, so the delta-sync feature ships into a stack already validated by frontier post-training runs — but the tweet does not back the claim with throughput numbers for the new sync path itself [README §“Why This Design Matters”].

Why it’s interesting

Delta weight sync is the train→rollout-side primitive that complements the AReaL-style rollout-side staleness/load-balancing primitives the wiki already tracks. AReaL Code Walk Through — SGLang RL team's deep dive into Yi Wu's asynchronous RL framework dissects how AReaL bounds rollout staleness via StalenessManager.get_capacity and rebalances variable-length completions via FFD in DistRolloutCoordinator, but the actual weight-shipping step (the moment a new trainer version reaches the rollout engine) is left implicit there. slime PR #1806 is the concrete answer for the other half of the disaggregation: ship just the delta, over disk for async or NCCL for in-band. Together they describe both ends of the Megatron-trainer ↔ SGLang-rollout pipe.

It also complements Scaling and Optimizing Frontier Model Training (Fireworks AI) (the named inspiration in the tweet) and Cursor’s Composer 2 Technical Report — Fireworks runs a closed-source 4D-parallel + streaming-pipeline trainer-side stack with its own weight-sync optimizations, Composer 2 runs RL inside the actual Cursor harness with proprietary infra; slime is now the OSS path to the same delta-sync primitive in Megatron+SGLang. This is the “asynchronous RL infrastructure” decoupling generation from training that GLM-5: from Vibe Coding to Agentic Engineering mentioned extending in GLM-5 — now landing in the framework that backs the GLM family.