English · Español

01 — MoE (Mixture of Experts)¶

🇪🇸 MoE separa "cuántos parámetros tiene el modelo" de "cuánto cómputo usa cada token". El modelo tiene $E$ "expertos" (capas FFN paralelas); un router asigna cada token a $k$ de ellos. Los parámetros crecen con $E$; los FLOPs por token crecen con $k$. Ese desacoplamiento es la idea entera.

El transformer denso tiene un problema de escalado conocido: aumentar la capacidad del modelo requiere aumentar el conteo de parámetros, y el conteo de parámetros marca tanto el coste de entrenamiento (cada parámetro ve gradientes en cada paso) como el cómputo de inferencia (cada parámetro se multiplica con activaciones en cada forward).

Mixture of Experts desacopla esas dos cosas. Añade $E$ bloques FFN paralelos ("experts") por capa; para cada token, lo routea solo a $k$ de ellos (típicamente $k = 1$ o $k = 2$). El conteo de parámetros crece ∝ $E$; los FLOPs por token crecen ∝ $k$. Si $E \gg k$, obtienes un modelo disperso que tiene la capacidad de $E$ FFNs pero el cómputo de $k$ FFNs.

Las matemáticas¶

Conteo de parámetros¶

Una FFN densa: $|W_{\text{dense}}| = 2 \cdot d_{\text{model}} \cdot d_{\text{ff}}$.

Una capa MoE con $E$ experts: $|W_{\text{moe}}| = E \cdot |W_{\text{dense}}| + |W_{\text{gate}}|$, donde el gate es un lineal $d_{\text{model}} \to E$, aportando $d_{\text{model}} \cdot E$ parámetros (poco).

Para $d_{\text{model}} = 4096, d_{\text{ff}} = 16384$, la FFN densa tiene 134M parámetros. MoE con $E = 8$ son ~1B parámetros por capa — el mismo cómputo por token que la FFN densa, 8× la capacidad.

Routing¶

Para la activación de entrada de un token $x \in \mathbb{R}^{d_{\text{model}}}$:

\[\text{gate}(x) = \mathrm{softmax}(W_g x) \in \mathbb{R}^E\]

Coge los índices top-$k$ y renormaliza sobre ellos. Salida del token:

\[\text{MoE}(x) = \sum_{i \in \text{top}_k(\text{gate}(x))} \text{gate}(x)_i \cdot \text{Expert}_i(x)\]

Para $k = 2$: dos forwards de expert, suma ponderada.

Pérdida de balanceo de carga¶

Sin intervención, el router colapsa: unos pocos experts "populares" se llevan la mayoría de los tokens; muchos experts son peso muerto. La cura es una pérdida auxiliar que empuja la distribución del routing hacia uniforme.

Sea $f_i = $ fracción de tokens del batch routeados al expert $i$, $p_i = $ probabilidad media del gate para el expert $i$ a lo largo del batch. La pérdida del Switch Transformer:

\[\mathcal{L}_{\text{aux}} = E \cdot \sum_i f_i \cdot p_i\]

Cuando el routing es uniforme, $f_i = p_i = 1/E$, y $\mathcal{L}_{\text{aux}} = E \cdot E \cdot (1/E)^2 = 1$. (El factor de $E$ mantiene la pérdida invariante a la escala.) Cuando el routing está desbalanceado — digamos que todos los tokens van al expert 0 — $f_0 = 1, p_0 = 1$, todos los demás cero, así que $\mathcal{L}_{\text{aux}} = E$. La pérdida sube $E$× bajo colapso, proporcionando un gradiente fuerte de vuelta hacia los pesos del gate.

Pérdida total: $\mathcal{L}_{\text{total}} = \mathcal{L}_{\text{language}} + \alpha \cdot \mathcal{L}_{\text{aux}}$, con $\alpha \approx 0.01$.

Capacidad de expert y dropping¶

Si exactamente $k$ tokens van a cada expert en un batch balanceado de $N$ tokens con routing-$k$: cada expert ve $N \cdot k / E$ tokens. Pero la asignación de tokens es difícil — el lenguaje natural tiene distribuciones sesgadas. Para acotar la memoria por expert, las implementaciones de MoE fijan un capacity factor $C$: cada expert acepta como mucho $C \cdot N \cdot k / E$ tokens, descartando el resto (salida cero para los tokens descartados, lo que el stream residual cubre).

Capacity factor $C = 1.0$: ajustado, muchos drops. $C = 1.25$: típico. $C = 2.0$: holgado, hambriento de memoria.

Variantes¶

