Miles Blackwell RL tauscht BF16-Einheitlichkeit gegen natives MXFP8 und NVFP4

Die Miles-Blackwell-Unterstützung umfasst nun zwei native Rezepte für Reinforcement Learning mit niedriger Präzision, die in sechs Konfigurationen auf acht NVIDIA-B200-GPUs getestet wurden. Eines verwendet MXFP8 durchgängig für Rollout und Training. Das andere setzt NVFP4 pro Token für die Gewichte von Mixture-of-Experts ein und behält andernorts eine höhere Präzision bei.

Das Ergebnis stellt eine geläufige Annahme über Reinforcement Learning, kurz RL, infrage. Geringere Präzision erfordert nicht zwangsläufig die Hinnahme einer offensichtlich schwächeren Lernkurve. In Miles’ Qwen3-30B-A3B-Ablation folgten alle fünf Konfigurationen mit niedriger Präzision den Roh-Rewards der BF16-Basislinie eng.

Diese Erkenntnis ist mit einer wichtigen Einschränkung verbunden. Das Experiment war eine kontrollierte Rezept-Ablation, kein vollständig optimierter Trainings-Benchmark und keine allgemeine Genauigkeitsgarantie. Miles behielt zudem BF16 in empfindlichen Schichten bei, führte eine zusätzliche BF16-Gewichtskopie und beobachtete gelegentliche NVFP4-Gradientenspitzen.

Der eigentliche Wettbewerb lautet daher nicht einfach vier Bit gegen sechzehn Bit. Es geht um einen konsistenten, selektiven Präzisionsvertrag gegenüber einer einheitlichen BF16-Pipeline. Miles argumentiert, dass Blackwell-native Formate dann nützlich werden, wenn Training, Sampling, Konvertierung und Live-Gewichtsaktualisierungen dieselben Tensoren auf dieselbe Weise quantisieren.

Die Miles-Blackwell-Unterstützung deckt nun den gesamten RL-Zyklus ab

Miles hat MXFP8 und NVFP4 über isolierte Kernel hinausgeführt, indem es sie über den vollständigen Reinforcement-Learning-Pfad hinweg verbindet.

Das Miles-Team veröffentlichte die Rezepte am 29. Juli 2026. Seine Ergebnisse zur niedrigen Präzision umfassen Checkpoint-Konvertierung, Megatron-Training, SGLang-Rollout und Live-Gewichtsexport. Die Implementierung hängt außerdem von Komponenten ab, die in TransformerEngine, FlashInfer, cuDNN frontend und verwandten Projekten beigesteuert wurden.

Das erste Rezept verwendet MXFP8 entlang des gesamten zentralen Rechenpfads. MXFP8 ist ein Acht-Bit-Mikroskalierungsformat, bei dem jeder Block aus 32 E4M3-Werten eine E8M0-Skala teilt. Rollout, Vorwärtspropagierung, Matrixmultiplikationen für Gewichtsgradienten und Matrixmultiplikationen für Datengradienten können es sämtlich verwenden.

Diese breite Abdeckung ist wichtig, weil ein RL-System zwei eng verknüpfte Policies enthält. Die Trainings-Policy berechnet Aktualisierungen, während die Rollout-Policy die Antworten erzeugt, aus denen Rewards berechnet werden. Wenn sie Gewichte unterschiedlich quantisieren, repräsentieren sie nicht mehr exakt dasselbe Modell.

Miles unterstützte zuvor ein FP8-Design im DeepSeek-V3-Stil, das auf größeren Skalierungsblöcken basiert. Dieser Ansatz bleibt insbesondere auf Hopper-Hardware relevant. Er wendet die Skalierung jedoch in Software rund um den Tensor-Core-Pfad an, statt Blackwells native Mikroskalierungs-Hardware zu nutzen.

Das zweite Rezept verfolgt einen selektiveren Ansatz. Es wendet NVFP4 auf die gerouteten Expertengewichte und Aktivierungen innerhalb von Mixture-of-Experts-, kurz MoE-,Schichten an. NVFP4 speichert E2M1-Werte in vier Bit, mit einer E4M3-Skala für jeden 16-Werte-Block.

