Miles Blackwell RL zastępuje jednolitość BF16 natywnymi MXFP8 i NVFP4

Obsługa Miles Blackwell obejmuje teraz dwie natywne receptury uczenia ze wzmocnieniem o niskiej precyzji, przetestowane w sześciu konfiguracjach na ośmiu GPU NVIDIA B200. Jedna wykorzystuje MXFP8 w rolloucie i treningu. Druga stosuje NVFP4 per token do wag mixture-of-experts, zachowując wyższą precyzję w pozostałych miejscach.

Wynik podważa znane założenie dotyczące uczenia ze wzmocnieniem, czyli RL. Niższa precyzja nie musi oznaczać akceptacji wyraźnie słabszej krzywej uczenia. W ablacjach Miles dla Qwen3-30B-A3B wszystkie pięć konfiguracji niskiej precyzji ściśle podążało za surowymi nagrodami bazowego BF16.

Wynik ten wymaga istotnego zastrzeżenia. Eksperyment był kontrolowaną ablacją receptury, a nie w pełni dostrojonym benchmarkiem treningowym ani ogólną gwarancją dokładności. Miles zachował także BF16 w wrażliwych warstwach, utrzymywał dodatkową kopię wag BF16 i zaobserwował sporadyczne skoki gradientów NVFP4.

Prawdziwa rywalizacja nie sprowadza się zatem do czterech bitów przeciwko szesnastu bitom. Chodzi o spójny, selektywny kontrakt precyzji kontra jednolity potok BF16. Miles przekonuje, że natywne dla Blackwell formaty stają się użyteczne, gdy trening, próbkowanie, konwersja i aktualizacje wag na żywo kwantyzują te same tensory w ten sam sposób.

Obsługa Miles Blackwell obejmuje teraz pełną pętlę RL

Miles wyprowadził MXFP8 i NVFP4 poza pojedyncze kernele, łącząc je w całej ścieżce uczenia ze wzmocnieniem.

Zespół Miles opublikował receptury 29 lipca 2026 r. Jego wyniki dla niskiej precyzji obejmują konwersję checkpointów, trening Megatron, rollout SGLang i eksport wag na żywo. Implementacja zależy również od komponentów tworzonych w projektach TransformerEngine, FlashInfer, cuDNN frontend i pokrewnych.

Pierwsza receptura wykorzystuje MXFP8 w całej głównej ścieżce obliczeniowej. MXFP8 to ośmiobitowy format mikroskalowania, w którym każdy blok 32 wartości E4M3 współdzieli skalę E8M0. Mogą z niego korzystać rollout, propagacja w przód, mnożenia macierzy dla gradientów wag i mnożenia dla gradientów danych.

Tak szerokie zastosowanie ma znaczenie, ponieważ system RL zawiera dwie ściśle powiązane polityki. Polityka treningowa oblicza aktualizacje, a polityka rollout generuje odpowiedzi używane do wyliczania nagród. Jeżeli kwantyzują wagi inaczej, nie reprezentują już dokładnie tego samego modelu.

Miles wcześniej wspierał projekt FP8 w stylu DeepSeek-V3, oparty na większych blokach skalowania. To podejście pozostaje istotne, zwłaszcza na sprzęcie Hopper. Stosuje jednak skalowanie programowo wokół ścieżki Tensor Core, zamiast korzystać z natywnego sprzętu mikroskalowania Blackwell.

Druga receptura przyjmuje bardziej selektywne podejście. Stosuje NVFP4 do kierowanych wag ekspertów i aktywacji wewnątrz warstw mixture-of-experts, czyli MoE. NVFP4 przechowuje wartości E2M1 w czterech bitach, ze skalą E4M3 dla każdego bloku 16 wartości.

Druga skala FP32 obejmuje większy zakres. Miles oblicza ją osobno dla każdego tokenu, zamiast współdzielić ją w obrębie tensora lub batcha. Ten szczegół ma zapobiegać zmianie reprezentacji jednego tokenu wraz ze składem batcha.

