Miles Blackwell RL Troca a Uniformidade BF16 por MXFP8 e NVFP4 Nativos

O suporte Miles Blackwell agora inclui duas receitas nativas de aprendizado por reforço de baixa precisão, testadas em seis configurações com oito GPUs NVIDIA B200. Uma executa MXFP8 no rollout e no treinamento. A outra aplica NVFP4 por token aos pesos de mixture-of-experts, preservando maior precisão em outras partes.

O resultado desafia uma premissa conhecida sobre aprendizado por reforço, ou RL. Menor precisão não exige necessariamente aceitar uma curva de aprendizado visivelmente pior. Na ablação Qwen3-30B-A3B da Miles, todas as cinco configurações de baixa precisão acompanharam de perto as recompensas brutas da linha de base BF16.

A descoberta traz uma qualificação importante. O experimento foi uma ablação de receita controlada, não um benchmark de treinamento totalmente ajustado nem uma garantia geral de precisão. A Miles também manteve BF16 em camadas sensíveis, preservou uma cópia extra dos pesos em BF16 e observou picos ocasionais de gradiente com NVFP4.

A disputa real, portanto, não é simplesmente quatro bits contra dezesseis bits. É um contrato de precisão consistente e seletivo contra um pipeline BF16 uniforme. A Miles argumenta que os formatos nativos do Blackwell se tornam úteis quando treinamento, amostragem, conversão e atualizações de pesos ao vivo quantizam os mesmos tensores da mesma forma.

O Suporte Miles Blackwell Agora Abrange Todo o Loop de RL

A Miles levou MXFP8 e NVFP4 além de kernels isolados ao conectá-los por todo o caminho completo do aprendizado por reforço.

A equipe da Miles publicou as receitas em 29 de julho de 2026. Seus resultados de baixa precisão abrangem conversão de checkpoints, treinamento com Megatron, rollout com SGLang e exportação de pesos ao vivo. A implementação também depende de componentes contribuídos por TransformerEngine, FlashInfer, cuDNN frontend e projetos relacionados.

A primeira receita usa MXFP8 em todo o principal caminho computacional. MXFP8 é um formato de microescalonamento de oito bits no qual cada bloco de 32 valores E4M3 compartilha uma escala E8M0. Rollout, propagação direta, multiplicações de matrizes de gradientes de peso e multiplicações de gradientes de dados podem usá-lo.

Essa ampla cobertura importa porque um sistema de RL contém duas políticas estreitamente vinculadas. A política de treinamento calcula atualizações, enquanto a política de rollout gera as respostas usadas para calcular recompensas. Se elas quantizam pesos de forma diferente, deixam de representar exatamente o mesmo modelo.

A Miles já oferecia suporte a um design FP8 no estilo DeepSeek-V3, baseado em blocos de escalonamento maiores. Essa abordagem continua relevante, especialmente em hardware Hopper. No entanto, ela aplica escalonamento em software ao redor do caminho dos Tensor Cores, em vez de usar o hardware nativo de microescalonamento do Blackwell.

A segunda receita adota uma abordagem mais seletiva. Ela aplica NVFP4 aos pesos e ativações dos experts roteados dentro das camadas mixture-of-experts, ou MoE. NVFP4 armazena valores E2M1 em quatro bits, com uma escala E4M3 para cada bloco de 16 valores.

Uma segunda escala FP32 cobre um escopo maior. A Miles calcula essa escala separadamente para cada token, em vez de compartilhar uma única escala por tensor ou lote. Esse detalhe busca impedir que a representação de um token mude conforme a composição do lote.

O restante do modelo NVFP4 permanece em BF16, a menos que regras de configuração selecionem outro formato. Esse design concentra a computação de quatro bits onde os modelos MoE armazenam grande parte de seus dados de peso. Também evita forçar atenção e outros componentes sensíveis para a representação mais limitada disponível.

