FP4 n'existe pas : il existe des FP4, et chaque runtime choisit son dialecte

Le FP4 n’est pas un format — c’est un territoire

Il y a un an, la conversation sur la basse précision se résumait à « FP8 ou INT4, et lequel tenir sur mon GPU ». Les fondamentaux des formats FP4 — blocs de valeurs E2M1 partageant un facteur d’échelle, portée dynamique restaurée par le microscaling — sont désormais acquis. Ce qui a changé depuis, ce n’est pas le principe : c’est la fragmentation.

En mai 2026, dire « je fais du FP4 » ne veut plus rien dire de précis. Derrière ce label coexistent au moins trois familles de formats distinctes — MXFP4 MXFP4 Microscaling FP4. Format à blocs où 32 valeurs FP4 partagent un facteur d'échelle commun. C'est ce facteur d'échelle partagé qui permet de tenir en 4 bits sans effondrer la précision. La variante NVFP4 de NVIDIA utilise des blocs plus fins (16 valeurs). (le standard ouvert OCP), NVFP4 (la variante propriétaire NVIDIA), et W4A4 (poids et activations en 4 bits, sans postulat sur le format de bloc) — auxquelles s’ajoutent des schémas hybrides comme TurboQuant pour le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. . Chaque runtime d’inférence — vLLM, SGLang, TensorRT-LLM, llama.cpp — en implémente un sous-ensemble différent, sur un sous-ensemble de matériel différent, avec des kernels différents.

La question de 2026 n’est plus « FP4 FP4 Format à virgule flottante 4 bits — la frontière 2026 de l'inférence à haut débit. Quatre fois moins de mémoire que le FP16, mais une portée dynamique très étroite : ne tient qu'avec un scaling fin via formats à blocs (MXFP4, NVFP4). ou non ». C’est : quel FP4, sur quel GPU, via quel runtime — et quelles sont les conséquences sur la qualité, le débit et la portabilité.

Deux dialectes, deux stratégies de scaling

NVFP4 et MXFP4 partagent les mêmes éléments de base : chaque valeur est codée en E2M1 — 2 bits d’exposant, 1 bit de mantisse, soit 8 niveaux exploitables (plus le signe). Ce qui les sépare, c’est la manière dont le facteur d’échelle restaure la portée dynamique que ces 4 bits seuls n’ont pas.

MXFP4, défini par la spécification OCP MX v1.0, regroupe 32 valeurs par bloc. Chaque bloc partage un exposant E8M0 — 8 bits d’exposant, pas de mantisse — qui ne peut représenter que des puissances de deux. C’est un compromis délibéré : l’absence de mantisse dans l’exposant rend le circuit de scaling très simple, mais force l’échelle à « sauter » par pas de ×2. Si la plage réelle du bloc tombe entre deux puissances de deux, la résolution effective se dégrade — le format n’a pas de demi-mesure.

NVFP4 prend une dose supplémentaire de précision à deux endroits. D’abord, les blocs sont plus fins — 16 valeurs au lieu de 32 — ce qui limite l’hétérogénéité au sein d’un bloc : un outlier ne contamine que 15 voisins au lieu de 31. Ensuite, le scaling est à deux niveaux : un facteur par bloc codé en E4M3 (qui dispose d’une mantisse, donc d’un positionnement continu de l’échelle) et un facteur global par tenseur en FP32. Le premier ajuste finement chaque bloc ; le second recale l’ensemble. Le résultat est un meilleur encadrement des distributions à longue traîne — exactement celles que produisent les couches d’attention des LLM modernes.

Le prix de cette précision se mesure en silicium. Le scaling à deux niveaux et les blocs plus fins demandent environ 6 % de surface supplémentaire dans les Tensor Cores Tensor Cores Unités matérielles spécialisées dans les multiplications de matrices à basse précision, introduites par NVIDIA avec Volta (2017). Chaque génération ajoute des formats supportés : FP16 → FP8 (Hopper) → FP6/FP4 (Blackwell). Ce sont elles qui exécutent l'essentiel du calcul d'inférence. par rapport à l’implémentation MX standard. Le standard MXFP4 économise environ 12 % de surface dans le tensor core — un écart que les concepteurs de puces portables ou les architectures multi-chiplet ne négligent pas.