Pozostała część modelu NVFP4 pozostaje w BF16, chyba że reguły konfiguracji wybiorą inny format. Projekt ten koncentruje czterobitowe obliczenia tam, gdzie modele MoE przechowują dużą część danych wag. Unika też wymuszania najwęższej dostępnej reprezentacji dla attention i innych wrażliwych komponentów.

NVIDIA opisuje skalowanie NVFP4 jako dwupoziomowy system zaprojektowany dla Blackwell Tensor Cores. Bloki 16 wartości zapewniają dokładniejszą lokalną adaptację niż formaty używające grup 32 wartości. Skala FP32 na poziomie tensora rozszerza użyteczny zakres.

Miles zmienił zakres większej skali z per tensor na per token. Wybór ten odróżnia jego recepturę RL od prostego wdrożenia inferencyjnego. Pokazuje też, dlaczego dodanie typu danych FP4 nie wystarcza do stworzenia stabilnego systemu RL.

Obie receptury obsługują tryby wsteczne wysokiej precyzji i dekwantyzowane. Tryb wysokiej precyzji wykorzystuje oryginalne operandy BF16 do mnożeń macierzy w propagacji wstecznej. Tryb dekwantyzowany odtwarza natomiast operandy BF16 z dokładnych wartości niskiej precyzji użytych podczas propagacji w przód.

Druga opcja poświęca część szczegółów numerycznych, ale zachowuje większą zgodność z polityką propagacji w przód. Żaden z trybów NVFP4 nie wykonuje mnożeń macierzy w propagacji wstecznej w FP4. Miles testuje więc selektywną niską precyzję, a nie twierdzi, że pętla treningowa jest uniwersalnie czterobitowa.

Krzywe nagród przesuwają ciężar dowodu

Najbardziej zauważalnym wynikiem nie jest szczytowa przepustowość Tensor Core, lecz brak oczywistej kary w nagrodach w testowanym obciążeniu.

Miles ocenił Qwen3-30B-A3B w synchronicznym RL w stylu GRPO na zbiorze danych dapo-math-17k. System wykorzystywał osiem GPU B200, podzielonych równo między rollout i trening. Każdy prompt otrzymał osiem próbek rolloutu, a odpowiedzi ograniczono do 8 192 tokenów.

W badaniu porównano jeden bazowy wariant BF16 z pięcioma konfiguracjami niskiej precyzji. Obejmowały one kompleksowe MXFP8 oraz dwa tryby wsteczne dla każdego formatu niskiej precyzji. Warianty NVFP4 ograniczały działanie czterobitowe do ścieżki ekspertów MoE.

Wszystkie pięć krzywych surowych nagród niskiej precyzji ściśle śledziło krzywą BF16. Nie ustanawia to równoważności między zadaniami, seedami ani dłuższymi przebiegami treningowymi. Sugeruje jednak, że rollout o niższej precyzji nie przytłoczył sygnału uczenia w tym konkretnym eksperymencie.

To istotny próg dla RL. Trening nadzorowany może uśredniać sygnały optymalizacyjne w dużym i względnie stabilnym zbiorze danych. RL często pracuje z bardziej zaszumionymi nagrodami i mniejszymi aktualizacjami polityki, przez co dodatkowy błąd kwantyzacji trudniej oddzielić od rzeczywistego uczenia.

Miles poinformował również, że MXFP8 i NVFP4 skróciły czas rolloutu w porównaniu z BF16. Opublikowany artykuł przedstawia porównanie graficznie, ale nie podaje pojedynczego procentu odpowiedniego dla uniwersalnego nagłówka. Kierunek wyniku jest wyraźniejszy niż jego przenośność.

Poprawa rolloutu ma znaczenie, ponieważ generowanie często dominuje w obciążeniach uczenia ze wzmocnieniem. Polityka musi wytworzyć kompletne odpowiedzi, zanim można obliczyć nagrody i aktualizacje. Długie konteksty i wiele próbek sprawiają, że ten etap jest szczególnie kosztowny.

MXFP8 poprawił również czas treningu względem BF16 w zmierzonej konfiguracji. Strona treningowa NVFP4 poszła w przeciwnym kierunku. Oba warianty nadpisania propagacji wstecznej NVFP4 były podczas treningu wolniejsze od BF16, mimo szybszego rolloutu.

Miles przypisuje tę różnicę obecnej integracji, a nie Tensor Cores FP4 Blackwell. Zmierzona ścieżka TransformerEngine wykonuje skalowanie FP32 per token jako oddzielną operację PyTorch. Istnieją zfuzowane kernele cuDNN frontend, lecz ich integracja z TransformerEngine pozostaje w toku.

Ten mieszany wynik utrzymuje analizę na solidnym gruncie. NVFP4 nie jest automatycznie szybszy tylko dlatego, że jego wartości są mniejsze. O tym, czy teoretyczna przepustowość dotrze do kompletnej aplikacji, decydują fuzja kerneli, układy danych, operacje skalowania i granice frameworków.

Konfiguracje niskiej precyzji wykazały także większą rozbieżność między treningiem a rolloutem niż BF16. NVFP4 zaczynał z wyższym pomiarem referencyjnym KL, który porównuje rozkłady polityk. Miles obliczał jednak tę diagnostykę względem referencyjnego modelu BF16 Megatron.

Metryka zawiera więc różnicę formatów od samego początku. Jej współczynnik ustawiono na zero, dlatego nie działała jako kara optymalizacyjna. Miles ostrzega przed traktowaniem tego pomiaru jako samodzielnej oznaki niepowodzenia uczenia.

Krzywe nagród tworzą użyteczne odwrócenie sytuacji. Niedopasowanie precyzji wzrosło, ale obserwowane nagrody nie oddzieliły się istotnie od BF16 w trakcie ablacji. To połączenie uzasadnia dalsze testy, pozostawiając jednocześnie otwarte pytanie o stabilność w długim okresie.

Wspólny kwantyzer jest rzeczywistym mechanizmem

Miles traktuje RL niskiej precyzji jako problem rozproszonej spójności, a nie jedynie prośbę o mniejsze liczby.

Każda część stosu RL może niezależnie kwantyzować tensory. Megatron odpowiada za trening, podczas gdy SGLang i FlashInfer obsługują operacje rolloutu. Konwersja checkpointów i aktualizacje wag na żywo tworzą dwie kolejne okazje do rozbieżności wartości lub układów.

Nawet niewielkie różnice mogą kumulować się podczas powtarzanych aktualizacji polityki. Worker treningowy może optymalizować jedną skwantyzowaną reprezentację, podczas gdy workery rolloutu próbkują z innej. Nagrody opisują wtedy zachowanie polityki, której optymalizator nigdy nie widzi dokładnie.

Miles rozwiązuje ten problem za pomocą kontraktu bitowo dokładnego kwantyzera. Testy FlashInfer porównują jego wynik bajt po bajcie z referencją w stylu TransformerEngine. Dane testowe obejmują wartości losowe, przypadki graniczne, tensory zerowe i maksymalne wartości reprezentowalne.

Zespół wyłącza również opcję fast-math FlashInfer dla odpowiedniej ścieżki kwantyzacji FP4. Matematyka przybliżona może być rozsądna w zwykłym serwowaniu, gdzie drobne różnice nie wpływają zwrotnie na przyszłe wagi. RL czyni z tych różnic część pętli uczenia.

MXFP8 stwarza kolejny problem układu. Blackwell Tensor Cores oczekują, że bloki mikroskalowania będą przebiegać wzdłuż wymiaru redukcji macierzy. Operacje w przód i wstecz mogą używać różnych orientacji, więc jedna skwantyzowana kopia nie zawsze może poprawnie obsłużyć obie ścieżki.

