LLM 2026 · Lo que los cursos no cubren · 2

Mixture of Experts: más parámetros sin más cómputo por token

Desde Mixtral (fines de 2023) casi todos los modelos abiertos grandes son MoE: DeepSeek-V3, Llama 4, gpt-oss, Qwen3, Gemma 4 26B. La idea es de 1991 y el truco es uno solo: reemplazar la FFN de cada bloque por varias FFN y dejar que un router elija, por token, cuáles corren. Esta página explica el mecanismo, el problema de balanceo que lo hizo difícil durante años, y la cuenta de memoria y cómputo que decide cuándo conviene.

Antes de leerLLM 2026 · 1 §2, la FFN con compuerta · PyTorch 5 §4, DDP y FSDP

🎯 Al terminar vas a poder

Explicar qué hace el router de una capa MoE, qué significa "top-k de E expertos" y por qué un modelo "671B / 37B activos" cuesta por token lo que un 37B denso.
Decir por qué el balanceo de carga es el problema central de MoE y qué soluciones usaron Switch Transformer (loss auxiliar) y DeepSeek-V3 (sesgo sin loss).
Distinguir expertos gruesos (Mixtral: 8 de 14B), expertos finos (DeepSeek: 256 chicos) y expertos compartidos, y leer "128 expertos, 8 activos + 1 compartido" en una model card.
Calcular la VRAM mínima para servir un MoE y explicar por qué el ahorro de MoE es de cómputo y ancho de banda por token, nunca de memoria.

0. Parámetros totales y parámetros activos

En la página siguiente vas a ver que la calidad de un modelo crece con sus parámetros, pero el cómputo por token de un modelo denso crece igual: cada token pasa por todas las matrices. Un Mixture of Experts rompe esa proporción: tiene muchos parámetros, pero cada token usa una fracción. Por eso las fichas de estos modelos traen dos números:

Modelo	Fecha	Totales	Activos por token	Expertos por capa (activos / totales)
Mixtral 8x7B	dic. 2023	46,7B	12,9B	2 / 8
Mixtral 8x22B	abr. 2024	141B	39B	2 / 8
DeepSeek-V3 (y R1)	dic. 2024	671B	37B	8 / 256, más 1 compartido
Llama 4 Scout	abr. 2025	109B	17B	1 / 16, más 1 compartido
Llama 4 Maverick	abr. 2025	400B	17B	1 / 128, más 1 compartido
Qwen3-235B-A22B	abr. 2025	235B	22B	8 / 128
gpt-oss-120b	ago. 2025	117B	5,1B	4 / 128
Gemma 4 26B A4B	2026	25,2B	3,8B	8 / 128, más 1 compartido

La convención de nombres ya lo dice: "26B A4B" es 26B totales, 4B activos; "235B-A22B", lo mismo. El cómputo por token, y por lo tanto el costo de entrenar por token y la latencia de generar, se rigen por el segundo número. La memoria para tener el modelo cargado, por el primero. Toda la página es la consecuencia de esa asimetría.

1. El mecanismo: router, top-k y suma ponderada

En la página anterior viste que la FFN con compuerta es alrededor de dos tercios de los parámetros de cada bloque. Una capa MoE deja la atención como está y reemplaza esa FFN por E copias independientes (los expertos, cada uno una FFN completa con sus propias matrices) más una capa lineal chica, el router, que decide por token cuáles de las E copias corren:

El router elige por token y solo corren los expertos elegidos; la salida es la suma ponderada con los pesos del softmax renormalizados. Los parámetros son los de todos los expertos; el cómputo, el de los activos. El experto compartido absorbe lo común para que los demás se especialicen.

class CapaMoE(nn.Module):
    def __init__(self, d, d_ff, n_expertos, k):
        super().__init__()
        self.router = nn.Linear(d, n_expertos, bias=False)
        self.expertos = nn.ModuleList([FFNConCompuerta(d, d_ff) for _ in range(n_expertos)])
        self.k = k

    def forward(self, x):                         # x: (tokens, d)
        logits = self.router(x)                       # (tokens, E): un puntaje por experto
        pesos, idx = logits.softmax(-1).topk(self.k)  # los k mejores y su probabilidad
        pesos = pesos / pesos.sum(-1, keepdim=True)   # renormalizar entre los k elegidos
        y = torch.zeros_like(x)
        for e, experto in enumerate(self.expertos):
            filas, cual = (idx == e).nonzero(as_tuple=True)   # qué tokens eligieron a e
            if len(filas):
                y[filas] += pesos[filas, cual, None] * experto(x[filas])
        return y

