ARQUITECTURA

MoE (Mixture of Experts)

Arquitectura en la que un modelo tiene muchos parámetros totales pero solo activa una pequeña fracción de ellos por cada token, gracias a un router que elige qué expertos consultar.

Nivel · avanzado5 min de lecturaActualizado 24 may 2026
También conocido como: Mixture of Experts, Modelo de expertos, Sparse MoE

Definición

MoE (Mixture of Experts) es una familia de arquitecturas de redes neuronales —hoy aplicada masivamente a transformers— en la que el modelo contiene muchos sub-modelos especializados llamados "expertos", y un mecanismo llamado router decide qué expertos activar para cada token de entrada. La consecuencia clave: el modelo tiene un número enorme de parámetros totales pero usa solo una fracción pequeña en cada paso.

Por ejemplo, Mixtral 8x7B tiene 47.000 millones de parámetros totales pero en cada token solo activa unos 13.000 millones. Su coste de inferencia es similar al de un modelo denso de 13B, pero su calidad se acerca a la de un modelo denso de 70B. DeepSeek-V3 tiene 671B parámetros totales pero activa solo 37B por token. Grok y los rumoreados internals de GPT-5 también son MoE.

El MoE es probablemente la innovación arquitectónica más relevante desde el transformer original. Permite escalar parámetros sin que el coste de inferencia crezca proporcionalmente — el cuello de botella económico del despliegue moderno.

Cómo funciona

En un transformer denso clásico, cada token pasa por todas las capas y todos los parámetros. En un MoE, las capas feed-forward (que son donde está la mayoría de los parámetros) se reemplazan por bloques MoE con esta estructura:

  1. Router (también llamado gate): una pequeña red neuronal recibe el embedding del token y produce probabilidades sobre los N expertos disponibles. Típicamente selecciona los top-k expertos (en MoE moderno, k = 2 o k = 8).
  2. Expertos: N redes feed-forward independientes, cada una con sus propios pesos. Cada experto procesa una versión modificada del token.
  3. Combinación: las salidas de los k expertos seleccionados se suman ponderadas por las probabilidades del router.

Si el modelo tiene 64 expertos y el router elige 2 por token, solo el ~3% de los parámetros del bloque FFN se activan en cada paso. Pero esos 2 expertos pueden ser distintos para cada token, así que durante una secuencia entera el modelo usa todos los expertos — distribuidos.

Ejemplo práctico

Imaginemos un MoE pequeño con 8 expertos, donde el router activa 2 por token. La secuencia "Antonio dirige una empresa industrial en Barcelona":

  • Token "Antonio": el router puede seleccionar expertos 1 y 7 (uno especializado en nombres propios, otro en español).
  • Token "dirige": expertos 3 y 5 (verbos, gestión).
  • Token "Barcelona": expertos 4 y 7 (lugares, español).

Cada token activa solo 2/8 = 25% de los parámetros FFN. El coste computacional baja drásticamente, pero el modelo total contiene mucho más conocimiento del que un modelo denso equivalente cabría.

En la práctica los expertos NO se especializan limpiamente por temas humanos. Se especializan en patrones estadísticos que emergen durante el entrenamiento — a menudo opacos para los investigadores.

Por qué es la arquitectura del momento

Tres razones económicas y técnicas:

  1. Coste de inferencia: el cuello de botella en producción no es entrenar, es servir billones de tokens al día. MoE permite tener modelos enormes corriendo al coste de modelos medianos.
  2. Calidad: a mismo coste de inferencia, MoE supera a modelos densos. La capacidad adicional ayuda incluso si no se activa toda.
  3. Hardware moderno: GPUs y aceleradores actuales tienen memoria masiva (H100: 80GB, H200: 141GB) pero ancho de banda limitado. MoE encaja: muchos pesos en RAM, pocos leídos por token.

Por eso prácticamente todos los modelos top de 2025-2026 son MoE: GPT-5, Claude Opus (rumor), Gemini 2.x, Llama 4, DeepSeek-V3, Mixtral, Grok, Qwen 2.5 MoE.

Desafíos técnicos del MoE

A pesar de las ventajas, MoE introduce complejidades nuevas:

  • Carga desbalanceada: si el router prefiere unos expertos sobre otros, los "infrautilizados" no aprenden bien y los "saturados" se sobre-especializan. Se mitiga con auxiliary losses que premian distribución uniforme.
  • Tamaño en memoria: aunque solo se activan 2 expertos por token, los 64 deben estar cargados. Esto consume RAM, dificultando despliegues edge.
  • Comunicación entre GPUs: en entrenamiento e inferencia distribuidos, enrutar tokens a expertos en GPUs distintas implica comunicación que limita la escalabilidad.
  • Inferencia con batching difícil: si en un batch unos tokens van al experto 3 y otros al 7, gestionar el cómputo eficientemente es complejo.
  • Fine-tuning más sensible: el router puede cambiar comportamiento del modelo de formas inesperadas durante fine-tuning.

Variantes y evolución

  • Sparse MoE clásico (Switch Transformer, GShard): k=1, máxima eficiencia.
  • Top-k MoE (Mixtral): k=2, el sweet spot actual.
  • Shared experts (DeepSeek): algunos expertos siempre activos + algunos seleccionados. Mejora estabilidad.
  • Fine-grained MoE (DeepSeek-V2/V3): muchos expertos pequeños (256+) en lugar de pocos grandes.
  • MoE de atención: la innovación de empezar a aplicar MoE también a las capas de atención, no solo al FFN.
  • Auxiliary-loss-free balancing: técnicas recientes para evitar la auxiliary loss tradicional.

Errores comunes al hablar de MoE

  • "Cada experto sabe de un tema": no es así. La especialización es estadística y opaca.
  • "MoE es más rápido que un modelo denso del mismo tamaño total": solo en términos de cómputo (FLOPs). En memoria y ancho de banda puede ser similar o peor.
  • "MoE escala infinito": no. Hay límites prácticos en hardware, comunicación y estabilidad de entrenamiento.
  • Confundir MoE con ensemble: en ensemble, varios modelos votan. En MoE, los expertos son partes del mismo modelo que cooperan, elegidos por un router aprendido.
  • Pensar que es "trivial" hacerlo bien: entrenar MoE estable requiere ingeniería sofisticada. Mucho del moat de DeepSeek está aquí.

Cuándo importa entender MoE

Sí, conviene profundizar si:

  • Decides qué modelo desplegar y debates coste/calidad.
  • Trabajas en optimización de inferencia o despliegue de modelos grandes.
  • Estás considerando entrenar modelos propios y miras alternativas a densos.
  • Inviertes o trabajas en empresas que entrenan modelos frontera.

Es menos crítico si:

  • Solo consumes APIs y la arquitectura subyacente es opaca para tu caso.
  • Tu trabajo es producto/UX donde basta saber qué hace el modelo.

Referencias

Tagsiaarquitecturaeficienciamodelos