🤖 machine learning

Compute-Optimal Is Not Cluster-Optimal: Systems-Aware Scaling for Sparse Mixture-of-Experts

Este artículo presenta MOSAIC, un marco de codiseño consciente del sistema que demuestra cómo la escasez óptima para los modelos de Mezcla de Expertos dispersos surge únicamente al optimizar conjuntamente la arquitectura del modelo con las restricciones del hardware, en lugar de hacerlo solo mediante las tradicionales leyes de escala de computación óptima.

Autores originales: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Publicado 2026-08-12

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás tratando de construir el cerebro robótico definitivo y más poderoso. En el mundo de la inteligencia artificial, este "cerebro" es un programa informático masivo llamado Modelo de Lenguaje de Gran Escala (LLM, por sus siglas en inglés). Para hacer estos cerebros más inteligentes, los científicos han descubierto una regla simple: si les proporcionas más datos y los haces más grandes, mejoran su comprensión del mundo. Esta regla se llama "ley de escalamiento". Durante mucho tiempo, la receta para construir estos cerebros se dividió en dos pasos separados. Primero, un matemático calculaba el tamaño perfecto para el cerebro basándose en la cantidad de potencia informática (llamada "cómputo") disponible. Luego, un ingeniero diferente intentaba comprimir ese cerebro en un conjunto específico de chips informáticos para hacerlo funcionar lo más rápido posible.

Piensa en esto como planificar un viaje por carretera. El primer paso es decidir qué tan lejos quieres conducir basándote en tu presupuesto de gasolina. El segundo paso es elegir el coche. Pero, ¿qué pasa si el coche que elegiste es tan pesado y tosco que consume gasolina a un ritmo terrible, lo que significa que no puedes conducir tan lejos como planeaste? Ese es el problema que aborda este artículo. Argumenta que no puedes simplemente elegir un tamaño de cerebro y luego preocuparte por el coche. Tienes que diseñar el cerebro y el coche juntos, porque la forma del cerebro cambia la eficiencia con la que conduce el coche. Si ignoras el motor del coche, podrías terminar con un cerebro "perfecto" que es demasiado pesado para moverse, dejándote estancado en la línea de salida.

El Problema: El Cerebro "Perfecto" Que No Cabrá

El artículo introduce una nueva forma de pensar llamada MOSAIC (Optimización de Modelos mediante Entrenamiento Co-diseñado Consciente del Sistema). Los autores, trabajando en Amazon AGI Foundations, notaron que la forma antigua de hacer las cosas estaba dejando dinero sobre la mesa. Tradicionalmente, los investigadores calculaban el modelo "Computacionalmente Óptimo". Este es el tamaño de modelo que obtiene los mejores resultados para una cantidad fija de potencia informática, asumiendo que cada bit de potencia se utiliza perfectamente.

Sin embargo, los autores encontraron una trampa oculta. Se centraron en un tipo especial de arquitectura de IA llamada Mezcla de Expertos (MoE). Imagina una biblioteca gigante donde, en lugar de un bibliotecario gigante leyendo cada libro, tienes miles de expertos diminutos y especializados. Cuando llega una pregunta, un enrutador inteligente la envía a solo unos pocos de estos expertos (por ejemplo, 2 de 100) para que la respondan. Esto hace que el modelo sea muy rápido y eficiente porque no tiene que despertar a toda la biblioteca para cada pregunta.

La matemática antigua sugería que, para obtener los mejores resultados, deberías hacer la biblioteca lo más grande posible y despertar a la menor cantidad de expertos posible. En otras palabras, el "modelo perfecto" debería ser increíblemente disperso (mayormente vacío). El artículo muestra que si solo miras la matemática pura de "¿cuántos cálculos necesitamos?", la respuesta es siempre: "Hazlo lo más disperso que puedas". La matemática dice que la mejor dispersión está en el extremo mismo de lo que es posible.

El Giro: El Motor del Coche Importa

Aquí es donde la historia cambia. Los autores se dieron cuenta de que, aunque la matemática dice "hazlo súper disperso", la realidad física de los chips informáticos dice "de ninguna manera".

