Miles Blackwell remplace l’uniformité BF16 par MXFP8 et NVFP4 natifs

La prise en charge de Miles Blackwell comprend désormais deux recettes natives d’apprentissage par renforcement à faible précision, testées dans six configurations sur huit GPU NVIDIA B200. L’une utilise MXFP8 pour le rollout et l’entraînement. L’autre applique NVFP4 par jeton aux poids de mixture-of-experts tout en conservant une précision plus élevée ailleurs.

Le résultat remet en cause une hypothèse familière sur l’apprentissage par renforcement, ou RL. Une précision plus faible n’implique pas nécessairement l’acceptation d’une courbe d’apprentissage manifestement moins bonne. Dans l’ablation Qwen3-30B-A3B de Miles, les cinq configurations à faible précision ont suivi de près les récompenses brutes de référence en BF16.

Cette conclusion comporte une importante réserve. L’expérience était une ablation contrôlée de recettes, et non un benchmark d’entraînement entièrement optimisé ni une garantie générale de précision. Miles a également conservé BF16 dans les couches sensibles, maintenu une copie supplémentaire des poids en BF16 et observé des pics de gradient NVFP4 occasionnels.

La véritable comparaison n’oppose donc pas simplement quatre bits à seize bits. Elle oppose un contrat de précision cohérent et sélectif à un pipeline BF16 uniforme. Miles soutient que les formats natifs de Blackwell deviennent utiles lorsque l’entraînement, l’échantillonnage, la conversion et les mises à jour de poids en direct quantifient les mêmes tenseurs de la même manière.

La prise en charge de Miles Blackwell couvre désormais l’ensemble de la boucle RL

Miles a étendu MXFP8 et NVFP4 au-delà de kernels isolés en les reliant sur l’ensemble du parcours d’apprentissage par renforcement.

L’équipe Miles a publié les recettes le 29 juillet 2026. Ses résultats à faible précision couvrent la conversion de checkpoints, l’entraînement Megatron, le rollout SGLang et l’exportation de poids en direct. L’implémentation dépend également de composants apportés par TransformerEngine, FlashInfer, cuDNN frontend et des projets associés.

La première recette utilise MXFP8 sur l’ensemble du parcours de calcul principal. MXFP8 est un format de microscaling sur huit bits dans lequel chaque bloc de 32 valeurs E4M3 partage une échelle E8M0. Le rollout, la propagation avant, les multiplications matricielles des gradients de poids et les multiplications des gradients de données peuvent tous l’utiliser.

Cette large couverture est importante, car un système RL contient deux politiques étroitement liées. La politique d’entraînement calcule les mises à jour, tandis que la politique de rollout génère les réponses utilisées pour calculer les récompenses. Si elles quantifient les poids différemment, elles ne représentent plus exactement le même modèle.

Miles prenait auparavant en charge une conception FP8 de style DeepSeek-V3 fondée sur des blocs d’échelle plus grands. Cette approche reste pertinente, en particulier sur le matériel Hopper. Elle applique toutefois l’échelle dans le logiciel autour du parcours Tensor Core plutôt que d’utiliser le matériel natif de microscaling de Blackwell.

La seconde recette adopte une approche plus sélective. Elle applique NVFP4 aux poids et aux activations des experts routés dans les couches mixture-of-experts, ou MoE. NVFP4 stocke des valeurs E2M1 sur quatre bits, avec une échelle E4M3 pour chaque bloc de 16 valeurs.

Une seconde échelle FP32 couvre un périmètre plus large. Miles calcule cette échelle séparément pour chaque jeton au lieu d’en partager une entre les valeurs d’un tenseur ou d’un lot. Ce détail vise à empêcher la représentation d’un jeton de changer selon la composition du lot.

Le reste du modèle NVFP4 reste en BF16, sauf si les règles de configuration sélectionnent un autre format. Cette conception concentre le calcul sur quatre bits là où les modèles MoE stockent une grande partie de leurs données de poids. Elle évite également de forcer l’attention et d’autres composants sensibles dans la représentation la plus étroite disponible.