Eine zweite FP32-Skala deckt einen größeren Bereich ab. Miles berechnet diese Skala separat für jeden Token, statt sie über einen Tensor oder Batch zu teilen. Dieses Detail soll verhindern, dass sich die Repräsentation eines Tokens mit der Batch-Zusammensetzung verändert.

Der Rest des NVFP4-Modells bleibt in BF16, sofern Konfigurationsregeln kein anderes Format auswählen. Dieses Design konzentriert Vier-Bit-Berechnungen dort, wo MoE-Modelle einen Großteil ihrer Gewichtsdaten speichern. Zudem verhindert es, dass Attention und andere empfindliche Komponenten in die schmalste verfügbare Repräsentation gezwungen werden.

NVIDIA beschreibt die NVFP4-Skalierung als ein zweistufiges System für Blackwell Tensor Cores. Die 16-Werte-Blöcke ermöglichen eine feinere lokale Anpassung als Formate mit 32-Werte-Gruppen. Die FP32-Skala auf Tensor-Ebene erweitert den nutzbaren Bereich.

Miles änderte den Geltungsbereich der größeren Skala von pro Tensor auf pro Token. Diese Entscheidung unterscheidet sein RL-Rezept von einer einfachen Inferenzbereitstellung. Sie zeigt auch, warum das Hinzufügen eines FP4-Datentyps nicht genügt, um ein stabiles RL-System zu schaffen.

Beide Rezepte unterstützen Rückwärtsmodi mit hoher Präzision und dequantisierte Rückwärtsmodi. Der Rückwärtsmodus mit hoher Präzision verwendet die ursprünglichen BF16-Operanden für Rückwärts-Matrixmultiplikationen. Der dequantisierte Rückwärtsmodus rekonstruiert stattdessen BF16-Operanden aus den exakten Werten niedriger Präzision, die beim Vorwärtsdurchlauf verwendet wurden.

Die zweite Option opfert einige numerische Details, erhält aber eine engere Übereinstimmung mit der Vorwärts-Policy. Keiner der NVFP4-Modi führt seine Rückwärts-Matrixmultiplikationen in FP4 aus. Miles testet damit selektive niedrige Präzision und behauptet keinen universell vierbittigen Trainingszyklus.

Die Reward-Kurven verschieben die Beweislast

Das bemerkenswerteste Ergebnis ist nicht die Spitzenleistung der Tensor Cores, sondern das Ausbleiben eines offensichtlichen Reward-Nachteils im getesteten Workload.

Miles evaluierte Qwen3-30B-A3B mit synchronem RL im GRPO-Stil auf dem Datensatz dapo-math-17k. Das System verwendete acht B200-GPUs, gleichmäßig zwischen Rollout und Training aufgeteilt. Jeder Prompt erhielt acht Rollout-Samples, wobei Antworten auf 8.192 Token begrenzt waren.

Die Studie verglich eine BF16-Basislinie mit fünf Konfigurationen niedriger Präzision. Dazu gehörten End-to-End-MXFP8 und zwei Rückwärtsmodi für jedes Format niedriger Präzision. Die NVFP4-Varianten beschränkten den Vier-Bit-Betrieb auf den MoE-Expertenpfad.

Alle fünf Roh-Reward-Kurven niedriger Präzision folgten der BF16-Kurve eng. Das belegt keine Gleichwertigkeit über Aufgaben, Seeds oder längere Trainingsläufe hinweg. Es deutet jedoch darauf hin, dass ein Rollout mit niedrigerer Präzision das Lernsignal in diesem speziellen Experiment nicht überwältigte.

Das ist eine bedeutsame Schwelle für RL. Überwachtes Training kann Optimierungssignale über einen großen und relativ stabilen Datensatz mitteln. RL arbeitet häufig mit verrauschteren Rewards und kleineren Policy-Aktualisierungen, wodurch zusätzlicher Quantisierungsfehler schwieriger von echtem Lernen zu trennen ist.

Miles berichtete außerdem, dass MXFP8 und NVFP4 die Rollout-Zeit gegenüber BF16 verkürzten. Der veröffentlichte Artikel stellt den Vergleich grafisch dar, liefert jedoch keinen einzelnen Prozentsatz, der sich für eine universelle Schlagzeile eignet. Die Richtung des Ergebnisses ist klarer als seine Übertragbarkeit.