Caractéristique	NVFP4	MXFP4
Éléments	E2M1 (4 bits)	E2M1 (4 bits)
Taille de bloc	16 valeurs	32 valeurs
Format de l'échelle	E4M3 par bloc + FP32 par tenseur	E8M0 par bloc (puissance de 2)
Scaling	Deux niveaux (continu)	Un niveau (discret)
Bits effectifs / valeur	~4,5 bits	~4,25 bits
Surface tensor core (relative)	+6 % vs MX	Référence (−12 % vs NVFP4)
Spécification	Propriétaire NVIDIA	OCP MX v1.0 (ouvert)
Matériel natif	Blackwell (NVIDIA)	Blackwell (NVIDIA), CDNA3/4 (AMD)

Ce tableau ne dit pas lequel est « meilleur ». Il dit que NVFP4 est conçu pour maximiser la qualité quand le silicium et le runtime sont NVIDIA de bout en bout, et que MXFP4 est conçu pour être le format interopérable — celui que plusieurs fournisseurs peuvent implémenter sans licence propriétaire. La fragmentation commence ici, dans le silicium, avant même que le runtime ne s’en mêle.

L’écart de qualité — et comment il se réduit

L’intuition serait que les blocs plus fins et le scaling à deux niveaux de NVFP4 dominent systématiquement MXFP4. Les mesures confirment un avantage — mais pas un gouffre, et l’écart se ferme rapidement.

Le papier « Diagnosing FP4 inference » (Cim et al., arXiv 2603.08747) a produit une analyse couche par couche et bloc par bloc de la sensibilité des deux formats. Les couches d’attention, dont la distribution comporte davantage d’outliers, pénalisent davantage MXFP4 que les couches MLP — ce qui confirme le mécanisme : les blocs de 32 avec un exposant en puissance de deux encaissent moins bien les valeurs extrêmes.

Le papier « Unveiling the Potential of Quantization with MXFP4 » (arXiv 2603.08713) chiffre l’écart brut à environ 10 % en moyenne sur les benchmarks de qualité — et propose deux techniques pour le refermer. La première, Overflow-Aware Scaling (OAS), ajuste le facteur d’échelle par bloc pour éviter la saturation des valeurs extrêmes au lieu de minimiser l’erreur quadratique moyenne, ce qui revient à privilégier les outliers plutôt que les valeurs centrales. La seconde, Macro Block Scaling (MBS), ajoute un facteur d’échelle de second niveau — un « macro-bloc » qui regroupe plusieurs blocs de 32 — pour rapprocher le comportement de celui d’un scaling à deux niveaux, sans modifier le format de base. Résultat : l’écart moyen MXFP4 vs NVFP4 passe de ~10 % à moins de 1 %, pour un surcoût GEMM de 6,2 % en moyenne.

Côté NVFP4, NVIDIA a publié QAD — « Quantization-Aware Distillation for NVFP4 Inference Accuracy Recovery » (arXiv 2601.20088, janvier 2026, révisé en mars). Le principe : distiller un modèle BF16 vers un modèle NVFP4 en faisant passer les gradients à travers le schéma de quantification, plutôt que de quantifier post-entraînement et espérer que les poids tiennent. Sur Nemotron 3 Nano, Nemotron Nano V2, AceReason Nemotron et Llama Nemotron Super v1, QAD récupère une précision quasi-BF16 — ce qui fait du NVFP4 avec distillation un format de production, pas un compromis expérimental.

Les runtimes et leurs dialectes : qui parle quoi

C’est dans la couche runtime que la fragmentation devient concrète. Un format FP4 n’existe pas dans le vide — il n’existe que là où un kernel le calcule, sur un GPU qui sait le décoder, dans un runtime qui expose l’option. Voici l’état du terrain en mai 2026.

vLLM 0.20–0.21 : le hub multi-dialecte

