SkyRL movió once puntos la puntuación AIME de Mistral Large 4 en ocho nodos: lo que demuestra el RL desde el día cero en un MoE de 1T

Mistral Large 4 se anunció como vista previa de API el 6 de octubre de 2026, y sus pesos solo pasaron a estar disponibles para descarga a las 14:51 UTC del 29 de octubre — lo que hace que el informe de aprendizaje por refuerzo publicado ese mismo día sea notable por un motivo en el que sus autores no se detienen: antes de esa tarde, nadie fuera de Mistral tenía un resultado de ajuste fino que publicar. La nota proviene del equipo SkyRL de NovaSky. Ocho nodos NVIDIA GB200, aprendizaje por refuerzo con LoRA sobre el checkpoint NVFP4, vLLM sirviendo los rollouts, y el average@8 de AIME 2024 subiendo de alrededor del 64% a alrededor del 75% a lo largo de 75 pasos de entrenamiento. Once puntos en un benchmark que normalmente se decide en décimas es o el resultado de día cero más útil del trimestre o el menos reproducible, y la nota tal como está escrita no te dice cuál de los dos.

Lo que sí te dice es real, y vale la pena separarlo de lo que no te dice. Se indica el hardware. Se indica el checkpoint. Se indica el motor de rollout. El framework de entrenamiento se indica como uno de dos. Lo que falta es la función de recompensa, el rango del adaptador, el arnés de evaluación y cualquier curva de aprendizaje — las cuatro cosas que otro equipo necesitaría para intentar la misma ejecución. Así que esto es el anuncio de una receta con una cifra destacada adjunta, no un paquete de reproducción. Léelo como lo primero y es genuinamente informativo sobre cuánto cuesta postentrenar a finales de 2026 una mezcla de expertos de un billón de parámetros. Léelo como lo segundo y sobrevalorarás un benchmark sobre una sola tarea.

Lo que realmente dice la nota de SkyRL

Toda la afirmación cabe en cinco líneas, así que aquí está sin el encuadre:

• Hardware — 8 nodos NVIDIA GB200, alquilados en lugar de propios, lo que, con cuatro GPU por nodo, equivale a 32 unidades Blackwell y aproximadamente 6,1 TB de HBM agregada a 192 GB por GPU.

• Checkpoint: el hermano cuantizado en NVFP4 de la versión abierta, 610,1 GB repartidos en 32 fragmentos, y no el padre FP8 de 1.060,6 GB. Esa elección es la fundamental: es lo que hace que un modelo de 1T quepa en ocho nodos con espacio libre para activaciones, caché KV y dos copias de los pesos del motor de rollout.

• Método — LoRA en lugar de RL con todos los parámetros. Solo los adaptadores reciben gradientes, por lo que el estado del optimizador se mantiene pequeño y la base congelada puede permanecer en su forma cuantizada.

• Loop — vLLM genera los rollouts; FSDP2 o Megatron se encarga de la mitad del entrenamiento. La nota ofrece cualquiera de los dos, lo que indica que el backend de entrenamiento todavía se estaba intercambiando cuando se redactó el resultado.

• Resultado — AIME 2024 average@8 de aproximadamente 64% a aproximadamente 75% en 75 pasos de entrenamiento.

Nada en esa lista es una especificación de la ejecución. No hay tamaño de lote, ni longitud de secuencia, ni tasa de aprendizaje, ni tamaño de grupo para el gradiente de política, ni ninguna indicación de cuál fue la recompensa más allá de la implícita «las respuestas de AIME son verificables». La cifra de 75 pasos es precisa; casi todo lo necesario para interpretarla no lo es.

Por qué el recuento de nodos es el titular, no la puntuación de AIME

Un billón de parámetros es una cifra que funciona principalmente como elemento disuasorio. El checkpoint FP8 ocupa 1,06 TB, lo cual está bien si tienes un centro de datos y es un problema si tienes un rack. El checkpoint NVFP4 lo reduce a la mitad, a 610 GB, y 610 GB es una cantidad que puedes distribuir entre ocho nodos sin trucos de sharding que te cuesten más en comunicación de lo que te ahorran en memoria.

Por eso, la frase interesante de la nota no es la que contiene el porcentaje. Hugging Face ya había publicado una receta de ajuste fino supervisado para este modelo —LoRA mediante el entrenador SFT de TRL, en un único nodo de ocho GPUs B300, sobre los pesos FP8—. Por tanto, el SFT en un solo nodo quedó documentado antes de que los pesos tuvieran un día de vida. Lo que no estaba documentado era el aprendizaje por refuerzo, y la razón es estructural: el RL necesita un motor de inferencia ejecutándose junto al entrenador, generando rollouts con la suficiente rapidez para que el tiempo de GPU dedicado al entrenamiento no quede eclipsado por el tiempo de GPU dedicado al muestreo. El SFT lee un conjunto de datos fijo. El RL tiene que producir el suyo propio.