Cuando tienes un modelo con miles de expertos diminutos, la computadora tiene que hacer mucho trabajo extra solo para decidir qué expertos despertar y para pasar la información entre ellos. Es como tener un edificio de oficinas gigante donde el gerente pasa todo el día corriendo entre cubículos para entregar memorandos, dejando muy poco tiempo para el trabajo real. Cuanto más disperso es el modelo, más tiempo pierde la computadora en estas tareas de "correr de un lado a otro" (costos de comunicación) y menos tiempo dedica al pensamiento real (cálculos).

El artículo argumenta que la antigua matemática de "Computacionalmente Óptimo" era defectuosa porque asumía que la computadora podía dedicar el 100% de su potencia al pensamiento. En la realidad, un modelo súper disperso podría recibir solo el 8% de la potencia de la computadora para el pensamiento real, mientras que un modelo ligeramente más denso podría recibir un 15%.

La Solución: MOSAIC

Para solucionar esto, el equipo construyó MOSAIC. En lugar de preguntar, "¿Cuál es el mejor modelo para una cantidad fija de matemáticas?", preguntaron: "¿Cuál es el mejor modelo que realmente podemos ejecutar en nuestro clúster específico de computadoras en una cantidad fija de tiempo?".

Combinaron dos cosas:

Una Ley de Escalamiento: Una predicción de qué tan inteligente será el modelo basándose en su tamaño y forma.
Un Modelo de Rendimiento: Un simulador que predice qué tan rápido se ejecutará realmente el modelo en el hardware real, teniendo en cuenta los costos de "correr de un lado a otro".

Cuando ejecutaron MOSAIC, los resultados fueron sorprendentes. El "modelo perfecto" no fue aquel que estaba en el extremo de la dispersión. En cambio, el mejor modelo fue una solución de interior —un punto medio feliz. Era lo suficientemente disperso para ser eficiente, pero no tanto como para que la computadora se estancara por la carga de gestionar todos esos expertos diminutos.

Lo Que Encontraron

El equipo probó esto en hardware real utilizando GPUs NVIDIA B200. Entrenaron modelos que variaban desde 700 millones hasta 18 mil millones de parámetros activos (y hasta 79 mil millones de parámetros totales).

La Forma Antigua: Si simplemente seguías la matemática antigua, elegirías un modelo con una dispersión de aproximadamente 0.985 (lo que significa que el 98.5% de los expertos están dormidos). Pero en su clúster específico, este modelo sería tan lento que tardaría una eternidad en entrenarse, y de hecho terminaría siendo menos inteligente que un modelo ligeramente más denso.
La Forma MOSAIC: El sistema encontró que el punto ideal era una dispersión de alrededor de 0.96. Este modelo no era el "teórico" mejor, pero era el mejor práctico. Funcionaba más rápido, usaba la potencia de la computadora de manera más eficiente y lograba una tasa de error más baja (es decir, era más inteligente) que el "teórico" mejor.

De hecho, demostraron que el modelo que parecía mejor en el papel (el que tenía más "Model FLOPs") era en realidad el más lento de entrenar en la vida real. El modelo que ganó fue el que equilibró la matemática con la realidad del hardware.

Por Qué Esto Importa

Este artículo sugiere que debemos dejar de tratar el diseño de los modelos de IA y el diseño de las computadoras que los ejecutan como pasos separados. No puedes simplemente elegir un tamaño de modelo y esperar que las computadoras puedan manejarlo. La forma del modelo cambia cómo se comporta la computadora.

Los autores son cuidadosos al notar que sus hallazgos son específicos para el tipo de chips informáticos que usaron (NVIDIA B200) y el software específico que construyeron. No encontraron una ley universal que se aplique a cada computadora en el universo. Sin embargo, demostraron que para la frontera del entrenamiento de IA, ignorar los "sistemas" (el hardware y cómo mueve los datos) conduce a resultados subóptimos.

Al usar MOSAIC, demostraron que el "mejor" modelo no es un punto fijo en un gráfico, sino un objetivo móvil que depende de tu presupuesto de hardware específico. El modelo más eficiente es el que se ajusta a tu clúster como un guante, no el que se ve mejor en un pedazo de papel. Esto es un cambio de "Computacionalmente Óptimo" (lo que dice la matemática) a "Clúster-Óptimo" (lo que el hardware puede entregar realmente).

En resumen, si quieres construir la IA más inteligente posible, no solo necesitas un cerebro más grande; necesitas un cerebro que encaje en el cuerpo en el que vive.

