🦥Guide d’exécution d’Unsloth Dynamic NVFP4

Unsloth Dynamic NVFP4 est un format de modèle quantifié qui fonctionne sur les GPU NVIDIA Blackwell et est conçu pour une inférence 4 bits plus rapide et plus précise. Il combine la précision NVFP4 native de NVIDIA avec Unsloth Dynamic 2.0 la quantification afin de préserver la précision du modèle tout en réduisant l’utilisation de la VRAM et en augmentant la vitesse. Ce guide explique la quantification FP4, compare NVFP4 à d’autres formats et montre comment exécuter des modèles comme Qwen3.8, Gemma 4 et Qwen3.6 localement avec vLLM ou SGLang sur RTX 5050-5090, B200, RTX PRO 6000 et d’autres GPU.

Dynamic NVFP4 fonctionne en sélectionnant les couches importantes pour rester en FP8 (W8A8) ou BF16 et le reste en W4A4 (et non W4A16) au lieu de forcer chaque couche en FP4. Cela permet jusqu’à une inférence 2,5x plus rapide car W4A4 exploite les cœurs tensoriels FP4 du GPU Blackwell. Pour tous les quants, nous fournissons également un étalonnage du cache KV FP8 permettant des longueurs de contexte 2x plus longues.

Float4 contre d’autres précisions

L’astuce pour des GPU plus rapides consiste à réduire la précision numérique des multiplications matricielles. Le nombre de transistors nécessaires pour les unités de multiplication matricielle est lié au carré de la mantisse. La mantisse permet aux nombres d’avoir combien de décimales « fractionnaires » - donc plus il y a de bits, plus les décimales peuvent être représentées avec précision. Par exemple, exprimer 0.121332 est possible avec davantage de bits de mantisse, tandis qu’avec peu de bits de mantisse, cela sera arrondi à 0.1.

FP32 possède 23 bits de mantisse, donc 23^2 + 8 bits d’exposant = 537 unités d’espace sont nécessaires. Bfloat16 possède 7 bits de mantisse, donc 7^2 + 8 exposants = 57 unités d’espace. Cela signifie que bfloat16 nécessite environ 9x moins d’espace que FP32 ! Et lorsque l’on passe à float8, qui possède 3 bits de mantisse, donc 3^2 + 4 exposants = 13 - cela représente 41x moins d’espace que FP32 !

Enfin, float4 possède 1 bit de mantisse et 2 exposants, donc 3 unités d’espace - soit un énorme gain de 179x moins d’espace que FP32 - cela signifie essentiellement qu’un GPU peut effectuer environ 179x plus de multiplications matricielles FP4 que de FLOPs de multiplication FP32 dans le même espace!

NVFP4 contre MXFP4

Il existe un autre format FP4 appelé MXFP4 - il est moins précis que NVFP4 pour 2 raisons :

1. NVFP4 utilise une taille de bloc de 16 contre 32 pour MXFP4 - cela permet d’isoler plus facilement les valeurs aberrantes et des facteurs d’échelle sont fournis pour des sous-ensembles plus petits de poids, ce qui augmente la précision

2. Une échelle E4M3 (FP8) est utilisée à la place d’une E8M0 (mise à l’échelle par puissances de 2) par bloc. L’utilisation d’une taille de bloc de type FP8 semble bien meilleure, surtout pour les LLM.

Analyse des performances

Nos nouveaux quants Qwen3.6 NVFP4 dynamiques s’exécutent environ2,5x plus vite que les autres quants NVFP4, avec de meilleures performances et des tailles de fichier comparables. Exécutez Qwen3.6-27B NVFP4 2,5x plus vite sur 24 Go de VRAM et Qwen3.6-35B-A3B 1,7x plus vite sur 32 Go de VRAM. Nous avons également ajouté l’étalonnage du cache KV FP8 pour des longueurs de contexte 2x plus longues ! NVFP4 nécessite des GPU Blackwell de NVIDIA comme RTX 50X, DGX Spark (voir Unsloth Dynamic NVFP4), GPU B200, B300. Pour les GPU plus anciens, nos GGUF fonctionnent bien !

Tous les benchmarks utilisent 1x B200 avec 128 de concurrence. Une concurrence plus élevée peut porter le 35B à 17 561 tokens/s. Nous venons aussi de publier nos nouveaux Qwen3.8 quants NVFP4 :

• Qwen3.8-27B NVFP4 (nouveau)

Nous publions également deux versions NVFP4 35B-A3B :

• Qwen3.6-35B-A3B-NVFP4-Fast qui est un quant W4A4 complet - 1,79x plus rapide

• Qwen3.6-35B-A3B-NVFP4 qui est légèrement plus volumineux mais plus précis et 1,56x plus rapide

Pour les benchmarks de précision, nous avons exécuté MMLU-Pro, AIME 2025, GPQA pour FP8, BF16, le NVFP4 de NVIDIA et nos NVFP4 - nous montrons que nos quants plus rapides se comportent de manière similaire sur tous :

