vLLM NVFP4 registry contains two kernels whose is_supported() tests only has_flashinfer() and has no compute-capability gate at all (FlashInferTrtllmNvFp4LinearKernel, FlashInferCudnnNvFp4LinearKernel)

Read 2026-10-05 from vLLM main @ 528772a4. This is a VERIFIED NEGATIVE about the safety of the FP4 capability gate, and it cuts against the assumption in the existing repo advice that 'your GPU has native FP4' is answerable from the engine's own gate list. Two classes in vllm/model_executor/kernels/linear/nvfp4/flashinfer.py, both quoted: class FlashInferTrtllmNvFp4LinearKernel(NvFp4LinearKernel) docstring 'NVFP4 GEMM via FlashInfer's TensorRT-LLM wrapper.', is_supported() body is exactly `if has_flashinfer(): return True, None` / `return False, 'FlashInfer required'`, and can_implement() body is exactly `return True, None`. class FlashInferCudnnNvFp4LinearKernel(NvFp4LinearKernel) docstring 'NVFP4 GEMM via FlashInfer's cuDNN wrapper.' has the IDENTICAL is_supported() and can_implement() bodies. Neither inspects compute_capability. By contrast, every other kernel in the same registry that can serve NVFP4 W4A4 IS arch-gated, and the contrast is the point: FlashInferCuteDslNvFp4LinearKernel requires is_device_capability_family(100) ('FlashInfer cutedsl requires sm_10x'); FlashInferCutlassNvFp4LinearKernel requires cutlass_fp4_supported() AND has_device_capability(100) AND has_flashinfer(); FlashInferB12xNvFp4LinearKernel requires has_device_capability(120) and has_flashinfer_b12x_gemm(); CutlassNvFp4LinearKernel requires cutlass_fp4_supported(); TorchNvFp4LinearKernel requires is_device_capability_family(100), torch._scaled_mm and torch.float4_e2m1fn_x2; FlashInferCuteDslNvFp4W4A16LinearKernel (the weight-only one) requires compute_capability in (100, 103) or 120<=cc<130 AND has_flashinfer_bf16_fp4(); FbgemmNvFp4LinearKernel requires only has_fbgemm_gpu(); MarlinNvFp4LinearKernel requires only is_fp4_marlin_supported() = is_cuda() and has_device_capability(75). So in the CUDA NVFP4 registry, six of thirteen entries carry a real architecture gate, and the two that would be chosen on a Hopper or Ampere box when FlashInfer is installed (FlashInferTrtllm at index 6, FlashInferCudnn at index 7) carry none. Selection is first-match-wins (init_nvfp4_linear_kernel iterates the list in order and returns the first kernel passing both is_supported and can_implement), so with FlashInfer installed these two are reachable on a V100. The practical reading, and it is a limit on the existing advice rather than a refutation of it: the repo's recommended probe torch.ops._C.cutlass_scaled_mm_supports_fp4(capability) remains the correct way to ask about native CUTLASS FP4 specifically, but it is NOT a complete answer to 'will vLLM use an FP4 tensor-core GEMM for my NVFP4 checkpoint', because on an SM80 part with FlashInfer installed the selector can reach a kernel that has asserted no architecture support and whose real failure will surface inside FlashInfer's own dispatch rather than in vLLM's gate list. No repository record states this.