Mixture-of-Experts es la arquitectura que impulsa los LLMs de producción más grandes — y funciona de manera diferente a lo que la mayoría piensa

Cuando OpenAI lanzó GPT-4, la compañía se negó a publicar un recuento de parámetros. Meses después, documentos filtrados y benchmarks que lo corroboraban sugirieron que utiliza una arquitectura Mixture-of-Experts (MoE) con aproximadamente 1,8 billones de parámetros totales distribuidos en ocho subredes expertas — pero solo activa unos 220 mil millones por pasada hacia adelante. Esa sola decisión de diseño explica tanto el techo de capacidad del modelo como su economía de inferencia de maneras que un recuento ingenuo de parámetros jamás podría.

MoE es ahora la arquitectura dominante para los modelos frontera. Gemini 1.5 de Google usa MoE. Los modelos abiertos Mixtral 8x7B y 8x22B de Mistral AI hicieron accesible MoE para quienes alojan sus propios modelos. La investigación interna de Meta sobre MoE para los sucesores de Llama está bien documentada. Entender cómo funciona realmente — y dónde ayuda genuinamente frente a dónde solo hace que las diapositivas se vean bien — importa si estás decidiendo qué modelos desplegar o cómo evaluar nuevos lanzamientos.

La idea central: computación condicional

Un transformer denso estándar como Llama 2 70B activa cada uno de sus 70 mil millones de parámetros por cada token que procesa. Esto es costoso computacionalmente pero predecible. MoE reemplaza las capas feedforward (las capas que componen la mayor parte del recuento de parámetros de un transformer) con múltiples redes "expertas" en paralelo más un router ligero. Por cada token, el router selecciona los top-k expertos — típicamente 2 de 8 o 16 — y solo esos expertos procesan ese token. Los resultados se ponderan y combinan.

La consecuencia práctica: un modelo Mixtral 8x7B tiene ~47 mil millones de parámetros totales, pero cada token solo toca unos 13 mil millones de ellos. Obtienes la mayor parte de la capacidad representacional de un modelo denso de 47B mientras ejecutas inferencia a un costo más cercano a 13B. El throughput se duplica aproximadamente en comparación con un modelo denso equivalente en el mismo hardware, para la misma calidad de salida.

Lo que realmente aprende el router

El router es una pequeña capa lineal que produce una distribución de probabilidad sobre todos los expertos disponibles. Se entrena de extremo a extremo con el resto del modelo usando descenso de gradiente estándar — no hay pre-entrenamiento separado ni etiquetado manual de qué experto debería manejar qué contenido. Lo que emerge es aproximadamente una especialización por dominio: el análisis de los patrones de enrutamiento de Mixtral muestra que los expertos desarrollan preferencias suaves por sintaxis de código, razonamiento en lenguaje natural, recuperación de hechos, etc. Pero esta especialización es imprecisa y no siempre se alinea con las intuiciones humanas sobre la materia.

Un problema de ingeniería persistente es el equilibrio de carga. Sin intervención, el router tiende a colapsar en un pequeño conjunto de expertos "populares" y a privar a otros, desperdiciando capacidad. La solución estándar es una pérdida auxiliar de equilibrio de carga añadida durante el entrenamiento que penaliza la utilización desigual de los expertos. Ajustar la fuerza de esta pérdida es un hiperparámetro que afecta significativamente tanto a la calidad del modelo como a la eficiencia del hardware — demasiado poca, y los expertos colapsan; demasiada, y el router no puede aprender una especialización significativa.

El cuello de botella de memoria que el marketing ignora

Aquí es donde MoE se vuelve complicado para los implementadores. Todos los parámetros deben residir en memoria aunque solo una fracción se active por token. Un modelo Mixtral 8x22B — con ~141 mil millones de parámetros totales — requiere aproximadamente 280 GB de VRAM de GPU en precisión BF16 antes de contabilizar la caché KV. Eso significa al menos cuatro GPUs H100 de 80 GB solo para mantener los pesos, aunque el throughput de inferencia sea similar al de un modelo denso mucho más pequeño.

Esto crea una división de infraestructura. En un centro de datos donde puedes dedicar un nodo de 4 GPUs por réplica del modelo, MoE es genuinamente más barato por token. En un despliegue donde intentas colocar múltiples modelos en hardware compartido, la huella de memoria de MoE lo hace costoso. También es por eso que la cuantización importa más para los modelos MoE: llevar Mixtral 8x7B a precisión de 4 bits (aproximadamente 25 GB) es lo que lo hace práctico para ejecutar en una workstation de consumo única o un servidor con doble GPU.

El paralelismo de expertos como palanca de escalado