Dokumentacja MXFP8 wyjaśnia, że TransformerEngine tworzy kopie wierszowe i kolumnowe z oryginalnego wejścia wysokiej precyzji. Zużywa to więcej pamięci, ale pozwala uniknąć dekwantyzacji i ponownej kwantyzacji istniejącej kopii niskiej precyzji.

Miles akceptuje ten koszt pamięci w pełnej ścieżce MXFP8. Jego alternatywy propagacji wstecznej wysokiej precyzji i dekwantyzowanej unikają utrzymywania drugiej skwantyzowanej kopii. Wybór staje się równowagą między zgodnością numeryczną, zużyciem pamięci, pracą dekwantyzacji i szybkością mnożenia macierzy.

NVFP4 wprowadza inny problem spójności. Współdzielenie jednej skali aktywacji między wieloma tokenami sprawia, że skwantyzowana wartość tokenu zależy od jego sąsiadów. Zmiany w harmonogramowaniu rolloutu, długości sekwencji lub pakowaniu batchy mogą wtedy zmienić reprezentację polityki.

Miles oblicza jedną skalę aktywacji FP32 na token online. FlashInfer scala to obliczenie z kernelem kwantyzacji aktywacji rolloutu. Ta sama operacja emituje spakowane aktywacje FP4, skale bloków i skale tokenów.

Trening i rollout muszą również korzystać z dopasowanych partycji tensor parallel dla ekspertów. W przeciwnym razie każdy system widzi inne fragmenty tensora podczas obliczania skali per token. Identyczne formuły nie mogą tworzyć identycznych polityk z różnych wejść.

Warstwy ekspertów SwiGLU dodają kolejny szczególny przypadek. Ich projekcje gate i up zwykle trafiają do jednego zfuzowanego mnożenia macierzy, choć checkpointy mogą przechowywać je osobno. Miles kwantyzuje każdą parę gate-and-up razem, aby obie otrzymały jedną spójną większą skalę.

Te szczegóły implementacyjne wyjaśniają, dlaczego praca Miles Blackwell obejmuje kilka repozytoriów. Żadna pojedyncza biblioteka nie kontroluje każdej reprezentacji między zapisanym checkpointem a wygenerowanym rolloutem. Kontrakt precyzji musi przetrwać każde przekazanie.

Ta praca systemowa odróżnia również recepturę od kwantyzacji po treningu. Statyczny checkpoint inferencyjny można skalibrować raz i serwować wielokrotnie. Uczenie ze wzmocnieniem stale zmienia wagi, więc każdy eksport na żywo faktycznie tworzy nowe zdarzenie kwantyzacji.

Zespoły oceniające podobne systemy będą potrzebować możliwych do prześledzenia dowodów tych zdarzeń. Wewnętrzna baza wiedzy inżynieryjnej może łączyć konfiguracje, wersje jądra, krzywe ewaluacyjne i notatki dotyczące incydentów. Taki zapis staje się ważny, gdy regresja numeryczna pojawia się kilka aktualizacji później.

NVFP4 per token podważa domyślny wybór jednolitego BF16

Podejście Miles Blackwell zmusza zespoły do uzasadnienia stosowania BF16 wszędzie, jednocześnie traktując selektywne BF16 jako narzędzie zapewniające stabilność.

BF16 pozostaje prostszym punktem odniesienia. Oferuje szerszy zakres numeryczny, mniej wymogów związanych z kwantyzacją i łatwiejsze porównania między treningiem a wdrożeniem. Jego słabością jest to, że każda waga eksperta i aktywacja zużywa więcej przepustowości pamięci, niż wymagają węższe formaty.

Modele MoE czynią ten kompromis bardziej widocznym. Zawierają wiele parametrów ekspertów, choć każdy token aktywuje jedynie ich podzbiór. Przenoszenie wag ekspertów przez pamięć podczas wdrożenia może stać się większym ograniczeniem niż sama wydajność obliczeniowa.