Así que el delta entre las dos recetas publicadas no es de ocho nodos frente a uno. Es de ocho nodos más una pila de servicio frente a un nodo sin pila de servicio, para una tarea en la que el modelo tiene que intentar treinta problemas ocho veces cada uno antes de aprender algo. El motor de rollout es el nuevo centro de costes, y nombrar vLLM como el generador es la parte de la nota sobre la que otros equipos pueden actuar hoy.

La comparación que todo el mundo hará, y por qué es injusta en ambos sentidos

Mistral ejecutó su propio RL sobre este modelo antes de distribuir los pesos, y la empresa ha sido específica sobre cómo es: aproximadamente tres semanas adicionales después de la vista previa del 6 de octubre, ejecutado en cómputo francés que la empresa describe en megavatios en lugar de GPU —alrededor de 10 MW—, y con informes de otros medios que sitúan la infraestructura de RL más amplia a la escala de 3.000 GPU. Los resultados que publicó de esa ejecución:

• Terminal-Bench 4.0 — 28,3 % antes del RL adicional, 41 % después.

• BrowseComp — 75 % antes, 84,5 % después.

• Suite de seguridad de agentes B3 — 93,3 % antes, 97,1 % después.

• Longitud de salida — aproximadamente un 30 % menos de tokens por tarea tras el RL, lo que para un comprador importa más que cualquiera de las filas de precisión.

Poner eso junto a 64–75 en AIME y la tentación es calcular una ratio de horas de GPU por punto. Resístela, porque las dos ejecuciones casi no comparten variables. La mejora de Mistral está en trabajo agéntico en terminal y navegación, medida por un proveedor con el diseño de recompensa interno y tres semanas de reloj. La mejora de SkyRL está en matemáticas de competición, medida por un socio con un clúster alquilado y una recompensa que un script puede verificar. Un avance de 13 puntos en Terminal-Bench y un avance de 11 puntos en AIME no son el mismo logro expresado en unidades distintas; son logros diferentes que casualmente tienen un tamaño similar.

La lectura justa es más limitada y más útil: tres semanas de RL a escala de centro de datos movieron la puntuación de terminal de Mistral en trece puntos, y unas pocas horas de RL con LoRA a escala de ocho nodos movieron la puntuación de matemáticas de un socio en once. Ambas cifras dicen lo mismo — este checkpoint responde con facilidad al aprendizaje por refuerzo — y ninguna dice nada sobre la otra.

Qué demuestra y qué no demuestra 64 a 75 en AIME 2024

Empieza por la aritmética, porque es la única parte de esto que se puede comprobar sin una GPU. AIME 2024 son treinta problemas. Average@8 significa ocho intentos muestreados por problema, así que la cifra reportada se basa en 240 finalizaciones. El error de muestreo en una proporción cercana al 70% con ese tamaño de muestra es de unos pocos puntos porcentuales, lo que sitúa un cambio de once puntos cómodamente fuera del ruido. Si las dos cifras procedieran del mismo arnés, la mejora es real en esa tarea.

Eso es lo más contundente que se puede decir, y vale la pena decirlo claramente porque la mayoría de las afirmaciones de día cero ni siquiera son tan buenas. Ahora, los límites:

• No hay una puntuación AIME publicada por Mistral para este modelo. El 64 % de línea base es la propia medición de SkyRL del checkpoint base con su propio harness, por lo que el delta es internamente consistente pero externamente no está anclado — no puedes verificarlo contra una cifra del proveedor porque no existe ninguna cifra del proveedor.

• Average@8 no es pass@1. Ocho intentos por problema favorecen a cualquier modelo con una distribución de muestreo amplia, y la diferencia entre ambas métricas suele ser de cinco a quince puntos en matemáticas de competición. El número que decide si desplegarías el modelo es el único intento que le das en producción.

• AIME 2024 tiene dos años y medio y es uno de los conjuntos de matemáticas más representados en los datos de posentrenamiento. Que un modelo de 2026 obtenga buenos resultados en él es evidencia de un checkpoint entrenable, no un veredicto sobre el razonamiento. Nada en la nota reporta una evaluación con datos reservados o más reciente.

