_nvfp4_quantize copied every activation into a zero-padded buffer (F.pad
copies even when no rows are added) before FlashInfer quantization. For
the 128x4 swizzled layout FlashInfer already pads the scale factors to
whole row tiles and quantizes the logical rows exactly as it would the
padded copy, so quantize the input directly and keep the padded path as
a fallback when the returned scales do not span the padded tile.
On DGX Spark the pad accounted for about 2.7k device copies plus the
matching fills per FastH3 Trim denoise (about 6 s of 62 s). Quantized
bytes, scale factors and mm_fp4 outputs are bit-identical for the H3
projection shapes, and a FastH3 Trim 832x480x124 clip is bit-identical
with denoise at 72 s instead of 78 s.
The GB10 quantization fence stays: without it, identical seeded requests
still diverge with or without the pad copy, on FlashInfer 0.6.18 and
0.7.0. Its comment and the Spark guide now describe it without the
padded input. The off-Spark fence test skips on GB10, where the fence is
expected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