Miles skupia się więc najpierw na ścieżce ekspertów. Strategia przypomina budżet finansowy, a nie ideologiczne przywiązanie do treningu czterobitowego. Przeznacza precyzję na tensory, które najprawdopodobniej wpływają na stabilność, i kompresuje największe, powtarzalne struktury.

W eksperymencie końcowe 15 procent warstw modelu pozostawiono w BF16 dla każdej konfiguracji niskiej precyzji. Miles twierdzi, że wybór ten zmniejszył rozbieżność między treningiem a inferencją i poprawił stabilność gradientów. Utrzymanie wczesnych warstw w BF16 nie przyniosło podobnie znaczącej redukcji.

Współdzieleni eksperci również pozostali w wyższej precyzji. W przeciwieństwie do ekspertów kierowanych trasowaniem przetwarzają każdy token. Ich błędy kwantyzacji propagowałyby się więc przez każdy blok MoE, a nie wyłącznie przez wybrane ścieżki.

Niektóre projekcje wielogłowowej uwagi ukrytej również otrzymały wyjątki BF16. Ich osie kontrakcji mogą zmieniać się wraz z trybem wykonania, podczas gdy MXFP8 wykorzystuje jednowymiarowe bloki skalowania. Zmieniona oś może ponownie grupować wartości pod różnymi skalami.

Te wyjątki są kluczową częścią receptury, a nie przypadkowym porządkowaniem. Nagłówek opisujący model całkowicie FP4 fałszowałby obraz tej pracy. Miles stworzył zamiast tego precyzyjne mechanizmy kontroli, które zachowują każdy wyjątek podczas konwersji, treningu, wdrożenia i aktualizacji na żywo.

Wywiera to presję na konwencjonalne potoki BF16 na dwa sposoby. Po pierwsze, ablacja nagród sugeruje, że węższe ścieżki wdrożeniowe zasługują na ocenę na Blackwell. Po drugie, system konfiguracji oferuje alternatywę dla wyboru jednego formatu dla każdej warstwy.

Wywiera również presję na wcześniejsze podejścia FP8 zaprojektowane wokół Hopper. DeepSeek-V3 wykorzystuje bloki 128 na 128 dla wag oraz kafelki 1 na 128 dla aktywacji. Miles opisuje ten projekt jako skuteczny, lecz nie może on wykorzystywać sprzętu mikroskalowania Blackwell w ten sam natywny sposób.

Porównanie nie czyni starszej metody przestarzałą. Klastry Hopper są nadal szeroko wdrożone, a skalowane blokowo FP8 ma dłuższą historię operacyjną. Formaty natywne dla Blackwell tworzą też granice kompatybilności dla zespołów obsługujących mieszane generacje GPU.

Przewodnik TransformerEngine firmy NVIDIA obsługuje obecnie FP8, MXFP8 i NVFP4 za pośrednictwem zoptymalizowanych bloków konstrukcyjnych. Sama obsługa przez framework nie rozstrzyga jednak, które warstwy powinny używać każdego z formatów. O tej decyzji nadal decydują architektura modelu i charakter obciążenia.

Najbardziej bezpośrednimi beneficjentami są organizacje uruchamiające duże zadania uczenia ze wzmocnieniem MoE na Blackwell. Mogą testować szybsze wdrożenie bez natychmiastowego przenoszenia każdej operacji wstecznej do niskiej precyzji. Ta etapowa ścieżka obniża koszt gromadzenia dowodów.

Mniejsze zespoły stoją przed inną kalkulacją. Odtworzenie konfiguracji wymaga ośmiu GPU B200, kilku skoordynowanych bibliotek i starannej zgodności konfiguracji. Obciążenie inżynieryjne może przewyższyć oszczędności podczas wdrożenia przy umiarkowanej skali.

Podstawowa linia konkurencji przebiega więc między selektywną spójnością a jednolitą prostotą. Miles oferuje większą kontrolę i ścieżkę do mniejszego ruchu pamięci. BF16 oferuje mniej interfejsów, w których niezauważona rozbieżność może wejść do procesu uczenia.

