Silent precision degradation: when W4A4 formats are served as W4A16 on pre-Blackwell hardware

PROXY ENUM VALUE - DECLARED 2026-10-04 (minor but load-bearing): this record documents silent precision degradation when W4A4 formats are served through a weight-only kernel, filed under 'nvfp4' because NVFP4 is the format the repo's other two records use for that failure mode. The phenomenon is general - it applies to any W4A4 format served at W4A16 - so do not read this as an NVFP4-specific defect. The nvfp4 record covers the format. THIS IS THE MOST IMPORTANT RECORD FOR THE REPO'S THEME. The documented cases of silent precision degradation: (1) SGLang's --fp4-gemm-backend auto-selection uses Marlin on SM80-SM90, which is a W4A16 kernel. An NVFP4 checkpoint loaded on an A100 or H100 will be served with Marlin, which dequantizes FP4 weights to FP16 and upcasts FP4 activations to FP16. The user sees the memory saving but not the compute speedup. (2) vLLM's modelopt_fp4 uses 'Marlin W4A16 fallback on Ampere/Hopper and native FP4 backends on Blackwell'. Same issue. (3) The vLLM --kernel-config example shows 'nvfp4_w4a16' as a quantization scheme name, which explicitly acknowledges that NVFP4 is being served as W4A16. This is a SILENT failure: the model produces correct results (the dequantization is numerically correct), but the user is not getting the performance they expected. The accuracy is also affected: the FP4 activation quantization is dropped, so the activation is effectively FP16, which is higher precision than expected. This means the accuracy is BETTER than expected, but the performance is WORSE than expected. The user may not realize that the FP4 activation quantization is not being used. This is the same pattern as the existing records: MXFP4 W4A16 misclassified as W4A4; FlashInfer W4A16 actually executing as W4A4; NVFP4 with w13 global scales; FP8 scatter not CUDA-graph safe; sliding-window attention plus fp8 KV plus speculative decoding causing silent corruption.