fix(fp8): round onto the e4m3 grid before the native float8e4nv downcast

[gdevenyi]

The bug

Triton lowers fp32 -> tl.float8e4nv as a double rounding: fp32 to fp16 with truncation, then fp16 to e4m3. A value just above a grid midpoint collapses onto the midpoint in the first step, and round-half-to-even then sends it down. The error is one-sided.

Measured on sm_89, 2^22 samples drawn uniformly from [-448, 448], against torch's RNE cast:

x.to(tl.float8e4nv)               16127 / 4194304 differ  (0.3845%)
   of those:  16127 toward zero,  0 away from zero
round_e4m3(x).to(tl.float8e4nv)       0 / 4194304 differ

  x=400.199585  triton=384.0  torch=416.0     (midpoint 400, ulp 32)
  x=272.156555  triton=256.0  torch=288.0     (midpoint 272)
  x=136.002075  triton=128.0  torch=144.0     (midpoint 136)

Setting fp_downcast_rounding="rtne" does not change it.

So every native-fp8 activation quantizer shrinks about 0.4% of its values by one unit in the last place, always toward zero. On the per-token-group quantizer that is a 0.02% bias in magnitude: mean|dequant| / mean|x| moves from 0.998937 to 0.999169. The bias is small, but it is one-sided, and it costs nothing to remove.

The emulated path for pre-sm_89 GPUs never had this. It goes through round_e4m3, whose docstring already warns about an fp32 to fp16 to 3-bit chain that double-rounds on a tie. The hazard was known when the emulation was written. Only the native branch skipped the guard.

The fix

Round onto the e4m3 grid in fp32 first, on both paths. The downcast is then exact and the lowering's rounding mode stops mattering.

• fp8_block_linear._act_quant_kernel
• fp8_pertensor_linear._static_quant_kernel
• dsv4/fp8_linear._act_quant_fp8_kernel
• dsv4/fp8_linear._act_quant_inplace_kernel, where the native branch's fp8 round trip only ever re-quantized a value already on the grid, so it collapses into the shared round_e4m3 call.

Test changes

tests/kernels/test_e4m3_compat.py::test_forced_emu_matches_native fails on main on sm_89 hardware, with blk_aq_y: EMU output differs from native, 52 of 18944 elements. The forced-emulation A/B is what catches this, because the emulation was the correct side.

Two changes there:

1. test_native_downcast_needs_the_grid_round pins the invariant directly, so a later change cannot make the emulation match the native bug instead. It deliberately does not assert that the bare downcast is wrong: a future Triton may lower it correctly, and the pre-round would then be redundant rather than incorrect.

2. The three GEMM keys that compare an fp8 MMA against a bf16 MMA get a bound on the tensor scale instead of an elementwise one. Triton selects different MMA shapes for fp8 x fp8 and bf16 x bf16, so the fp32 reduction trees differ and the results land about one output ULP apart. The file's own comment predicted this: bit-exact on H100 is "lowering luck, not a guarantee", and it is not bit-exact on sm_89. moe_prefill_fp8 chains two such GEMMs and then sums top-k outputs of magnitude 8e3 down to about 2e2, so an error worth 2e-3 of the GEMM scale reads as 13% elementwise. Bounding against max|ref| measures the GEMM's own error rather than the cancellation:

   key	max abs diff	max abs ref	ratio
   blk_gemm	0.5	109	4.6e-3
   dsv4_gemm	4	1240	3.2e-3
   moe_prefill_fp8	16	8256	1.9e-3

   The limit is 1e-2.

Testing

RTX 6000 Ada, sm_89. tests/kernels/test_e4m3_compat.py on main with this PR: 9 passed. On main without it: 1 failed, 7 passed.

Found while reviewing #48. That PR does not cause the failure; I reverted it and reproduced the failure on main.