A NVIDIA descreve o escalonamento NVFP4 como um sistema de dois níveis projetado para os Tensor Cores Blackwell. Os blocos de 16 valores fornecem adaptação local mais refinada do que formatos que usam grupos de 32 valores. A escala FP32 em nível de tensor amplia a faixa utilizável.

A Miles alterou o escopo da escala maior de por tensor para por token. Essa escolha diferencia sua receita de RL de uma implantação de inferência convencional. Ela também mostra por que adicionar um tipo de dados FP4 não basta para criar um sistema de RL estável.

Ambas as receitas oferecem suporte a modos backward de alta precisão e desquantizado. O backward de alta precisão usa os operandos BF16 originais para multiplicações de matrizes no backward. Já o backward desquantizado reconstrói operandos BF16 a partir dos valores exatos de baixa precisão usados durante a passagem direta.

A segunda opção sacrifica parte do detalhamento numérico, mas preserva uma correspondência mais próxima com a política da passagem direta. Nenhum modo NVFP4 executa suas multiplicações de matrizes no backward em FP4. Portanto, a Miles está testando baixa precisão seletiva, e não alegando um loop de treinamento universalmente de quatro bits.

As Curvas de Recompensa Mudam o Ônus da Prova

O resultado mais notável não é o pico de throughput dos Tensor Cores, mas a ausência de uma penalidade evidente de recompensa na carga de trabalho testada.

A Miles avaliou Qwen3-30B-A3B com RL síncrono no estilo GRPO no conjunto de dados dapo-math-17k. O sistema usou oito GPUs B200, divididas igualmente entre rollout e treinamento. Cada prompt recebeu oito amostras de rollout, com respostas limitadas a 8.192 tokens.

O estudo comparou uma linha de base BF16 com cinco configurações de baixa precisão. Elas incluíram MXFP8 de ponta a ponta e dois modos backward para cada formato de baixa precisão. As variantes NVFP4 limitaram a operação de quatro bits ao caminho dos experts MoE.

Todas as cinco curvas de recompensa bruta de baixa precisão acompanharam de perto a curva BF16. Isso não estabelece equivalência entre tarefas, seeds ou execuções de treinamento mais longas. Mas sugere que o rollout de menor precisão não sobrepujou o sinal de aprendizado nesse experimento específico.

Esse é um limiar significativo para RL. O treinamento supervisionado pode calcular a média dos sinais de otimização em um grande conjunto de dados relativamente estável. O RL frequentemente trabalha com recompensas mais ruidosas e atualizações menores de política, tornando mais difícil separar erros adicionais de quantização de aprendizado genuíno.

A Miles também relatou que MXFP8 e NVFP4 reduziram o tempo de rollout em comparação com BF16. O artigo publicado apresenta a comparação graficamente, mas não fornece uma porcentagem única apropriada para uma manchete universal. A direção do resultado é mais clara que sua portabilidade.

A melhoria no rollout importa porque a geração frequentemente domina as cargas de trabalho de aprendizado por reforço. Uma política precisa produzir respostas completas antes que recompensas e atualizações possam ser calculadas. Contextos longos e múltiplas amostras tornam essa etapa especialmente cara.

MXFP8 também melhorou o tempo de treinamento em relação ao BF16 na configuração medida. O lado de treinamento do NVFP4 se moveu na direção oposta. Ambas as variantes NVFP4 com override de backward foram mais lentas que BF16 durante o treinamento, apesar do rollout mais rápido.

A Miles atribui essa diferença à sua integração atual, e não aos Tensor Cores FP4 do Blackwell. O caminho TransformerEngine medido executa o escalonamento FP32 por token como uma operação PyTorch separada. Existem kernels cuDNN frontend fusionados, mas sua integração ao TransformerEngine ainda está pendente.

Esse resultado dividido mantém a análise fundamentada. NVFP4 não é automaticamente mais rápido apenas porque seus valores são menores. Fusão de kernels, layouts de dados, operações de escalonamento e limites entre frameworks determinam se o throughput teórico chega à aplicação completa.