• Una tarea, una ejecución, una recompensa. El RL sobre matemáticas verificables es el caso más fácil que existe: la recompensa no necesita juez, ni rúbrica, ni humano. El resultado es una afirmación sobre hasta dónde avanza este modelo bajo la señal de RL más barata posible, que es genuinamente el primer experimento correcto y también el menos transferible.

Qué necesitarías para reproducirlo y qué permite la licencia.

La lista práctica de compras, reconstruida a partir de la nota en lugar de publicada por esta:

• El checkpoint NVFP4 — 610 GB, 32 shards, sin restricciones, descargable hoy sin la barrera de una cuenta de Hugging Face.

• Aproximadamente 32 GPU de clase Blackwell en ocho nodos, además de la interconexión necesaria para evitar que la sincronización del adaptador se coma el tiempo de paso.

• Una compilación de vLLM con una ruta NVFP4 funcional para esta arquitectura. La tarjeta del modelo recomienda vLLM con un contenedor oficial y un tamaño de paralelismo tensorial de ocho, y señala una cabeza de decodificación especulativa integrada que el proveedor afirma que ofrece hasta 1,9× el rendimiento; esa cabeza no es lo que necesita un bucle de RL, pero el contenedor sí.

• Un rango de adaptador y una recompensa tendrás que elegir tú mismo, porque la nota no lo especifica.

La cuestión de la licencia se resuelve de forma más clara que la técnica. Mistral lo publicó bajo la Mistral Ecosystem Open-Weight License, un texto MIT modificado que permite el uso comercial, el fine-tuning y los derivados, y exige una licencia comercial separada solo para operar un negocio de modelo como servicio sobre él. El fine-tuning interno, un adaptador privado, una ejecución de evaluación en nodos alquilados: todo eso queda dentro de la autorización. Montar una API por token y vender acceso a tu fine-tune no queda incluido. Si tu plan es el primero, la licencia no es tu problema. Si es el segundo, es todo el problema, y ninguna mejora en AIME lo cambia.

La mitad del bucle que se encarece más adelante

AIME es el caso barato por una razón que vale la pena explicar. La recompensa es una cadena de respuesta que un script compara. No hay juez, ni rúbrica, ni un segundo modelo en el bucle, así que el coste marginal de un rollout es la inferencia y nada más. Traslada la misma receta a tareas agénticas, escritura abierta o cualquier cosa evaluada por preferencia, y la recompensa se convierte en una llamada a un modelo, emitida a escala de rollout, miles de veces por paso, durante toda la ejecución. Ese es un problema de adquisición distinto del cómputo de entrenamiento, y es el que la mayoría de los equipos descubre después de haber reservado las GPU.

Mistral Large 4 en sí no es un modelo que servimos, así que esta pieza no es una vía para llegar a él: autoalojarlo significa recurrir al repositorio de Hugging Face y a la API propia del proveedor. Lo que sí es enrutable es la otra mitad del bucle. Si tu verificador es un modelo juez en lugar de un script, tiene que sobrevivir a ser llamado al volumen de un rollout: un único endpoint sobre más de 200 modelos, el precio de lista del proveedor pasado sin ningún recargo adicional, y failover cuando un único endpoint de juez alcanza su límite de tasa en mitad de un paso de entrenamiento. Los modelos que usarías realmente como jueces aparecen listados, con contexto y precio, en el catálogo de modelos de OrcaRouter. La cuestión no es que el enrutamiento abarate el RL. Es que la señal de recompensa es la parte de una ejecución de RL que no puedes planificar de antemano, así que es la parte que merece la pena poner detrás de una interfaz estable.

Qué ver a continuación

Tres cosas convertirían esto de una nota prometedora en un resultado. Que el equipo de SkyRL publique el rango del adaptador, la definición de la recompensa y una curva de aprendizaje, lo que permitiría a otro grupo intentar la misma ejecución en lugar de admirarla. Una segunda tarea, idealmente una cuya recompensa no sea una comparación de cadenas, que mostraría si el efecto sobrevive al contacto con un juez. Y una evaluación independiente de AIME o de matemáticas más difíciles del checkpoint publicado, porque el piso del 64 % es actualmente la medición del propio socio y la única manera de retirar esa salvedad es que alguien más lo mida.

Hasta entonces, el resumen honesto es breve. Los pesos tienen un día de antigüedad, un socio subió un benchmark de matemáticas once puntos en ocho nodos alquilados con un adaptador LoRA, y nadie lo ha reproducido todavía. Eso es más de lo que ofrecen la mayoría de los lanzamientos de pesos abiertos en su primera semana, y menos de lo que sugiere el titular.