Mixture of Experts: por qué los modelos grandes ya no usan todos sus parámetros cada vez que responden

Cuando un modelo como Mixtral 8x7B o DeepSeek-V3 anuncia 469.000 millones de parámetros, uno espera que cada respuesta cueste una fortuna de cómputo. Y sin embargo, contestar una pregunta breve consume mucho menos. La paradoja se resuelve con una idea que lleva casi tres décadas dando vueltas por la literatura y que en los últimos dos años se ha convertido en el patrón dominante de los modelos abiertos y propietarios: Mixture of Experts (MoE).

Qué significa "mezcla de expertos" en la práctica

La intuición es vieja: en lugar de tener un único bloque gigante que procesa cualquier entrada, dividimos ese bloque en varios sub-bloques más pequeños, llamados expertos, y añadimos un mecanismo que decide en cada paso cuáles de esos expertos se activan. Es la versión neuronal de la vieja idea de tener varios especialistas en una empresa y un recepcionista que pasa la consulta al que mejor pueda atenderla.

En un Transformer denso tradicional, cada capa feed-forward contiene una matriz enorme: si la dimensión oculta es H=8192 y la capa intermedia es 4·H=32768, esa capa tiene H x 4H = 268 millones de parámetros. Y se usan todos, en cada token, en cada capa. Multiplica eso por 80 o 120 capas y tienes los números que aparecen en las fichas técnicas.

Una capa MoE reemplaza esa única matriz intermedia por N matrices más pequeñas (típicamente N entre 8 y 256). Cada una es una experta. La magia está en que para cada token solo se eligen las K mejores (K suele ser 2 u 8), y solo esas se ejecutan. El resto, literalmente, no se toca.

El portero: el router o puerta de acceso

El componente que decide qué expertos recibe cada token se llama router o gating network. En la inmensa mayoría de implementaciones modernas es tan simple como problemático: una capa lineal que produce N logits (uno por experto), seguida de un softmax top-K.

Matemáticamente, para un token x el router calcula g(x) = softmax(W·x) y se queda con los K índices de mayor probabilidad. Solo se aplican los expertos seleccionados y la salida se pondera por esos pesos. La fórmula, simplificada, es:

y = Σ_{i ∈ topK(g(x))} g(x)_i · E_i(x)

Donde E_i es el i-ésimo experto. El coste de cómputo total se reduce de N expertos a K, así que la velocidad de inferencia es aproximadamente N/K veces mayor que si todos los expertos se ejecutasen. Para Mixtral 8x7B eso significa que cada token paga solo 2 de los 8 expertos: un 25 % del cómputo total del bloque, manteniendo un total de parámetros casi 8 veces superior al de un modelo denso equivalente.

Por qué importa: el truco de la capacidad sin el coste

Esta es la razón por la que MoE se ha vuelto omnipresente. Hay tres propiedades que cualquier equipo de producto valora:

• Capacidad de aprendizaje: más parámetros totales significan más capacidad de memorizar hechos, matices y patrones poco frecuentes. Un modelo denso con 7B parámetros aprende menos que uno MoE con 8x7B.
• Coste de inferencia estable: el FLOPs por token se acerca al de un modelo mucho más pequeño, porque solo se activan K expertos. Pagas memoria y ancho de banda, pero no computación proporcional.
• Escalabilidad horizontal: añadir más expertos es "gratis" en inferencia hasta cierto punto. Puedes lanzar un 8x22B sin que cada usuario pague el coste del 22B.

Esa última propiedad es la que explica la explosión de modelos chinos abiertos (DeepSeek-V3, Qwen3-MoE, GLM-5.3-MoE) y por qué empresas con presupuestos ajustados pueden competir con frontera cerrada. La memoria es el nuevo suelo: cargar 469.000 millones de parámetros requiere hardware serio, pero solo una fracción se mueve en cada token.

El lado oscuro: por qué MoE no es gratis

Tres problemas llevan años abiertos y todavía no están bien resueltos:

1. Desequilibrio de carga (load balancing)

Si el router aprende a mandar siempre el mismo par de expertos, los demás se atrofian. El entrenamiento introduce un término auxiliar en la loss —el load-balancing loss— que penaliza distribuciones demasiado sesgadas. Pero es un parche: en inferencia no hay nada que fuerce ese equilibrio, y si un grupo de expertos recibe muchas más consultas que otros, el throughput real cae.

2. El problema del batching

Cuando un servidor procesa muchas peticiones a la vez, cada token tiene su propia ruta. Si los 64 tokens del batch eligen expertos distintos, hay que materializar 64 invocaciones distintas. Eso destruye la ganancia teórica y obliga a usar kernels especializados (como Megablocks o ScatterMoE) que reordenan tokens por experto. Buena parte del trabajo de inferencia rápida de vLLM y SGLang está dedicado precisamente a esto.

3. Memoria vs. cómputo

Aunque solo uses K expertos por token, todos viven en la VRAM. Un modelo 8x7B sigue necesitando unos 90 GB en cuantización 4-bit solo para los pesos de los expertos, más embeddings y atención. Eso limita dónde puedes desplegarlo y por qué MoE es la arquitectura preferida en cloud pero menos común en edge.

El estado del arte en 2026

Los últimos dos años han consolidado varias tendencias:

• Fine-grained experts: en lugar de 8 expertos grandes, modelos como DeepSeek-V3 o Qwen3-MoE usan 256 expertos pequeños y activan 8 por token. Más flexibilidad, mejor balanceo.
• Shared experts: rutas que siempre se ejecutan (un experto "común" que captura conocimiento general) más rutas especializadas. Lo vimos en DeepSeekMoE y en varias iteraciones recientes.
• Routing diferenciado por capa: las primeras capas prefieren pocos expertos grandes; las últimas se benefician de muchos pequeños. Modelos como JetMoE demostraron que esta asimetría funciona.
• Mezcla con atención dispersa: ciertas arquitecturas combinan MoE en feed-forward con atención que también escoge qué cabezas usar, llevando el principio de "solo lo necesario" hasta el mecanismo de atención.

Cómo encaja en el panorama actual de modelos

Si miras las fichas técnicas de los modelos que dominan 2026 verás que MoE ya no es la excepción, es la norma. GPT-6 Astra, Gemini 3.8 Flash, Nemotron 3.5 Lightning, Mixtral, DeepSeek-V3, Qwen3-MoE, GLM-5.3, DBRX, Grok 4.6: todos MoE o derivados. Los modelos densos siguen existiendo (Llama 4 Scout en su versión pequeña, Gemma, Phi), pero se reservan para casos donde el tamaño total importa más que la calidad por FLOP.

Para alguien que trabaja en producto o seguridad esto tiene una consecuencia directa: cuando leas un informe que habla de un modelo con 670B parámetros, recuerda que un atacante que paga por una API solo paga el coste de K expertos por token, y que el operador paga memoria para todos. Entender esa asimetría es la diferencia entre estimar bien el coste de un ataque y llevarse sorpresas desagradables a final de mes.

Lectura recomendada para profundizar: Switch Transformers (Fedus et al., 2021), el paper fundacional de MoE moderno; GShard (Lepikhin et al., 2020), que escaló la idea a 600B parámetros; y DeepSeekMoE, que introdujo la segmentación de expertos compartidos y específicos que hoy usa media industria.