Die Verbesserung beim Rollout ist wichtig, weil die Generierung Reinforcement-Learning-Workloads oft dominiert. Eine Policy muss vollständige Antworten erzeugen, bevor Rewards und Aktualisierungen berechnet werden können. Lange Kontexte und mehrere Samples machen diese Phase besonders kostspielig.

MXFP8 verbesserte im gemessenen Setup auch die Trainingszeit gegenüber BF16. Auf der Trainingsseite entwickelte sich NVFP4 dagegen in die entgegengesetzte Richtung. Beide NVFP4-Varianten mit Rückwärts-Override waren beim Training langsamer als BF16, trotz schnellerem Rollout.

Miles führt diese Lücke auf seine aktuelle Integration zurück, nicht auf Blackwells FP4 Tensor Cores. Der gemessene TransformerEngine-Pfad führt die FP32-Skalierung pro Token als separate PyTorch-Operation aus. Fused cuDNN-frontend-Kernel existieren, ihre TransformerEngine-Integration steht jedoch noch aus.

Dieses geteilte Ergebnis hält die Analyse auf dem Boden der Tatsachen. NVFP4 ist nicht automatisch schneller, nur weil seine Werte kleiner sind. Kernel-Fusion, Datenlayouts, Skalierungsoperationen und Framework-Grenzen entscheiden darüber, ob die theoretische Durchsatzleistung die vollständige Anwendung erreicht.

Die Konfigurationen niedriger Präzision zeigten zudem einen größeren Train-Rollout-Mismatch als BF16. NVFP4 begann mit einer höheren Referenz-KL-Messung, die Policy-Verteilungen vergleicht. Miles berechnete diese Diagnose jedoch gegenüber einem BF16-Megatron-Referenzmodell.

Die Metrik enthält daher den Formatunterschied von Beginn an. Ihr Koeffizient wurde auf null gesetzt, sodass sie nicht als Optimierungsstrafe wirkte. Miles warnt davor, die Messung isoliert als Zeichen eines Lernfehlers zu behandeln.

Die Reward-Kurven bewirken eine nützliche Umkehrung. Der Präzisions-Mismatch nahm zu, doch die beobachteten Rewards trennten sich während der Ablation nicht wesentlich von BF16. Diese Kombination stützt weitere Tests, lässt die Frage der Langzeitstabilität jedoch offen.

Ein gemeinsamer Quantisierer ist der eigentliche Mechanismus

Miles behandelt RL mit niedriger Präzision als verteiltes Konsistenzproblem, nicht lediglich als Wunsch nach kleineren Zahlen.

Jeder Teil des RL-Stacks kann Tensoren unabhängig quantisieren. Megatron übernimmt das Training, während SGLang und FlashInfer Rollout-Operationen abwickeln. Checkpoint-Konvertierung und Live-Gewichtsaktualisierungen schaffen zwei weitere Gelegenheiten, bei denen Werte oder Layouts auseinanderlaufen können.

Selbst kleine Unterschiede können sich über wiederholte Policy-Aktualisierungen hinweg aufsummieren. Ein Trainings-Worker kann eine quantisierte Repräsentation optimieren, während Rollout-Worker aus einer anderen samplen. Rewards beschreiben dann das Verhalten einer Policy, die der Optimierer nie exakt sieht.

Miles begegnet diesem Problem mit einem bitgenauen Quantisierer-Vertrag. FlashInfer-Tests vergleichen seine Ausgabe Byte für Byte mit einer Referenz im TransformerEngine-Stil. Die Testeingaben umfassen Zufallswerte, Grenzfälle, Nulltensoren und maximal darstellbare Werte.

Das Team deaktiviert außerdem eine FlashInfer-Fast-Math-Option für den betreffenden FP4-Quantisierungspfad. Approximative Mathematik kann für gewöhnliches Serving angemessen sein, bei dem kleine Unterschiede nicht in künftige Gewichte zurückfließen. RL macht diese Unterschiede zu einem Teil des Lernzyklus.

