En un Transformer estándar, cada token pasa por la misma red feedforward (FFN) en cada capa. En un Transformer MoE, esa FFN única se reemplaza con múltiples FFNs paralelas — los “expertos” — más una pequeña red de enrutamiento (a menudo llamada gate) que decide qué expertos procesan cada token. Típicamente, el gate selecciona los top-k expertos (usualmente 2) y mezcla sus salidas usando los pesos softmax del gate. La idea clave es que el conteo total de parámetros puede ser masivo (dando al modelo enorme capacidad para memorizar y generalizar), mientras que el cómputo por token se mantiene manejable porque la mayoría de los expertos están inactivos para cualquier entrada dada. Mixtral 8x7B, por ejemplo, tiene aproximadamente 47B parámetros totales pero activa solo unos 13B por token.
El mecanismo de enrutamiento es donde vive la mayor parte de la complejidad de ingeniería. Un router ingenuo podría enviar todos los tokens a los mismos pocos expertos, dejando otros sin usar — un problema llamado colapso de expertos. Para prevenir esto, los modelos MoE usan pérdidas auxiliares de balanceo de carga que penalizan la utilización desigual de expertos durante el entrenamiento. El Switch Transformer original de Google usaba enrutamiento top-1 (un experto por token) y logró un escalamiento impresionante, pero la mayoría de los modelos MoE modernos prefieren enrutamiento top-2 por estabilidad. Algunos enfoques más nuevos como DeepSeekMoE añaden expertos compartidos que siempre se activan junto con los enrutados, asegurando un nivel base de procesamiento para cada token independientemente de las decisiones de enrutamiento.
El trade-off que define el despliegue de MoE es memoria versus cómputo. Aunque solo una fracción de los expertos están activos por token, todos deben estar cargados en memoria. Un modelo MoE 8x7B necesita aproximadamente la misma memoria que un modelo denso de 47B, aunque funciona aproximadamente a la velocidad de un modelo denso de 13B. Esto hace que los modelos MoE sean incómodos para hardware de consumidor — si solo puedes caber 13B parámetros en la VRAM de tu GPU, obtendrías la misma velocidad de inferencia de un modelo denso de 13B sin el overhead de MoE. MoE realmente brilla cuando tienes suficiente memoria para mantener el modelo completo y quieres máxima calidad por FLOP. Por eso es una opción natural para servicio en la nube: proveedores como OpenAI y Mistral pueden aprovisionar suficiente memoria en sus clústeres, y el costo de cómputo por solicitud es lo que impulsa sus márgenes.
El paralelismo de expertos es un patrón de despliegue específico de MoE. En una configuración multi-GPU, puedes colocar diferentes expertos en diferentes GPUs para que cada dispositivo solo mantenga y compute un subconjunto de expertos. Los tokens se enrutan a través de GPUs según qué expertos necesitan, se procesan y los resultados se recopilan de vuelta. Esto introduce overhead de comunicación all-to-all pero permite que modelos demasiado grandes para un solo dispositivo funcionen eficientemente. Los papers de GShard y Switch Transformer de Google demostraron esto a escala, y así es como se sirven en producción hoy los modelos MoE más grandes.
Un matiz con el que los practicantes se encuentran: los modelos MoE pueden comportarse de manera impredecible durante el fine-tuning. Si haces fine-tuning en un dominio estrecho, el router podría empezar a canalizar todos los tokens a un pequeño subconjunto de expertos, desperdiciando efectivamente la capacidad del resto. Algunos equipos congelan el router durante el fine-tuning; otros añaden regularización extra. La cuantización es otra trampa — los expertos que se activan raramente tienen menos muestras de calibración, por lo que la cuantización post-entrenamiento ingenua puede degradarlos desproporcionadamente. El campo está trabajando activamente en estos desafíos operativos, pero MoE es claramente la dirección en la que van las cosas. Grok, DBRX, Mixtral y casi seguramente GPT-4 todos lo usan, y el argumento de eficiencia solo se fortalece a medida que los tamaños de modelo crecen.