y=\sum_{i\in\mathrm{top}\text{-}k(p)} g_i\,E_i(x)+E_{\text{comp}}(x),\quad p=\mathrm{softmax}(W_r x),\quad g_i=\frac{p_i}{\sum_{j\in\mathrm{top}\text{-}k}p_j}

Cómo se lee. El router W_r produce una probabilidad por experto; se toman los k mejores, sus probabilidades se renormalizan entre sí (los g_i), y la salida es la suma ponderada de esas k FFN más la compartida, que no pasa por el router. Es el forward de CapaMoE línea por línea.

📐 Formulación matemática del router Top-k y compuerta con ruido

Dado un token $\mathbf{x} \in \mathbb{R}^d$ , el router lineal parametrizado por $\mathbf{W}_r \in \mathbb{R}^{d \times E}$ computa los logits de afinidad. Para evitar que el router colapse prematuramente durante las primeras etapas de entrenamiento, Shazeer et al. (2017) introdujeron una perturbación gaussiana aprendible (Noisy Top-k Gating):

H(\mathbf{x})_i = (\mathbf{x}\mathbf{W}_r)_i + \epsilon \cdot \text{Softplus}\big((\mathbf{x}\mathbf{W}_{\text{noise}})_i\big), \quad \epsilon \sim \mathcal{N}(0, 1)

Se seleccionan los $k$ índices de mayor valor $\mathcal{K} = \text{TopK}(H(\mathbf{x}), k)$ , y se normalizan exclusivamente sus coeficientes mediante softmax sobre el conjunto reducido:

g_i = \frac{\exp(H(\mathbf{x})_i)}{\sum_{j \in \mathcal{K}} \exp(H(\mathbf{x})_j)} \quad \forall i \in \mathcal{K}

La salida combinada del bloque MoE, sumando el experto compartido $E_{\text{comp}}$ , es:

\mathbf{y} = \sum_{i \in \mathcal{K}} g_i E_i(\mathbf{x}) + E_{\text{comp}}(\mathbf{x})

Tres cosas para mirar en ese código. El router es una sola matriz d × E, despreciable en parámetros: para DeepSeek-V3, 7168 × 256. La salida es una suma ponderada de las salidas de los k expertos elegidos, con los pesos del softmax renormalizados; el gradiente fluye a los expertos elegidos y al router por esos pesos, así que el router aprende junto con todo lo demás. Y el loop sobre expertos es la parte que ningún kernel real hace así: en producción los tokens se agrupan por experto y cada experto corre un solo matmul con su lote, porque un experto que recibe 3 tokens y otro que recibe 300 cuestan lo mismo de lanzar.

El "8x7B" de Mixtral engaña un poco: no son ocho modelos de 7B. La atención, los embeddings y las normas están una sola vez (por eso 46,7B y no 56B), y cada capa tiene sus propios 8 expertos con su propio router; un token puede ir al experto 3 en la capa 1 y al 7 en la capa 2. El paper de Mixtral buscó especialización por dominio y encontró poca: los expertos se reparten más por sintaxis y posición que por tema. El nombre "experto" es histórico, no descriptivo.

2. El problema real: que todos los expertos trabajen

Un router recién inicializado elige casi al azar. Los expertos elegidos reciben gradiente y mejoran; el router, que también aprende, tiende a mandarles más tokens porque dan mejor salida; los demás expertos reciben cada vez menos y nunca aprenden. Es un feedback loop, y sin nada que lo frene termina en dos o tres expertos haciendo todo el trabajo: parámetros muertos y, en entrenamiento distribuido, dos GPUs saturadas mientras las demás esperan. Este colapso es la razón por la que MoE existió en papers desde 1991 (Jacobs et al.) y en escala desde 2017 (Shazeer et al.) pero no fue práctico hasta que se resolvió el balanceo.