MXFP8 bringt ein weiteres Layout-Problem mit sich. Blackwell Tensor Cores erwarten, dass Mikroskalierungsblöcke der Reduktionsdimension der Matrix folgen. Vorwärts- und Rückwärtsoperationen können unterschiedliche Orientierungen verwenden, sodass eine quantisierte Kopie nicht immer beide Pfade korrekt bedienen kann.

Die MXFP8-Dokumentation erklärt, dass TransformerEngine zeilenweise und spaltenweise Kopien aus der ursprünglichen Eingabe hoher Präzision erstellt. Das verbraucht mehr Speicher, vermeidet jedoch die Dequantisierung und erneute Quantisierung einer bereits quantisierten Kopie niedriger Präzision.

Miles akzeptiert diese Speicherkosten in seinem vollständigen MXFP8-Pfad. Seine Alternativen für Rückwärtsrechnungen mit hoher Präzision und dequantisierte Rückwärtsrechnungen vermeiden das Vorhalten der zweiten quantisierten Kopie. Die Wahl wird zu einem Ausgleich zwischen numerischer Übereinstimmung, Speichernutzung, Dequantisierungsaufwand und Matrixmultiplikationsgeschwindigkeit.

NVFP4 führt ein anderes Konsistenzproblem ein. Das Teilen einer Aktivierungsskala über mehrere Token hinweg macht den quantisierten Wert eines Tokens von seinen Nachbarn abhängig. Änderungen an Rollout-Scheduling, Sequenzlänge oder Batch-Packing können dann die Policy-Repräsentation verändern.

Miles berechnet online eine FP32-Aktivierungsskala pro Token. FlashInfer fusioniert diese Berechnung in den Kernel zur Aktivierungsquantisierung beim Rollout. Dieselbe Operation erzeugt gepackte FP4-Aktivierungen, Blockskalen und Tokenskalen.

Training und Rollout müssen außerdem übereinstimmende tensorparallele Expertenpartitionen verwenden. Andernfalls sieht jedes System beim Berechnen der Skala pro Token unterschiedliche Teile des Tensors. Identische Formeln können aus unterschiedlichen Eingaben keine identischen Policies erzeugen.

SwiGLU-Expertenschichten fügen einen weiteren Sonderfall hinzu. Ihre Gate- und Up-Projektionen gehen üblicherweise in eine fusionierte Matrixmultiplikation ein, obwohl Checkpoints sie separat speichern können. Miles quantisiert jedes Gate-und-Up-Paar gemeinsam, damit beide eine konsistente größere Skala erhalten.

Diese Implementierungsdetails erklären, warum sich die Miles-Blackwell-Arbeit über mehrere Repositories erstreckt. Keine einzelne Bibliothek kontrolliert jede Repräsentation zwischen einem gespeicherten Checkpoint und einem generierten Rollout. Der Präzisionsvertrag muss jede Übergabe überstehen.

Diese Systemarbeit unterscheidet das Rezept auch von Post-Training-Quantisierung. Ein statischer Inferenz-Checkpoint kann einmal kalibriert und wiederholt bereitgestellt werden. Reinforcement Learning verändert Gewichte kontinuierlich, sodass jeder Live-Export faktisch ein neues Quantisierungsereignis erzeugt.

Teams, die ähnliche Systeme evaluieren, benötigen nachvollziehbare Belege für diese Ereignisse. Eine interne Engineering-Wissensdatenbank kann Konfigurationen, Kernel-Versionen, Evaluierungskurven und Incident-Notizen verknüpfen. Diese Dokumentation wird wichtig, wenn mehrere Updates später eine numerische Regression auftritt.

Per-Token-NVFP4 setzt den einheitlichen BF16-Standard unter Druck

Der Miles-Blackwell-Ansatz setzt Teams unter Druck, BF16 überall zu rechtfertigen, während selektives BF16 weiterhin als Stabilitätsinstrument gilt.

BF16 bleibt die einfachere Ausgangsbasis. Es bietet einen größeren numerischen Bereich, weniger Quantisierungsbedingungen und einfachere Vergleiche zwischen Training und Rollout. Seine Schwäche besteht darin, dass jedes Expertengewicht und jede Aktivierung mehr Speicherbandbreite beansprucht, als schmalere Formate benötigen.

