Miles v0.1: Production-level Post-training

Miles TeamAugust 18, 2026

We present Miles v0.1, a full-stack production-ready system for frontier post-training, the successor to our first Miles release [1]. Building upon slime's [16] clean design, Miles optimizes every stage in the RL training loop around a simple principle: verified, clean, and customizable everywhere. With accuracy, efficiency, reliability, and scalability as first-class goals, Miles aims to make frontier-scale RL accessible to researchers and developers alike. In this blog post, we will walk through Miles end-to-end.

The Miles RL Loop

An RL training job in Miles is a loop over the following stages:

Rollout — SGLang engines generate trajectories. In agentic RL, each multi-turn rollout session interacts with its own isolated environment that executes actions and produces the reward.
Training — completed trajectory groups are consumed by the trainer (NVIDIA Megatron-LM or FSDP), which computes the RL loss and updates the policy.
Weight update — new weights are synchronized back to the rollout fleet with minimal interruption to in-flight rollouts.

In what follows, we will go through each element in the loop to highlight how we make Miles accurate, efficient, reliable, and scalable.

The Miles fully async RL loop

Figure 1. The Miles fully async RL loop.

Rollout

Every rollout in Miles is generated by SGLang. Building upon SGLang's native inference efficiency, Miles unlocks the full agentic training workflow: multi-turn sessions, tool execution, sandboxed environments, and token-faithful trajectory capture.

Fast Agentic Rollout by SGLang

Miles provides fast agentic rollout by natively integrating SGLang [15], which is optimized for long, multi-turn generation. Agentic trajectories vary widely in length, and each new turn reuses most of the previous context. By default, Miles uses the SGLang router, which keeps all turns of a session on the same SGLang engine and DP rank (if DP attention is enabled) to reuse the cached prefix, while assigning new sessions to the least-loaded rank so that a few long trajectories do not overload part of the fleet. The SGLang router also reserves KV-cache capacity for long sessions beforehand. These features ensure a balanced and stable rollout concurrency, keeping cache-hit rate high in agentic training.

Fully Async RL

For long-context, tool-use, and agentic workloads, rollout time is mainly determined by a handful of stragglers. A synchronous schedule exacerbates the straggler issue, because the trainer has to sit idle until the slowest trajectory in the batch returns, and the rollout engines have to wait until the optimizer finishes model update. Miles' fully asynchronous RL eliminates such mutual-blocking by allowing rollout engines to generate persistently: rollout generation stays continuously in flight while the trainer consumes completed groups and updates the model. Neither side is blocked by the other.

How fully async handles long-tail trajectories

Figure 2. How fully async RL handles the long tails. Different colors indicate different weight versions; the green fragments represent tool-call time.

Scheduling operates at sample granularity: each completed trajectory immediately frees a slot, keeping generation concurrency stable despite large differences in trajectory length. Completed groups enter a bounded data buffer that decouples rollout throughput from training cadence. This buffer also forms a customizable policy boundary where users decide which samples to keep, retry, discard, or reject as stale without modifying scheduling or execution.

To make evaluation asynchronous, Miles provides three evaluation modes, distinguished by where model weights come from.

Shared-engine evaluation uses the rollout fleet and temporarily pauses new submissions, making it suitable for small debug sets without extra GPUs.
Dedicated evaluation uses a separate GPU fleet loaded from checkpoint snapshots, allowing training and rollout to continue uninterrupted.
External evaluation passes a checkpoint directory to any user-provided evaluator, including non-SGLang services.

All three modes associate results with the checkpoint and training step that produced them. If evaluation finishes several steps later, Miles reports that lag rather than misattributing the result; failures skip the evaluation point instead of terminating training.

Evaluation modes on the timeline

Figure 3. Evaluation modes: sharing the rollout engines gates generation, while a checkpoint snapshot hands the eval to a dedicated fleet or an external service without stopping training.

Agentic Environments

In agentic RL, much of the work happens in an isolated environment. Training a coding agent, for example, means giving the model its own sandbox for each task: it runs commands, edits files, reads what comes back, and a test suite at the end decides whether the task was solved. The environment holds that state, executes the actions, and runs the verifier that produces the reward. Miles runs many such episodes at once, records each trajectory in a form the trainer can learn from, and carries the verifier's result through as the reward.

An environment reaches Miles through a plug-in point. Miles offers multiple plug-in points at different levels of the rollout stack, so an environment can take over as much or as little of the rollout as it needs. We ship integrations for existing ecosystems, including Harbor, HUD, NeMo Gym, OpenEnv, and Prime Intellect Verifiers. You can even bring your own environments, which plug in through the same points.

The sandboxes run on any backend of your choosing. We support several, including AgentENV, Daytona, E2B, and Modal. Each episode gets a fresh sandbox, built from that task's own image, so nothing is shared between episodes and nothing stays resident after a run.

Miles v0.1 ships maintained end-to-end recipes for agentic coding and terminal tasks. They are validated on real hardware and can be launched as they stand.

Token-In-Token-Out (TITO)