Resumen Técnico: Óptimo de Cómputo no es Óptimo de Clúster

Planteamiento del Problema
Los flujos de trabajo convencionales de preentrenamiento a gran escala separan habitualmente las decisiones de escalado algorítmico de la implementación de sistemas. Una etapa de "ley de escalado" selecciona una arquitectura de modelo y un presupuesto de datos para minimizar la pérdida bajo una restricción fija de cómputo (FLOPs), seguida de una etapa de "sistemas" desconectada que optimiza la implementación para la eficiencia del hardware. Los autores argumentan que esta separación es defectuosa para los modelos de Mezcla de Expertos (MoE) dispersos. Mientras que las leyes de escalado tradicionales optimizan para los FLOPs del Modelo ( $C_{model}$ ), ignoran la eficiencia de sistemas de la arquitectura prescrita. Dos arquitecturas con idéntica pérdida predicha y $C_{model}$ pueden generar tasas de transferencia (throughput) de entrenamiento muy distintas debido a variaciones en la Utilización de FLOPs del Modelo (MFU), costos de comunicación y huellas de memoria. En consecuencia, la configuración "óptima de cómputo" derivada de un presupuesto de FLOPs puede ser inviable o subóptima en un clúster de hardware específico, ya que no tiene en cuenta el cómputo "entregable" que un clúster puede sostener realmente durante una ventana de entrenamiento fija.

Metodología: MOSAIC
Los autores presentan MOSAIC (Optimización de Modelos mediante Co-diseño Sensible al Sistema), un marco que formula el co-diseño de arquitectura de modelo y sistemas como un único problema de optimización. MOSAIC selecciona conjuntamente la arquitectura del modelo, el presupuesto de tokens de entrenamiento y el esquema de ejecución distribuida (estrategia de paralelismo) para minimizar la pérdida predicha bajo un presupuesto restringido por hardware.

El marco integra tres componentes principales:

Una Ley de Escalado Conjunta de Cuatro Dimensiones: Los autores ajustan una nueva ley de escalado para modelos MoE dispersos que incluye el número total de parámetros ( $N_{tot}$ ), los tokens de entrenamiento ( $D$ ), la dispersión ( $S$ ) y un factor de división de expertos ( $G$ ). $G$ se define como la relación entre el ancho de la red feed-forward densa y el ancho de un solo experto ( $G = d_{ff}/d_{expert}$ ), capturando la granularidad de los expertos. La ley se formula como:
$L(N_{tot}, S, D, G) = \frac{a}{N_{tot}^\alpha} + \frac{b}{D^\beta} + \frac{c}{(1-S)^\lambda} + \frac{j}{(1-S)^\delta N_{tot}^\gamma G^\eta} + e$
Esta formulación permite predecir la pérdida basándose en elecciones geométricas discretas en lugar de conteos de parámetros abstractos.
Un Modelo de Rendimiento a Nivel de Operador: Para estimar la eficiencia de los sistemas, los autores desarrollaron un modelo analítico de rendimiento que predice el MFU y la huella de memoria para una arquitectura y un esquema de paralelismo dados. Este modelo tiene en cuenta:
- Costos de cómputo (GEMMs densos y agrupados, atención).
- Sobrecargas de comunicación (all-to-all para paralelismo de expertos, burbujas de pipeline, colectivos de paralelismo de datos).
- Latencia de despacho de CPU (crítica para micro-lotes pequeños).
- Factores de calibración específicos de hardware para rezagos (stragglers) entre nodos y solapamiento intra-nodo.
  El modelo es validado contra ejecuciones de entrenamiento de hasta 18 mil millones de parámetros activos, logrando un error porcentual absoluto medio (MAPE) inferior al 15% en la predicción de MFU.
Optimización Conjunta (MINLP): MOSAIC resuelve un programa no lineal de enteros mixtos (MINLP) que minimiza la pérdida predicha sujeto a la restricción de que los Model FLOPs requeridos ( $C_{model}$ ) no excedan los Model FLOPs Entregables ( $C_{deliverable}$ ).
$C_{deliverable} = C_{peak} \times \text{MFU}(Z, P_\ell, B) \times \eta_{good}$
Aquí, $C_{peak}$ es el techo bruto del hardware, y MFU depende de la arquitectura. La optimización busca en una cuadrícula discreta de geometrías realizables ( $Z$ ) y planes de ejecución ( $P_\ell$ ) para encontrar la configuración que minimiza la pérdida dentro de las capacidades reales del clúster.