vLLM 0.20.0 (avril 2026) a posé les fondations : CUDA 13 par défaut, FlashAttention FlashAttention Implémentation tile-by-tile de l'attention qui évite de matérialiser la matrice d'attention complète en HBM. Réduit drastiquement la consommation mémoire et accélère le calcul, particulièrement sur longs contextes. Trois versions (v1/v2/v3), chacune optimisée pour une génération de GPU. 4 comme backend de prefill par défaut sur SM90+, et un frontend de quantification en ligne qui permet de quantifier à la volée sans pré-conversion. La version 0.21.0 (mai 2026) étend la couverture FP4 sur deux fronts — le backend Humming MXFP4 MoE pour les architectures Mixture-of-Experts, et l’intégration du TRT-LLM NVFP4 fused MoE pour Gemma4 sur Blackwell.

vLLM 0.21 est aussi le premier runtime à revendiquer des chiffres de production à l’échelle : le blog « vLLM Tops Artificial Analysis » (mai 2026) annonce 230 tokens par seconde par utilisateur sur DeepSeek V3.2 sur Blackwell Ultra — un chiffre qui reflète la combinaison NVFP4 + FlashAttention 4 + batching continu sur du matériel de pointe.

Le benchmark de Benjamin Marie (Data Science Collective, 2026) illustre le gain sur matériel plus accessible. Sur une RTX 6000 Pro (94 Go de VRAM), vLLM v0.10.0 avec NVFP4 affiche un facteur 2,35× de throughput par rapport au FP16 — pas « 2-3× » comme on le lit parfois, mais un chiffre reproductible sur cette configuration précise.

SGLang 0.5.12 : le pari W4A4 et l’ouverture AMD

SGLang 0.5.12 (mai 2026) prend un chemin différent. Les kernels W4A4 MegaMoE quantifient poids et activations en 4 bits — un mode plus agressif que le NVFP4 ou le MXFP4 qui ne quantifient que les poids. Le gain de débit est plus élevé, la pression mémoire réduite sur les deux axes, mais la sensibilité aux distributions d’activations est aussi plus grande.

Le signal le plus significatif : SGLang est le premier runtime majeur à proposer du MXFP4 sur CDNA3 et CDNA4 — les architectures AMD des MI300 et MI350. C’est le point d’entrée du FP4 dans l’écosystème AMD, via le standard ouvert plutôt que via un format propriétaire. S’y ajoutent des kernels W4A8 MoE sur Hopper (via Marlin et FlashInfer) et le support EAGLE sur Qwen3.5 FP8/MXFP4 via aiter unified attention — un pipeline de décodage spéculatif qui exploite la basse précision pour accélérer la vérification des candidats.

TensorRT-LLM 1.3 : NVFP4 natif, verrouillé NVIDIA

TensorRT-LLM 1.3, en série de release candidates depuis mai 2026 (rc12.post1, rc14, rc15), supporte NVFP4, FP8 FP8 Format à virgule flottante 8 bits. Format de travail polyvalent pour l'inférence (et l'entraînement) sur GPU récents. Divise par 2 l'empreinte mémoire et le débit nécessaires par rapport au FP16, pour une perte de précision marginale sur la plupart des modèles. et MXFP4 sur Blackwell et DGX Spark. Le modèle est le même que celui du comparatif des runtimes : un engine compilé, lié à une version exacte du GPU et du driver, qui extrait le maximum sur le matériel cible au prix de la portabilité.

La valeur ajoutée de TRT-LLM en FP4 est dans la fusion de kernels — la quantification, le scaling, la matmul et le de-scaling s’exécutent en un seul lancement CUDA, sans round-trip en HBM HBM High Bandwidth Memory. Mémoire empilée en couches, soudée à proximité immédiate du GPU, avec une bande passante de plusieurs To/s — contre ~50 Go/s pour de la DDR5. Indispensable au-delà d'une certaine taille de modèle. entre les étapes. Sur des architectures MoE comme Gemma4, le kernel fusionné NVFP4 est intégré dans vLLM 0.21 comme backend optionnel — TRT-LLM fournit le kernel, vLLM fournit l’orchestration.

Toutes les versions 1.3 publiées à ce jour sont des release candidates, pas des versions GA. C’est un détail qui compte pour un déploiement en production.

llama.cpp : le nouveau venu FP4