In multi-turn agentic RL, model outputs pass through message parsing, tool execution, and chat-template rendering before entering the next turn. This process can change tokenization, prune historical reasoning, or reserialize tool calls, causing the trainer to see a different token context from the one actually used during rollout.

The TITO session server in Miles [6] preserves the exact token IDs generated by the model. On each new turn, it tokenizes only the newly appended messages and merges them with the existing prefix. This allows the complete trajectory to be assembled into one contiguous training sample, preserving the original rollout log probabilities while loss-masking tokens that are not generated by the model. For each model family, TITO is validated through CPU round-trip tests and real SGLang GPU sessions, safeguarding the token-level exactness necessary for R3, OPD, and zero-KL alignment.

Building on TITO, Miles is developing a training recipe for black-box agent harnesses such as Claude Code and Codex. These harnesses spawn subagents and compact context at runtime, so the number of trajectories per task is dynamic and unknown in advance. Miles therefore records the full trajectory tree through the session server, and on the training side applies the loss normalization required for varying batch sizes, keeping gradient scale consistent.

The TITO session server

Figure 4. Token-in, token-out. The session server keeps the exact token ids the engines produced, so the trainer sees the tokens the model actually generated even when the harness is an opaque black box.

Efficient Rollout Routing Replay (R3)

MoE RL is sensitive to tiny numerical differences between rollout and training: a single top-k routing flip changes both the token computation and the expert weights that receive the gradients. To resolve this issue, Miles' Rollout Routing Replay (R3) records SGLang's expert routing results during rollout and replays them during training. Such replay is handled efficiently in SGLang, adding only minimal overhead compared with normal routing.

Training

Trainer is the backbone of RL. In Miles, we ship numerous trainer optimizations that make RL stable, fast, and resource-efficient.

Low-precision Training

Miles supports rollouts in NVFP4, MXFP4, MXFP8, and FP8; end-to-end training recipes for NVFP4, MXFP8, and FP8; and INT4 quantization-aware training (QAT) [3] for most models. Earlier posts cover the FP8 [2] and INT4 QAT [3] recipes in depth.

Capturing Blackwell's low-precision throughput in RL requires more than swapping GEMM dtypes: quantization on the rollout and training sides must agree, or the mismatch accumulates across weight updates into policy divergence. To this end, we build the Blackwell-native MXFP8 and NVFP4 recipes [9] as end-to-end precision contracts across the stack: MXFP8 runs rollout, forward, and both gradient GEMMs with hardware blockwise scaling; NVFP4 quantizes MoE expert weights per-token with online activation scaling to avoid batch-dependent quantization artifacts; a bit-exact quantizer contract keeps training and rollout kernels seeing the same quantized values, with fine-grained flags to keep sensitive layers in BF16. The recipes are verified with low KL divergence between SGLang and Megatron-LM. All low-precision configurations keep reward curves closely tracking the BF16 baseline while reducing rollout time.

Memory Efficiency & Disk Offload

Training a 744B-parameter model asynchronously on 16 nodes poses a significant memory issue. Miles ships with sophisticated memory optimization that large-scale runs depend on, starting with the optimizer: optimizer states can be offloaded to CPU or node-local NVMe and streamed back per bucket during each optimizer step, so they never need to be resident on the GPU at once. In the example that we demonstrate at the end of this blog post, this NVMe optimizer-state streaming is what lets the GLM-5.2 optimizer fit alongside the training engine on 32 GB300 GPUs. Beyond offloading, Miles also enables a series of other GPU and CPU memory footprint reductions, saving 30+ GB HBM memory per GPU in the example GLM-5.2 run, and hundreds of GB of CPU memory per node when the trainer is colocated with the rollout engines.

Two Training Backends

Miles supports two training backends behind one interface: NVIDIA Megatron-LM and PyTorch FSDP. A single launch flag picks which of them owns the model on the GPU; a backend implements five methods, and nothing above that line changes.

Megatron-LM is the default, and the backend the model recipes are written against. It splits the model internally across tensor, pipeline, context, expert and expert-tensor parallelism, and supports CPU and NVMe optimizer offload, per-bucket optimizer state streaming, and checkpoints that are parallelism-agnostic, so the layout can change later without reconverting.
FSDP trains the model's own HuggingFace implementation under PyTorch FSDP2. Config and weights load straight from the HuggingFace directory, so there is no conversion step and no architecture flags to write, and parallelism is data parallel only. Architectures that need small corrections register them as adaptation specs rather than forking the model code.

Weight Update

In each training step, after the optimizer updates the model weights, the new weights have to be synchronized across all rollout engines. When training and rollout run on different GPUs, weight synchronization can become a major pipeline bottleneck. Miles provides two optimized paths for diverse deployment settings. With P2P weight transfer [5], training ranks re-shard each weight bucket for the target SGLang layout and write only the required shards directly into rollout-rank memory over RDMA. This avoids broadcasting the full model to every rank and uses multiple training ranks as senders in parallel. The benefit grows with model size and expert parallelism: for Kimi-K2 1T, P2P reduced weight-update time from 53.3 seconds to 7.2 seconds.