NVIDIA décrit le scaling NVFP4 comme un système à deux niveaux conçu pour les Tensor Cores Blackwell. Les blocs de 16 valeurs offrent une adaptation locale plus fine que les formats utilisant des groupes de 32 valeurs. L’échelle FP32 au niveau du tenseur étend la plage utilisable.

Miles a modifié le périmètre de la plus grande échelle, passant d’une échelle par tenseur à une échelle par jeton. Ce choix distingue sa recette RL d’un déploiement d’inférence classique. Il montre également pourquoi l’ajout d’un type de données FP4 ne suffit pas à créer un système RL stable.

Les deux recettes prennent en charge les modes backward à haute précision et déquantifié. Le backward à haute précision utilise les opérandes BF16 d’origine pour les multiplications matricielles du backward. Le backward déquantifié reconstruit plutôt les opérandes BF16 à partir des valeurs exactes à faible précision utilisées lors de la passe avant.

La seconde option sacrifie certains détails numériques, mais préserve une meilleure concordance avec la politique de la passe avant. Aucun mode NVFP4 n’exécute ses multiplications matricielles du backward en FP4. Miles teste donc une faible précision sélective, sans revendiquer une boucle d’entraînement universellement sur quatre bits.

Les courbes de récompense déplacent la charge de la preuve

Le résultat le plus notable n’est pas le débit maximal des Tensor Cores, mais l’absence de pénalité évidente sur les récompenses dans la charge de travail testée.

Miles a évalué Qwen3-30B-A3B avec un RL synchrone de style GRPO sur le jeu de données dapo-math-17k. Le système utilisait huit GPU B200, répartis à parts égales entre le rollout et l’entraînement. Chaque prompt recevait huit échantillons de rollout, avec des réponses limitées à 8 192 jetons.

L’étude a comparé une référence BF16 à cinq configurations à faible précision. Celles-ci comprenaient MXFP8 de bout en bout et deux modes backward pour chacun des formats à faible précision. Les variantes NVFP4 limitaient le fonctionnement sur quatre bits au parcours des experts MoE.

Les cinq courbes de récompense brute à faible précision ont suivi de près la courbe BF16. Cela n’établit pas une équivalence entre les tâches, les graines ou des entraînements plus longs. Cela suggère que le rollout à faible précision n’a pas submergé le signal d’apprentissage dans cette expérience particulière.

Il s’agit d’un seuil significatif pour le RL. L’entraînement supervisé peut moyenner les signaux d’optimisation sur un jeu de données vaste et relativement stable. Le RL travaille souvent avec des récompenses plus bruitées et des mises à jour de politique plus modestes, ce qui rend les erreurs de quantification supplémentaires plus difficiles à distinguer d’un véritable apprentissage.

Miles a également indiqué que MXFP8 et NVFP4 réduisaient le temps de rollout par rapport à BF16. L’article publié présente la comparaison sous forme graphique, mais ne fournit pas de pourcentage unique adapté à un titre universel. La direction du résultat est plus claire que sa portabilité.

L’amélioration du rollout est importante, car la génération domine souvent les charges de travail d’apprentissage par renforcement. Une politique doit produire des réponses complètes avant que les récompenses et les mises à jour puissent être calculées. Les contextes longs et les multiples échantillons rendent cette étape particulièrement coûteuse.

MXFP8 a également amélioré le temps d’entraînement par rapport à BF16 dans la configuration mesurée. Le volet entraînement de NVFP4 a évolué dans la direction opposée. Les deux variantes NVFP4 avec override du backward étaient plus lentes que BF16 pendant l’entraînement, malgré un rollout plus rapide.

Miles attribue cet écart à son intégration actuelle plutôt qu’aux Tensor Cores FP4 de Blackwell. Le parcours TransformerEngine mesuré effectue le scaling FP32 par jeton sous la forme d’une opération PyTorch distincte. Des kernels cuDNN frontend fusionnés existent, mais leur intégration à TransformerEngine reste en attente.

Ce résultat partagé ancre l’analyse dans le réel. NVFP4 n’est pas automatiquement plus rapide simplement parce que ses valeurs sont plus petites. La fusion des kernels, les dispositions de données, les opérations de scaling et les frontières entre frameworks déterminent si le débit théorique atteint l’application complète.

