Miles and the SGLang RL ecosystem implemented two Blackwell-native low-precision reinforcement learning recipes, end-to-end MXFP8 and per-token NVFP4, in work published July 29, 2026 by Ziang Li, humans& and the Miles Team. The recipes coordinate checkpoint conversion, Megatron training, SGLang rollout and live weight updates under one precision contract so the sampler and trainer do not drift into different low-precision policies. MXFP8 covers rollout, forward propagation, weight-gradient GEMMs and data-gradient GEMMs, while NVFP4 targets MoE expert paths with online per-token activation scaling. In a Qwen3-30B-A3B ablation on 8x B200, BF16 and all five low-precision configurations showed closely overlapping raw reward curves, while MXFP8 and NVFP4 reduced rollout time.

The work extends earlier Miles low-precision RL efforts, including an FP8 RL recipe and an INT4 QAT recipe. The authors say prior approaches were not designed around Blackwell-native MXFP8 or NVFP4: the existing DeepSeek-V3-style FP8 path uses 128x128 block scaling for weights and 1x128 tile scaling for activations, with FP32 scales applied in software around the Tensor Core path. NVIDIA HGX dense Tensor Core figures cited in the article list per-GPU throughput at 2.25 PFLOPS BF16, 4.5 PFLOPS FP8 and 9 PFLOPS FP4 for B200; 2.25 PFLOPS BF16, 4.5 PFLOPS FP8 and 13.5 PFLOPS FP4 for B300; and 4 PFLOPS BF16, 17.5 PFLOPS FP8 and 35 PFLOPS FP4 for Rubin GPU (NVL8).

MXFP8 is described as a microscaling FP8 format in which every 32 consecutive E4M3 values share one local E8M0 scale. In the Miles recipe, TransformerEngine and Megatron provide the Blackwell training path, while SGLang uses FlashInfer and Triton rollout kernels. TransformerEngine materializes both row-wise and column-wise quantized copies because rowwise 1x32 blocks and columnwise 32x1 blocks are numerically different; the article says this uses more memory but avoids an extra requantization step and reduces additional quantization error in backward computation.

NVFP4 is used more selectively because it is more aggressive than MXFP8. The recipe quantizes MoE experts and leaves the rest of the model BF16 unless configured otherwise. The article gives DeepSeek-V3 as an example: the model has about 671B total parameters, and its MoE experts account for (61 - 3) (256 + 1) 3 7168 2048 / 1e9 = 656.5B parameters, or about 97.8% of the model. NVFP4 stores FP4 E2M1 values with one FP8 E4M3 scale per 16-value block, plus a coarse FP32 scale at a larger tensor or token scope.

For RL, the authors reject a direct copy of the NVFP4 pretraining recipe because RL has noisy gradients, high-variance rewards and small useful updates. The Miles NVFP4 recipe computes one FP32 activation scale per token online, avoiding per-tensor scaling that can make training batch-variant and inter-token scale sharing that can leak future-token information into past-token representations. FlashInfer fuses that FP32 scale computation into its activation quantization path, and Miles requires SGLang and Megatron to use the same expert-tensor-parallel size when that scale is computed inside a partition.

The stack also adds high-precision and dequantized backward modes. In high-precision-backward NVFP4, forward pass and rollout use NVFP4 for MoE experts while backward GEMMs use original BF16 operands. In dequantized backward, backward GEMMs still run in BF16 but consume BF16 dequantizations of the exact low-precision forward operands. Memory validation for MXFP8 linear layers with input_shape=(2048, 2048) and out_features=8192 showed high precision e2e_alloc at 53.12 MB versus 94.14 MB default, a -41.02 MB (-43.57%) change; NVFP4 high precision e2e_alloc was 44.50 MB versus 150.27 MB default, a -105.77 MB (-70.39%) change. The authors also aligned FlashInfer and TransformerEngine quantizers to a bit-exact MXFP8 and NVFP4 contract, testing random, boundary, zeros and maxes inputs.