MoE-Modelle machen diesen Zielkonflikt sichtbarer. Sie enthalten viele Expertenparameter, obwohl jedes Token nur eine Teilmenge aktiviert. Das Verschieben von Expertengewichten durch den Speicher während des Rollouts kann restriktiver werden als die reine Rechenkapazität.

Miles richtet sich daher zunächst auf den Expertenpfad. Die Strategie ähnelt eher einem finanziellen Budget als einem ideologischen Bekenntnis zum Vier-Bit-Training. Sie investiert Präzision in die Tensoren, die Stabilität am wahrscheinlichsten beeinflussen, und komprimiert die größten wiederkehrenden Strukturen.

Das Experiment behielt für jede Low-Precision-Konfiguration die letzten 15 Prozent der Modellschichten in BF16. Miles zufolge verringerte diese Entscheidung die Diskrepanz zwischen Training und Inferenz und verbesserte die Gradientenstabilität. Die Beibehaltung früher Schichten in BF16 führte nicht zu einer ähnlich bedeutsamen Verbesserung.

Gemeinsame Experten blieben ebenfalls bei höherer Präzision. Anders als geroutete Experten verarbeiten sie jedes Token. Ihre Quantisierungsfehler würden sich daher durch jeden MoE-Block fortpflanzen und nicht nur durch ausgewählte Routen.

Bestimmte Projektionen der Multi-Head Latent Attention erhielten ebenfalls BF16-Ausnahmen. Ihre Kontraktionsachsen können sich mit dem Ausführungsmodus ändern, während MXFP8 eindimensionale Skalierungsblöcke nutzt. Eine geänderte Achse kann Werte unter anderen Skalen neu gruppieren.

Diese Ausnahmen sind zentral für das Rezept und keine beiläufige Bereinigung. Eine Überschrift, die ein vollständig in FP4 ausgeführtes Modell beschreibt, würde die Arbeit falsch darstellen. Miles entwickelte stattdessen feingranulare Steuerungen, die jede Ausnahme über Konvertierung, Training, Rollout und Live-Updates hinweg bewahren.

Das setzt konventionelle BF16-Pipelines auf zwei Arten unter Druck. Erstens legt die Reward-Ablation nahe, dass schmalere Rollout-Pfade auf Blackwell evaluiert werden sollten. Zweitens bietet das Konfigurationssystem eine Alternative dazu, für jede Schicht ein einziges Format zu wählen.

Es setzt auch frühere, für Hopper entwickelte FP8-Ansätze unter Druck. DeepSeek-V3 verwendet 128-mal-128-Blöcke für Gewichte und 1-mal-128-Kacheln für Aktivierungen. Miles beschreibt dieses Design als effektiv, doch es kann Blackwells Microscaling-Hardware nicht auf dieselbe native Weise nutzen.

Der Vergleich macht die ältere Methode nicht obsolet. Hopper-Cluster sind weiterhin weit verbreitet, und blockskaliertes FP8 verfügt über eine längere Betriebserfahrung. Blackwell-native Formate schaffen zudem Kompatibilitätsgrenzen für Teams, die gemischte GPU-Generationen unterstützen.

NVIDIAs TransformerEngine-Leitfaden unterstützt inzwischen FP8, MXFP8 und NVFP4 über optimierte Bausteine. Framework-Unterstützung allein entscheidet jedoch nicht darüber, welche Schichten welches Format verwenden sollten. Modellarchitektur und Workload-Struktur bestimmen diese Entscheidung weiterhin.

Die unmittelbarsten Nutznießer sind Organisationen, die große MoE-Reinforcement-Learning-Jobs auf Blackwell ausführen. Sie können schnelleren Rollout testen, ohne sofort jede Backward-Operation in niedrige Präzision zu überführen. Dieser schrittweise Weg senkt die Kosten für die Gewinnung von Belegen.

Kleinere Teams stehen vor einer anderen Rechnung. Die Reproduktion des Setups erfordert acht B200-GPUs, mehrere koordinierte Bibliotheken und sorgfältige Konfigurationsparität. Der Engineering-Aufwand kann bei moderatem Umfang die Rollout-Einsparungen überwiegen.

Die zentrale Wettbewerbslinie lautet daher selektive Konsistenz versus einheitliche Einfachheit. Miles bietet mehr Kontrolle und einen Weg zu geringerem Speicherverkehr. BF16 bietet weniger Schnittstellen, an denen eine unbemerkte Diskrepanz in den Lernprozess gelangen kann.