llama.cpp a longtemps été absent du terrain FP4 — son domaine était le GGUF GGUF GPT-Generated Unified Format. Format de fichier de llama.cpp qui stocke dans un seul fichier les tenseurs, leurs types de quantification, le vocabulaire et les métadonnées du modèle. Sa structure alignée permet de le lire par mmap — le modèle « démarre » en une fraction de seconde. entier (Q4_K, Q5_K) sur des backends portables. Le PR #22196 (fusionné le 28 avril 2026, repost de #21896 par michaelw9999) change la donne : un nouveau type GGML GGML_TYPE_NVFP4 (type 40) avec des kernels pour CUDA (dp4a), MMQ, SYCL, Vulkan et les Tensor Cores Blackwell.

L’impact mémoire se mesure directement : Qwen 3.6-27B passe de ~17 Go en Q4_K_M à ~14 Go en NVFP4 — une réduction de ~18 % à nombre de bits comparable. Le gain ne vient pas d’un meilleur taux de compression (les deux sont autour de 4 bits par poids) mais du format de bloc plus compact de NVFP4, qui amortit l’échelle sur moins de valeurs et élimine les métadonnées de super-bloc que Q4_K transporte.

Le fork ik_llama.cpp (Iwan Kawrakow) ajoute le support MXFP4 — ce qui fait de l’écosystème llama.cpp le seul où les deux dialectes coexistent, même si c’est à travers deux codebases distinctes.

Runtime	NVFP4	MXFP4	W4A4	KV cache FP4	Matériel cible
vLLM 0.21	Oui (TRT-LLM MoE)	Oui (Humming MoE)	—	TurboQuant 2-bit	Blackwell, Hopper (SM90+)
SGLang 0.5.12	—	Oui (CDNA3/4)	Oui (MegaMoE)	—	Hopper, CDNA3, CDNA4
TensorRT-LLM 1.3 (rc)	Oui	Oui	—	—	Blackwell, DGX Spark
llama.cpp (HEAD)	Oui (type 40)	— (fork ik_llama)	—	—	CUDA, SYCL, Vulkan, Blackwell

Au-delà des poids : le KV cache entre dans la danse

La quantification FP4 des poids ne résout que la moitié du problème mémoire. Sur des contextes longs, c’est le KV cache qui sature la VRAM en premier — et la frontière de 2026 se déplace vers la quantification agressive du cache lui-même.

TurboQuant (ICLR 2026, Google Research + NYU, arXiv 2504.19874) pousse cette logique jusqu’à ~3 bits par coordonnée. Le mécanisme repose sur deux étages. Le premier, PolarQuant, applique une rotation orthogonale aléatoire aux vecteurs K/V avant quantification — l’effet est de « gaussianiser » la distribution, c’est-à-dire de transformer une distribution à longue traîne en une distribution plus uniforme que la quantification uniforme encaisse sans perte excessive. Le signal analogique le plus proche est un compresseur-expanseur (compandor) en télécommunications : on transforme la distribution du signal avant la quantification pour que chaque pas de quantification porte autant d’information. Le second étage, 1-bit QJL (quantized Johnson-Lindenstrauss), ajoute une correction résiduelle à 1 bit par coordonnée qui récupère l’information perdue par la rotation et la quantification grossière.

Le résultat : une qualité maintenue à 3,5 bits par coordonnée (quality-neutral), avec une dégradation marginale à 2,5 bits. Les gains annoncés — 6× de réduction mémoire sur le KV cache, 8× d’accélération de l’attention sur H100 — sont mesurés par rapport à une baseline FP32, pas FP16. Par rapport au FP16 que la plupart des déploiements utilisent déjà, les facteurs sont environ la moitié. Cela reste un gain massif : un contexte de 128k tokens qui saturait 80 Go en FP16 tient sous 15 Go en TurboQuant 3-bit.

vLLM 0.20 intègre TurboQuant comme option de KV cache sous les identifiants turboquant_3bit_nc et turboquant_4bit_nc, avec support FlashAttention 3 et 4. C’est la première fois qu’un runtime grand public offre un cache à moins de 4 bits par coordonnée en production — et cela déplace le goulot mémoire des contextes longs vers les poids eux-mêmes, ce qui renforce la pertinence du FP4 sur les poids.

FlashAttention 4 : le kernel qui rend tout cela praticable

