Modelos Dense vs. Mixture of Experts — La Decisión Arquitectónica Que Define la Economía de Inferencia

TL;DR

• Modelos Dense activan todos los parámetros para cada token. Simples, predecibles, pero con escalamiento lineal en computo y memoria.
• Mixture of Experts (MoE) activa solo un subconjunto de parámetros por token. Cuentas masivas de parámetros totales con menor computo activo, pero con compensaciones en memoria, comunicación y estabilidad del entrenamiento.
• La regla empírica: Un modelo sparse de 8 vías tiene una economía de inferencia aproximadamente equivalente a un modelo dense de la mitad de su tamaño total — no su tamaño activo, y ciertamente no su tamaño completo.
• Cuándo elegir qué: Dense para servicio de bajo batch, limitado por memoria y tareas puramente de razonamiento. MoE para cargas de trabajo de alto batch, limitadas por computo y aplicaciones intensivas en conocimiento.

La Pregunta Que Todo Equipo de Infraestructura Se Está Haciendo

Si estás construyendo infraestructura de IA en 2026, probablemente has mirado una hoja de cálculo de adquisiciones y te has hecho la misma pregunta que yo: ¿Desplegamos un modelo dense o un MoE?

La respuesta no está en la ficha técnica del modelo. Está en tu carga de trabajo. Las arquitecturas dense y MoE resuelven el mismo problema — predecir el siguiente token — pero hacen apuestas fundamentalmente distintas sobre dónde residen los cuellos de botella. Entender esas apuestas es lo que separa a un sistema que escala elegantemente de uno que colapsa bajo su propia cuenta de parámetros.

Desglosemos cómo funcionan estas arquitecturas en la práctica, dónde se esconden los costos y cómo los laboratorios de vanguardia navegan estas compensaciones.

Cómo Funciona un Modelo Dense

En un Transformer dense estándar — piensa en Llama, GPT-3 o Qwen2.5 — cada capa contiene una única Red Feed-Forward (FFN). Cuando un token pasa por esa capa, cada peso en esa FFN se lee, multiplica y actualiza. No hay lógica condicional. Si el modelo tiene 70 mil millones de parámetros, los 70 mil millones participan en cada pase hacia adelante.

La aritmética es brutal pero simple:

Compute(FLOPs) ∝ Total Parameters
Memory(VRAM)   ∝ Total Parameters

Esta relación lineal hace que los modelos dense sean predecibles. Un modelo de 7B cabe en una GPU. Uno de 70B necesita ocho. La capacidad por la que pagas es la capacidad que usas. No hay costos ocultos de enrutamiento, no hay cuellos de botella de comunicación all-to-all, y no hay riesgo de que una compuerta mal inicializada colapse la mitad de tus expertos en peso muerto.

Pero la linealidad también es la trampa. Si quieres 10× la capacidad de conocimiento, necesitas 10× el computo por token. No hay almuerzo gratis — a menos que cambies la arquitectura.

Cómo el Mixture of Experts Cambia la Ecuación

Una capa MoE reemplaza esa única FFN con un banco de redes “expertas” independientes y un pequeño router (red de compuerta). Para cada token, el router calcula una puntuación para cada experto, selecciona los top-k, y solo esos k expertos procesan el token. El resto duerme.

La Anatomía de una Capa MoE

Tomemos Mixtral 8x7B como el ejemplo canónico. En cada capa del Transformer, la FFN estándar se reemplaza por:

• 8 redes expertas, cada una una FFN SwiGLU independiente
• Un router lineal que proyecta el estado oculto del token en 8 puntuaciones
• Una máscara top-2 que anula todas las puntuaciones excepto las dos mejores antes del softmax
• Una suma ponderada de las salidas de los dos expertos seleccionados

El modelo almacena 46.7 mil millones de parámetros en total. Pero por token, solo ~13 mil millones están activos. El costo de cómputo es aproximadamente el de un modelo dense de 13B. El costo de memoria, sin embargo, es el de un modelo de 47B — porque todos los expertos deben residir en VRAM, esperando su turno.