Loss auxiliar (Switch Transformer, 2021)

Fedus, Zoph y Shazeer simplificaron a top-1 (un experto por token) y agregaron a la loss un término que penaliza la desviación del reparto uniforme: por experto, la fracción de tokens que recibió multiplicada por la probabilidad promedio que el router le asignó, sumado sobre expertos y escalado por E. El mínimo es el reparto parejo. Además fijaron una capacidad por experto (tokens del batch / E, por un factor 1,25): los tokens que exceden la capacidad de su experto se saltan la capa (pasan por el residual solos). Mixtral usa la misma loss con top-2.

Balanceo sin loss (DeepSeek-V3, 2024)

La loss auxiliar tiene un costo: empuja al router hacia un reparto uniforme aunque el reparto óptimo para el lenguaje no lo sea, y el coeficiente es un hiperparámetro delicado. DeepSeek-V3 la reemplaza por un sesgo b por experto que se suma a los logits solo para decidir el top-k (no para calcular los pesos de la suma): después de cada batch, si un experto recibió más tokens que el promedio se le resta un γ a su sesgo; si recibió menos, se le suma. Es un controlador proporcional sobre la carga, fuera del gradiente, y el paper muestra que balancea igual de bien con mejor perplejidad. Queda un término de balanceo por secuencia muy chico, para que una sola secuencia no sature un experto.

📐 Formulación matemática de la Loss Auxiliar y el Enrutamiento Dinámico sin Loss

En Switch Transformer y Mixtral, la loss auxiliar de balanceo de carga sobre un lote de $T$ tokens y $E$ expertos se define formalmente como:

\mathcal{L}_{\text{aux}} = \alpha \cdot E \sum_{i=1}^E f_i \cdot P_i

donde $f_i = \frac{1}{T} \sum_{t=1}^T \mathbb{1}[\text{token } t \text{ elige experto } i]$ es la fracción observada de tokens enviados al experto $i$ , y $P_i = \frac{1}{T} \sum_{t=1}^T p_i(\mathbf{x}_t)$ es la probabilidad promedio asignada por el router.

Por la desigualdad de Cauchy-Schwarz, $\sum_{i=1}^E f_i P_i \ge \frac{1}{E} (\sum f_i)(\sum P_i) = \frac{1}{E}$ . El mínimo global se alcanza si y solo si $f_i = P_i = \frac{1}{E}$ para todo $i$ (distribución perfectamente uniforme).

El defecto de la loss auxiliar: obliga al router a enviar tokens a expertos inadecuados para mitigar la penalización de pérdida, contaminando el gradiente de modelado de lenguaje: $\nabla_\theta \mathcal{L} = \nabla_\theta \mathcal{L}_{\text{LM}} + \nabla_\theta \mathcal{L}_{\text{aux}}$ .

Enfoque Aux-Loss-Free de DeepSeek-V3: desacopla la decisión de enrutamiento de la ponderación de las salidas. Para la selección se computa un score con sesgo dinámico:

\text{Score}_i = s_i + b_i, \quad s_i = \text{Sigmoid}(\mathbf{x}\mathbf{W}_r)_i

Los $k$ expertos se eligen con $\text{TopK}(\text{Score}, k)$ , pero la ponderación final de salida usa los scores originales $s_i$ renormalizados (sin el sesgo $b_i$ ). Fuera del grafo de autograd, el sesgo se actualiza por retroalimentación proporcional tras cada batch:

b_i \leftarrow b_i + \gamma \left( \frac{1}{E} - f_i \right)

Si un experto se sobrecarga ( $f_i > 1/E$ ), su sesgo se reduce automáticamente en el siguiente batch, forzando un equilibrio de carga estricto entre GPUs sin distorsionar los gradientes del modelo.

🟢 Por qué esto importa más de lo que parece

El balanceo no es un detalle de entrenamiento: decide cuánto de los "671B" son parámetros útiles. Un MoE mal balanceado es un modelo denso chico con mucho peso muerto en disco. Cuando una model card habla de expert utilization o de routing collapse está hablando de esto, y cuando un fine-tuning propio de un MoE "empeora sin razón", lo primero a mirar es si el router se desbalanceó con los datos nuevos.