Czego ablacja Qwen3 nie dowodzi

Opublikowany eksperyment wspiera obiecującą recepturę, ale nie ustanawia szerokiej równoważności jakości ani pełnej wydajności czterobitowej.

Najbardziej bezpośrednim ograniczeniem jest zakres. Miles przetestował jeden model, jeden zbiór danych zorientowany na matematykę, jeden układ sprzętowy i jedną główną konfigurację obciążenia. Ścisłe śledzenie nagród w tym przypadku nie pozwala przewidzieć zachowania w zadaniach programistycznych, użyciu narzędzi, dialogu czy zadaniach wieloagentowych.

Stała konfiguracja wykorzystywała synchroniczne RL oraz podział na cztery GPU zarówno dla wdrożenia, jak i treningu. Systemy asynchroniczne mogą wprowadzać większe opóźnienie polityki między generowaniem danych a optymalizacją. To opóźnienie może inaczej oddziaływać z rozbieżnością kwantyzacji.

Opublikowany wykres nagród obejmuje również ablacją receptury, a nie w pełni dostrojony przebieg treningu. Miles wyraźnie opisuje go w ten sposób. Czytelnicy nie powinni interpretować wykresu jako zwycięstwa benchmarkowego nad zoptymalizowanymi systemami BF16.

Surowa nagroda może ukrywać zmiany behawioralne. Dwie polityki mogą osiągać podobne wyniki, korzystając z odmiennych wzorców rozumowania, długości odpowiedzi lub trybów awarii. Mocniejsza walidacja obejmowałaby oceny na wydzielonych danych, wiele losowych ziaren i analizę błędów specyficzną dla zadania.

Kolejną kwestią pozostają sporadyczne skoki gradientów w NVFP4. Wariant z wsteczną propagacją w wysokiej precyzji wykazał skoki podczas opisanego przebiegu. Zdekwantyzowana propagacja wsteczna ograniczyła największe przykłady, ale ich nie usunęła.

Jest to zgodne z szerszymi obawami dotyczącymi treningu czterobitowego. Badania nad wartościami odstającymi NVFP4 wykazały utrzymującą się wrażliwość w określonych komponentach architektury. Praca ta dotyczy wstępnego treningu, a nie receptury RL Milesa, lecz wzmacnia potrzebę monitorowania na poziomie warstw.

Obecna historia pamięci jest również niepełna. Megatron nadal zachowuje dodatkową kopię wag BF16, mimo że wykonuje trening i wdrożenie przez receptury niskiej precyzji. Ta kopia ogranicza ilość pamięci modelu, którą system faktycznie odzyskuje.

Natywne dla Blackwell zbieranie parametrów niskiej precyzji wciąż dojrzewa. Miles zauważa, że odpowiednia ścieżka zbierania parametrów NVFP4 nie obsługuje jeszcze jego jednowymiarowego układu wag 1 na 16. Usunięcie kopii BF16 częściowo zależy od tej infrastruktury.

Wydajność treningu NVFP4 stanowi drugi niedokończony obszar. Wdrożenie przyspieszyło, ale trening zwolnił w testowanej implementacji. Oczekiwana zintegrowana integracja TransformerEngine musi zlikwidować tę lukę, zanim NVFP4 będzie mógł deklarować wyraźniejszą przewagę end-to-end.

Przenoszenie wag na żywo również pozostaje skomplikowane. Backendy obsługujące serwowanie często dopełniają, przestawiają lub swizzlują wagi do układów zoptymalizowanych pod konkretne kernelle. Systemy treningowe zwykle utrzymują inną kanoniczną reprezentację tensorów.

Te transformacje mogą utrudniać aktualizacje o niskim opóźnieniu lub zdalny bezpośredni dostęp do pamięci. Każdy układ specyficzny dla backendu dodaje kolejny krok, który musi pozostać weryfikowalny. Szybki kernel ma ograniczoną wartość, jeśli każda aktualizacja polityki wywołuje kosztowne przepakowanie.