Les configurations à faible précision ont également montré un décalage entraînement-rollout plus important que BF16. NVFP4 a commencé avec une mesure KL de référence plus élevée, qui compare les distributions de politiques. Miles a toutefois calculé ce diagnostic par rapport à un modèle de référence Megatron en BF16.

La métrique intègre donc dès le départ la différence de format. Son coefficient a été fixé à zéro, de sorte qu’elle n’a pas agi comme une pénalité d’optimisation. Miles déconseille de considérer cette mesure comme un signe autonome d’échec de l’apprentissage.

Les courbes de récompense produisent un renversement utile. Le décalage de précision a augmenté, mais les récompenses observées ne se sont pas matériellement écartées de BF16 durant l’ablation. Cette combinaison justifie des tests supplémentaires tout en laissant ouverte la question de la stabilité à long terme.

Un quantificateur partagé est le véritable mécanisme

Miles traite le RL à faible précision comme un problème de cohérence distribuée, et non comme une simple demande de nombres plus petits.

Chaque partie de la pile RL peut quantifier les tenseurs indépendamment. Megatron gère l’entraînement, tandis que SGLang et FlashInfer assurent les opérations de rollout. La conversion des checkpoints et les mises à jour de poids en direct introduisent deux occasions supplémentaires pour les valeurs ou les dispositions de diverger.

Même de petites différences peuvent s’accumuler au fil des mises à jour répétées de la politique. Un worker d’entraînement peut optimiser une représentation quantifiée tandis que les workers de rollout échantillonnent une autre. Les récompenses décrivent alors le comportement d’une politique que l’optimiseur ne voit jamais exactement.

Miles résout ce problème par un contrat de quantificateur bit-exact. Les tests FlashInfer comparent sa sortie octet par octet à une référence de style TransformerEngine. Les entrées de test comprennent des valeurs aléatoires, des cas limites, des tenseurs nuls et les valeurs maximales représentables.

L’équipe désactive également une option de fast-math de FlashInfer pour le parcours de quantification FP4 concerné. Les mathématiques approximatives peuvent convenir au serving ordinaire, où des différences mineures ne se répercutent pas sur les poids futurs. Le RL fait de ces différences une partie de la boucle d’apprentissage.

MXFP8 présente un autre problème de disposition. Les Tensor Cores Blackwell attendent que les blocs de microscaling suivent la dimension de réduction matricielle. Les opérations avant et backward peuvent utiliser des orientations différentes, de sorte qu’une copie quantifiée ne peut pas toujours servir correctement les deux parcours.

La documentation MXFP8 explique que TransformerEngine crée des copies par lignes et par colonnes à partir de l’entrée haute précision d’origine. Cela consomme davantage de mémoire, mais évite de déquantifier et de requantifier une copie existante à faible précision.

Miles accepte ce coût mémoire dans son parcours MXFP8 complet. Ses alternatives de backward à haute précision et déquantifié évitent de conserver la seconde copie quantifiée. Le choix devient un équilibre entre la concordance numérique, l’utilisation de la mémoire, le travail de déquantification et la vitesse des multiplications matricielles.

NVFP4 introduit un problème de cohérence différent. Le partage d’une même échelle d’activation entre plusieurs jetons fait dépendre la valeur quantifiée d’un jeton de ses voisins. Des changements dans l’ordonnancement du rollout, la longueur des séquences ou le regroupement des lots peuvent alors modifier la représentation de la politique.

Miles calcule en ligne une échelle d’activation FP32 par jeton. FlashInfer fusionne ce calcul dans le kernel de quantification des activations de rollout. La même opération produit des activations FP4 compactées, des échelles de bloc et des échelles de jeton.

L’entraînement et le rollout doivent également utiliser des partitions tensor-parallel d’experts correspondantes. Dans le cas contraire, chaque système voit des portions différentes du tenseur lorsqu’il calcule l’échelle par jeton. Des formules identiques ne peuvent pas produire des politiques identiques à partir d’entrées différentes.

Les couches d’experts SwiGLU ajoutent un autre cas particulier. Leurs projections gate et up entrent couramment dans une multiplication matricielle fusionnée, bien que les checkpoints puissent les stocker séparément. Miles quantifie chaque paire gate-and-up ensemble afin qu’elles reçoivent toutes deux une échelle plus grande cohérente.