3. Expertos finos y expertos compartidos: DeepSeek, Llama 4, Gemma 4

Mixtral tiene 8 expertos grandes (cada uno una FFN de 14B de ancho intermedio) y elige 2. DeepSeekMoE (enero 2024) propuso dos cambios que hoy son el estándar:

Expertos finos. Partir cada experto en m expertos de 1/m de ancho y elegir m·k en vez de k. A igual cómputo, el número de combinaciones posibles crece de forma combinatoria: elegir 2 de 8 da 28 combinaciones; elegir 8 de 64, más de 4.000 millones. Cada combinación es una "FFN distinta" para ese token. DeepSeek-V3 lleva esto a 256 expertos con 8 activos; Gemma 4 26B, Qwen3 y gpt-oss a 128.
Experto compartido. Uno o más expertos que todos los tokens usan siempre, sin pasar por el router. La idea: el conocimiento común (sintaxis, formato) no tiene por qué duplicarse en cada experto especializado. DeepSeek-V3, Llama 4 y Gemma 4 26B llevan un experto compartido; en Llama 4 cada token va a exactamente un experto ruteado más el compartido.

📐 Análisis combinatorio de la granularidad de expertos

La partición de la FFN en expertos ultra-finos incrementa drásticamente la expresividad representacional del modelo a idéntico costo de cómputo por token:

MoE Grueso (Mixtral 8x7B, $E=8, k=2$ ): el número de posibles configuraciones de subred activas por capa es: $\binom{8}{2} = \frac{8!}{2! \times 6!} = 28 \text{ combinaciones}$
MoE Fino (DeepSeek-V3, $E=256, k=8$ ): manteniendo acotados los FLOPs activos, el espacio combinatorio de ensamblado dinámico explota exponencialmente: $\binom{256}{8} = \frac{256!}{8! \times 248!} \approx 4.39 \times 10^{14} \text{ combinaciones}$

Este incremento de 13 órdenes de magnitud en la diversidad de subredes permite que representaciones semánticas altamente especializadas compartan la capacidad paramétrica total sin comprometer el rendimiento en inferencia.

DeepSeek-V3 agrega una tercera pieza que solo importa a escala de datacenter: routing limitado por nodo. Con 256 expertos repartidos en muchas GPUs, mandar cada token a 8 expertos en 8 máquinas distintas satura la red; el router elige primero como mucho 4 nodos y dentro de ellos los 8 expertos. Es un ejemplo de arquitectura decidida por la topología del hardware, y de por qué el "all-to-all" de MoE es la operación colectiva que domina el costo de comunicación, donde en un modelo denso dominaba el all-reduce de DDP/FSDP.

El reporte de Gemma 4 lista, en su tabla de la arena, modelos MoE de 2026 con proporciones aún más extremas: DeepSeek V4 Pro con 1,6T totales y 49B activos, Qwen 3.5 con 397B y 17B. La dirección es clara: cada vez más totales por activo, con expertos cada vez más finos.

4. Qué se paga y qué se ahorra: entrenamiento, inferencia, memoria

El cómputo por token de un transformer es aproximadamente 2 FLOPs por parámetro que ese token toca en inferencia, y 6 en entrenamiento (forward más backward), como vas a ver en la regla 6ND. En un MoE el parámetro que cuenta es el activo: DeepSeek-V3 cuesta por token lo que un 37B denso, y se entrenó con 14,8T tokens en unas 2,8 millones de horas de H800, un orden de magnitud menos que lo que un denso de 671B habría necesitado. Esa es la ganancia, y es real.

Lo que no baja es la memoria. Para servir hay que tener todos los expertos cargados, porque el próximo token puede pedir cualquiera:

La barra gris es la memoria; la ámbar, el cómputo por token. La proporción entre las dos creció de 3,6× (Mixtral) a 23× (gpt-oss, Llama 4 Maverick) en dos años: cada vez más parámetros que casi nunca se usan por token, pero que hay que tener cargados porque el router puede pedir cualquiera.

Y hay un tercer efecto, sutil, en la inferencia. El decode de un modelo está limitado por ancho de banda de memoria, no por cómputo (HF cap. 1 §5): generar un token exige leer los pesos que ese token usa. Con un usuario solo, un MoE lee únicamente sus expertos activos, así que gpt-oss-120b genera a la velocidad de un 5B. Con un batch grande, en cambio, los tokens del batch se reparten entre todos los expertos y cada paso de decode termina leyendo todos los pesos: la ventaja de ancho de banda se diluye y el modelo se comporta como un denso de 117B en tráfico de memoria, aunque no en FLOPs. Por eso los MoE brillan en latencia de un usuario y en costo de entrenamiento, y su ventaja en throughput con muchos usuarios depende del batch.

Recurso	Denso de N parámetros	MoE de N totales, A activos
FLOPs por token (inferencia)	≈ 2N	≈ 2A
FLOPs por token (entrenamiento)	≈ 6N	≈ 6A, más el costo del all-to-all
Memoria de pesos	N × bytes	N × bytes, sin descuento
Pesos leídos por token, un usuario	N	≈ A
Pesos leídos por paso, batch grande	N	tiende a N
KV cache	igual: depende de la atención, no de la FFN

5. MoE en la práctica: servir, cuantizar, fine-tunear

Servir. vLLM y SGLang tienen kernels de MoE fusionados que agrupan los tokens por experto y corren los matmuls en un solo lanzamiento, y expert parallelism para repartir expertos entre GPUs cuando no entran en una. Con 8 GPUs de 80 GB, DeepSeek-V3 en FP8 (unos 700 GB) entra justo con expertos repartidos; en bf16 no entra. Para un modelo como Gemma 4 26B A4B, los 25,2B totales en bf16 son 50 GB: una GPU de 80 GB, o dos de 24 GB con cuantización de 4 bits.

Cuantizar. Los expertos son matrices grandes con las mismas propiedades que la FFN densa, así que las recetas de 4 bits se les aplican igual y son el grueso del ahorro (gpt-oss se publicó directamente con expertos en MXFP4 y el resto en bf16). Lo que hay que dejar en float es lo mismo de siempre más el router: una matriz chica cuyo error de cuantización cambia qué experto se elige, no cuánto, y ese error no es suave. La receta de tu pipeline NVFP4 aplicada al 26B A4B tendría que excluir router como excluye normas y lm_head.

Fine-tunear. LoRA sobre la atención funciona igual; LoRA sobre los expertos multiplica los adaptadores por E y un token entrena solo los de sus expertos activos, así que converge más lento por experto. Y el router: congelarlo es lo seguro para datos parecidos a los de pre-entrenamiento; entrenarlo con un dominio nuevo y estrecho es la manera más rápida de desbalancearlo (§2). Otra ruta, sparse upcycling (Komatsuzaki et al., 2022), arranca un MoE copiando la FFN de un denso ya entrenado en cada experto y dejando que diverjan: es como se hicieron varios MoE medianos sin entrenar desde cero.

🔧 En tu proyecto

Elegiste Gemma 4 31B denso, y para tu caso es la elección correcta: el MTP de tu decoding especulativo, la receta NVFP4 y el LoRA generacional de interpretante-lacaniano están validados sobre un modelo denso. Si algún día lo cambiás por el 26B A4B, lo que cambia es exactamente esta página: 50 GB de pesos en bf16 en vez de 62, un decode con un usuario que lee 3,8B de parámetros por token en vez de 30,7B, el router fuera de la cuantización, y una revalidación del gate anti-alucinación porque un MoE puede rutear distinto los números que el texto que los rodea.

6. Errores comunes

Error	Por qué pasa	Qué hacer
Dimensionar la GPU por los parámetros activos	Los activos miden cómputo por token; los pesos hay que tenerlos todos cargados porque el router puede pedir cualquiera.	VRAM = parámetros totales × bytes por peso, más KV cache y activaciones (§4).
Esperar que un MoE sea proporcionalmente más rápido con batch grande	Con muchos tokens por paso todos los expertos se activan y el tráfico de memoria vuelve al del modelo completo.	Medir throughput al batch real; la ventaja limpia de MoE es en latencia de un usuario y en costo de entrenamiento (§4).
Cuantizar el router a 4 bits junto con los expertos	El error cambia el argmax del top-k: elige otro experto, no "casi el mismo".	Router, normas, embeddings y `lm_head` en bf16; cuantizar expertos y atención (§5).
Fine-tunear el router con un dataset estrecho	Los tokens del dominio nuevo empujan a pocos expertos; el balanceo se rompe y la calidad general cae.	Congelar el router en fine-tunings chicos; si se entrena, mantener el término de balanceo y monitorear la carga por experto (§2, §5).
Leer "8x7B" como ocho modelos de 7B	Solo la FFN se replica; atención, embeddings y normas están una vez, y cada capa tiene su propio router.	Totales = compartido + E × FFN; activos = compartido + k × FFN (§1).
Buscar "el experto de matemática"	La especialización que emerge es sintáctica y posicional, no temática; Mixtral lo midió y no la encontró.	Pensar los expertos como capacidad extra que el router reparte, no como módulos por dominio (§1).

7. Resumen

Una capa MoE reemplaza la FFN por E expertos y un router lineal que elige k por token; la salida es la suma ponderada de los k. Atención, embeddings y normas siguen siendo una sola copia.
El cómputo por token lo fijan los parámetros activos; la memoria, los totales. "671B / 37B" cuesta entrenar y generar como un 37B y ocupa como un 671B.
El problema histórico fue el colapso del router: pocos expertos con todo el tráfico. Switch lo resolvió con una loss auxiliar y capacidad por experto; DeepSeek-V3 con un sesgo ajustado fuera del gradiente.
El estándar 2025-2026 es expertos finos (64 a 256, con 4 a 8 activos) más un experto compartido que todos usan; DeepSeek, Llama 4, Qwen3, gpt-oss y Gemma 4 26B lo siguen con variantes.
En inferencia el MoE gana en latencia de un usuario (lee solo expertos activos) y pierde esa ventaja con batch grande; el router se deja en float al cuantizar y congelado en fine-tunings chicos.

8. Ponete a prueba

Respondé antes de abrir cada respuesta. Si fallás una, volvé a la sección indicada.

1. Una model card dice "26B totales, 3,8B activos, 128 expertos, 8 activos + 1 compartido". ¿Cuánta VRAM necesitás para cargarlo en bf16 y a qué velocidad de decode con un usuario deberías esperar que se parezca?

Unos 50 GB (25,2B × 2 bytes) más KV cache. El decode con un usuario está limitado por los pesos que lee por token: alrededor de 3,8B, así que se parece a un modelo denso de 4B en tokens por segundo, aunque ocupe como uno de 25B. (§0, §4)

2. ¿Por qué un router sin balanceo colapsa, y cuál es la diferencia entre la solución de Switch y la de DeepSeek-V3?

Los expertos elegidos mejoran y el router los elige más, en un feedback loop que deja a los demás sin gradiente. Switch agrega a la loss un término que penaliza el reparto desigual (dentro del gradiente, con un coeficiente que hay que tunear); DeepSeek-V3 ajusta un sesgo por experto después de cada batch, fuera del gradiente, solo para la selección del top-k, y el paper muestra mejor perplejidad sin sacrificar balanceo. (§2)

3. ¿Qué gana un modelo al pasar de 8 expertos con 2 activos a 64 expertos de un octavo de ancho con 16 activos, si el cómputo es el mismo?

Combinaciones: 28 contra miles de millones. Cada token recibe una "FFN" armada a medida de entre muchas más posibles, con el mismo costo. Es la idea de expertos finos de DeepSeekMoE. (§3)

4. ¿Para qué sirve un experto compartido, si el router ya podría aprender a mandar todos los tokens a uno?

Para que el conocimiento común no tenga que replicarse dentro de cada experto ruteado: el compartido lo absorbe y los demás quedan libres para especializarse. Y como no pasa por el router, no compite en el balanceo ni depende de que el router aprenda ese patrón. (§3)