Specyfika sprzętowa tworzy ryzyko komercyjne. MXFP8 i NVFP4 otrzymują natywne przyspieszenie na Blackwell, ale wiele organizacji nadal wykorzystuje sprzęt Hopper. Przyjęcie nowych receptur może podzielić wsparcie infrastruktury między wiele ścieżek precyzji.

W opublikowanych dowodach brakuje też niezależnej replikacji. Wyniki pochodzą od zespołu, który zaprojektował i wdrożył receptury. Jest to odpowiednie dla wstępnego raportu inżynieryjnego, lecz odtworzenia przez strony trzecie wzmocniłyby zaufanie.

Żadne z tych ograniczeń nie przekreśla zaobserwowanego wyniku. Definiują one, co ten wynik oznacza. Miles pokazał, że starannie kontrolowana niska precyzja może podążać za nagrodami BF16 w jednej wymagającej konfiguracji, jednocześnie skracając czas wdrożenia.

Kolejny standard jest trudniejszy. Receptury muszą pozostać stabilne w dłuższych przebiegach, zróżnicowanych zadaniach, aktualizacjach asynchronicznych, większych modelach i różnych układach równoległości. Muszą też zachować swoje zyski po uwzględnieniu w pomiarze wszystkich narzutów frameworka.

Trzy sygnały zdecydują, czy receptura się sprawdzi

Trzy kolejne sygnały to zintegrowany trening NVFP4, niezależna replikacja nagród oraz usunięcie dodatkowej kopii wag BF16.

Po pierwsze, obserwuj oczekującą integrację TransformerEngine dla zintegrowanego skalowania NVFP4 per token. Miles już używa zintegrowanego skalowania w ścieżce wdrożeniowej FlashInfer, ale jego mierzona ścieżka treningowa wykonuje osobną operację. Integracja powinna ujawnić, czy NVFP4 może poprawić czas treningu, a także czas wdrożenia.

Szybszy wynik end-to-end wzmocniłby argument za tym formatem. Utrzymujące się spowolnienie treningu ograniczyłoby jego atrakcyjność do obciążeń zdominowanych przez wdrożenie. Każdy z tych wyników wyjaśniłby, gdzie obliczenia czterobitowe zapewniają praktyczną wartość.

Po drugie, obserwuj niezależne reprodukcje dla różnych modeli i zadań. Testy o największej wartości obejmowałyby programowanie, rozumowanie z długim kontekstem, użycie narzędzi i asynchroniczne RL. Wiele ziaren pomogłoby oddzielić zachowanie formatu od zwykłej wariancji nagród.

Podobne krzywe nagród dla tych obciążeń wspierałyby tezę Milesa o spójności. Rozbieżności w określonych warstwach lub zadaniach wskazałyby natomiast, gdzie wyjątki BF16 muszą zostać rozszerzone. Każdy wynik byłby użyteczniejszy niż pojedyncza, uniwersalna zasada precyzji.

Po trzecie, obserwuj, czy Megatron może usunąć dodatkową kopię wag BF16, nadal obsługując układ wag tej receptury. Ta zmiana ujawniłaby korzyść pamięciową obecnie ukrytą przez wymagania kompatybilności. Sprawdziłaby również, czy polityka niskiej precyzji może stać się podstawową reprezentacją przechowywaną przez system.

Praca Miles Blackwell przekroczyła ważną granicę inżynieryjną. MXFP8 i NVFP4 per token uczestniczą teraz w jednej połączonej pętli RL, zamiast pojawiać się wyłącznie w odizolowanych testach inferencji lub treningu.

Istotniejsze pytanie nie brzmi już, czy Blackwell może wykonywać operacje czterobitowe i ośmiobitowe. Brzmi ono, czy zespoły potrafią zachować jedną politykę we wszystkich systemach, które dotykają tych wartości. Śledź integracje, reprodukcje i zmiany pamięci, zanim uznasz krzywe Qwen3 za wynik ogólny.