Miles and the SGLang RL ecosystem implemented two Blackwell-native low-precision reinforcement learning recipes, end-to-end MXFP8 and per-token NVFP4, in work published July 29, 2026 by Ziang Li, humans& and the Miles Team. The recipes coordinate checkpoint conversion, Megatron training, SGLang rollout and live weight updates under one precision contract so the sampler and trainer do not drift into different low-precision policies. MXFP8 covers rollout, forward propagation, weight-gradient GEMMs and data-gradient GEMMs, while NVFP4 targets MoE expert paths with online per-token activation scaling. In a Qwen3-30B-A3B ablation on 8x B200, BF16 and all five low-precision configurations showed closely overlapping raw reward curves, while MXFP8 and NVFP4 reduced rollout time.

The work extends earlier Miles low-precision RL efforts, including an FP8 RL recipe and an INT4 QAT recipe. The authors say prior approaches were not designed around Blackwell-native MXFP8 or NVFP4: the existing DeepSeek-V3-style FP8 path uses 128x128 block scaling for weights and 1x128 tile scaling for activations, with FP32 scales applied in software around the Tensor Core path. NVIDIA HGX dense Tensor Core figures cited in the article list per-GPU throughput at 2.25 PFLOPS BF16, 4.5 PFLOPS FP8 and 9 PFLOPS FP4 for B200; 2.25 PFLOPS BF16, 4.5 PFLOPS FP8 and 13.5 PFLOPS FP4 for B300; and 4 PFLOPS BF16, 17.5 PFLOPS FP8 and 35 PFLOPS FP4 for Rubin GPU (NVL8).

MXFP8 is described as a microscaling FP8 format in which every 32 consecutive E4M3 values share one local E8M0 scale. In the Miles recipe, TransformerEngine and Megatron provide the Blackwell training path, while SGLang uses FlashInfer and Triton rollout kernels. TransformerEngine materializes both row-wise and column-wise quantized copies because rowwise 1x32 blocks and columnwise 32x1 blocks are numerically different; the article says this uses more memory but avoids an extra requantization step and reduces additional quantization error in backward computation.

NVFP4 is used more selectively because it is more aggressive than MXFP8. The recipe quantizes MoE experts and leaves the rest of the model BF16 unless configured otherwise. The article gives DeepSeek-V3 as an example: the model has about 671B total parameters, and its MoE experts account for (61 - 3) (256 + 1) 3 7168 2048 / 1e9 = 656.5B parameters, or about 97.8% of the model. NVFP4 stores FP4 E2M1 values with one FP8 E4M3 scale per 16-value block, plus a coarse FP32 scale at a larger tensor or token scope.

For RL, the authors reject a direct copy of the NVFP4 pretraining recipe because RL has noisy gradients, high-variance rewards and small useful updates. The Miles NVFP4 recipe computes one FP32 activation scale per token online, avoiding per-tensor scaling that can make training batch-variant and inter-token scale sharing that can leak future-token information into past-token representations. FlashInfer fuses that FP32 scale computation into its activation quantization path, and Miles requires SGLang and Megatron to use the same expert-tensor-parallel size when that scale is computed inside a partition.

The stack also adds high-precision and dequantized backward modes. In high-precision-backward NVFP4, forward pass and rollout use NVFP4 for MoE experts while backward GEMMs use original BF16 operands. In dequantized backward, backward GEMMs still run in BF16 but consume BF16 dequantizations of the exact low-precision forward operands. Memory validation for MXFP8 linear layers with input_shape=(2048, 2048) and out_features=8192 showed high precision e2e_alloc at 53.12 MB versus 94.14 MB default, a -41.02 MB (-43.57%) change; NVFP4 high precision e2e_alloc was 44.50 MB versus 150.27 MB default, a -105.77 MB (-70.39%) change. The authors also aligned FlashInfer and TransformerEngine quantizers to a bit-exact MXFP8 and NVFP4 contract, testing random, boundary, zeros and maxes inputs.