5. Servís un MoE con vLLM y notás que con 64 requests concurrentes el throughput por GPU es mucho menor de lo que esperabas por los parámetros activos. ¿Qué pasa?

Con 64 secuencias por paso los tokens se reparten entre todos los expertos y cada paso de decode lee los pesos completos: el tráfico de memoria es el de un denso del tamaño total. La cuenta de "activos" describe FLOPs y latencia con un usuario, no ancho de banda con batch grande. (§4)

6. ¿Qué parte de un MoE no conviene cuantizar a 4 bits y por qué es distinta de una capa cualquiera?

El router. Su salida no se usa como valor sino como ranking (top-k): un error pequeño puede cambiar qué experto se elige, y ese cambio es discreto, no un error suave que se compense. Es chico, así que dejarlo en bf16 no cuesta memoria. (§5)

9. Para practicar

✏️ Ejercicio 1 — ver el colapso del router y arreglarlo

Armá una CapaMoE como la de §1 con d = 64, 8 expertos, k = 2, y entrenala en una tarea sintética (por ejemplo, predecir x @ W_verdadera con ruido) durante 500 pasos. En cada paso, contá cuántos tokens fueron a cada experto e imprimí el histograma cada 100 pasos. Después agregá la loss auxiliar de Switch (fracción de tokens por experto × probabilidad media por experto, sumado y × E, con coeficiente 0,01) y repetí.

Pista / qué esperar

Sin la loss, en unas decenas de pasos dos o tres expertos reciben casi todo y el resto queda en cero o casi. Con la loss el histograma se mantiene aproximadamente parejo. Si no ves colapso, subí el learning rate del router o inicializalo con más varianza; el colapso es más rápido cuanto más confiado arranca el router.

✏️ Ejercicio 2 — la cuenta de memoria y cómputo para tu hardware

Sin código: para Gemma 4 31B denso y Gemma 4 26B A4B, calculá (a) VRAM de pesos en bf16 y en NVFP4 (4,5 bits por peso efectivos, con embeddings, normas y router en bf16: estimá el embedding como 262.144 × d_model), (b) FLOPs por token de inferencia, y (c) decidí cuál entra en tu 5090 de 24 GB y con qué contexto, usando la cuenta de KV cache de la página anterior.

Pista / qué esperar

La tabla oficial de Google de memoria de inferencia da 69,9 GB para el 31B y 57,7 GB para el 26B A4B en bf16 (con encoder de visión y embeddings), y 17,5 y 14,4 GB en Q4_0. Ninguno entra en bf16; los dos entran en 4 bits, y el MoE con 8 veces menos FLOPs por token que el 31B. Lo que debería quedarte claro al terminar: el MoE te da más margen de contexto y más velocidad con un usuario, y el denso te da más calidad por GB de VRAM, que es la variable que a vos te limita.

10. Fuentes y para seguir

Shazeer et al. — Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer (2017, arXiv:1701.06538) — el primer MoE a escala, con la formulación del gating y del balanceo.
Fedus, Zoph & Shazeer — Switch Transformers (2021, arXiv:2101.03961) — top-1, la loss auxiliar de balanceo y el factor de capacidad, con los experimentos de estabilidad.
Jiang et al. — Mixtral of Experts (2024, arXiv:2401.04088) — el modelo que hizo MoE abierto y práctico; incluye el análisis de (no) especialización por dominio.
Dai et al. — DeepSeekMoE (2024, arXiv:2401.06066) — expertos finos y expertos compartidos.
Wang et al. — Auxiliary-Loss-Free Load Balancing Strategy for MoE (2024, arXiv:2408.15664) y DeepSeek-AI — DeepSeek-V3 Technical Report (2024, arXiv:2412.19437) — el balanceo por sesgo, el routing limitado por nodo y el costo de entrenamiento citado en §4.
Komatsuzaki et al. — Sparse Upcycling (2022, arXiv:2212.05055) — arrancar un MoE desde un checkpoint denso.
Meta — The Llama 4 herd (abril 2025), OpenAI — Introducing gpt-oss (agosto 2025) y la model card de Gemma 4 — las cifras de totales, activos y expertos de la tabla de §0.