[Performance] Use CuTe-DSL for FlashInfer MXFP4 quantization

[BWAAEEEK]

Summary

Use the CuTe-DSL backend for activation quantization in
FlashInferMxFp4LinearKernel.

The kernel is already selected only on SM100+ when FlashInfer CuTe-DSL is
available, and its following MXFP4 GEMM already uses the CuTe-DSL backend.
This change makes the activation quantization use the same backend while
keeping backend selection explicit at the kernel call site.

Fixes #48205.

Motivation

The default CUDA backend for flashinfer.mxfp4_quantize is a significant
bottleneck on B200. Changing only activation quantization to CuTe-DSL improves
both the quantization kernel and end-to-end MXFP4 serving performance.

This is not duplicate work. I checked the issue discussion and searched open
PRs for #48205, MXFP4 quantization, and CuTe-DSL backend changes before
starting and immediately before opening this PR; no open PR addresses this
fix.

Performance

Environment: NVIDIA B200 (SM100), FlashInfer 0.6.13, PyTorch 2.11.0+cu130,
CUDA 13.0.

An independent A/B benchmark covering 16 quantization shapes and corrected
Qwen3-8B-like linear shapes produced:

• quantization geometric-mean speedup: 4.74x eager, 6.13x CUDA Graph
• quantization + CuTe-DSL GEMM geometric-mean speedup:
  1.78x eager, 2.72x CUDA Graph

End-to-end nm-testing/Meta-Llama-3-8B-Instruct-MXFP4-GPTQ results with 64
prompts, 512 input tokens, 64 output tokens, five trials:

Mode	CUDA quant	CuTe-DSL quant	Change
Eager output throughput	1061.6 tok/s	1714.5 tok/s	+61.5%
Eager mean TTFT	311.4 ms	175.0 ms	-43.8%
CUDA Graph output throughput	4282.4 tok/s	6823.0 tok/s	+59.3%
CUDA Graph mean TTFT	292.6 ms	153.9 ms	-47.4%

Correctness and model evaluation

• CUDA and CuTe-DSL packed values and scales were bitwise identical for actual
  Llama-3-8B widths K={4096, 14336} across M=1..16384.
• Eager and CUDA Graph capture/replay quantization outputs were bitwise
  identical.
• Quantization plus the same CuTe-DSL GEMM produced bitwise-identical outputs
  across the benchmarked shape combinations.
• A single-request 8B greedy generation produced the same 128 token IDs.
• Full gsm8k_cot_llama evaluation, 1,319 samples, 8-shot, fixed batch size
  32, synchronous scheduling:

Metric	CUDA quant	CuTe-DSL quant
Flexible exact match	0.6255	0.6285
Strict exact match	0.6012	0.6058
Evaluation time	252.1 s	164.6 s

Concurrent batched generations have existing run-to-run numerical variation
with both backends, so concurrent token equality is not used as correctness
evidence.

Tests

VLLM_FLASHINFER_AUTOTUNE_SKIP_OPS=fp4_gemm \
  .venv/bin/python -m pytest \
  tests/quantization/test_compressed_tensors.py::test_compressed_tensors_mxfp4 \
  -v

Result: 1 passed.

.venv/bin/pre-commit run --files \
  vllm/utils/flashinfer.py \
  vllm/model_executor/kernels/linear/mxfp4/flashinfer.py

All applicable hooks passed, including ruff, formatting, mypy, SPDX, and
configuration validation.

AI assistance was used and I reviewed the results.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[mgoin]

Hi @BWAAEEEK thanks for the PR! Do you think this heuristic is something that could be put into flashinfer? My only concern is the cutedsl backend not working on all CUDA arches that the cuda backend does

[BWAAEEEK]

Thanks for review @mgoin , that is a good point. FlashInfer currently exposes explicit cuda and cute-dsl backends for mxfp4_quantize, with cuda as the default, but does not currently provide an auto selector.

In this vLLM path, FlashInferMxFp4LinearKernel.is_supported() already requires both current_platform.has_device_capability(100) and has_flashinfer_cutedsl(). The following MXFP4 GEMM in the same kernel is also already fixed to backend="cute-dsl". Therefore, this change does not route architectures below SM100, or installations without CuTe-DSL, through the CuTe-DSL quantizer.

I agree that a generic architecture-aware backend selection would ideally live in FlashInfer so other callers can benefit from it as well. Would you prefer that I move the selection upstream first, or is keeping the explicit backend at this already-gated vLLM kernel call site acceptable for this PR?