[Perf][SM70][FP8] Use bitcast E4M3 decoder in QSA

[Leonccaa]

Purpose

This stacked follow-up routes the generic Triton Qwen4Exp QSA E4M3 read path
to the existing exact bitcast software decoder on SM70.

Depends on #447. Until #447 merges, GitHub also shows its four parent
commits in this PR. This follow-up itself is one commit changing one import
(+1/-1).

This does not change the KV-scale overlay, loader gate, scale placement,
cache-write path, indexer cache, Flash-V100 grouped path, XQA path, or routing
policy. E4M3 still requires the checkpoint-revision-bound
model-kvscales.safetensors overlay described in #447 and fails closed unless
all 24 calibrated values are loaded.

Change

Bind the existing fp8_e4m3fn_bits_to_fp32 call-site name to
fp8_e4m3fn_bits_to_fp32_bitcast. The exact decoded FP32 values are unchanged,
while the generic Triton path avoids the scalar decoder's per-element exp2
work on SM70.

The call sites are deliberately left unchanged so the scale-hoisting change in
sibling draft #453 can be reviewed and merged independently.

Split and merge independence

Neither performance PR depends on the other: #452 and #453 both use #447 as
their only functional base, and both merge orders were checked locally without
conflicts. The combined tree calls the same bitcast decoder that was used for
the V100 numerical and performance validation before this review-only split.

Test plan

uv tool run pre-commit run --files \
  vllm/models/qwen4_exp/nvidia/ops/qsa.py
git diff --check 562bd404df000a6bc4f8410dd6e7e2ceffab302b..HEAD
PYTHONPATH=. python -m pytest -q tests/models/qwen4_exp/test_qsa_e4m3.py

The decoder regression in the #447 test set covers all 256 E4M3 byte
encodings, including finite-value equality and identical NaN masks.

Test results

• Full pre-commit over the changed file: passed, including ruff check/format,
  mypy, SPDX, forbidden-import, and attention-config checks.
• git diff --check: passed.
• CPU-only pytest collection: 6 CUDA tests skipped as expected.
• Both merge orders with [Perf][SM70][FP8] Hoist QSA E4M3 KV scales #453: conflict-free.
• All 256 decoder inputs on the combined validated tree: finite results were
  bit-exact with the scalar decoder and NaN masks were identical.

Combined SM70 validation provenance

The GPU numerical checks and formal performance matrix were run on the source
tree of #447 plus both optimizations before this review-only split
(d3a2c62c9a). The newly split combined tree
binds the same exact bitcast decoder and differs only in its local imported
symbol name; no kernel arithmetic or dispatch changed.

On that combined V100 / TP4 / MTP0 / FP16-activation tree:

• E4M3 long split-K versus FP32 dequant reference: max absolute error
  8.262693881988525e-06.
• Mixed grouped/XQA route versus optimized Triton reference: max absolute
  error 1.52587890625e-05, mean absolute error
  1.2406309224388679e-06.
• The formal matrix covered concurrency 1/4/8 x context
  1K/4K/16K/32K/64K/128K, with 17 E4M3 cells passing, one expected capacity
  skip (C8 x 128K), and all 87 scored requests completing.
• At the same memory budget, KV capacity was 507,093 FP16 tokens versus
  931,100 E4M3 tokens (1.836x). Across 15 matched cells, E4M3 decode was
  1.92% lower and server E2E elapsed time was 1.26% higher by geometric mean.

The measured optimization effect combines this PR and #453 and is near run
noise in aggregate; it must not be attributed independently to the decoder
switch. The result supports a small hot-loop simplification, not a global
speedup claim.

AWQ formal-r6 replication (2026-09-02)

The same combined #447 + #452 + #453 source composition was then validated
with a per-expert asymmetric AWQ W4A16 g32 checkpoint and FP8 E4M3 PLE splice.
The updated stacked branches also carry #447's dedicated-PLE-worker gate scope
fix; every GPU worker retains the 24/24 fail-closed scale gate.

• The SM70 numerical suite passed, including all 256 E4M3 encodings, FP16
  split-K parity, calibrated E4M3 single/split/long shapes, and the mixed
  grouped/XQA route.
• The fixed GMU 0.89 matrix covered concurrency 1/4/8 and
  1K/4K/16K/32K/64K/128K with three scored repeats per cell.
• FP16 completed 15/18 cells and E4M3 completed 17/18, with no failed cells;
  all 174 FP16 and 210 E4M3 scored requests produced 256 tokens.
• KV capacity increased from 310,480 FP16 tokens to 569,579 E4M3 tokens
  (1.8345x). C4 x 128K and C8 x 64K were E4M3-only capacity
  cells; both modes skipped C8 x 128K.
• Over the nine matched cells at 16K and longer, E4M3 prefill was 3.42% lower,
  decode was 2.54% lower, and server E2E elapsed time was 3.12% higher.

This replication again measures #452 and #453 together and does not attribute
the aggregate result to either optimization independently. The matching AWQ
quality acceptance and scale-calibration details are reported in #447.

Measurement caveats

• FP16 XQA uses P1024 while generic E4M3 G6 XQA uses P256, so reduction order
  is a second variable in FP16/E4M3 A/B runs that enter XQA.
• Synthetic performance output hashes are not quality evidence. The separate
  TP4/MTP0/128K quality, retrieval, held-out tool-task, selected-block, and
  attention-output acceptance remains in [Model][SM70][FP8] Add calibrated E4M3 QSA KV cache #447.

AI assistance disclosure

This PR was developed with OpenAI Codex assistance. The human submitter
reviewed the scope and supervised the numerical and end-to-end validation.

[yangzhuxinyzx]

Superseded by merged #462, which replays this runtime/test work onto current main, preserves #460 QSA workspace sharing, carries both E4M3 hot-loop follow-ups, and records the narrow TP4/MTP0 capacity contract and validation boundary.