humans& Open-Sources Weight Teleportation: RL Weight Sync for a 445 GB Model With a 0.23 s Pause

humans& has open-sourced a way to push reinforcement-learning weight updates to inference GPUs almost instantly. The lab calls it Weight Teleportation. On its own reference benchmark, a 445 GB model update shrank to a 2.65 GB payload, finished syncing in under four seconds, and paused the samplers for only 219.6 milliseconds. The write-up, by Ziang Li and colleagues, went up on the humans& blog on November 2, 2026.

This is infrastructure news, not a model launch. It matters if you train or fine-tune large models with RL, or if you wonder why frontier post-training is so expensive. Idle GPUs are one of the biggest hidden costs, and weight sync is where many of them sit idle.

TL;DR: what was released, and what is claimed

Why does RL weight sync stall training?

Large-scale RL splits the work in two. Trainers update the policy. Samplers, usually running an inference engine, generate the trajectories the trainers learn from. After every training step the samplers need the new weights, or the data they produce comes from an older policy.

The humans& post describes the bind. You can use fast intra-cluster networking to ship weights, or accept a delay from moving terabytes of data and blocking the samplers. A blocking update leaves inference GPUs idle. A full checkpoint load can also evict the key-value cache, which means in-flight generations lose their state.

Our earlier coverage of RadixArk's Miles framework explained why labs build whole stacks around this loop. Weight sync is the part that scales worst as models grow, which is why a 445 GB NVFP4 checkpoint is a useful stress test.

Reinforcement learning loop where a trainer sends updated weights to a sampler that generates new trajectories

How does delta weight sync work?

The core trick is not new. The post credits the "disk delta" method in the Miles v0.1 release. The trainer does a bitwise XOR of the old and new weights. Every zero bit in the result means "unchanged", every one means "flipped". The sampler applies the same XOR to its old weights and gets the new weights exactly.

Because the operation works on raw bits, data types do not matter. There is no rounding and no floating-point arithmetic. The post notes this also works with low-precision RL, and that small high-precision updates often vanish inside a low-precision format, which makes the delta even sparser.

The bet is that RL updates are sparse. Only a tiny share of weights change per step, so the XOR mask is almost all zeros and compresses well. humans& uses 0.085% of weights mutated per step as its proxy for a steady-state update.

Why the obvious version was not fast enough

humans& first measured the existing disk-delta design. The compressed payload was small, 0.876 GB with CPU Zstd, as expected. But the gain was lost elsewhere:

• The trainer spent time compressing.
• Patching the checkpoint needed a disk round trip.
• Rollout engines reloaded the whole checkpoint from disk.

The next step was to move everything onto GPUs. The team used NVIDIA's nvCOMP library and compared codecs. LZ4 compressed the proxy mask to 5.36 GB and is supported by the Blackwell Decompression Engine (DE), a fixed-function hardware block. Trainer-side compression took 0.834 s and receiver-side work took 6.041 s. That is a strong baseline, but the post names two flaws: LZ4 sends 6.1 times as many bytes as CPU Zstd, and the decompressed masks need GPU buffers big enough to force KV cache eviction.

How does Weight Teleportation fix those two flaws?

Three design choices carry the result.

Double compression. The pipeline first compresses with a GPU-friendly codec, then adds an outer Zstd pass. The post's Table 2 shows the numbers:

Snappy plus Zstd won, probably, the authors suggest, because Snappy's simpler copy commands are easier for Zstd to compress further.

Heterogeneous decompression. The outer Zstd layer is decompressed on the CPU. That work happens while the samplers keep decoding, and it leaves a Snappy payload staged in pinned host memory. The Decompression Engine can read that memory directly and write to GPU memory, which also removes input staging buffers from HBM. The post says ordinary pinned allocations are not enough; the memory has to be created with the host-NUMA and hardware-decompress flags in the CUDA driver API.

Overlapping the DE with compute. The DE is separate hardware, so it can work while the streaming multiprocessors do something else. The pipeline uses two small buffers. The DE decompresses a layer into one slot while a Triton kernel applies the XOR from the other. The buffers hold two layers at a time, so no KV cache eviction is needed. An Nsight Systems trace in the post shows the DE saturated and the Triton work hidden behind it.

The final timing, from the post:

Only the last stage pauses inference. That is why the lab says the DE hardware throughput is now the bottleneck.

What else does it enable?

The post argues the same machinery is more than a steady-state RL trick.

• Evaluation engines do not update every step, so they need deltas against an older version. The trainer keeps auxiliary deltas for the last eval version and the engines' base version.
• Fault tolerance: when a rollout engine dies, it restarts from its base checkpoint and applies a delta in one call.
• Resuming from a trained checkpoint: an LZ4 plus Zstd codec fits here, because the transfer happens once and a smaller inner payload keeps staging buffers small.
• Inference deployment: a new checkpoint can cross data centers as a tiny delta. The engine launches from a base checkpoint and calls /update_weights_from_gpu_delta. An opt-in release_state argument frees staging buffers afterward.
• LoRA comparison: the authors call the approach a superior alternative to LoRA adapters to some extent, because it compresses full-parameter deltas into a tiny payload.

Where is the code?

According to the post, orchestration, distributed GPU compression, fault tolerance and delta checkpointing live in Miles. The receiver pipeline, Triton kernels and the one-shot API are in SGLang. The SGLang change is pull request 42210, which adds the endpoints /get_gpu_delta_info, /update_weights_from_gpu_delta, /get_gpu_delta_status and /clear_gpu_delta_state. It is paired with Miles pull request 3894.

Read the PR text carefully before you plan around it. The title still carries a WIP tag. The description says live weight writes wait for a pause, and that "concurrent-serving impact has not been measured." It also states that an uncertain XOR application is never replayed, and that failed preparation is released. Fresh engines can recover from a Hugging Face base checkpoint to the current version, and validate_payload_hash=True controls payload hash checks. The post thanks the NVIDIA nvCOMP team for its compression and decompression kernels.

How should you read the numbers?

Every figure comes from humans&. It is a vendor-style engineering blog, not a peer-reviewed paper, and we found no independent reproduction on launch day. Three caveats stand out.

1. Proxy workload. The 0.085% mutation rate is a stand-in for a steady RL step. The authors say denser or less compressible updates raise payload size, network time and sampler pause.
2. Hardware lock-in. The DE is a Blackwell feature. The test used B300 GPUs. On older GPUs you would not get the same pipeline.
3. Strong wording. The conclusion says the lab does not "foresee further work on RL weight sync" and that "even the best intra-cluster P2P RDMA implementation becomes obsolete." That is a claim, not a result. Other teams, including the LMSYS group, have published their own peer-to-peer weight transfer work, and the comparison deserves a neutral benchmark.

The post itself notes that its RDMA claim holds for "most real-world workloads", not all of them.

What does this mean for what you build or pay?

If you only call APIs, nothing changes today. If you post-train open models with RL, the practical points are these:

• GPU hours. Less idle sampler time means more rollouts per dollar. How much you save depends on how long your pause was before.
• Multi-site setups. Sending a 2.65 GB delta instead of a full checkpoint makes cross-data-center RL and deployment far more practical.
• Model choice. The test model is GLM-5.3. Our coverage of the GLM-5.3 launch and of why its open weights were delayed gives background on that family.
• Maturity. Wait for the SGLang change to merge and for someone outside humans& to reproduce the timings before you rebuild a training stack around it.

The release also shows what the lab is working on. We covered the lab's first model in humans& Ampersand v0.1 and Boba. A group-chat model is a different product from RL tooling, but the infrastructure post says its numbers come from the lab's "Ampersand production RL configuration", so this is the stack behind that work.

How to try it

1. Read the two pull requests and the humans& post end to end.
2. Check you have Blackwell GPUs with the Decompression Engine, and a Miles plus SGLang setup you can modify.
3. Start with the eval and fault-tolerance paths, which are easier to test than the hot loop.
4. Measure your own update sparsity first. If a large share of weights changes per step, the payload will grow.
5. Log the sampler pause before and after, since that is the number the lab leads with.

Other RL infrastructure stories worth comparing: Castform's RL-trained open model, an 8B RL model on ALFWorld, and OpenAI on pacing frontier RL.

What to watch next

• Whether the SGLang pull request merges and drops its WIP tag.
• An independent benchmark against RDMA-based weight transfer.
• Whether the Miles maintainers fold the pipeline into a tagged release. Our RadixArk Miles coverage tracks the project.
• Support for non-Blackwell GPUs, which the post does not promise.
• Measured effects on concurrent serving, which the PR says are not yet measured.

Bottom line

Weight Teleportation is a careful piece of systems work: bit-exact deltas, two-stage compression, a hardware decompressor used in parallel with compute, and a one-call API. The numbers are strong and come from the authors. The code is real and public, but not yet merged. If you run RL on Blackwell, it is worth testing. If you do not, it is a clear sign of where RL infrastructure is heading.

Related reading

• RadixArk Miles: RL for frontier post-training
• humans& Ampersand v0.1 and Boba
• GLM-5.3 launch and cyber-defense benchmarks
• GLM-5.3 open weights delay
• Castform: RL post-training of an open model
• OpenAI on pacing frontier RL

Details reflect the humans& post and the linked pull requests as of November 2, 2026. Pull requests change quickly; check them before relying on any figure.