Ces détails d’implémentation expliquent pourquoi le travail Miles Blackwell s’étend sur plusieurs dépôts. Aucune bibliothèque unique ne contrôle chaque représentation entre un checkpoint enregistré et un rollout généré. Le contrat de précision doit survivre à chaque transfert.

Ce travail sur les systèmes distingue également la recette de la quantification post-entraînement. Un checkpoint d’inférence statique peut être calibré une fois et servi à répétition. L’apprentissage par renforcement modifie continuellement les poids, de sorte que chaque exportation en direct crée en pratique un nouvel événement de quantification.

Les équipes évaluant des systèmes similaires auront besoin de preuves traçables de ces événements. Une base de connaissances d’ingénierie interne peut relier les configurations, les versions de noyau, les courbes d’évaluation et les notes d’incident. Cet historique devient important lorsqu’une régression numérique apparaît plusieurs mises à jour plus tard.

Le NVFP4 par token remet en cause le BF16 uniforme par défaut

L’approche de Miles Blackwell pousse les équipes à justifier l’usage du BF16 partout, tout en considérant le BF16 sélectif comme un outil de stabilité.

Le BF16 reste la base de référence la plus simple. Il offre une plage numérique plus large, moins de contraintes de quantification et des comparaisons plus faciles entre l’entraînement et le déploiement. Sa faiblesse est que chaque poids d’expert et chaque activation consomme davantage de bande passante mémoire que ne l’exigent des formats plus étroits.

Les modèles MoE rendent ce compromis plus visible. Ils contiennent de nombreux paramètres d’experts, alors que chaque token n’en active qu’un sous-ensemble. Le déplacement des poids d’experts en mémoire pendant le déploiement peut devenir plus contraignant que la capacité de calcul brute.

Miles cible donc d’abord le chemin des experts. La stratégie ressemble davantage à un budget financier qu’à un engagement idéologique en faveur d’un entraînement à quatre bits. Elle réserve la précision aux tenseurs les plus susceptibles d’influencer la stabilité et compresse les plus grandes structures répétées.

L’expérience a conservé les 15 derniers pour cent des couches du modèle en BF16 pour chaque configuration à faible précision. Miles indique que ce choix a réduit l’écart entre l’entraînement et l’inférence et amélioré la stabilité des gradients. Le maintien des premières couches en BF16 n’a pas apporté une réduction aussi significative.

Les experts partagés sont également restés à plus haute précision. Contrairement aux experts routés, ils traitent chaque token. Leurs erreurs de quantification se propageraient donc dans chaque bloc MoE, plutôt que seulement le long des routes sélectionnées.

Certaines projections d’attention latente multi-têtes ont aussi bénéficié d’exceptions BF16. Leurs axes de contraction peuvent changer selon le mode d’exécution, tandis que MXFP8 utilise des blocs de mise à l’échelle unidimensionnels. Un axe modifié peut regrouper des valeurs sous différentes échelles.

Ces exceptions sont au cœur de la recette, et non un simple nettoyage accessoire. Un titre décrivant un modèle entièrement FP4 déformerait le travail. Miles a plutôt mis en place des contrôles fins qui préservent chaque exception lors de la conversion, de l’entraînement, du déploiement et des mises à jour en direct.

Cela met les pipelines BF16 conventionnels sous pression de deux manières. Premièrement, l’ablation de récompense suggère que les chemins de déploiement plus étroits méritent d’être évalués sur Blackwell. Deuxièmement, le système de configuration offre une alternative au choix d’un seul format pour chaque couche.

Cela remet également en cause les approches FP8 antérieures conçues autour de Hopper. DeepSeek-V3 utilise des blocs de 128 par 128 pour les poids et des tuiles de 1 par 128 pour les activations. Miles décrit cette conception comme efficace, mais elle ne peut pas exploiter le matériel de microscaling de Blackwell de la même manière native.

Cette comparaison ne rend pas l’ancienne méthode obsolète. Les clusters Hopper restent largement déployés, et le FP8 à échelle par blocs possède un historique opérationnel plus long. Les formats natifs de Blackwell créent aussi des limites de compatibilité pour les équipes prenant en charge plusieurs générations de GPU.