As configurações de baixa precisão também mostraram maior divergência entre treinamento e rollout do que BF16. NVFP4 começou com uma medição de KL de referência mais alta, que compara distribuições de políticas. No entanto, a Miles calculou esse diagnóstico em relação a um modelo de referência Megatron em BF16.

Portanto, a métrica já contém desde o início a diferença de formato. Seu coeficiente foi definido como zero, de modo que ela não funcionou como penalidade de otimização. A Miles alerta contra tratar a medição como um sinal isolado de falha de aprendizado.

As curvas de recompensa produzem uma inversão útil. A divergência de precisão aumentou, mas as recompensas observadas não se separaram materialmente do BF16 durante a ablação. Essa combinação sustenta novos testes, ao mesmo tempo que mantém em aberto a questão da estabilidade no longo prazo.

Um Quantizador Compartilhado É o Verdadeiro Mecanismo

A Miles trata o RL de baixa precisão como um problema de consistência distribuída, não apenas como um pedido por números menores.

Cada parte da pilha de RL pode quantizar tensores de forma independente. Megatron controla o treinamento, enquanto SGLang e FlashInfer tratam das operações de rollout. A conversão de checkpoints e as atualizações de pesos ao vivo introduzem mais duas oportunidades para que valores ou layouts divirjam.

Mesmo pequenas diferenças podem se acumular ao longo de atualizações repetidas da política. Um worker de treinamento pode otimizar uma representação quantizada, enquanto workers de rollout amostram outra. As recompensas passam então a descrever o comportamento de uma política que o otimizador nunca vê exatamente.

A Miles resolve esse problema por meio de um contrato de quantizador exato em bits. Os testes do FlashInfer comparam sua saída byte a byte com uma referência no estilo TransformerEngine. As entradas de teste incluem valores aleatórios, casos de limite, tensores zero e valores máximos representáveis.

A equipe também desativa uma opção de fast-math do FlashInfer para o caminho relevante de quantização FP4. A matemática aproximada pode ser razoável para serving comum, em que pequenas diferenças não retroalimentam pesos futuros. O RL transforma essas diferenças em parte do loop de aprendizado.

MXFP8 apresenta outra questão de layout. Os Tensor Cores Blackwell esperam que blocos de microescalonamento sigam a dimensão de redução da matriz. Operações forward e backward podem usar orientações diferentes, portanto uma cópia quantizada não pode sempre atender corretamente aos dois caminhos.

A documentação do MXFP8 explica que o TransformerEngine cria cópias por linha e por coluna a partir da entrada original de alta precisão. Isso consome mais memória, mas evita desquantizar e requantizar uma cópia de baixa precisão já existente.

A Miles aceita esse custo de memória em seu caminho MXFP8 completo. Suas alternativas backward de alta precisão e desquantizado evitam reter a segunda cópia quantizada. A escolha se torna um equilíbrio entre concordância numérica, uso de memória, trabalho de desquantização e velocidade de multiplicação de matrizes.

NVFP4 introduz um problema diferente de consistência. Compartilhar uma única escala de ativação entre múltiplos tokens faz o valor quantizado de um token depender de seus vizinhos. Mudanças no agendamento de rollout, no comprimento da sequência ou no empacotamento de lotes podem então alterar a representação da política.

A Miles calcula uma escala de ativação FP32 por token online. O FlashInfer funde esse cálculo ao kernel de quantização de ativações do rollout. A mesma operação produz ativações FP4 empacotadas, escalas de bloco e escalas de token.

Treinamento e rollout também precisam usar partições correspondentes de paralelismo de tensor dos experts. Caso contrário, cada sistema vê partes diferentes do tensor ao calcular a escala por token. Fórmulas idênticas não conseguem produzir políticas idênticas a partir de entradas diferentes.

Camadas de experts SwiGLU acrescentam outro caso especial. Suas projeções gate e up normalmente entram em uma multiplicação de matrizes fusionada, embora os checkpoints possam armazená-las separadamente. A Miles quantiza cada par gate-and-up em conjunto para que ambos recebam uma escala maior consistente.

Esses detalhes de implementação explicam por que o trabalho Miles Blackwell se estende por vários repositórios. Nenhuma biblioteca única controla todas as representações entre um checkpoint salvo e um rollout gerado. O contrato de precisão precisa sobreviver a cada transferência.

Esse trabalho de sistemas também diferencia a receita da quantização pós-treinamento. Um checkpoint de inferência estático pode ser calibrado uma vez e servido repetidamente. O aprendizado por reforço altera pesos continuamente, de modo que cada exportação ao vivo efetivamente cria um novo evento de quantização.

As equipes que avaliam sistemas semelhantes precisarão de evidências rastreáveis para esses eventos. Uma base de conhecimento de engenharia interna pode conectar configurações, versões de kernel, curvas de avaliação e notas de incidentes. Esse registro se torna importante quando uma regressão numérica aparece várias atualizações depois.

O NVFP4 por token pressiona o padrão uniforme de BF16

A abordagem Miles Blackwell pressiona as equipes a justificarem o BF16 em todos os lugares, ao mesmo tempo que trata o BF16 seletivo como uma ferramenta de estabilidade.

O BF16 continua sendo a base mais simples. Ele oferece uma faixa numérica mais ampla, menos restrições de quantização e comparações mais fáceis entre treinamento e rollout. Sua fraqueza é que cada peso e ativação de especialista consome mais largura de banda de memória do que formatos mais estreitos exigem.

Os modelos MoE tornam essa troca mais visível. Eles contêm muitos parâmetros de especialistas, embora cada token ative apenas um subconjunto. Mover pesos de especialistas pela memória durante o rollout pode se tornar mais restritivo do que a capacidade aritmética bruta.

Por isso, Miles mira primeiro o caminho dos especialistas. A estratégia se assemelha a um orçamento financeiro, e não a um compromisso ideológico com o treinamento em quatro bits. Ela investe precisão nos tensores com maior probabilidade de influenciar a estabilidade e comprime as maiores estruturas repetidas.

O experimento manteve os 15% finais das camadas do modelo em BF16 em todas as configurações de baixa precisão. Miles afirma que essa escolha reduziu a divergência entre treinamento e inferência e melhorou a estabilidade dos gradientes. Manter as camadas iniciais em BF16 não proporcionou uma redução igualmente significativa.

Os especialistas compartilhados também permaneceram em maior precisão. Diferentemente dos especialistas roteados, eles processam todos os tokens. Portanto, seus erros de quantização se propagariam por cada bloco MoE, e não apenas pelas rotas selecionadas.

Certas projeções de atenção latente multi-head também receberam exceções em BF16. Seus eixos de contração podem mudar com o modo de execução, enquanto o MXFP8 usa blocos de escala unidimensionais. Uma mudança de eixo pode reagrupar valores sob escalas diferentes.

Essas exceções são centrais para a receita, não uma limpeza incidental. Uma manchete que descrevesse um modelo inteiramente FP4 distorceria o trabalho. Em vez disso, Miles construiu controles detalhados que preservam cada exceção durante a conversão, o treinamento, o rollout e as atualizações em tempo real.

Isso pressiona os pipelines convencionais de BF16 de duas maneiras. Primeiro, a ablação de recompensa sugere que caminhos de rollout mais estreitos merecem avaliação no Blackwell. Segundo, o sistema de configuração oferece uma alternativa a escolher um único formato para cada camada.

Também pressiona abordagens FP8 anteriores projetadas para Hopper. O DeepSeek-V3 usa blocos de 128 por 128 para pesos e tiles de 1 por 128 para ativações. Miles descreve esse design como eficaz, mas ele não consegue usar o hardware de microescalonamento do Blackwell da mesma maneira nativa.

A comparação não torna o método mais antigo obsoleto. Os clusters Hopper continuam amplamente implantados, e o FP8 com escala por bloco possui um histórico operacional mais longo. Os formatos nativos do Blackwell também criam limites de compatibilidade para equipes que oferecem suporte a gerações mistas de GPUs.

O guia TransformerEngine da NVIDIA agora oferece suporte a FP8, MXFP8 e NVFP4 por meio de blocos de construção otimizados. Ainda assim, o suporte do framework por si só não define quais camadas devem usar cada formato. A arquitetura do modelo e o perfil da carga de trabalho continuam determinando essa decisão.

Os beneficiários mais diretos são organizações que executam grandes trabalhos de aprendizado por reforço com MoE no Blackwell. Elas podem testar um rollout mais rápido sem mover imediatamente todas as operações backward para baixa precisão. Esse caminho em etapas reduz o custo de coletar evidências.

Equipes menores enfrentam um cálculo diferente. Reproduzir a configuração exige oito GPUs B200, várias bibliotecas coordenadas e uma cuidadosa paridade de configuração. A carga de engenharia pode superar as economias no rollout em escala modesta.

A principal linha competitiva é, portanto, consistência seletiva versus simplicidade uniforme. Miles oferece mais controle e um caminho para menor tráfego de memória. O BF16 oferece menos interfaces pelas quais uma divergência despercebida pode entrar no processo de aprendizado.

O que a ablação do Qwen3 não estabelece

O experimento publicado sustenta uma receita promissora, mas não estabelece ampla paridade de qualidade nem eficiência completa em quatro bits.

A limitação mais imediata é o escopo. Miles testou um modelo, um conjunto de dados voltado para matemática, uma configuração de hardware e uma configuração principal de carga de trabalho. Acompanhamentos próximos das recompensas nesse contexto não podem prever o comportamento em programação, uso de ferramentas, diálogo ou tarefas multiagente.

A configuração fixa usou RL síncrono e uma divisão de quatro GPUs para cada um dos processos de rollout e treinamento. Sistemas assíncronos podem introduzir maior defasagem de política entre a geração de dados e a otimização. Essa defasagem pode interagir de forma diferente com a divergência de quantização.

O gráfico de recompensa publicado também cobre uma ablação de receita, e não uma execução de treinamento totalmente ajustada. Miles o descreve explicitamente dessa forma. Os leitores não devem interpretar o gráfico como uma vitória de benchmark contra sistemas BF16 otimizados.

A recompensa bruta pode ocultar mudanças comportamentais. Duas políticas podem atingir pontuações semelhantes usando padrões de raciocínio, extensões de resposta ou modos de falha diferentes. Uma validação mais robusta incluiria avaliações retidas, múltiplas seeds aleatórias e análise de erros específica por tarefa.

Os picos ocasionais de gradiente do NVFP4 continuam sendo outra preocupação. A variante com backward em alta precisão apresentou picos durante a execução relatada. O backward desquantizado reduziu os maiores exemplos, mas não os eliminou.

Isso é consistente com preocupações mais amplas sobre o treinamento em quatro bits. Pesquisas sobre outliers de NVFP4 identificaram sensibilidade persistente em componentes arquiteturais específicos. Esse trabalho trata de pré-treinamento, não da receita de RL de Miles, mas reforça a necessidade de monitoramento no nível das camadas.

A atual narrativa sobre memória também está incompleta. O Megatron ainda preserva uma cópia adicional dos pesos em BF16, apesar de executar o treinamento e o rollout por meio de receitas de baixa precisão. Essa cópia limita quanto da memória do modelo o sistema realmente recupera.

A coleta de parâmetros em baixa precisão nativa do Blackwell ainda está amadurecendo. Miles observa que o caminho relevante de coleta de parâmetros NVFP4 ainda não oferece suporte ao seu layout unidimensional de pesos 1 por 16. Remover a cópia em BF16 depende, em parte, dessa infraestrutura.

O desempenho do treinamento com NVFP4 apresenta uma segunda área inacabada. O rollout melhorou, mas o treinamento ficou mais lento na implementação testada. A integração pendente com TransformerEngine fundido precisa fechar essa lacuna antes que o NVFP4 possa reivindicar uma vantagem mais clara de ponta a ponta.

A movimentação de pesos em tempo real também continua complicada. Os backends de serving frequentemente preenchem, embaralham ou reorganizam pesos em layouts otimizados para kernels específicos. Os sistemas de treinamento normalmente mantêm uma representação canônica de tensor diferente.

Essas transformações podem dificultar atualizações de baixa latência ou acesso remoto direto à memória. Cada layout específico de backend acrescenta outra etapa que precisa continuar verificável. Um kernel rápido tem valor limitado se cada atualização de política aciona um reempacotamento caro.

A especificidade de hardware cria um risco comercial. MXFP8 e NVFP4 recebem aceleração nativa no Blackwell, mas muitas organizações ainda operam hardware Hopper. Adotar as novas receitas pode dividir o suporte de infraestrutura entre múltiplos caminhos de precisão.

Também não há replicação independente nas evidências publicadas. Os resultados vêm da equipe que projetou e implementou as receitas. Isso é apropriado para um relatório inicial de engenharia, mas reproduções de terceiros fortaleceriam a confiança.

Nenhum desses limites apaga o resultado observado. Eles definem o que o resultado significa. Miles mostrou que uma baixa precisão cuidadosamente controlada pode acompanhar as recompensas do BF16 em uma configuração exigente enquanto reduz o tempo de rollout.

O próximo padrão é mais difícil. As receitas precisam permanecer estáveis em execuções mais longas, tarefas variadas, atualizações assíncronas, modelos maiores e diferentes layouts de paralelismo. Elas também precisam preservar seus ganhos depois que toda a sobrecarga do framework entrar na medição.

Três sinais decidirão se a receita se transfere

Os próximos três sinais são o treinamento NVFP4 fundido, a replicação independente das recompensas e a remoção da cópia extra de pesos em BF16.

Primeiro, acompanhe a integração pendente do TransformerEngine para escalonamento NVFP4 fundido por token. Miles já usa escalonamento fundido no caminho de rollout do FlashInfer, mas seu caminho de treinamento medido executa uma operação separada. A integração deverá revelar se o NVFP4 pode melhorar o tempo de treinamento, além do tempo de rollout.

Um resultado de ponta a ponta mais rápido fortaleceria o argumento a favor do formato. Uma desaceleração contínua no treinamento restringiria seu apelo a cargas de trabalho intensivas em rollout. Qualquer um dos resultados esclarecerá onde a computação em quatro bits produz valor prático.

Segundo, acompanhe reproduções independentes em modelos e tarefas diferentes. Os testes de maior valor incluiriam programação, raciocínio de contexto longo, uso de ferramentas e RL assíncrono. Múltiplas seeds ajudariam a separar o comportamento do formato da variância normal de recompensa.

Curvas de recompensa semelhantes nessas cargas de trabalho sustentariam a tese de consistência de Miles. Divergências em camadas ou tarefas específicas, por outro lado, identificariam onde as exceções BF16 precisam se expandir. Qualquer resultado seria mais útil do que uma única regra universal de precisão.

Terceiro, acompanhe se o Megatron consegue remover a cópia extra de pesos em BF16 enquanto oferece suporte ao layout de pesos da receita. Essa mudança exporia o benefício de memória atualmente oculto por requisitos de compatibilidade. Ela também testaria se a política de baixa precisão pode se tornar a principal representação armazenada do sistema.

O trabalho Miles Blackwell cruzou uma importante fronteira de engenharia. MXFP8 e NVFP4 por token agora participam de um único loop de RL conectado, em vez de aparecerem apenas em testes isolados de inferência ou treinamento.

A pergunta mais precisa já não é se o Blackwell consegue executar operações de quatro e oito bits. É se as equipes conseguem preservar uma única política em todos os sistemas que manipulam esses valores. Acompanhe as integrações, reproduções e mudanças de memória antes de tratar as curvas do Qwen3 como um resultado geral.