L’accélération des formats basse précision dans le KV cache ne sert à rien si le kernel d’attention ne sait pas les consommer efficacement. FlashAttention 4 (arXiv 2603.05451, Tri Dao, Together AI, mars 2026) est le chaînon manquant. Écrit en CuTe-DSL plutôt qu’en CUDA brut, FA4 atteint 1 613 TFLOPs/s à 71 % d’utilisation sur Blackwell — soit 1,5 à 2× le débit d’attention de FA3 sur les séquences longues. C’est le backend de prefill par défaut de vLLM 0.20 sur SM90+, et le kernel que TurboQuant utilise pour matérialiser son gain théorique en gain de débit réel.

FA4 est forward-only — pas de backward pass, donc pas d’entraînement. Pour l’inférence, où seul le forward compte, c’est sans conséquence. Ce qui compte, c’est que FA4 est le premier kernel d’attention à être conçu pour les formats basse précision du KV cache plutôt qu’adapté après coup.

La frontière 2-3 bits : GSQ et la quantification scalaire

Le mouvement ne s’arrête pas au FP4. Le papier GSQ — « Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling » (arXiv 2604.18556) — explore la quantification scalaire à 2-3 bits, sans format de bloc. Le principe : plutôt que de fixer les bornes de quantification et d’arrondir chaque poids au niveau le plus proche, GSQ traite l’affectation de chaque poids à un niveau de quantification comme un problème d’échantillonnage différentiable via Gumbel-Softmax. Les bornes et les affectations s’optimisent conjointement, ce qui donne un meilleur placement des niveaux de quantification que GPTQ ou QuIP à 2 bits.

À 2-3 bits, GSQ se rapproche de la frontière QTIP — le meilleur résultat connu en quantification non structurée — sans en utiliser les transformations non linéaires. C’est un indicateur que la limite pratique de la quantification des poids descend encore, et que les runtimes de 2027 devront probablement gérer du 2-3 bits aussi naturellement qu’ils gèrent du 4 bits aujourd’hui.

Comment choisir son dialecte

Le choix ne se fait pas sur le format mais sur trois contraintes qui se combinent.

Le matériel dicte le format natif. Sur Blackwell, NVFP4 et MXFP4 sont tous les deux câblés dans les Tensor Cores — mais NVFP4 bénéficie de l’outillage NVIDIA (QAD, TRT-LLM fusionné). Sur CDNA3/CDNA4 (AMD MI300/MI350), seul MXFP4 est disponible nativement — et SGLang est le seul runtime majeur à l’exposer sur ce matériel. Sur Hopper, aucun des deux n’est natif : le plancher matériel reste le FP8, et le « FP4 sur Hopper » passe par de la dé-quantification logicielle qui ne donne ni le débit ni la pression mémoire du natif. Hors NVIDIA et AMD, Google a câblé le FP4 natif dans ses TPU 8t/8i — sa pile logicielle TorchTPU/XLA est détaillée ici.

Le runtime dicte le sous-ensemble accessible. Si vous opérez vLLM sur Blackwell, vous accédez à NVFP4 via TRT-LLM et à MXFP4 via Humming — mais pas à W4A4. Si vous opérez SGLang, vous accédez à W4A4 et MXFP4 sur AMD — mais pas à NVFP4. Le format « universel » n’existe pas encore. Le choix du runtime précède le choix du format.

Le modèle dicte la tolérance. Les architectures denses (Llama, Qwen) et les architectures MoE (DeepSeek, Gemma4) ne réagissent pas de la même façon à la quantification FP4. Les MoE, dont seuls quelques experts sont actifs par token, concentrent davantage d’information par paramètre actif — ce qui les rend plus sensibles à la quantification par poids. C’est précisément pour cette raison que vLLM 0.21 et SGLang 0.5.12 développent des kernels MoE spécifiques (Humming, MegaMoE, TRT-LLM fused MoE) plutôt que d’appliquer la quantification FP4 naïve aux poids de chaque expert.

Conclusion