Was die Qwen3-Ablation nicht belegt

Das veröffentlichte Experiment unterstützt ein vielversprechendes Rezept, belegt jedoch weder eine breite Qualitätsparität noch vollständige Vier-Bit-Effizienz.

Die unmittelbarste Einschränkung ist der Umfang. Miles testete ein Modell, einen mathematikorientierten Datensatz, eine Hardware-Anordnung und eine zentrale Workload-Konfiguration. Eng übereinstimmende Rewards können dort kein Verhalten bei Coding, Tool-Nutzung, Dialogen oder Multi-Agent-Aufgaben vorhersagen.

Das feste Setup nutzte synchrones RL und eine Aufteilung auf vier GPUs jeweils für Rollout und Training. Asynchrone Systeme können einen größeren Policy-Lag zwischen Datengenerierung und Optimierung einführen. Dieser Lag könnte anders mit Quantisierungsdiskrepanzen interagieren.

Der veröffentlichte Reward-Plot deckt zudem eine Rezept-Ablation und keinen vollständig abgestimmten Trainingslauf ab. Miles beschreibt ihn ausdrücklich so. Leser sollten die Grafik nicht als Benchmark-Sieg gegenüber optimierten BF16-Systemen interpretieren.

Rohe Reward-Werte können Verhaltensänderungen verbergen. Zwei Policies können ähnliche Scores erreichen und dabei unterschiedliche Schlussfolgerungsmuster, Antwortlängen oder Fehlermodi verwenden. Eine stärkere Validierung würde Holdout-Evaluierungen, mehrere Zufallsseeds und aufgabenspezifische Fehleranalysen umfassen.

Die gelegentlichen Gradientenspitzen von NVFP4 bleiben ein weiteres Problem. Die Variante mit hochpräzisem Backward zeigte während des berichteten Laufs Spitzen. Dequantisiertes Backward verringerte die größten Beispiele, beseitigte sie jedoch nicht.

Das stimmt mit umfassenderen Bedenken rund um Vier-Bit-Training überein. Forschung zu NVFP4-Ausreißern hat anhaltende Empfindlichkeit in bestimmten Architekturkomponenten festgestellt. Diese Arbeit betrifft Pretraining, nicht Miles’ RL-Rezept, unterstreicht jedoch die Notwendigkeit eines Monitorings auf Schichtebene.

Auch die aktuelle Speichergeschichte ist unvollständig. Megatron bewahrt weiterhin eine zusätzliche BF16-Gewichtskopie, obwohl Training und Rollout über Low-Precision-Rezepte ausgeführt werden. Diese Kopie begrenzt, wie viel Modellspeicher das System tatsächlich zurückgewinnt.

Blackwell-natives Sammeln von Low-Precision-Parametern reift noch. Miles weist darauf hin, dass der relevante NVFP4-Parameter-Gather-Pfad sein eindimensionales 1-mal-16-Gewichtslayout noch nicht unterstützt. Die Entfernung der BF16-Kopie hängt teilweise von dieser Infrastruktur ab.

Die NVFP4-Trainingsleistung stellt einen zweiten noch offenen Bereich dar. Der Rollout verbesserte sich, doch das Training wurde in der getesteten Implementierung langsamer. Die ausstehende integrierte TransformerEngine-Integration muss diese Lücke schließen, bevor NVFP4 einen klareren End-to-End-Vorteil beanspruchen kann.

Auch Live-Gewichtsbewegungen bleiben kompliziert. Serving-Backends füllen Gewichte häufig auf, mischen sie um oder swizzeln sie in Layouts, die für bestimmte Kernel optimiert sind. Trainingssysteme halten üblicherweise eine andere kanonische Tensorrepräsentation vor.

Diese Transformationen können Updates mit geringer Latenz oder Remote Direct Memory Access behindern. Jedes backend-spezifische Layout fügt einen weiteren Schritt hinzu, der überprüfbar bleiben muss. Ein schneller Kernel bietet nur begrenzten Wert, wenn jedes Policy-Update kostspieliges Repacking auslöst.