Le guide TransformerEngine de NVIDIA prend désormais en charge FP8, MXFP8 et NVFP4 via des blocs de construction optimisés. Pourtant, la seule prise en charge par le framework ne permet pas de déterminer quelles couches doivent utiliser chaque format. L’architecture du modèle et la forme de la charge de travail continuent de guider cette décision.

Les bénéficiaires les plus directs sont les organisations exécutant de grands travaux d’apprentissage par renforcement MoE sur Blackwell. Elles peuvent tester un déploiement plus rapide sans basculer immédiatement toutes les opérations de rétropropagation en faible précision. Cette voie progressive réduit le coût de collecte des preuves.

Les petites équipes font face à un calcul différent. Reproduire la configuration exige huit GPU B200, plusieurs bibliothèques coordonnées et une stricte parité de configuration. La charge d’ingénierie peut l’emporter sur les économies de déploiement à une échelle modeste.

La principale ligne de concurrence oppose donc la cohérence sélective à la simplicité uniforme. Miles offre davantage de contrôle et une voie vers une réduction du trafic mémoire. Le BF16 offre moins d’interfaces où une divergence inaperçue peut s’introduire dans le processus d’apprentissage.

Ce que l’ablation Qwen3 ne démontre pas

L’expérience publiée étaye une recette prometteuse, mais elle ne démontre pas une parité générale de qualité ni une efficacité complète à quatre bits.

La limitation la plus immédiate est l’étendue. Miles a testé un modèle, un jeu de données orienté mathématiques, une configuration matérielle et une configuration principale de charge de travail. Des récompenses très proches dans ce cadre ne permettent pas de prédire le comportement pour le code, l’utilisation d’outils, le dialogue ou les tâches multi-agents.

La configuration fixe utilisait un RL synchrone et une répartition sur quatre GPU pour le déploiement comme pour l’entraînement. Les systèmes asynchrones peuvent introduire un retard de politique plus important entre la génération des données et l’optimisation. Ce retard pourrait interagir différemment avec les écarts de quantification.

Le graphique de récompense publié couvre également une ablation de recette plutôt qu’un entraînement entièrement optimisé. Miles le décrit explicitement ainsi. Les lecteurs ne devraient pas interpréter ce graphique comme une victoire de benchmark face à des systèmes BF16 optimisés.

La récompense brute peut masquer des changements comportementaux. Deux politiques peuvent atteindre des scores similaires tout en utilisant des schémas de raisonnement, des longueurs de réponse ou des modes d’échec différents. Une validation plus solide inclurait des évaluations sur des jeux tenus à l’écart, plusieurs graines aléatoires et une analyse des erreurs spécifique aux tâches.

Les pics occasionnels de gradients avec NVFP4 constituent une autre préoccupation. La variante à rétropropagation haute précision a présenté des pics pendant l’exécution rapportée. La rétropropagation déquantifiée a réduit les exemples les plus importants sans les éliminer.

Cela concorde avec des préoccupations plus larges autour de l’entraînement à quatre bits. Les recherches sur les valeurs aberrantes NVFP4 ont identifié une sensibilité persistante dans certains composants architecturaux. Ces travaux concernent le préentraînement, et non la recette RL de Miles, mais ils renforcent la nécessité d’une surveillance au niveau des couches.

L’histoire actuelle de la mémoire est également incomplète. Megatron conserve encore une copie supplémentaire des poids en BF16, malgré l’exécution de l’entraînement et du déploiement via des recettes à faible précision. Cette copie limite la quantité de mémoire de modèle réellement récupérée par le système.

La collecte de paramètres à faible précision native de Blackwell est encore en phase de maturation. Miles note que le chemin pertinent de collecte des paramètres NVFP4 ne prend pas encore en charge sa disposition de poids unidimensionnelle 1 par 16. La suppression de la copie BF16 dépend en partie de cette infrastructure.

Les performances d’entraînement NVFP4 constituent un second domaine inachevé. Le déploiement s’est amélioré, mais l’entraînement est devenu plus lent dans l’implémentation testée. L’intégration fusionnée de TransformerEngine en attente doit combler cet écart avant que NVFP4 puisse revendiquer un avantage de bout en bout plus clair.