Contribuciones Clave

Reformulación del Presupuesto de Cómputo: El artículo demuestra que para los modelos MoE dispersos, la optimización bajo un presupuesto fijo de $C_{model}$ conduce a un comportamiento de "búsqueda de frontera" donde la dispersión óptima se sitúa en el límite superior del soporte de datos (es decir, el modelo más disperso posible). Esto se debe a que la ley de escalado predice una pérdida menor para modelos más dispersos a FLOPs fijos, ignorando el costo del sistema.
Co-diseño Sensible al Sistema: Al acoplar la ley de escalado con un modelo de rendimiento, MOSAIC desplaza el presupuesto de $C_{model}$ a $C_{deliverable}$ . Esto revela que la dispersión óptima es un punto interior determinado por las restricciones específicas del clúster (memoria, ancho de banda, sobrecargas de paralelismo), en lugar de la frontera.
Validación del Modelo de Rendimiento: Los autores proporcionan un modelo de rendimiento validado a nivel de operador que predice con precisión el MFU e identifica el esquema de paralelismo óptimo (Paralelismo de Tensor, de Experto, de Pipeline, de Datos) para MoEs dispersos, mostrando que el "mejor" esquema depende altamente de la geometría específica y el tamaño del clúster.
Validación Empírica: El marco fue probado en nodos AWS p6 (GPUs NVIDIA B200) con ejecuciones de hasta 250B de parámetros totales. Los resultados confirmaron que la configuración basada en el ranking de Model FLOPs difiere significativamente del ranking basado en la eficiencia de cómputo de hardware (tiempo de reloj real).

Resultados

Óptimos de Frontera vs. Óptimos de Interior: Bajo un $C_{model}$ fijo, la pérdida ajustada disminuye monótonamente con el aumento de la dispersión, empujando el óptimo hacia la frontera ( $S_{max}$ ). Sin embargo, bajo un presupuesto de hardware fijo ( $C_{deliverable}$ ), la curva de pérdida exhibe un mínimo interior. Los costos de sistema (comunicación, memoria) de los modelos extremadamente dispersos eventualmente superan sus beneficios teóricos de pérdida.
Compromiso entre Pérdida y Rendimiento (Throughput): En experimentos con un presupuesto de 32 nodos y 20 días, la configuración que realizó la mayor cantidad de Model FLOPs (una geometría de expertos más densa y gruesa) no logró la pérdida más baja. Por el contrario, la configuración óptima de pérdida (una geometría de expertos más dispersa y fina) mantuvo un MFU más bajo pero logró una pérdida final menor porque fue la única configuración que encajó dentro de la restricción de los FLOPs entregables mientras mantenía una trayectoria de pérdida favorable.
Validación en el Mundo Real: Ejecuciones de preentrenamiento por etapas en clústeres de 8 nodos validaron el marco. El orden de MFU medido coincidió con el orden predicho. Además, al graficar la pérdida contra el "cómputo de hardware pico equivalente" (considerando el MFU), el ranking de las configuraciones se invirtió en comparación con el ranking contra los Model FLOPs brutos, confirmando que el modelo "óptimo de cómputo" no es el "óptimo de clúster".

Significancia
El artículo aboga por un cambio fundamental en la forma en que se entrenan los modelos de lenguaje de frontera: pasar de etapas desconectadas de "selección de ley de escalado" y "ajuste de sistemas" a un co-diseño de arquitectura-sistema unificado. Los autores afirman que confiar únicamente en presupuestos de Model FLOPs es insuficiente para los modelos MoE dispersos porque no logra valorar la eficiencia de sistemas de la arquitectura. Al introducir MOSAIC, demuestran que la geometría óptima del modelo no es una constante universal, sino que es contingente al clúster de hardware específico, la ventana de entrenamiento y las restricciones de paralelismo. Este enfoque asegura que la arquitectura seleccionada no solo sea teóricamente óptima en términos de pérdida, sino también práctica y eficientemente viable en el hardware objetivo.

Más como este