Die Hardwarespezifität schafft ein kommerzielles Risiko. MXFP8 und NVFP4 erhalten native Beschleunigung auf Blackwell, doch viele Organisationen betreiben weiterhin Hopper-Hardware. Die Einführung der neuen Rezepte kann die Infrastrukturunterstützung auf mehrere Präzisionspfade aufteilen.

In den veröffentlichten Belegen gibt es zudem keine unabhängige Reproduktion. Die Ergebnisse stammen von dem Team, das die Rezepte entworfen und implementiert hat. Das ist für einen ersten Engineering-Bericht angemessen, doch Reproduktionen durch Dritte würden das Vertrauen stärken.

Keine dieser Einschränkungen hebt das beobachtete Ergebnis auf. Sie definieren, was das Ergebnis bedeutet. Miles hat gezeigt, dass sorgfältig kontrollierte niedrige Präzision in einem anspruchsvollen Setup BF16-Rewards folgen und zugleich die Rollout-Zeit verkürzen kann.

Der nächste Maßstab ist anspruchsvoller. Die Rezepte müssen über längere Läufe, unterschiedliche Aufgaben, asynchrone Updates, größere Modelle und verschiedene Parallelisierungslayouts hinweg stabil bleiben. Außerdem müssen sie ihre Gewinne bewahren, nachdem sämtlicher Framework-Overhead in die Messung einfließt.

Drei Signale werden entscheiden, ob sich das Rezept übertragen lässt

Die nächsten drei Signale sind integriertes NVFP4-Training, unabhängige Reward-Replikation und die Entfernung der zusätzlichen BF16-Gewichtskopie.

Erstens sollte die ausstehende TransformerEngine-Integration für fusionierte Per-Token-NVFP4-Skalierung beobachtet werden. Miles nutzt bereits fusionierte Skalierung im Rollout-Pfad von FlashInfer, doch sein gemessener Trainingspfad führt eine separate Operation aus. Die Integration sollte zeigen, ob NVFP4 neben der Rollout-Zeit auch die Trainingszeit verbessern kann.

Ein schnelleres End-to-End-Ergebnis würde den Fall für das Format stärken. Eine anhaltende Verlangsamung des Trainings würde seine Attraktivität auf rolloutsintensive Workloads begrenzen. Beide Ergebnisse würden klären, wo Vier-Bit-Berechnung praktischen Nutzen erzeugt.

Zweitens sollten unabhängige Reproduktionen über verschiedene Modelle und Aufgaben hinweg beobachtet werden. Die wertvollsten Tests würden Coding, Long-Context-Reasoning, Tool-Nutzung und asynchrones RL umfassen. Mehrere Seeds würden helfen, Formatverhalten von gewöhnlicher Reward-Varianz zu trennen.

Ähnliche Reward-Kurven bei diesen Workloads würden Miles’ Konsistenzthese stützen. Abweichungen in bestimmten Schichten oder Aufgaben würden stattdessen zeigen, wo BF16-Ausnahmen ausgeweitet werden müssen. Beide Ergebnisse wären nützlicher als eine einzelne universelle Präzisionsregel.

Drittens sollte beobachtet werden, ob Megatron die zusätzliche BF16-Gewichtskopie entfernen kann, während es das Gewichtslayout des Rezepts unterstützt. Diese Änderung würde den derzeit durch Kompatibilitätsanforderungen verdeckten Speichervorteil sichtbar machen. Sie würde außerdem testen, ob die Low-Precision-Policy zur primär gespeicherten Repräsentation des Systems werden kann.

Die Miles-Blackwell-Arbeit hat eine wichtige Engineering-Grenze überschritten. MXFP8 und Per-Token-NVFP4 nehmen nun an einem verbundenen RL-Loop teil, statt nur in isolierten Inferenz- oder Trainingstests aufzutreten.

Die präzisere Frage lautet nicht länger, ob Blackwell Vier-Bit- und Acht-Bit-Operationen ausführen kann. Sie lautet, ob Teams eine Policy über jedes System hinweg bewahren können, das diese Werte berührt. Verfolgen Sie die Integrationen, Reproduktionen und Speicheränderungen, bevor Sie die Qwen3-Kurven als allgemeines Ergebnis behandeln.