Para entrenar modelos MoE muy grandes, una técnica llamada paralelismo de expertos distribuye diferentes expertos entre diferentes GPUs físicas. Cuando un token se enruta al Experto #5, el cálculo ocurre en la GPU que contiene los pesos del Experto #5, y el resultado se envía de vuelta. Esto convierte la comunicación all-reduce en transferencias punto a punto más localizadas y permite entrenar a escalas que de otro modo requerirían demasiada memoria por GPU.

El artículo de Google sobre Switch Transformer de 2021 demostró esto con 1,6 billones de parámetros — el primer modelo de billones de parámetros documentado públicamente. El hallazgo clave: un MoE de 64 expertos con el mismo presupuesto computacional que un modelo denso T5-XXL logró una aceleración de 4x en el tiempo de entrenamiento mientras igualaba o superaba la calidad en benchmarks estándar. El artículo también documentó modos de falla: inestabilidad del entrenamiento con recuentos altos de expertos, el problema de colapso del equilibrio de carga y la sobrecarga de comunicaciones en configuraciones multi-nodo.

Donde MoE realmente rinde por debajo de los modelos densos

El aprendizaje few-shot en tareas altamente específicas de dominio es un área donde los modelos MoE pueden rendir por debajo de modelos densos de tamaño similar. Como el router asigna tokens probabilísticamente y diferentes tokens en el mismo prompt pueden ir a diferentes expertos, la "memoria" del modelo del contexto temprano puede fragmentarse entre los expertos de maneras que perjudican la coherencia en documentos largos y especializados. Informes anecdóticos de despliegues empresariales de Mixtral sugieren que los modelos densos de costo de inferencia equivalente a veces producen mejores resultados en texto legal o médico donde la consistencia exacta de la terminología es importante.

El tamaño del lote también importa. La ventaja de throughput de la arquitectura MoE es más pronunciada en lotes grandes donde todos los expertos obtienen una utilización más o menos uniforme. Con un tamaño de lote de 1 — un solo usuario haciendo una consulta en tiempo real — estás activando dos expertos y esperando ociosos a los otros seis. La latencia por token puede ser peor que la de un modelo denso de recuento de parámetros activados equivalente debido a la sobrecarga de enrutamiento. Por eso los despliegues de producción agrupan solicitudes de manera agresiva y por qué los puntos finales de API streaming tienen perfiles de latencia diferentes a los de los puntos finales de inferencia por lotes.

Decisiones prácticas para equipos que evalúan modelos MoE

Si estás comparando un modelo denso de 70B con un modelo MoE como Mixtral 8x22B para despliegue, la comparación correcta no es el recuento de parámetros — es la huella de memoria frente a la calidad en tu carga de trabajo específica. Ejecuta ambos en tu distribución de tareas real. Mixtral 8x22B superará consistentemente a Llama 2 70B en benchmarks de razonamiento, pero la brecha se reduce significativamente en tareas estrechas de generación aumentada por recuperación (RAG) donde el conjunto de datos es homogéneo.

Para fine-tuning, los modelos MoE presentan un desafío particular: el fine-tuning con LoRA aplicado solo a las capas densas no tocará los pesos de los expertos, que contienen la mayoría del conocimiento especializado del modelo. El fine-tuning completo de modelos MoE consume mucha memoria. Existen variantes de LoRA específicas para MoE que aplican adaptadores a las capas feedforward de los expertos, pero aún no son herramientas estándar — verifica si tu framework de fine-tuning las soporta antes de comprometerte.

Los pesos del router mismos se pueden congelar durante el fine-tuning para preservar los patrones de especialización aprendidos durante el pre-entrenamiento. Esto funciona bien cuando se ajusta para una tarea que está bien representada en la distribución de entrenamiento original. Al adaptarse a un dominio genuinamente nuevo, vale la pena descongelar el router y aceptar la ejecución de fine-tuning más larga.

Lo que viene después

Las direcciones de investigación que se exploran activamente incluyen MoE disperso con más de dos expertos activados por token (intercambiando cómputo por calidad), enrutamiento jerárquico donde un router grueso selecciona "familias" de expertos antes de que un router fino seleccione expertos específicos, y arquitecturas mixture-of-depths que enrutan tokens a diferentes capas en lugar de diferentes expertos dentro de una capa. El artículo de 2024 de Google DeepMind sobre mixture-of-depths mostró que no todos los tokens necesitan pasar por cada capa del transformer, lo que permite mayores ganancias de computación condicional.

La lección arquitectónica de MoE es consistente: las leyes de escalado recompensan la computación condicional. Gastar todo tu cómputo en cada token para cada tarea es derrochador. Los modelos que importarán en los próximos dos años serán cada vez más sistemas híbridos que enruten el trabajo de manera inteligente — ya sea enrutando a expertos dentro de un modelo, enrutando a diferentes modelos mediante orquestación, o enrutando a herramientas externas. MoE es la primera demostración a escala de producción de que este principio funciona a nivel de pesos.