La prochaine fracture ne sera pas entre NVFP4 et MXFP4 — le gap de qualité se ferme, et les runtimes intègrent les deux. Elle sera entre les piles qui unifient la quantification des poids et du KV cache dans un seul pipeline cohérent, et celles qui les traitent comme deux problèmes séparés. TurboQuant à 2-3 bits sur le cache, NVFP4 ou MXFP4 sur les poids, FlashAttention 4 comme kernel d’attention — la pile complète existe déjà dans vLLM 0.21, en fragments. La question qui s’ouvre pour les runtimes de fin 2026 est de savoir lequel assemblera ces fragments en une abstraction unique, où l’opérateur spécifie une enveloppe mémoire et le runtime choisit le dialecte, la granularité de scaling et le schéma de cache — sans que l’utilisateur ait à naviguer la carte des dialectes lui-même.

Sources et méthode

Formats NVFP4 et MXFP4. Spécifications NVFP4 (bloc 16, scaling deux niveaux E4M3 + FP32) : NVIDIA Developer Blog — Introducing NVFP4 (fait vérifié). Spécification MXFP4 (bloc 32, E8M0) : OCP Microscaling (MX) Formats Specification v1.0, Open Compute Project (fait vérifié). Écart de surface silicium (~6 % NVFP4 vs MX, ~12 % d’économie MX) : arXiv 2603.08713, « Unveiling the Potential of Quantization with MXFP4 » (fait vérifié).

Qualité MXFP4 vs NVFP4. Écart brut ~10 %, réduction à moins de 1 % via OAS + MBS, surcoût GEMM 6,2 % : arXiv 2603.08713 (fait vérifié). Analyse couche par couche de la sensibilité : Cim et al., arXiv 2603.08747, « Diagnosing FP4 inference » (fait vérifié).

QAD (distillation NVFP4). Récupération quasi-BF16 via distillation sur Nemotron et Llama Nemotron : arXiv 2601.20088, révisé mars 2026 (fait vérifié).

Benchmark NVFP4. Speedup 2,35× sur RTX 6000 Pro (94 Go), vLLM v0.10.0 : Benjamin Marie, « NVFP4: Same Accuracy with 2.3x Higher Throughput for 4-Bit LLMs », Data Science Collective / Medium (fait vérifié — matériel = RTX 6000 Pro, pas DGX Spark).

NVFP4 dans llama.cpp. PR #22196 fusionné le 28 avril 2026, type GGML 40, kernels CUDA dp4a / MMQ / SYCL / Vulkan / Blackwell TC. Mémoire Qwen 3.6-27B : ~17 Go (Q4_K_M) → ~14 Go (NVFP4) (fait vérifié). Fork ik_llama.cpp avec MXFP4 : dépôt ikawrakow (fait vérifié).

vLLM 0.20.0 (27 avril 2026) : CUDA 13, FlashAttention 4, TurboQuant 2-bit KV, frontend de quantification en ligne (fait vérifié). vLLM 0.21.0 (15 mai 2026) : Humming MXFP4 MoE, TRT-LLM NVFP4 fused MoE Gemma4, 230 TPS/utilisateur DeepSeek V3.2 sur Blackwell Ultra (fait vérifié — blog vLLM, 11 mai 2026).

SGLang 0.5.12 (16 mai 2026) : W4A4 MegaMoE, W4A8 MoE Hopper (Marlin/FlashInfer), MXFP4 CDNA3/CDNA4, EAGLE Qwen3.5 FP8/MXFP4 (fait vérifié).

TensorRT-LLM 1.3 : rc14 (7 mai), rc12.post1 (16 mai), rc15 (21 mai 2026). NVFP4, FP8, MXFP4 sur DGX Spark. Toutes les versions publiées sont des release candidates, pas GA (fait vérifié).

TurboQuant. ICLR 2026, Google Research + NYU, arXiv 2504.19874. PolarQuant + 1-bit QJL, ~3 bits/coordonnée quality-neutral. 6× réduction KV, 8× accélération attention sur H100 — baseline FP32, pas FP16. Intégré vLLM 0.20 (turboquant_3bit_nc / turboquant_4bit_nc) (fait vérifié).

FlashAttention 4. arXiv 2603.05451, Tri Dao (Together AI), mars 2026. 1 613 TFLOPs/s, 71 % utilisation Blackwell, 1,5-2× vs FA3 sur séquences longues. Forward-only (fait vérifié).

GSQ. arXiv 2604.18556, « Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling ». Améliore GPTQ/QuIP à 2 bits, se rapproche de QTIP à 2-3 bits (fait vérifié).

Tous les faits relevés au 24 mai 2026.