Switch Transformer (Google). Routing top-1 ($k=1$). Un expert por token. Máxima dispersión.
Mixtral (Mistral). Routing top-2, 8 experts. La arquitectura "8 × 7B".
DeepSeek-V2 MoE. Routing top-6 de 64 experts de grano fino + 2 experts compartidos (siempre activos). Routing más expresivo.
Soft MoE (DeepMind). Routing continuo — cada expert ve una combinación de tokens ponderada por el gate. Diferenciable, sin top-k discreto, sin pérdida auxiliar. Más cómputo, optimización más suave.

La elección del router y la capacidad es un área de investigación activa. La receta Switch + capacity-factor + load-balance es la baseline estándar.

Paralelismo de experts¶

A escala de entrenamiento, MoE requiere una estrategia de paralelismo especializada. Los experts se colocan en distintos workers; los tokens se routean vía comunicación all-to-all: cada worker envía sus tokens al worker que tiene el expert elegido. El expert computa; los resultados vuelven en all-to-all.

Coste de comunicación por token por capa: 2 all-to-alls de $d_{\text{model}}$ bytes por token.

Para nuestro microscópico tutor de gramática: no hace falta paralelismo de experts (todo en una CPU). Las primitivas all-to-all son vocabulario de la Fase 35; aquí solo reconocemos que el serving de MoE a escala es una topología distinta.

Modos de fallo¶

Colapso del router. La mayoría de los tokens van a unos pocos experts. Curado por la aux loss, pero la cura es imperfecta — un desbalance leve crónico es normal.
Token dropping con capacity factor bajo. Algunos tokens reciben contribución cero de la capa MoE. El stream residual lo cubre, pero la calidad sufre en casos de cola larga.
Inestabilidad de entrenamiento. Las curvas de pérdida de MoE tienen spikes más afilados que las densas. La aux loss ayuda; a veces hace falta weight decay agresivo o LR baja.
La especialización de experts no siempre es lingüística. Los estudios muestran que los experts MoE a menudo se especializan en rasgos sintácticos / de tokenización más que en semánticos — p. ej., un expert por tipo de token. Curioso pero no sorprendente; los experts se entrenan desde cero sin sesgo inductivo hacia categorías semánticas.

¿Ayudaría MoE al tutor de gramática?¶

Apliquemos el test de theory/00-motivation.md:

Cuello de botella de MoE: "capacidad creciendo más rápido que el cómputo". Queremos más capacidad de modelo sin pagar más FLOPs por token.
¿El tutor de gramática lo tiene? No. El tutor tiene ~500k parámetros y entrena en segundos en CPU. La capacidad no es el cuello de botella — el corpus es tan pequeño que la capacidad ya se desborda (lo verás en las curvas de sobreajuste (overfitting) de la Fase 19).
¿Qué costaría MoE? Código nuevo: ~150 LOC para routing + load-balance loss. Nuevos modos de fallo: colapso del router, tokens descartados. Nuevo tuning: $E, k, C, \alpha$.
Veredicto: Nunca.

El lab 00 (lab/00-moe-on-grammar-tutor.md) sí corre un MoE de 2 experts como ejercicio didáctico, no porque ayude. El hallazgo honesto será: misma perplejidad que el denso, más parámetros, más inestabilidad de entrenamiento. Leer ese resultado y nombrar por qué es el propósito entero.

Cuándo ayudaría MoE (el contrafáctico)¶

Si el tutor de gramática fuera una versión de 5 idiomas (inglés + español + francés + alemán + italiano) y el corpus fuera 100× más grande:

Cada idioma tiene sus propios patrones de conjugación. El router podría aprender a especializar un expert por familia lingüística.
La capacidad se convierte en un cuello de botella — los modelos densos chocan con un techo de calidad.
Entonces MoE se gana su sitio.

Ese contrafáctico es la hipótesis del futuro, no el alcance actual. Que la Fase 36 lo señale explícitamente es honesto. No extender el currículum para encajar con la técnica; deja que la técnica se quede archivada hasta que el alcance la pida.

Lo que esta fase NO cubre¶

Entrenar un MoE real. Conceptualmente factible en experiments/36-moe-on-grammar-tutor/, pero es un stub. El MoE de 2 experts sobre el tutor de gramática es para ver el routing dispararse, no para entrenamiento de producción.
Implementación de paralelismo de experts. Solo vocabulario de la Fase 35; aquí solo lo reconocemos.
MoE continuo (Soft). Concepto mencionado; no derivado con profundidad matemática.
MoE en servidores de inferencia (p. ej., Mixtral en vLLM). Conceptual; las Fases 33+34 ya enseñaron las piezas de serving.
Herramientas de análisis de routing (qué token fue a qué expert). Mencionado en el lab 00 como extra opcional.

Siguiente: theory/02-mla.md.