Les tenseurs MTP sont également intégrés directement dans les quants pour des gains de vitesse supplémentaires. Les gains de précision proviennent d’améliorations apportées au modèle de conversation et à l’étalonnage du jeu de données de Qwen3.6. Nous utilisons nos précédentes mises à jour du modèle de conversation pour améliorer la cohérence du codage et de l’appel d’outils tout en réduisant les boucles et d’autres problèmes signalés. Notre étalonnage utilise un mélange de notre jeu de données optimisé pour le codage, l’appel d’outils et le chat, ainsi qu’UltraChat.

Pour la vitesse de décodage (tokens par personne), la nôtre est 1,03x plus rapide pour 27B et 1,17x et 1,22x plus rapide pour 35B.

Aperçu

Vous trouverez ci-dessous les exigences matérielles pour les modèles que vous pouvez utiliser, notamment Gemma 4 et Qwen3.6. Consultez aussi le gain de vitesse global que vous obtiendrez :

Gemma 4 :

Qwen3.6 :

Benchmarks NVFP4

NVFP4 exécute directement les poids 4 bits et les multiplications matricielles sur les cœurs tensoriels Blackwell. Nos quants NVFP4 Qwen3.6 utilisent W4A4, donc ils utilisent réellement les cœurs tensoriels FP4, et décodent donc plus vite que ceux de NVIDIA, qui utilisent W4A16. Nous quantifions également les couches de manière dynamique pour conserver la précision, et nous avons réalisé MMLU-Pro, AIME 2025, GPQA pour tous les quants, y compris des comparaisons avec FP8 et BF16.

Benchmarks de précision Qwen3.6-27B NVFP4

Benchmarks de précision Qwen3.6-35B-A3B NVFP4

Nous avons également vérifié la longueur de sortie de tous les benchmarks, et elles sont comparables, donc les nouveaux quants NVFP4 ne réfléchissent pas plus longtemps, ce qui annule l’intérêt de les quantifier ! (c.-à-d. si c’est 2x plus rapide, mais qu’il réfléchit 2x plus, alors c’est inutile)

Lancer les tutoriels NVFP4

Pour exécuter les quants NVFP4, voir ci-dessous les commandes pour lancer Qwen3.6-27B dans vLLM et SGLang (vous pouvez remplacer le nom du modèle par Qwen3.6-35-A3B-NVFP4).

Tutoriel vLLM

Vous pouvez exécuter tous les modèles NVFP4 dans vLLM. Ne sélectionnez AUCUN backend MoE - laissez vLLM le sélectionner - par exemple Marlin est 2,5x plus lent ! Voir Unsloth Dynamic NVFP4Si vous avez un DGX Spark, voir Unsloth Dynamic NVFP4 vous devez utiliser --moe-backend flashinfer_b12x sinon l’inférence sera beaucoup plus lente.

Pour installer vLLM dans un venv séparé :

Puis, pour servir la variante 35B Fast :

Remplacez unsloth/Qwen3.6-35B-A3B-NVFP4-Fast par les noms des quants NVFP4 !

Pour activer MTP / le décodage spéculatif (décodage plus rapide mais débit quelque peu inférieur), utilisez :

Si vous avez des problèmes avec Torchcodec, assurez-vous de faire ce qui suit puis relancez vllm.

Tutoriel DGX Spark

Pour vous assurer que DGX Spark dispose des bons kernels (sinon vous obtiendrez une inférence 2x PLUS LENTE), vérifiez d’abord :

qui ne devrait PAS générer d’erreur - si c’est le cas, mettez à jour vllm ou réinstallez via :

Puis, pour servir dans vLLM sur DGX Spark :

Si vous avez des problèmes avec Torchcodec, assurez-vous de faire ce qui suit puis relancez vllm.

Tutoriel SGLang :

Vous pouvez exécuter tous les modèles NVFP4 dans SGLang. N’oubliez pas de remplacer le nom du modèle par celui de votre choix.

Qwen3.6 :

Gemma 4 :

Gemma 4 et autres

Chaque variante Gemma 4 dispose désormais d’un checkpoint Unsloth Dynamic NVFP4.

Nous montrons que Gemma-4 n’offre au maximum qu’un gain de débit de 1,44x lors du service de 128 personnes en concurrence sur 1x B200 par rapport à BF16. Qwen3.5-122B-A10B est 1,38x plus rapide et GLM-4.7-Flash est 1,27x plus rapide.

Marlin contre Flashinfer contre CUTLASS contre Cute-DSL

Nous avons également constaté que les kernels Marlin ne prennent pas bien en charge W4A4 - l’activer provoquera une dégradation des performances de 2,5x - utilisez donc CUTLASS, Flashinfer-TRTLLM ou Cute-DSL (activé automatiquement dans vLLM) ! Si vous avez aussi un DGX Spark, voir Unsloth Dynamic NVFP4 vous devez utiliser --moe-backend flashinfer_b12x sinon vous obtiendrez une inférence 2,5x plus lente.

Donc ne définissez aucun backend - vLLM sélectionne automatiquement le meilleur.