Mixture of Experts (MoE): qué es, cómo funciona y por qué importa en 2026

11 de agosto del 202611 minIA, MoE, Mixture of Experts, Qwen, Kimi, Arquitectura, LLM

Respuesta corta (60 segundos): Mixture of Experts (MoE) es una arquitectura donde cada capa del transformer tiene muchos módulos pequeños llamados expertos (típicamente FFNs) y un router (gating network) que decide cuáles expertos activar para cada token. Solo se computan los expertos seleccionados — el resto del modelo está en memoria pero no participa del cálculo. La métrica clave es parámetros activos vs totales: Kimi K2 tiene 1T totales pero solo 32B activos por token; Qwen3-30B-A3B tiene 30.5B totales y 3.3B activos. Por qué importa: te da capacidad total alta al mismo costo de FLOPs por token que un modelo denso más chico. El tradeoff real: entrenamiento requiere balanceo de carga entre expertos (auxiliary loss, expert collapse) y la inferencia es más cara en memoria y comunicación porque todos los expertos tienen que vivir en VRAM aunque solo uses algunos.

Si querés entender por qué la conversación sobre LLMs en 2026 gira cada vez más alrededor de MoE — y por qué saber la diferencia entre "30B parámetros" y "3B activos" cambia cómo evalúas un modelo para tu SaaS — este post es para vos. Voy a explicar la arquitectura sin asumir que ya sabés qué es un FFN, voy a verificar los números de Qwen y Kimi (no de memoria), y voy a ser honesto sobre los tradeoffs que los papers suelen esconder.

Por qué MoE importa en 2026

Los números hablan solos:

Lo que la tabla te dice es contraintuitivo al principio: un modelo con 30 veces más parámetros totales puede ser más barato de correr por token que uno con muchos menos. Es la diferencia entre capacidad (cuánta información puede almacenar el modelo) y cómputo por token (cuánto te cuesta cada inferencia). MoE separa las dos cosas; los modelos densos no pueden.

El paper original de MoE es de 1991 (Jacobs et al.), pero recién en 2017 Shazeer et al. lo aplicaron a LSTM de 137B parámetros en producción. La diferencia con 2024-2026 es que ahora MoE es el patrón default para modelos frontier open-weight (Qwen, DeepSeek, Kimi, Mixtral) y probablemente para varios propietarios (GPT-4 rumored, Claude speculated).

Qué es MoE exactamente

La intuición primero: imaginá un hospital general con un solo médico que tiene que atender todo. Ahora imaginá un hospital con 128 médicos especialistas y una recepcionista que, según el síntoma, deriva al paciente al especialista correcto. El segundo hospital atiende la misma cantidad de pacientes por hora (un paciente solo ve a un especialista) pero tiene más capacidad instalada para casos raros porque hay un cardiólogo, un dermatólogo, un neurólogo, etc.

MoE es el equivalente neuronal del segundo hospital:

• Expertos: en vez de una FFN densa por capa del transformer, tenés N expertos (típicamente N entre 8 y 384). Cada experto es una FFN pequeña — más o menos del tamaño de una FFN densa dividido por N.
• Router (o gating network): una capa lineal pequeña (un solo nn.Linear) que toma el hidden state del token y produce N logits. De esos logits, el router selecciona los top-k expertos para ese token.
• Forward pass: solo los k expertos seleccionados computan su output. Sus outputs se combinan (típicamente suma ponderada por el softmax de los logits) y se pasan a la siguiente capa.

Para un modelo denso de 70B, cada token hace pasar sus 70B de pesos por cómputo. Para un MoE de 1T totales con 32B activos, cada token hace pasar solo 32B — pero el modelo tiene 1T de "memoria" para almacenar conocimiento.

La arquitectura visual

Lo crítico del diagrama es lo que no aparece: los expertos no seleccionados no computan nada. En Qwen3-30B-A3B, de 128 expertos solo 8 hacen trabajo por token. Los otros 120 están sentados mirando.

Parámetros totales vs activos: la métrica que cambia todo

Esta es la distinción más importante del post. Si tu proveedor o paper dice "30B parámetros", no te dice cuánto te cuesta. Necesitás los dos números:

• Parámetros totales (total parameters): todo lo que está almacenado. Define el tamaño del archivo del modelo, la VRAM mínima para cargarlo, y — en términos prácticos — cuánto conocimiento puede potencialmente codificar.
• Parámetros activos (active parameters): la fracción que participa del forward pass de un token. Define los FLOPs por token, la velocidad de inferencia, y el costo computacional por request.

Para los modelos MoE del momento:

Qwen3-30B-A3B (verificado del model card oficial en HuggingFace):

Kimi K2 (verificado del GitHub oficial de MoonshotAI y technical report):

El ratio de activación de Kimi K2 (~3.2%) es extremo y es parte de por qué Moonshot eligió Muon optimizer en vez del AdamW estándar: a esa escala, la eficiencia del optimizer importa mucho más.