Le mouvement des poids en direct demeure également complexe. Les backends de service complètent souvent les poids, les mélangent ou les réorganisent selon des dispositions optimisées pour certains noyaux. Les systèmes d’entraînement maintiennent généralement une représentation tensorielle canonique différente.

Ces transformations peuvent entraver les mises à jour à faible latence ou l’accès direct à la mémoire à distance. Chaque disposition spécifique à un backend ajoute une étape supplémentaire qui doit rester vérifiable. Un noyau rapide a une valeur limitée si chaque mise à jour de politique déclenche un reconditionnement coûteux.

La spécificité matérielle crée un risque commercial. MXFP8 et NVFP4 bénéficient d’une accélération native sur Blackwell, mais de nombreuses organisations exploitent encore du matériel Hopper. L’adoption des nouvelles recettes peut répartir le support d’infrastructure entre plusieurs chemins de précision.

Les éléments publiés ne comportent pas non plus de réplication indépendante. Les résultats proviennent de l’équipe qui a conçu et mis en œuvre les recettes. Cela convient à un rapport d’ingénierie initial, mais des reproductions par des tiers renforceraient la confiance.

Aucune de ces limites n’efface le résultat observé. Elles définissent ce que signifie ce résultat. Miles a montré qu’une faible précision soigneusement contrôlée peut suivre les récompenses BF16 dans une configuration exigeante tout en réduisant le temps de déploiement.

Le prochain critère est plus difficile. Les recettes doivent rester stables sur des exécutions plus longues, des tâches variées, des mises à jour asynchrones, des modèles plus grands et différentes dispositions de parallélisme. Elles doivent également préserver leurs gains une fois tous les surcoûts du framework intégrés à la mesure.

Trois signaux détermineront si la recette s’exporte

Les trois prochains signaux sont l’entraînement NVFP4 fusionné, la réplication indépendante des récompenses et la suppression de la copie supplémentaire des poids BF16.

Premièrement, surveillez l’intégration TransformerEngine en attente pour la mise à l’échelle NVFP4 fusionnée par token. Miles utilise déjà une mise à l’échelle fusionnée dans le chemin de déploiement de FlashInfer, mais son chemin d’entraînement mesuré effectue une opération distincte. L’intégration devrait révéler si NVFP4 peut améliorer le temps d’entraînement autant que le temps de déploiement.

Un résultat plus rapide de bout en bout renforcerait l’argument en faveur du format. Un ralentissement persistant de l’entraînement limiterait son attrait aux charges de travail fortement axées sur le déploiement. Dans les deux cas, le résultat préciserait où le calcul à quatre bits produit une valeur pratique.

Deuxièmement, surveillez les reproductions indépendantes sur différents modèles et tâches. Les tests les plus utiles incluraient le code, le raisonnement à long contexte, l’utilisation d’outils et le RL asynchrone. Plusieurs graines aideraient à distinguer le comportement du format de la variance ordinaire des récompenses.

Des courbes de récompense similaires sur ces charges de travail étayeraient la thèse de cohérence de Miles. Des divergences dans certaines couches ou tâches identifieraient au contraire les domaines où les exceptions BF16 doivent être étendues. Dans les deux cas, le résultat serait plus utile qu’une règle universelle de précision unique.

Troisièmement, surveillez si Megatron peut supprimer la copie supplémentaire des poids BF16 tout en prenant en charge la disposition de poids de la recette. Ce changement révélerait le bénéfice mémoire actuellement masqué par les exigences de compatibilité. Il testerait également si la politique à faible précision peut devenir la principale représentation stockée du système.

Le travail Miles Blackwell a franchi une frontière d’ingénierie importante. MXFP8 et NVFP4 par token participent désormais à une boucle RL connectée, plutôt que d’apparaître uniquement dans des tests d’inférence ou d’entraînement isolés.

La question la plus précise n’est plus de savoir si Blackwell peut exécuter des opérations à quatre et huit bits. Elle est de savoir si les équipes peuvent préserver une seule politique dans chaque système qui manipule ces valeurs. Suivez les intégrations, les reproductions et les évolutions de mémoire avant de considérer les courbes Qwen3 comme un résultat général.