Esto desacopla la capacidad total del computo activo. Es el equivalente arquitectónico de mantener una biblioteca de especialistas en retainer pero solo facturar a los dos que realmente consultas.

El Mecanismo de Enrutamiento en Detalle

Así es como la compuerta decide por token:

router_logits = x · W_g          # x ∈ R^4096, W_g ∈ R^(4096×8)
masked = TopK(router_logits, k=2) # Máscara dura: exactamente 2 expertos sobreviven
g = Softmax(masked)               # Pesos normalizados que suman 1
output = Σ_{i ∈ TopK} g_i · Expert_i(x)

La máscara dura antes del softmax es crítica. Si hicieras softmax primero, cada experto recibiría algún peso y perderías el ahorro computacional. Al enmascarar a menos infinito primero, fuerzas la verdadera sparseza: exactamente dos expertos se activan, y el resto cuesta cero en FLOPs.

Arquitecturas del Mundo Real: Cómo los Laboratorios de Vanguardia Construyen MoEs

MoE no es un diseño. Es una familia de diseños, y los laboratorios líderes han divergido significativamente en cómo lo implementan.

DeepSeekMoE: El Estado del Arte

La arquitectura de DeepSeek es arguably el diseño MoE más sofisticado documentado públicamente. Introduce dos innovaciones clave más allá del MoE estándar:

Segmentación fina de expertos: En lugar de 8 expertos grandes, DeepSeek-V3 usa 256 pequeños. Cada experto es diminuto, pero el espacio combinatorio explota. Con 8 activos de 256, tienes C(256,8) ≈ 4.3 mil millones de combinaciones posibles — comparado con C(8,2) = 28 para Mixtral. Esto permite al router dirigirse a conocimientos mucho más específicos por token.

Aislamiento de experto compartido: Un experto siempre está activo, independientemente del enrutamiento. Absorbe conocimiento común — gramática, sintaxis, hechos básicos — liberando a los 256 expertos enrutados para especializarse en dominios distintos y no superpuestos. Sin esto, cada experto aprendería redundantemente las mismas cosas “fáciles”.

¿El resultado? DeepSeek-V3 iguala el rendimiento de vanguardia con solo 37 mil millones de parámetros activos de 671 mil millones totales — una sparseza de ~5.5%. DeepSeek-V4-Pro lo empuja más allá: 1.6T parámetros totales, 49B activos, ~3.1% de sparseza.

El Problema de Estabilidad del Entrenamiento

Los MoE no se entrenan solos. El router es un interruptor discreto en un paisaje de optimización continua, y sin intervención, un bucle de retroalimentación colapsa casi todos los tokens en uno o dos expertos “estrella” mientras el resto atrofia.

La solución clásica es una pérdida auxiliar de balanceo de carga:

loss_bal = α · N · Σ_i (f_i · P_i)

Donde f_i es la fracción de tokens realmente enviados al experto i, y P_i es la probabilidad promedio de enrutamiento para el experto i. Esto penaliza el desequilibrio. DeepSeek más tarde reemplazó esto con balanceo de carga sin pérdida auxiliar: un término de sesgo dinámico por experto que empuja al router hacia expertos subutilizados sin interferir con el gradiente de la tarea. Es una optimización primal-dual disfrazada, y es una de las razones por las que DeepSeek entrena establemente a escala extrema.

La Economía de Inferencia: Donde Mueren los Mitos

Aquí es donde la mayoría de las comparaciones fallan. La gente dice “Mixtral 8x7B tiene 13B parámetros activos, así que corre como un modelo de 13B.” No lo hace. Y dicen “tiene 47B parámetros, así que cuesta como un modelo de 47B.” Tampoco hace eso.

La verdad depende del régimen, y las matemáticas son sutiles.

La Fórmula de Equivalente Dense

