NVIDIA a shipé FlashInfer 0.6.11 sans aucun cubin SM120/121 — FP4 MoE sur Blackwell grand public dead-on-arrival sur vLLM tant que ce gap n'est pas comblé

Salut les amis ! Ce matin, en triant les commentaires sur la vLLM PR #40082 “Integrate flashinfer b12x MoE + FP4 GEMM for SM120/121”, un blocker remonte qui confirme ce que certains d’entre nous notaient en silence sur les Blackwell grand public : NVIDIA a shipé FlashInfer 0.6.11 sans cubins SM120/121.

L’utilisateur AethoceSora a posté vers 05:00 UTC après un bringup de la PR sur un cluster DGX Spark 8-nodes (la plateforme de référence GB10) :

Two upstream blockers identified:

1. CUTLASS DSL MLIR→PTX bug → malformed _mma PTX
2. FlashInfer cubin gap: 0.6.11 ships only Sm100a/f/Sm103a cubins, zero SM120/121 binaries → falls back to wrong-arch kernels, “degenerate repetition” output. Recommendation: land with warning guard.

Ça touche tous ceux qui tournent :

• RTX 5090 Laptop / mobile (5090M) — sm_120, ce que j’ai dans mon Olares One
• RTX 5070 Ti / 5080 desktop — aussi sm_120
• DGX Spark / GB10 — sm_121

Toute personne qui a tenté de déployer un modèle quantisé NVFP4 (post-Q4) sur ces cartes via le path MoE FlashInfer de vLLM stock a probablement vu soit des erreurs de sélection de kernel, soit (plus insidieux) un output qui “marche” mais qui est du n’importe quoi — le pattern de boucle gibberish / répétition.

Ce qui est concrètement bloqué

Pour ma stack Olares One spécifiquement :

• sudo-0x2a/Qwen3.6-27B-NVFP4-GPTQ — je l’ai testé hier soir sur vllm/vllm-openai:tokenspeed-preview-x86_64-ubuntu2404 stock (vLLM 0.20.2). Ça boot et ça produit 31.79 t/s steady-state sans spec decoding. Pourquoi pas d’erreur FP4 ici ? Parce que Qwen3.6-27B n’est pas un MoE — les couches linéaires dense utilisent le FlashInferCutlassNvFp4LinearKernel de FlashInfer qui apparemment marche sur SM120 (juste lent). Le gap de cubins mord uniquement sur le path GEMM MoE que #40082 essaie d’introduire.

• nvidia/Gemma-4-26B-A4B-NVFP4 et autres quants MoE NVFP4 — ils heurteraient directement le gap de cubins. Tant que NVIDIA ne ship pas les cubins SM120 (ou que vLLM/FlashInfer ajoute un fallback Triton qui ne casse pas), faire tourner ces modèles sur Blackwell grand public avec FlashInfer stock = roll-dice sur la qualité d’output.

• vLLM TurboQuant + NVFP4 KV cache (PR #42345 “Support excluding SWA layers from NVFP4 KV cache”) — même dépendance arch.

Ce qui marche concrètement sur SM120 aujourd’hui

Testé live sur Olares One dans les dernières 24h :

Reco en attendant

Si vous tournez Blackwell grand public (5070 Ti / 5080 / 5090 / 5090M) :

1. Ne faites pas confiance aux quants NVFP4 MoE sur vLLM stock + FlashInfer tant que NVIDIA n’a pas shipé les cubins SM120 OU que vLLM ne land pas un guard comme celui recommandé par AethoceSora dans #40082.
2. Compressed-tensors WNA16-Marlin (AWQ-4bit) marche très bien — c’est le path que je ship en production pour Gemma 4 26B-A4B (cyankiwi) et Qwen3.6-27B (Lorbus AutoRound INT4 via Genesis).
3. llama.cpp Q4_K_M / Q3_K_XL / Q2_K_XL avec MTP speculative decoding sont mature et rapides — voir mon post Qwen3.6-27B MTP OOM fix pour la stack optimale actuelle.

Ce que j’aimerais que NVIDIA ship

NVIDIA : svp ajoutez les cubins SM120a / SM121a dans la prochaine release de FlashInfer. Les Blackwell grand public sont la plus grande base installée de GPU Blackwell aujourd’hui — verrouiller FP4 MoE sur ces cartes alors qu’il marche sur B200/B100 est une opportunité manquée.

En attendant, le thread review de PR #40082 est le meilleur endroit pour watch la résolution upstream. La reco de l’auteur du PR de “land with warning guard” pour que les utilisateurs aient au moins une erreur claire plutôt qu’un output garbage silencieux est le bon move court terme.

Repro Olares One (FlashInfer NVFP4 dense MARCHE sur SM120)

Si vous voulez confirmer que le path dense NVFP4 marche sur votre propre matos SM120 :

docker run --gpus all --rm \
  -v $(pwd)/models:/models \
  vllm/vllm-openai:tokenspeed-preview-x86_64-ubuntu2404 \
  vllm serve sudo-0x2a/Qwen3.6-27B-NVFP4-GPTQ \
  --served-model-name qwen3.6-27b-nvfp4 \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 28000 \
  --gpu-memory-utilization 0.95 \
  --max-num-seqs 1 --max-num-batched-tokens 4096 \
  --kv-cache-dtype fp8 --trust-remote-code \
  --download-dir /models

Attendez ~31 t/s sur RTX 5090M avec ce qui est ci-dessus. Si vous voyez de l’output “degenerate repetition” à la place, vous tapez un kernel wrong-arch — probablement un path MoE ou config KV cache différent. Essayez sans --kv-cache-dtype fp8 pour isoler.

Détails de stack complets + chart Helm dans orales-one-market.