Mixture-of-Experts (MoE) explicado: por qué los LLM “gigantes” pueden ser más baratos de lo que parecen

INTELIGENCIA ARTIFICIAL · ARQUITECTURA LLM · EFICIENCIA

Si te interesa decidir qué arquitectura usar en un producto real (RAG, fine-tuning, agentes, MoE…), te va a encajar esta guía: RAG vs fine-tuning vs agentes: mapa de decisión para elegir arquitectura. Aquí vamos a bajar MoE a tierra con ejemplos y con los “peros” que importan.

1. El malentendido típico: “parámetros” no es lo mismo que “coste por token”

Cuando oyes “un modelo de 1T parámetros”, tu cabeza hace una regla de tres: más grande = más caro. Y en modelos densos suele ser verdad: cada token pasa por las mismas capas y activa (casi) todos los pesos relevantes de cada capa.

En MoE, en cambio, puedes tener muchos parámetros “dormidos” en cada paso. Están ahí, disponibles, pero solo se encienden algunos expertos. Resultado: el modelo parece enorme por número total de parámetros, pero el coste de cómputo por token se parece al de un modelo mucho más pequeño (dependiendo de cuántos expertos actives).

Piensa en un hospital: tener 200 especialistas en plantilla no significa que, cada vez que entras con dolor de garganta, te atiendan 200 a la vez. Te atiende el especialista adecuado (y quizá un segundo para confirmar). El resto está disponible para otros casos.

2. Qué es MoE en un Transformer: cambiar el “FFN” por un panel de especialistas

En un Transformer clásico, cada bloque tiene dos grandes piezas: self-attention y una red feed-forward (FFN). En MoE, normalmente no tocas la atención: lo que haces es reemplazar la FFN por un conjunto de FFNs más pequeñas llamadas expertos.

¿Quién decide qué experto procesa cada token? Un router (también llamado gate). Ese router mira la representación del token y asigna el token al experto “más prometedor” (Top-1) o a los dos mejores (Top-2), según la variante.

Ese dibujo resume el corazón de Switch Transformers: en vez de una FFN densa, tienes un “Switching FFN layer” con varios expertos. Cada token es ruteado a uno (o dos) expertos y vuelve al flujo normal del Transformer.

3. Routing y sparsity: el truco para escalar sin multiplicar FLOPs

Aquí va la idea en una frase: creces en “capacidad” (parámetros), pero mantienes “cómputo activo” (FLOPs) casi constante.

Imagina que en una capa tienes 8 expertos y eliges Top-1. En términos simplificados:

Total de parámetros de expertos ≈ 8× (tamaño de un experto)
Parámetros activados por token ≈ 1× (tamaño de un experto)

O sea: la “biblioteca” crece, pero solo sacas 1 libro por consulta. Ese es el motivo por el que MoE permite “modelos gigantes” que, por coste por token, pueden comportarse como modelos bastante más modestos.

Ese esquema es útil para entender lo que de verdad pasa: el router produce puntuaciones por experto (normaliza) y decide a dónde va cada token. Parece sencillo… hasta que lo pones a correr en cientos o miles de GPUs.

4. Switch Transformers: por qué simplificar a Top-1 fue tan importante

Antes de Switch Transformers, muchas recetas MoE usaban Top-2 (cada token va a dos expertos). Eso ayuda a calidad y estabilidad en algunos casos, pero incrementa el coste: más cómputo y, sobre todo, más comunicación entre dispositivos.

Switch Transformers populariza una idea que suena casi “demasiado simple”: Top-1 routing (un experto por token). ¿Por qué importa?

• Menos coste de router: decidir 1 experto es más barato que combinar varios.
• Menos tráfico: si un token va a un sitio, hay menos “all-to-all” entre GPUs.
• Más fácil de escalar: menos piezas delicadas que se rompen cuando crece el cluster.

En la práctica, Switch no elimina la complejidad: la mueve. A cambio de Top-1, te obliga a tomarte en serio el equilibrio de carga (si no, un experto se satura y otros se quedan mirando).

5. El “lado B”: capacidad de expertos, balanceo y por qué los tokens se pierden (si no tienes cuidado)

En un mundo ideal, el router repartiría tokens de forma uniforme. En el mundo real, el router tiende a enamorarse de algunos expertos (“este experto va genial”) y deja otros infrautilizados. Eso genera dos problemas:

1) Cuello de botella: un experto recibe demasiados tokens y se convierte en el punto lento.
2) Infrautilización: estás pagando memoria y complejidad por expertos que casi no trabajan.

Por eso aparece el concepto de capacidad (cuántos tokens puede procesar un experto en un paso). Si un experto se llena, los tokens “sobrantes” se dropearán o se saltarán el MoE (dependiendo de implementación). Y aquí viene la parte importante: dropear tokens puede afectar calidad.

Para evitarlo, se usan técnicas como:

• Auxiliary load-balancing loss: una pérdida adicional que “empuja” al router a repartir mejor.
• Capacity factor: un margen extra de capacidad para absorber picos de demanda.
• Ruido / aleatoriedad controlada: para que el router explore y no colapse en 2 expertos.

Si te suena a “esto es una logística de almacén”, es porque lo es: MoE no es solo arquitectura de red, también es gestión de colas a escala GPU.

6. Por qué MoE acelera el entrenamiento: no es magia, es distribución + menos trabajo por token

Hay dos razones por las que MoE puede acelerar (y abaratar) el preentrenamiento:

(A) Sparsity computacional: activas solo 1–2 expertos, así que haces menos multiplicaciones por token que si tuvieses una FFN gigantesca densa.
(B) Expert parallelism: colocas expertos en diferentes dispositivos y repartes tokens hacia donde viven esos expertos.

Ese gráfico es la clave para entender por qué MoE “escala” bien: puedes tener expertos repartidos y mantener el resto del modelo replicado. Esto encaja especialmente con escenarios de entrenamiento masivo, donde el objetivo es exprimir throughput del cluster.

Y ojo: cuando hablamos de “barato” en LLM, muchas veces estamos hablando de energía + tiempo de GPU. Ahí MoE tiene sentido en un mundo donde el cuello de botella es infraestructura. Si te interesa esa capa física (coste real, consumo, centros de datos), aquí tienes un buen complemento: IA y consumo eléctrico en datacenters.

7. Los trade-offs (los de verdad): memoria, comunicación y “fine-tuning caprichoso”

Hasta ahora suena a chollo: más capacidad, menos coste. Pero MoE te pasa factura en varios sitios. Los más importantes:

Memoria: tienes que tener los expertos “a mano”

Aunque actives pocos expertos por token, en serving real normalmente necesitas cargar muchos pesos para poder responder a cualquier token. Eso significa VRAM alta. En modelos MoE modernos, el coste de memoria puede parecerse al de un modelo denso enorme, aunque el cómputo por token sea menor.

Comunicación: el all-to-all puede comerse tus ganancias

Cuando tokens viajan a expertos en otros dispositivos, aparece un enemigo silencioso: la red. Si el all-to-all es lento, la GPU se queda esperando. Por eso, muchas optimizaciones en MoE no son “mejor modelo”, sino “mejor ingeniería de sistema”: kernels eficientes, planificación de comunicación y topologías que reducen latencia.

Routing inestable: si el router colapsa, tu MoE se vuelve un “mono-experto”

Si el router manda casi todo a 1–2 expertos, pierdes el sentido del MoE: entrenas (y sirves) algo menos robusto, con calidad desigual. Por eso existen pérdidas auxiliares y trucos de estabilización.

Fine-tuning: a veces no transfiere como esperas

Una de las críticas históricas a MoE es que puede generalizar peor al fine-tuning en tareas pequeñas o con datos limitados (dependiendo del setup). En cristiano: el modelo aprende especialistas muy buenos para el pretraining, pero luego “se pone raro” cuando lo adaptas a un caso específico si no ajustas bien hiperparámetros, regularización y balanceo.

8. ¿Cuándo tiene sentido MoE y cuándo es mejor un modelo denso (o pequeño)?

MoE brilla cuando:

• Tienes infraestructura (muchas GPUs / buen interconect) y buscas throughput masivo.
• Quieres más capacidad sin multiplicar FLOPs por token de manera proporcional.
• Tu distribución de tareas es diversa (texto, código, razonamiento, estilo…), donde especializar puede ayudar.

Un modelo denso (o incluso varios modelos pequeños) suele ganar cuando:

• Sirves en hardware limitado y la VRAM es el cuello de botella.
• Necesitas simplicidad (operaciones, latencia predecible, menos piezas que pueden fallar).
• Tu producto está muy acotado y un modelo pequeño bien adaptado te da mejor coste total.

De hecho, el debate “más grande vs más pequeño y eficiente” es cada vez más práctico. Si te interesa esa línea (on-device, eficiencia, especialización), te recomiendo esta lectura: Small Language Models: el futuro de la IA en el móvil.

9. Checklist rápido: si estás evaluando MoE, mira esto antes de enamorarte

Para cerrar, una lista corta (pero muy realista) de preguntas que te ahorran dolores de cabeza:

• ¿Tu cuello es FLOPs o memoria? MoE suele bajar FLOPs por token, pero no “regala” VRAM.
• ¿Tu red aguanta all-to-all? Si no, puedes perder las ventajas en latencia/throughput.
• ¿Top-1 o Top-2? Top-1 simplifica y escala; Top-2 puede ayudar a calidad, pero encarece.
• ¿Cómo vas a balancear? Sin pérdidas auxiliares y capacidad bien elegida, el router colapsa.
• ¿Cómo vas a adaptar? Planifica fine-tuning (o instruction-tuning) con hiperparámetros específicos para MoE.