Epoch AI propuso una heurística para mapear el costo de inferencia MoE a un equivalente dense:

Equivalente Dense ≈ Params Totales / (Expertos^0.44 / Expertos_Activos^0.63)

Aplicando esto:

• Mixtral 8x22B (141B total, 8 expertos, 2 activos) → se comporta como un ~90B modelo dense en decodificación rápida de contexto corto
• GPT-4 (~1.76T total, 8 expertos, 2 activos) → costos de inferencia combinados más cercanos a un ~950B equivalente dense

Prefill vs. Decodificación: Dos Mundos Diferentes

Prefill y batches grandes (batch size 32+): La carga de trabajo está limitada por computo. El MoE brilla. Estás haciendo multiplicaciones de matrices, y el MoE hace menos porque la mayoría de los expertos están inactivos. Los 37B parámetros activos de DeepSeek-V3 realmente importan aquí.

Decodificación rápida y batches pequeños (batch size 1-4): La carga de trabajo está limitada por ancho de banda de memoria. La GPU pasa más tiempo leyendo pesos que computando. La ventaja de FLOPs del MoE se evapora porque todos los parámetros aún deben residir en memoria y ser leídos. El router agrega overhead. La comunicación all-to-all entre GPUs para reunir salidas de expertos agrega latencia. En este régimen, un modelo dense con la misma cuenta de parámetros activos suele ser más barato de servir.

La Memoria Es el Impuesto Oculto

Dense 70B en FP16: ~140 GB VRAM. Mixtral 8x7B (47B total, 13B activos): ~94 GB VRAM.

Ahorraste computo, pero no ahorraste tanta memoria como la cuenta de parámetros activos sugiere. Los 47B parámetros totales deben residir. Si estás sirviendo en dispositivos edge o configuraciones de GPU única, la huella de memoria del MoE es una restricción genuina.

Pros y Contras: Una Perspectiva de Sistemas

Modelos Dense

Ventajas:

• Costo predecible. Cada token cuesta lo mismo. Sin sorpresas de enrutamiento, sin colapso de expertos.
• Menor huella de memoria para la misma calidad activa. Un modelo dense de 13B cabe donde un MoE de 47B parámetros no.
• Mejor para razonamiento. Con parámetros totales iguales, los modelos dense superan a los MoE en matemáticas, lógica y benchmarks de código. El razonamiento escala con el ancho activo, no con la cuenta total de parámetros.
• Entrenamiento y fine-tuning más simples. Sin pérdidas de balanceo de carga, sin jitter del router, sin riesgo de “deriva de expertos” durante el fine-tuning.

Desventajas:

• Escalamiento lineal de computo. Duplicar el conocimiento requiere duplicar los FLOPs activos.
• Memorización ineficiente. Para igualar la capacidad de conocimiento mundial de un MoE, un modelo dense debe escalar proporcionalmente su tamaño activo, lo cual es computacionalmente derrochador.
• Neuronas polisemánticas. Las neuronas individuales en modelos dense a menudo codifican múltiples características no relacionadas, haciendo la interpretabilidad más difícil.

Mixture of Experts

Ventajas:

• Escalamiento masivo de parámetros sin computo proporcional. DeepSeek-V3 accede a 671B parámetros al costo de ~37B activos.
• Memorización y recuperación de conocimiento superiores. Los MoE dominan en trivia, preguntas naturales y benchmarks multilingües con costos de entrenamiento iguales.
• Interpretabilidad potencial. Evidencia emergente sugiere que los expertos se organizan en representaciones coherentes y especializadas — “monosemánticas” — en contraste con el caos polisemántico de las redes dense.
• Mayor eficiencia de entrenamiento. Bajo leyes de escalamiento conjuntas, un MoE bien configurado puede superar a un modelo dense con la misma huella de memoria entrenando en más tokens.

Desventajas:

• Inferior capacidad de razonamiento con el mismo tamaño total. Los MoE subperformer en matemáticas y lógica a menos que su cuenta de parámetros activos sea competitiva.
• Inestabilidad del entrenamiento. Gradientes sparse, colapso del router y balanceo de carga son desafíos de ingeniería persistentes.
• Mayor overhead de memoria y comunicación. Todos los parámetros deben residir. La comunicación all-to-all multi-GPU puede consumir ~32% del tiempo de entrenamiento de reloj de pared.
• Fragilidad en fine-tuning. La deriva del router durante la adaptación de dominio puede degradar el rendimiento si no se gestiona cuidadosamente.

Cuándo Elegir Qué

Si estás tomando esta decisión para tu stack, aquí está mi framework de decisión:

La intuición más importante: el MoE no es universalmente más barato. Es más barato en FLOPs por token, pero los FLOPs no son la única factura que pagas. El ancho de banda de memoria, la comunicación entre GPUs y la complejidad de ingeniería escalan con los parámetros totales. Si tu stack de servicio está limitado por memoria — que la mayoría de las APIs en tiempo real lo están — un modelo dense con parámetros activos competitivos a menudo gana en costo total de propiedad.

El Camino del Medio: Entrenamiento Denso, Inferencia Sparse

Uno de los desarrollos más interesantes de 2024-2025 es el paradigma DS-MoE: entrenar con todos los expertos activos (entrenamiento denso), luego cambiar a inferencia sparse top-K. Esto da gradientes de calidad dense durante el entrenamiento — sin problemas de gradientes sparse — mientras preserva los ahorros de computo del MoE en tiempo de servicio. Los modelos entrenados de esta manera igualan el rendimiento dense con la misma cuenta total de parámetros y corren 1.5–1.9× más rápido en inferencia.

De manera similar, upcycling — convertir un checkpoint dense preentrenado en un MoE dividiendo sus pesos FFN en fragmentos de expertos — se ha convertido en una ruta de migración práctica. Nemotron-4 15B de NVIDIA, convertido a MoE por upcycling, superó el entrenamiento denso continuo en el mismo presupuesto de tokens (67.6% vs. 65.3% MMLU). Si tienes un modelo dense en el que ya confías, el upcycling puede ser una opción de menor riesgo que entrenar un MoE desde cero.

La Línea de Fondo

El debate dense vs. MoE no es una guerra religiosa. Es una compensación de ingeniería, y la respuesta correcta depende de por qué recurso estás restringido.

Si estás restringido por computo — entrenando a escala masiva o sirviendo batches grandes — el MoE es atractivo. Te da la capacidad de conocimiento de un modelo muchas veces más grande que los FLOPs que realmente pagas.

Si estás restringido por memoria o sensible a latencia — despliegue edge, APIs de batch pequeño, o inferencia de GPU única — los modelos dense siguen siendo más simples, más predecibles y a menudo más rentables.

Los laboratorios de vanguardia no están eligiendo uno u otro. Están usando el MoE como el andamiaje para sistemas de billones de parámetros, mientras refinen submódulos dense para rutas críticas de razonamiento. La próxima generación de modelos probablemente será híbrida — no puramente sparse, no puramente dense, sino arquitecturas que enrutan inteligentemente entre ambas.

Tu trabajo como arquitecto de sistemas es saber dónde vive tu cuello de botella. Porque en la infraestructura de IA, la arquitectura que eliges no es solo una decisión de modelo. Es una decisión de asignación de capital.

Referencias

• Mixtral of Experts — Mistral AI
• Epoch AI — MoE vs Dense Models in Inference
• DeepSeekMoE: Towards Ultimate Expert Specialization
• DeepSeek-V3 Technical Report
• Switch Transformers: Scaling to Trillion Parameter Models
• Dense Training, Sparse Inference (DS-MoE)
• Upcycling Large Language Models into Mixture of Experts
• Joint MoE Scaling Laws
• MoE Architecture Comparison: GPT, Claude, DeepSeek, Qwen