Skip to content

feat(inference): opt-in online FP8 ue8m0 scales and stochastic weight rounding - #4041

Closed
garrett361 wants to merge 3 commits into
mainfrom
feat/online-fp8-weight-rounding
Closed

garrett361 wants to merge 3 commits into
mainfrom
feat/online-fp8-weight-rounding

Conversation

@garrett361

@garrett361 garrett361 commented Oct 12, 2026 •

Copy link
Copy Markdown
Contributor

Online FP8 serving rounds bf16 weights to nearest with amax / 448 block scales, which re-rounds dequantized FP8 releases and pins served weights under small RL updates. This adds two opt-in inference options, one for each problem.

  • fp8_ue8m0_weight_scales uses power-of-two block scales, so a dequantized FP8 checkpoint round-trips exactly.
  • fp8_stochastic_weight_rounding rounds without bias, so served weights track sub-grid updates in expectation.
  • Validators reject either option without online per-block FP8, and stochastic rounding with an FP8 trainer.
  • Known limitation: stochastic rounding uses the global torch RNG, so TP ranks serve identical copies of replicated layers only while their RNG streams stay in lockstep.

🤖 Generated with Claude Code

@garrett361
garrett361 added this pull request to stack #4042 October 12, 2026 18:17
@garrett361
garrett361 marked this pull request as ready for review October 12, 2026 18:40
@garrett361
garrett361 force-pushed the feat/online-fp8-weight-rounding branch from 56236a6 to 5c2f018 Compare October 12, 2026 18:58
Base automatically changed from fix/dsv4-vllm-serving-patches to main October 12, 2026 19:02
garrett361 and others added 3 commits October 12, 2026 15:02
…FP8 weight scales

vLLM's online block-FP8 methods quantize weights with the scale amax / 448.
Dequantized FP8 releases such as the DeepSeek V4 bf16 checkpoint already sit on
the e4m3 grid under power-of-two block scales, so that scale choice injects the
full e4m3 rounding error on weights that would otherwise round-trip exactly.
The new opt-in field forces use_ue8m0=True in per_block_cast_to_fp8 through the
PRIME_FP8_UE8M0_WEIGHT_SCALES env var.

The option is independent of VLLM_USE_DEEP_GEMM_E8M0: vLLM's E8M0 requant finds
power-of-two scales already in place and leaves the weights alone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ne FP8 weights

Round-to-nearest pins a weight that starts on the e4m3 grid until the trainer
has moved it half a bin, about 1000 steps at lr 1e-6, so the served policy
stays at step 0 while the trainer drifts. Rounding each weight to its far
neighbour with probability equal to the fractional distance makes the served
weight unbiased and lets it track sub-bin updates in expectation. On-grid
input rounds to nearest, so the checkpoint quantizes to identical bytes.

The wrapper is registered after the UE8M0 one, so it composes with it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…fect

fp8_ue8m0_weight_scales and fp8_stochastic_weight_rounding patch vLLM's online
per-block FP8 caster, so they are silent no-ops unless vLLM quantizes linear or
MoE weights online to per-block FP8. InferenceConfig now raises in that case,
resolving the quantization shorthand and the quantization_config passthrough
the way vLLM's resolve_quantization_config does.

RLConfig also rejects fp8_stochastic_weight_rounding with an FP8 trainer
(dense FP8 or DeepGEMM FP8 MoE compute). The trainer re-quantizes its weights
with round-to-nearest every step, so stochastic rounding on the inference side
only adds trainer/inference mismatch.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@garrett361
garrett361 force-pushed the feat/online-fp8-weight-rounding branch from 5c2f018 to 64c3a04 Compare October 12, 2026 19:02
@garrett361 garrett361 closed this Oct 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant