Miles Blackwell RL Cambia la Uniformidad BF16 por MXFP8 y NVFP4 Nativos

La compatibilidad con Miles Blackwell ahora incluye dos recetas nativas de aprendizaje por refuerzo de baja precisión, probadas en seis configuraciones sobre ocho GPU NVIDIA B200. Una emplea MXFP8 durante el rollout y el entrenamiento. La otra aplica NVFP4 por token a los pesos de mezcla de expertos, manteniendo mayor precisión en el resto.

El resultado cuestiona una suposición habitual sobre el aprendizaje por refuerzo, o RL. Una menor precisión no exige necesariamente aceptar una curva de aprendizaje visiblemente más débil. En la ablación de Qwen3-30B-A3B de Miles, las cinco configuraciones de baja precisión siguieron de cerca las recompensas brutas de referencia de BF16.

Este hallazgo incluye una salvedad importante. El experimento fue una ablación controlada de recetas, no un benchmark de entrenamiento totalmente ajustado ni una garantía general de precisión. Miles también mantuvo BF16 en las capas sensibles, conservó una copia adicional de los pesos en BF16 y observó picos ocasionales de gradientes con NVFP4.

Por tanto, la verdadera competencia no es simplemente cuatro bits contra dieciséis bits. Es un contrato de precisión selectivo y coherente frente a un pipeline BF16 uniforme. Miles sostiene que los formatos nativos de Blackwell resultan útiles cuando el entrenamiento, el muestreo, la conversión y las actualizaciones de pesos en vivo cuantizan los mismos tensores de la misma forma.

La Compatibilidad de Miles Blackwell Ahora Abarca Todo el Ciclo de RL

Miles ha llevado MXFP8 y NVFP4 más allá de kernels aislados al conectarlos en toda la ruta completa de aprendizaje por refuerzo.

El equipo de Miles publicó las recetas el 29 de julio de 2026. Sus resultados de baja precisión abarcan la conversión de checkpoints, el entrenamiento con Megatron, el rollout con SGLang y la exportación de pesos en vivo. La implementación también depende de componentes aportados por TransformerEngine, FlashInfer, el frontend de cuDNN y proyectos relacionados.

La primera receta utiliza MXFP8 en toda la ruta computacional principal. MXFP8 es un formato de microescalado de ocho bits en el que cada bloque de 32 valores E4M3 comparte una escala E8M0. El rollout, la propagación hacia delante, las multiplicaciones de matrices de gradientes de pesos y las multiplicaciones de gradientes de datos pueden utilizarlo.

Esta cobertura amplia importa porque un sistema de RL contiene dos políticas estrechamente vinculadas. La política de entrenamiento calcula actualizaciones, mientras que la política de rollout genera las respuestas utilizadas para calcular recompensas. Si cuantizan los pesos de forma distinta, dejan de representar exactamente el mismo modelo.

Miles ya admitía un diseño FP8 de estilo DeepSeek-V3 basado en bloques de escalado más grandes. Esa vía sigue siendo relevante, especialmente en hardware Hopper. Sin embargo, aplica el escalado mediante software alrededor de la ruta de Tensor Core, en lugar de utilizar el hardware nativo de microescalado de Blackwell.

La segunda receta adopta un enfoque más selectivo. Aplica NVFP4 a los pesos y activaciones de expertos enrutados dentro de las capas de mezcla de expertos, o MoE. NVFP4 almacena valores E2M1 en cuatro bits, con una escala E4M3 para cada bloque de 16 valores.

Una segunda escala FP32 cubre un ámbito mayor. Miles calcula esa escala por separado para cada token, en lugar de compartir una entre un tensor o un lote. Este detalle busca evitar que la representación de un token cambie con la composición del lote.

El resto del modelo NVFP4 permanece en BF16, salvo que las reglas de configuración seleccionen otro formato. Este diseño concentra el cálculo de cuatro bits allí donde los modelos MoE almacenan gran parte de sus datos de pesos. También evita forzar la atención y otros componentes sensibles a la representación más limitada disponible.

NVIDIA describe el escalado NVFP4 como un sistema de dos niveles diseñado para los Tensor Cores de Blackwell. Los bloques de 16 valores proporcionan una adaptación local más precisa que los formatos que usan grupos de 32 valores. La escala FP32 a nivel de tensor amplía el rango utilizable.

Miles cambió el ámbito de la escala mayor de por tensor a por token. Esta decisión distingue su receta de RL de un despliegue de inferencia convencional. También demuestra por qué añadir un tipo de datos FP4 no basta para crear un sistema de RL estable.

Ambas recetas admiten modos backward de alta precisión y de dequantización. El backward de alta precisión utiliza los operandos BF16 originales para las multiplicaciones de matrices backward. El backward dequantizado, en cambio, reconstruye operandos BF16 a partir de los valores exactos de baja precisión utilizados durante el paso forward.

La segunda opción sacrifica cierto detalle numérico, pero preserva una mayor concordancia con la política forward. Ninguno de los modos NVFP4 ejecuta sus multiplicaciones de matrices backward en FP4. Por tanto, Miles está probando baja precisión selectiva, no afirmando disponer de un ciclo de entrenamiento universalmente de cuatro bits.

Las Curvas de Recompensa Desplazan la Carga de la Prueba

El resultado más destacable no es el rendimiento máximo de Tensor Core, sino la ausencia de una penalización evidente en las recompensas de la carga de trabajo evaluada.

Miles evaluó Qwen3-30B-A3B con RL síncrono de estilo GRPO sobre el conjunto de datos dapo-math-17k. El sistema utilizó ocho GPU B200, divididas por igual entre rollout y entrenamiento. Cada prompt recibió ocho muestras de rollout, con respuestas limitadas a 8.192 tokens.

El estudio comparó una referencia BF16 con cinco configuraciones de baja precisión. Estas incluían MXFP8 de extremo a extremo y dos modos backward para cada formato de baja precisión. Las variantes NVFP4 limitaron la operación de cuatro bits a la ruta de expertos MoE.

Las cinco curvas de recompensas brutas de baja precisión siguieron de cerca la curva BF16. Esto no establece equivalencia entre tareas, semillas o ejecuciones de entrenamiento más largas. Sí sugiere que el rollout de menor precisión no anuló la señal de aprendizaje en este experimento concreto.

Ese es un umbral significativo para RL. El entrenamiento supervisado puede promediar señales de optimización en un conjunto de datos grande y relativamente estable. RL suele trabajar con recompensas más ruidosas y actualizaciones de política menores, lo que dificulta separar el error adicional de cuantización del aprendizaje genuino.

Miles también informó de que MXFP8 y NVFP4 redujeron el tiempo de rollout frente a BF16. El artículo publicado presenta la comparación de forma gráfica, pero no ofrece un único porcentaje adecuado para un titular universal. La dirección del resultado es más clara que su portabilidad.

La mejora en rollout importa porque la generación suele dominar las cargas de trabajo de aprendizaje por refuerzo. Una política debe producir respuestas completas antes de que puedan calcularse las recompensas y actualizaciones. Los contextos largos y las múltiples muestras encarecen especialmente esta etapa.

MXFP8 también mejoró el tiempo de entrenamiento frente a BF16 en la configuración medida. El lado de entrenamiento de NVFP4 se movió en la dirección opuesta. Ambas variantes NVFP4 con override backward fueron más lentas que BF16 durante el entrenamiento, pese a un rollout más rápido.

Miles atribuye esa brecha a su integración actual, no a los Tensor Cores FP4 de Blackwell. La ruta medida de TransformerEngine ejecuta el escalado FP32 por token como una operación PyTorch separada. Existen kernels fusionados del frontend de cuDNN, pero su integración con TransformerEngine sigue pendiente.

Este resultado dividido mantiene el análisis con los pies en la tierra. NVFP4 no es automáticamente más rápido simplemente porque sus valores sean más pequeños. La fusión de kernels, los diseños de datos, las operaciones de escalado y los límites entre frameworks determinan si el rendimiento teórico llega a la aplicación completa.

Las configuraciones de baja precisión también mostraron una mayor discrepancia entre entrenamiento y rollout que BF16. NVFP4 comenzó con una medición de KL de referencia más alta, que compara distribuciones de políticas. Sin embargo, Miles calculó ese diagnóstico frente a un modelo de referencia BF16 de Megatron.

Por tanto, la métrica incorpora la diferencia de formato desde el inicio. Su coeficiente se fijó en cero, de modo que no actuó como penalización de optimización. Miles advierte contra interpretar la medición como una señal independiente de fracaso del aprendizaje.

Las curvas de recompensa generan una inversión útil. La discrepancia de precisión aumentó, pero las recompensas observadas no se separaron materialmente de BF16 durante la ablación. Esta combinación respalda pruebas adicionales, a la vez que deja abierta la cuestión de la estabilidad a largo plazo.

Un Cuantizador Compartido Es el Mecanismo Real

Miles trata el RL de baja precisión como un problema de coherencia distribuida, no simplemente como una petición de números más pequeños.

Cada parte de la pila de RL puede cuantizar tensores de forma independiente. Megatron gestiona el entrenamiento, mientras que SGLang y FlashInfer manejan las operaciones de rollout. La conversión de checkpoints y las actualizaciones de pesos en vivo introducen dos oportunidades más para que los valores o diseños diverjan.

Incluso pequeñas diferencias pueden acumularse a lo largo de actualizaciones repetidas de la política. Un worker de entrenamiento puede optimizar una representación cuantizada mientras los workers de rollout muestrean de otra. Las recompensas describen entonces el comportamiento de una política que el optimizador nunca ve exactamente.

Miles aborda este problema mediante un contrato de cuantizador bit a bit exacto. Las pruebas de FlashInfer comparan su salida byte por byte con una referencia de estilo TransformerEngine. Las entradas de prueba incluyen valores aleatorios, casos límite, tensores cero y valores máximos representables.

El equipo también desactiva una opción de matemáticas rápidas de FlashInfer para la ruta de cuantización FP4 pertinente. Las matemáticas aproximadas pueden ser razonables para el serving convencional, donde las pequeñas diferencias no retroalimentan los pesos futuros. RL convierte esas diferencias en parte del ciclo de aprendizaje.

MXFP8 plantea otro problema de diseño. Los Tensor Cores de Blackwell esperan que los bloques de microescalado sigan la dimensión de reducción de la matriz. Las operaciones forward y backward pueden usar orientaciones distintas, por lo que una copia cuantizada no siempre puede servir correctamente a ambas rutas.

La documentación de MXFP8 explica que TransformerEngine crea copias por filas y por columnas a partir de la entrada original de alta precisión. Esto consume más memoria, pero evita dequantizar y requantizar una copia existente de baja precisión.

Miles acepta ese coste de memoria en su ruta MXFP8 completa. Sus alternativas backward de alta precisión y dequantizada evitan retener la segunda copia cuantizada. La decisión se convierte en un equilibrio entre concordancia numérica, uso de memoria, trabajo de dequantización y velocidad de multiplicación de matrices.

NVFP4 introduce un problema de coherencia diferente. Compartir una escala de activación entre varios tokens hace que el valor cuantizado de un token dependa de sus vecinos. Los cambios en la planificación del rollout, la longitud de secuencia o el empaquetado de lotes pueden alterar entonces la representación de la política.

Miles calcula una escala de activación FP32 por token en línea. FlashInfer fusiona este cálculo en el kernel de cuantización de activaciones de rollout. La misma operación emite activaciones FP4 empaquetadas, escalas de bloque y escalas de token.

El entrenamiento y el rollout también deben utilizar particiones tensor-paralelas de expertos coincidentes. De lo contrario, cada sistema ve partes distintas del tensor al calcular la escala por token. Fórmulas idénticas no pueden producir políticas idénticas a partir de entradas diferentes.

Las capas de expertos SwiGLU añaden otro caso especial. Sus proyecciones gate y up suelen entrar en una multiplicación de matrices fusionada, aunque los checkpoints pueden almacenarlas por separado. Miles cuantiza cada par gate-and-up conjuntamente para que ambos reciban una escala mayor coherente.

Estos detalles de implementación explican por qué el trabajo de Miles Blackwell se extiende por varios repositorios. Ninguna biblioteca única controla cada representación entre un checkpoint guardado y un rollout generado. El contrato de precisión debe sobrevivir a cada transferencia.

Este trabajo de sistemas también distingue la receta de la cuantización posterior al entrenamiento. Un checkpoint estático de inferencia puede calibrarse una vez y servirse repetidamente. El aprendizaje por refuerzo cambia los pesos de manera continua, por lo que cada exportación en vivo crea de facto un nuevo evento de cuantización.

Los equipos que evalúen sistemas similares necesitarán evidencia trazable de esos eventos. Una base de conocimientos de ingeniería interna puede conectar configuraciones, versiones del kernel, curvas de evaluación y notas de incidentes. Ese registro cobra importancia cuando aparece una regresión numérica varias actualizaciones después.

NVFP4 por token cuestiona el valor predeterminado uniforme de BF16

El enfoque de Miles Blackwell obliga a los equipos a justificar el uso de BF16 en todas partes, sin dejar de tratar el BF16 selectivo como una herramienta de estabilidad.

BF16 sigue siendo la base de referencia más sencilla. Ofrece un rango numérico más amplio, menos requisitos de cuantización y comparaciones más fáciles entre el entrenamiento y el despliegue. Su debilidad es que cada peso y activación de experto consume más ancho de banda de memoria del que requieren los formatos más estrechos.

Los modelos MoE hacen más visible esta disyuntiva. Contienen muchos parámetros de expertos, aunque cada token activa solo un subconjunto. Mover los pesos de los expertos a través de la memoria durante el despliegue puede llegar a ser más restrictivo que la capacidad aritmética bruta.

Por ello, Miles se centra primero en la ruta de los expertos. La estrategia se parece más a un presupuesto financiero que a un compromiso ideológico con el entrenamiento de cuatro bits. Asigna precisión a los tensores con mayor probabilidad de influir en la estabilidad y comprime las estructuras repetidas más grandes.

El experimento mantuvo el 15 por ciento final de las capas del modelo en BF16 para cada configuración de baja precisión. Miles afirma que esta decisión redujo la discrepancia entre entrenamiento e inferencia y mejoró la estabilidad de los gradientes. Mantener las capas iniciales en BF16 no aportó una reducción igual de significativa.

Los expertos compartidos también se mantuvieron en mayor precisión. A diferencia de los expertos enrutados, procesan cada token. Por tanto, sus errores de cuantización se propagarían por cada bloque MoE, en lugar de limitarse a las rutas seleccionadas.

Ciertas proyecciones de atención latente multicausal también recibieron excepciones en BF16. Sus ejes de contracción pueden cambiar según el modo de ejecución, mientras que MXFP8 utiliza bloques de escalado unidimensionales. Un eje modificado puede reagrupar valores bajo escalas diferentes.

Estas excepciones son fundamentales para la receta, no una corrección incidental. Un titular que describiera un modelo completamente FP4 tergiversaría el trabajo. En su lugar, Miles desarrolló controles granulares que preservan cada excepción durante la conversión, el entrenamiento, el despliegue y las actualizaciones en producción.

Esto presiona a las canalizaciones convencionales de BF16 de dos maneras. En primer lugar, la ablación de recompensas sugiere que las rutas de despliegue más estrechas merecen evaluarse en Blackwell. En segundo lugar, el sistema de configuración ofrece una alternativa a elegir un único formato para cada capa.

También cuestiona los enfoques previos de FP8 diseñados en torno a Hopper. DeepSeek-V3 utiliza bloques de 128 por 128 para los pesos y mosaicos de 1 por 128 para las activaciones. Miles describe ese diseño como eficaz, pero no puede utilizar el hardware de microescalado de Blackwell de la misma manera nativa.

La comparación no vuelve obsoleto el método anterior. Los clústeres Hopper siguen estando ampliamente desplegados, y FP8 con escalado por bloques cuenta con un historial operativo más extenso. Los formatos nativos de Blackwell también crean límites de compatibilidad para los equipos que dan soporte a generaciones mixtas de GPU.

La guía de TransformerEngine de NVIDIA ahora admite FP8, MXFP8 y NVFP4 mediante bloques de construcción optimizados. Sin embargo, el soporte del framework por sí solo no determina qué capas deben usar cada formato. La arquitectura del modelo y la forma de la carga de trabajo siguen rigiendo esa decisión.

Los beneficiarios más directos son las organizaciones que ejecutan grandes trabajos de aprendizaje por refuerzo MoE en Blackwell. Pueden probar un despliegue más rápido sin trasladar de inmediato cada operación hacia atrás a baja precisión. Esa ruta escalonada reduce el coste de recopilar evidencia.

Los equipos más pequeños se enfrentan a un cálculo distinto. Reproducir la configuración requiere ocho GPU B200, varias bibliotecas coordinadas y una cuidadosa paridad de configuración. La carga de ingeniería puede superar los ahorros de despliegue a escala moderada.

Por tanto, la principal línea competitiva es la consistencia selectiva frente a la simplicidad uniforme. Miles ofrece mayor control y una vía hacia un menor tráfico de memoria. BF16 ofrece menos interfaces por las que una discrepancia inadvertida puede entrar en el proceso de aprendizaje.

Lo que la ablación de Qwen3 no establece

El experimento publicado respalda una receta prometedora, pero no establece una paridad amplia de calidad ni una eficiencia completa de cuatro bits.

La limitación más inmediata es el alcance. Miles probó un modelo, un conjunto de datos orientado a matemáticas, una disposición de hardware y una configuración principal de carga de trabajo. Seguir de cerca las recompensas en ese contexto no permite predecir el comportamiento en programación, uso de herramientas, diálogo o tareas multiagente.

La configuración fija utilizó RL síncrono y una división de cuatro GPU para cada una de las fases de despliegue y entrenamiento. Los sistemas asíncronos pueden introducir un mayor retraso de política entre la generación de datos y la optimización. Ese retraso podría interactuar de forma distinta con la discrepancia de cuantización.

La gráfica de recompensas publicada también cubre una ablación de receta, en lugar de una ejecución de entrenamiento completamente ajustada. Miles lo describe explícitamente de esa forma. Los lectores no deberían interpretar la gráfica como una victoria de referencia frente a sistemas BF16 optimizados.

La recompensa bruta puede ocultar cambios de comportamiento. Dos políticas pueden alcanzar puntuaciones similares mientras utilizan patrones de razonamiento, longitudes de respuesta o modos de fallo diferentes. Una validación más sólida incluiría evaluaciones retenidas, múltiples semillas aleatorias y análisis de errores específicos por tarea.

Los picos ocasionales de gradiente de NVFP4 siguen siendo otra preocupación. La variante de retropropagación en alta precisión mostró picos durante la ejecución reportada. La retropropagación desquantizada redujo los ejemplos más grandes, pero no los eliminó.

Esto es coherente con preocupaciones más amplias sobre el entrenamiento de cuatro bits. La investigación sobre valores atípicos de NVFP4 ha detectado sensibilidad persistente en componentes arquitectónicos específicos. Ese trabajo se refiere al preentrenamiento, no a la receta de RL de Miles, pero refuerza la necesidad de supervisión a nivel de capa.

La actual historia de memoria también es incompleta. Megatron todavía conserva una copia adicional de los pesos en BF16, pese a ejecutar el entrenamiento y el despliegue mediante recetas de baja precisión. Esa copia limita la cantidad de memoria del modelo que el sistema recupera realmente.

La recopilación de parámetros de baja precisión nativa de Blackwell aún está madurando. Miles señala que la ruta correspondiente de recopilación de parámetros NVFP4 todavía no admite su disposición de pesos unidimensional de 1 por 16. Eliminar la copia BF16 depende en parte de esta infraestructura.

El rendimiento de entrenamiento con NVFP4 presenta una segunda área pendiente. El despliegue mejoró, pero el entrenamiento se volvió más lento en la implementación probada. La integración pendiente de TransformerEngine fusionado debe cerrar esa brecha antes de que NVFP4 pueda afirmar una ventaja integral más clara.

El movimiento de pesos en producción también sigue siendo complicado. Los backends de servicio suelen rellenar, reordenar o aplicar swizzling a los pesos en disposiciones optimizadas para kernels concretos. Los sistemas de entrenamiento normalmente mantienen una representación canónica de tensores diferente.

Esas transformaciones pueden dificultar las actualizaciones de baja latencia o el acceso remoto directo a memoria. Cada disposición específica del backend añade otro paso que debe seguir siendo verificable. Un kernel rápido aporta un valor limitado si cada actualización de política activa un reempaquetado costoso.

La especificidad del hardware crea un riesgo comercial. MXFP8 y NVFP4 reciben aceleración nativa en Blackwell, pero muchas organizaciones aún operan hardware Hopper. Adoptar las nuevas recetas puede dividir el soporte de infraestructura entre múltiples rutas de precisión.

Tampoco hay una replicación independiente en la evidencia publicada. Los resultados proceden del equipo que diseñó e implementó las recetas. Esto es adecuado para un informe inicial de ingeniería, pero las reproducciones de terceros reforzarían la confianza.

Ninguna de estas limitaciones elimina el resultado observado. Definen lo que significa el resultado. Miles ha demostrado que una baja precisión cuidadosamente controlada puede seguir las recompensas de BF16 en una configuración exigente mientras reduce el tiempo de despliegue.

El siguiente estándar es más difícil. Las recetas deben mantenerse estables en ejecuciones más largas, tareas variadas, actualizaciones asíncronas, modelos más grandes y distintas disposiciones de paralelismo. También deben conservar sus beneficios después de que toda la sobrecarga del framework entre en la medición.

Tres señales decidirán si la receta se generaliza

Las tres próximas señales son el entrenamiento NVFP4 fusionado, la replicación independiente de recompensas y la eliminación de la copia adicional de pesos BF16.

En primer lugar, observe la integración pendiente de TransformerEngine para el escalado NVFP4 fusionado por token. Miles ya utiliza escalado fusionado en la ruta de despliegue de FlashInfer, pero su ruta de entrenamiento medida realiza una operación independiente. La integración debería revelar si NVFP4 puede mejorar el tiempo de entrenamiento además del tiempo de despliegue.

Un resultado integral más rápido reforzaría el argumento a favor del formato. Una desaceleración continua del entrenamiento limitaría su atractivo a las cargas de trabajo con gran peso de despliegue. Cualquiera de los dos resultados aclararía dónde la computación de cuatro bits produce valor práctico.

En segundo lugar, busque reproducciones independientes en distintos modelos y tareas. Las pruebas de mayor valor incluirían programación, razonamiento de contexto largo, uso de herramientas y RL asíncrono. Múltiples semillas ayudarían a separar el comportamiento del formato de la variación habitual de las recompensas.

Curvas de recompensa similares en esas cargas de trabajo respaldarían la tesis de consistencia de Miles. La divergencia en capas o tareas concretas identificaría, en cambio, dónde deben ampliarse las excepciones de BF16. Cualquiera de los dos resultados sería más útil que una única regla universal de precisión.

En tercer lugar, observe si Megatron puede eliminar la copia adicional de pesos BF16 mientras admite la disposición de pesos de la receta. Ese cambio expondría el beneficio de memoria actualmente oculto por los requisitos de compatibilidad. También pondría a prueba si la política de baja precisión puede convertirse en la representación principal almacenada del sistema.

El trabajo Miles Blackwell ha cruzado una frontera de ingeniería importante. MXFP8 y NVFP4 por token ahora participan en un bucle de RL conectado, en lugar de aparecer solo en pruebas aisladas de inferencia o entrenamiento.

La pregunta más precisa ya no es si Blackwell puede ejecutar operaciones de cuatro y ocho bits. Es si los equipos pueden preservar una política única en cada sistema que manipula esos valores. Siga las integraciones, las reproducciones y los cambios de memoria antes de considerar las curvas de Qwen3 como un resultado general.