Mixture of Experts: cómo 30.000 millones de parámetros solo usan 3.000 millones por token
TL;DR: Un modelo MoE tiene muchos parámetros pero solo usa una fracción por token. Eso permite que modelos de 30B “piensen” como si fueran de 3B, pero con más conocimiento disponible. La trampa: todos los parámetros deben estar en memoria, aunque no se usen todos a la vez.
El problema
Un modelo tradicional (dense) procesa todos sus parámetros para cada token que genera. Un modelo de 14B procesa 14B por token. Uno de 30B, 30B. Más parámetros = más calidad, pero también más memoria.
Con 16GB VRAM, el límite práctico es ~14B en Q4 (cuantización de 4 bits). Si quieres más calidad, necesitas más VRAM. O necesitas MoE.
Cómo funciona MoE
Un transformer tiene capas. Cada capa tiene un bloque feed-forward (FFN) — la parte que almacena “conocimiento”. En un modelo dense, hay un FFN por capa.
En MoE, cada capa tiene varios FFN en paralelo. Cada uno es un “experto”. Y un router decide qué expertos activar para cada token.
Modelo dense (14B):
Token → [FFN 14B] → output
Modelo MoE (Gemma 4 26B, 3.8B activos):
Token → Router → [Experto A (1.9B)] → output
[Experto B (1.9B)] → output
[Experto C (1.9B)] (no activado)
...
(128 expertos total, 2 activos)
El router es una pequeña red neuronal que aprende qué expertos son mejores para qué tipo de token. Tokens de código → expertos de código. Tokens de razonamiento → expertos de razonamiento.
El resultado: Solo 3B parámetros se procesan por token. Pero esos 3B cambian dinámicamente según el contenido.
Los modelos MoE que importan para 16GB
| Modelo | Params totales | Params activos | Disco Q4 | VRAM usada | Expertos | Activos |
|---|---|---|---|---|---|---|
| Gemma 4 26B-A4B | 26B | 3.8B | ~16 GB | ~15 GB | 128 | 2 |
| Qwen3-Coder-30B | 30.5B | 3B | ~17 GB | ~14.5 GB | 128 | 8 |
| Qwen3.5-122B | 122B | 10B | ~33 GB | CPU offload | 128 | 10 |
| Qwen3.6-35B-A3B | 35B | 3B | ~16 GB | ~22 GB* | 256 | 8+1 |
*Requiere más de 16GB — solo entero en RTX 5090.
Patrón: La mayoría usa 128 expertos, activando 2-10 según modelo. Cada token pasa por ~1.5-6% de los expertos disponibles.
La trampa
Los parámetros activos son pocos. Pero los parámetros totales deben estar todos en memoria.
| Modelo | Activa | En memoria | Diferencia |
|---|---|---|---|
| Dense 14B | 14B | 14B | 1x |
| MoE 30B (3B activos) | 3B | 30B | 10x |
Procesas como un modelo de 3B, pero ocupas como uno de 30B. La velocidad de generación es comparable a un 3B, pero necesitas la VRAM de un 30B.
En la práctica con 16GB VRAM:
| Modelo | Cabe entero? | Velocidad |
|---|---|---|
| Dense 14B (qwen3:14b) | ✅ Sí | ~50 tok/s |
| MoE 30B (coder-30b) | ⚠️ Offload 3.8 GB | 7.2 tok/s |
El dense es más rápido. El MoE tiene más conocimiento disponible (30B vs 14B en memoria). La pregunta es: ¿necesitas ese conocimiento extra?
¿Cuándo usar MoE vs dense?
| Situación | Usa | Por qué |
|---|---|---|
| Chat rápido, preguntas | Dense (e4b, qwen3:14b) | Más rápido |
| Coding complejo, refactor | MoE (coder-30b) | Más conocimiento |
| Contexto largo (>32K) | Dense pequeño | Offload destruye velocidad |
| Razonamiento pesado | MoE grande | Más params = mejor razonamiento |
| GPU con poca VRAM (8GB) | Dense pequeño (e4b) | MoE no cabe |
El futuro: MoE cada vez más extremo
La tendencia es clara:
| Año | Modelo | Total | Activo | Ratio |
|---|---|---|---|---|
| 2024 | Mixtral 8x7B | 47B | 13B | 28% |
| 2025 | Qwen3 235B | 235B | 22B | 9% |
| 2025 | Gemma 4 26B | 26B | 4B | 15% |
| 2026 | Qwen3-Coder-480B | 480B | 35B | 7% |
Los modelos crecen en parámetros totales pero los activos se mantienen bajos. Eso significa: más conocimiento, mismo cómputo. Pero misma memoria.
El Qwen3-Coder-480B con solo 35B activos compite con Claude Sonnet-4 y GPT-4.1 en benchmarks de coding. No puedes correrlo en 16GB. Pero la arquitectura demuestra que el futuro no es “modelos más grandes que procesan más”. Es “modelos más grandes que eligen mejor”.
Anterior: El precipicio VRAM Siguiente: CUDA 13, Blackwell y el gap consumer/data center