¿Por qué importa esta distinción para vos? Porque cuando un proveedor te cobra por millón de tokens o te promete cierta velocidad, lo que importa son los FLOPs por token — y eso escala con activos, no con totales. Un modelo "1T parámetros" puede ser más barato por token que uno "70B parámetros" si su activación es chica.

Por qué MoE escala mejor que los modelos densos

El argumento central del paper de Mixtral (Mistral AI, dic 2023) y de varios análisis de DeepSeek es este: para un budget fijo de FLOPs de entrenamiento, un MoE con muchos expertos sparsity-optimizada aprende más rápido que un modelo denso con menos parámetros.

La intuición formal: en un modelo denso, agregar parámetros aumenta el costo por token linealmente. En un MoE, agregar expertos aumenta los parámetros totales (más capacidad de almacenamiento de conocimiento) pero no aumenta los FLOPs por token (porque el top-k se mantiene constante). Entonces, para el mismo FLOPs por token, podés tener 5-10x más capacidad.

El paper de Mixtral reportó que Mixtral 8x7B supera a Llama 2 70B en la mayoría de benchmarks con 6x más rápido en inferencia. La razón: Mixtral tiene ~12.9B activos vs 70B densos — y los FLOPs por token caen proporcionalmente.

Pero hay un "pero" importante que muchos papers minimizan: más capacidad sin más FLOPs no es gratis en entrenamiento. El modelo necesita más tokens para llenar esa capacidad, lo que sube el costo total del training run. MoE gana en eficiencia por token pero no necesariamente en costo total absoluto.

Desafíos de entrenamiento: por qué MoE no es trivial

Tres problemas concretos que cualquier equipo que entrena MoE tiene que resolver:

1. Load balancing. Si dejás al router entrenando libremente, colapsa: todos los tokens van al mismo experto (típicamente el que inicializa con logits más altos) y los demás expertos mueren de hambre. La solución estándar es un auxiliary loss que penaliza distribuciones desbalanceadas y fuerza a que cada experto reciba una fracción similar del tráfico. Shazeer et al. introdujeron el load balancing loss original; Mixtral y Qwen usan variantes con top-k.

2. Expert collapse. Síntoma del load balancing fallido: durante el entrenamiento, algunos expertos dejan de recibir tokens y sus gradientes se vuelven cero. Terminan representando conocimiento muerto. Las variantes modernas incluyen routing ruidoso (añadir ruido a los logits del router durante training) y capacity factors (limitar cuántos tokens puede atender un experto por batch) para evitarlo.

3. Communication overhead en entrenamiento distribuido. Cuando entrenás un MoE con 8 o más GPUs, el dispatch (mandar tokens a sus expertos asignados) y el combine (recoger resultados) requiere operaciones all-to-all que dominan el tiempo de entrenamiento a escala. DeepSeek-V3 reportó optimizaciones específicas (DualPipe, expert parallelism fino) para mitigar esto.

Desafíos de inferencia: por qué MoE es más caro de servir

Si el entrenamiento es difícil, la inferencia tiene sus propios problemas que muchas veces solo se ven en producción:

1. Memoria total, no activa. Aunque solo 3.3B de parámetros estén activos por token en Qwen3-30B-A3B, los 30.5B totales tienen que vivir en VRAM. Para Kimi K2 con 1T de parámetros en FP16, necesitás 2TB de VRAM distribuida entre GPUs (típicamente 16-32 accelerators H100/H200). El costo de capital de servir MoE es alto incluso si el cómputo por token es bajo.

2. All-to-all communication. En inferencia con expertos distribuidos en múltiples GPUs, cada token generado requiere comunicación all-to-all: el router le dice a cada GPU "tus expertos atienden estos tokens" y luego recoge los resultados. La latencia de esa comunicación es fija y domina el tiempo total cuando los expertos están en varias GPUs.

3. Latency bimodal. En producción, si algunos expertos se vuelven populares para ciertos tipos de queries (por ejemplo, el "experto de código" recibe mucho más tráfico que el "experto de poesía"), las GPUs que alojan esos expertos se congestionan. La latencia se vuelve bimodal: requests rápidos y requests lentos, sin un valor medio confiable. Monitorear y mitigar esto requiere batching dinámico o speculative expert prefetching.

4. KV cache fragmentation. Cada token generado requiere recomputar el router y mantener el KV cache. Como el routing cambia según el contexto, el patrón de acceso a memoria es irregular y los engines de inferencia (vLLM, SGLang) tienen que hacer optimizaciones específicas para MoE que no aplican a modelos densos.

Para un founder de SaaS, la traducción práctica es: MoE vía API es generalmente buena relación calidad/precio, pero self-hosting un MoE grande suele ser desfavorable en TCO hasta que tu volumen justifique la inversión en infraestructura distribuida.

¿Cuándo elegir MoE sobre un modelo denso?

Tres reglas prácticas que uso con clientes:

Elegí MoE si:

• Tu proveedor te lo ofrece vía API (no necesitás self-hosting) y la calidad por dólar es mejor que alternativas densas. Ejemplo: Qwen3-30B-A3B es competitivo con modelos densos de 14B-30B en muchos benchmarks pero corre a velocidad de 3B dense.
• Estás haciendo fine-tuning y querés más capacidad sin pagar el costo de un dense más grande. MoE fine-tuneado con LoRA es sorprendentemente eficiente.
• Tu workload es agentic o coding long-horizon donde la "memoria grande" del modelo importa más que latencia mínima por token.

Elegí dense si:

• Necesitás self-hosting y no querés manejar la complejidad de expert parallelism. Un dense de 7B-13B corre en una sola GPU moderna; un MoE equivalente casi siempre requiere múltiples.
• Tu workload es latency-sensitive extremo (ej: voz full-duplex). La variabilidad del routing MoE es un problema cuando cada milisegundo cuenta.
• Necesitás control fino sobre el routing o debugging detallado por arquitectura. Dense es más fácil de inspeccionar.

Elegí dense pequeño o MoE pequeño (3-8B activos) si:

• Estás prototipando. El costo de iteración es lo que importa, no la capacidad pico.

Conclusión: MoE es el default de 2026, pero no es magia

Mixture of Experts es la arquitectura dominante para modelos frontier en 2026 y va a seguir siéndolo. Pero "MoE" no es una propiedad binaria — es un espectro de decisiones: cuántos expertos, cuántos activos por token, qué tipo de routing, qué auxiliary losses, cómo distribuir en hardware. Cuando un proveedor te dice "usamos MoE", preguntale siempre el ratio de activación. Esa es la cifra que importa.

Si tu SaaS ya consume modelos frontier vía API y todavía no entendés la diferencia entre parámetros totales y activos, este es el momento de aprenderlo. Es la diferencia entre pagar USD 0.50 y USD 11 por la misma tarea terminada.

¿Querés discutir cómo encaja MoE en tu arquitectura antes de elegir modelo para producción? Hay un CTA al final con una llamada gratis de 30 minutos.

Preguntas frecuentes

¿Qué es Mixture of Experts (MoE) en una frase?

Es una arquitectura de red neuronal donde, en vez de una sola FFN densa por capa, tenés muchos módulos pequeños llamados "expertos" y un router que activa solo los k más relevantes para cada token. El modelo tiene muchos parámetros totales, pero solo una fracción está activa en cualquier inferencia.

¿Cuál es la diferencia entre parámetros totales y parámetros activos?

Parámetros totales = todo lo que vive en memoria del modelo (todos los expertos + embeddings + atención). Parámetros activos = la fracción que participa en el forward pass de un token (los k expertos seleccionados por el router + atención). Kimi K2 tiene 1T totales y 32B activos: por cada token, solo computa el 3.2% de sus pesos.

¿MoE hace al modelo más barato de entrenar?

No directamente. El costo de entrenamiento escala con parámetros activos por token (los FLOPs de forward + backward), no con el total. Entonces MoE te permite más capacidad total al mismo costo de entrenamiento por token, pero el costo total del entrenamiento sube porque necesitás más tokens para llenar esa capacidad. La métrica correcta es FLOPs por token, no parámetros totales.

¿Por qué MoE es más difícil de servir (inferencia) que un modelo denso?

Tres razones. (1) Memoria: todos los expertos tienen que estar en VRAM aunque solo uses algunos por token — para 1T de parámetros en FP16 necesitás 2TB de VRAM distribuida. (2) Communication: el router hace dispatch y combine entre GPUs (all-to-all), que es latencia pura. (3) Load balancing en producción: si la distribución de tokens por experto se desbalancea, los expertos populares se vuelven cuellos de botella y la latencia se vuelve bimodal.

¿Cuántos expertos activos usan Qwen3-30B-A3B y Kimi K2?

Qwen3-30B-A3B usa 128 expertos totales y activa 8 por token (top-8, sin shared expert). Kimi K2 es más extremo: usa un esquema MoE con 32B activos sobre 1T totales — no tengo público el conteo exacto de expertos en K2 al cierre de este post, pero el ratio es ~3% de activación.

¿Cuándo conviene un MoE sobre un modelo denso?

Cuando tu métrica es capacidad por FLOP (training compute o inferencia por token) y podés tolerar el costo fijo de memoria y la complejidad de serving. Para self-hosting, MoE suele ser desfavorable porque necesitás GPUs con mucha VRAM aunque uses pocos expertos activos. Para inferencia via API (donde el proveedor optimiza el serving), MoE te da más calidad por dólar.

¿MoE es lo mismo que "modelos dispersos" (sparse models)?

MoE es la implementación más popular de modelos dispersos. Sparse significa que, por cada token, solo una fracción de los parámetros participa del cómputo. MoE lo logra con el router que selecciona expertos; otras técnicas sparse (como sparse attention) operan en dimensiones distintas de la arquitectura.