For rollout fleets without direct NCCL or RDMA connectivity, Miles supports disk-delta updates. Consecutive RL steps often change only a small fraction of the model's bytes, so Miles only needs to publish the delta-weights against the previous policy version instead of transferring a full checkpoint. Rollout engines apply and verify the delta-weights while generation continues, then pause only to load the combined weights into SGLang. Usually only 2% of parameters are included in the delta-weights for BF16 rollout, and 0.5% for FP4 rollout. In a GLM-4.7-Flash run, this reduces the per-update payload from 62.4 GB to 0.69–0.83 GB while keeping the generation pause within 3–5 seconds.

Verified Day-0 Model Support

Miles lands new frontier models on the day their weights become public, together with SGLang. Kimi-K3 [13], DeepSeek-V4 [10], Inkling [12], Qwen3.8 [14] and NVIDIA Nemotron 3 Ultra [11] were all trainable in Miles on release day, because the inference path in SGLang and the RL recipe in Miles are brought up in parallel rather than one after the other. Day-0 coverage is not limited to one architecture family either: it spans dense and MoE models, hybrid attention, and multimodal inputs. Beyond day 0, almost every open frontier model runs on Miles, including DeepSeek-V3.2, Kimi-K2.6, Qwen3.8, GLM-5.2, Gemma-4, GPT-OSS and so on. For each supported model, we ship CI-guarded recipes in Miles. The full list can be found here.

Code Quality Principle

By now, we have covered the entire RL training loop in Miles, and all those features are built around our code quality principle: Miles should be easy to read and extend. The training driver is intentionally written like pseudocode, while major components, like rollout functions, data sources, losses, and rewards, sit behind small, typed interfaces. The rollout stack is divided into agent, generation, and rollout layers, so an environment or agent framework can replace only the layer it needs while reusing everything else. This makes it straightforward to build a custom RL training loop without forking or rewriting Miles.

Miles-Diffusion

Miles' design philosophy extends beyond LLMs to diffusion models. In Miles-diffusion, sglang-diffusion serves as the high-performance rollout engine and returns the full denoising trajectory with per-step log-probs. An FSDP2 trainer consumes selected SDE steps and optimizes the RL objective under hybrid shard and SP. Inherited from Miles' design, Flow-GRPO, DiffusionNFT, and SFT are all unified within a single trainer with pluggable loss, rollout, and reward components. Initial supported models include SD3.5, Qwen-Image, Wan2.2, LTX-2.3, Cosmos3, and Minimax-H3, with curve-verified recipes for each.

On the rollout side, sglang-diffusion rollout organizes generations into microgroups, reusing encoder results and batching samples. A 5.87× speed-up is observed over plain serial generation on Qwen-Image at 512×512 with group size 16. Each microgroup is then deserialized and reward-scored as its own async stream to overlap with others. On the training side, optional deterministic mode enables bitwise reproducibility, which verifies recipe quality together with documented curves and end-to-end CI. To address training-inference mismatch and keep precision-sensitive DiT parameters, FSDP2 is patched to enable fine-grained per-parameter dtype control.

Multi-Hardware Support

Miles runs the same training loop on NVIDIA and AMD GPUs. NVIDIA coverage spans A100 through GB300, the hardware behind the reference run and the Blackwell low-precision recipes in this post. AMD support is native ROCm through HIP and RCCL [4, 7]: Miles runs on MI300X through MI355X with the same SGLang rollout integration and dedicated Docker images, and CI exercises both vendors alike, running end-to-end training tests on NVIDIA and AMD runners.

Example: Training GLM-5.2 on Terminal-Use Tasks with 64 NVIDIA GB300 GPUs

As an end-to-end example of agentic RL training, we demonstrate how we use Miles to train a GLM-5.2 744B-A40B model on terminal-use coding tasks using fully asynchronous RL across 64 NVIDIA GB300 GPUs, with 32 GPUs for rollout and 32 GPUs for training. For maximal performance, we set training parallelism to TP 2 / PP 4 / CP 4 / EP 8 and inference parallelism to TP 8 / EP 8, with multi-token prediction (MTP) enabled. Each multi-turn terminal agent runs in its own sandbox using the OpenEnv integration in Miles. In this reference run, we use a 65k max sequence length and a batch size of 64.

The reference run completes 100 terminal-bench-like coding task rollout steps stably, sustaining roughly 4.5 minute training steps, with the rollout weights lagging on average 1.7 steps behind the trainer.
Rollout and training are almost fully overlapped via sample-level asynchronous scheduling, DP-aware and load-balanced routing, and a balanced SGLang server config. Rollout reaches a 96% prefix-cache hit rate with stable concurrency.
Thanks to the substantial memory optimization enabled by Miles, we can fit asynchronous training of a 744B model into 64 GPUs, hosting the training engine on only 32 GB300 GPUs.

The full launch script for this run can be found here.

Metrics in the GLM-5.2 agentic RL training example