La arquitectura Mixture of Experts (MoE) dejó de ser solo una técnica académica y pasó a aparecer en modelos comerciales, open-weight y enterprise. El motivo es simple: permite aumentar la capacidad total del modelo sin activar todos los parámetros en cada token. En la práctica, esto abre camino para modelos más grandes, con mejor relación entre calidad, costo de inferencia y throughput.
Este e-book mapea a los principales players que públicamente asociaron sus modelos a MoE, explica cómo funciona la arquitectura y traduce el tema a estrategia de infraestructura, LLMaaS, agentes, data center y operación empresarial.
Lectura ejecutiva: MoE no significa automáticamente "mejor modelo". Significa una forma diferente de escalar: parte del modelo queda especializada y solo una fracción es activada por token. La ganancia depende del entrenamiento, del enrutamiento, de los datos, del balanceo de los especialistas, de la memoria, de la red y del stack de serving.
Estado de los players: Google, Meta, Mistral, Alibaba/Qwen, DeepSeek, xAI, Databricks, Snowflake, AI21, Moonshot/Kimi y MiniMax cuentan con divulgaciones públicas que asocian modelos relevantes a MoE. OpenAI y Anthropic se tratan en este material como N/D públicamente, ya que no confirman abiertamente la arquitectura de sus modelos frontier actuales.
Qué es MoE en LLMs
En un modelo denso tradicional, la mayor parte de los pesos relevantes participa en el procesamiento de cada token. En un modelo MoE, ciertas capas son sustituidas por un conjunto de especialistas, normalmente redes feed-forward especializadas. Un router elige qué especialistas deben procesar cada token, frecuentemente usando top-1, top-2, top-4 o top-k.
La diferencia conceptual más importante es separar parámetros totales de parámetros activos. Un modelo puede tener cientos de miles de millones o incluso billones de parámetros totales, pero activar solo una fracción por token. Esto reduce el costo computacional por paso de inferencia, aunque la memoria, la red y la orquestación todavía deben tratar al modelo como un sistema distribuido.
Fórmula mental: el modelo denso escala activando casi todo. MoE escala aumentando la capacidad total, pero accionando especialistas según el token y la tarea. En vez de "un cerebro gigante siempre entero", piense en "un panel de especialistas con enrutador".
Componentes centrales
- Router/Gate: calcula qué especialistas deben recibir cada token.
- Experts: subredes especializadas, generalmente MLPs/feed-forward, con pesos independientes.
- Top-k: número de especialistas seleccionados por token.
- Load balancing: mecanismo para evitar que pocos experts queden sobrecargados.
- Expert parallelism: técnica para distribuir especialistas entre GPUs/nodos.
Línea de tiempo: de la investigación a la producción
La idea de computación condicional antecede a los LLMs modernos, pero ganó tracción con la capa Sparsely-Gated Mixture-of-Experts propuesta en 2017, que mostró cómo aumentar la capacidad sin un crecimiento proporcional del costo computacional. Después, trabajos como Switch Transformer simplificaron el enrutamiento y demostraron modelos esparsos a escala de billones de parámetros.
| Período | Hito | Impacto |
|---|---|---|
| 2017 | Sparsely-Gated MoE | Populariza la capa de especialistas con gate entrenable y computación condicional. |
| 2021-2022 | Switch Transformer / GShard | Simplificación del enrutamiento y prueba de escala en modelos muy grandes. |
| 2023-2024 | Mixtral, Grok-1, DBRX, Arctic, Jamba | MoE pasa a aparecer en modelos abiertos, enterprise y APIs comerciales. |
| 2025-2026 | DeepSeek-V3, Qwen3, Llama 4, Kimi K2, MiniMax | La disputa pasa a involucrar parámetros activos, costo de inferencia, agentes y long context. |
El punto crítico para las empresas es que MoE no es solo una elección de arquitectura de modelo. También altera el diseño de la infraestructura: más dependencias entre GPUs, mayor importancia de la red de baja latencia, necesidad de orquestar especialistas y mayor complejidad en el monitoreo de latencia por token.
Players LLM x MoE
La tabla a continuación separa los modelos con MoE públicamente declarado de aquellos cuyo uso de MoE no fue confirmado. Para modelos cerrados, el hecho de que existan rumores en el mercado no debe tratarse como evidencia técnica. En posicionamiento corporativo, lo correcto es usar "confirmado públicamente" o "no divulgado".
| Player | Modelo/familia | MoE público | Parámetros divulgados | Lectura estratégica |
|---|---|---|---|---|
| Gemini 1.5 | Sí | Arquitectura MoE anunciada; detalles de parámetros no abiertos. | MoE en modelo comercial de gran escala y contexto largo. | |
| Meta | Llama 4 Scout / Maverick | Sí | Scout: 17B activos, 16 experts; Maverick: 17B activos, 128 experts. | Open-weight multimodal con MoE, fuerte para ecosistema e integradores. |
| Mistral AI | Mixtral 8x7B / 8x22B | Sí | 8x7B: 47B totales, 13B activos. | Referencia open-weight para uso eficiente y deployment flexible. |
| Alibaba / Qwen | Qwen3-235B-A22B / 30B-A3B | Sí | 235B totales, 22B activos; 30B totales, 3B activos. | MoE abierto con foco en razonamiento, código y multilingüismo. |
| DeepSeek | DeepSeek-V3 | Sí | 671B totales, 37B activos por token. | Ejemplo de escala agresiva con costo activo menor. |
| xAI | Grok-1 | Sí | 314B parámetros; 25% activos por token. | Open-weight grande, relevante como referencia de MoE cerrado/abierto. |
| Databricks | DBRX | Sí | 132B totales, 36B activos; 16 experts, elige 4. | MoE enterprise integrado a stack de datos y entrenamiento corporativo. |
| Snowflake | Arctic | Sí | 480B totales, 17B activos; Dense-MoE hybrid. | LLM enterprise con foco en eficiencia y workloads de datos. |
| AI21 | Jamba / Jamba 1.5 | Sí | Arquitectura híbrida Transformer-Mamba-MoE. | Long context y eficiencia con diseño híbrido. |
| Moonshot AI | Kimi K2 | Sí | 1T total, 32B activos. | MoE orientado a agentes, código y tool-use a escala abierta. |
| MiniMax | MiniMax-Text-01 / M1 | Sí | 456B totales, 45.9B activos. | Long context y razonamiento con arquitectura híbrida + MoE. |
| OpenAI | GPT-4o / GPT-4.1 / otros | N/D | Arquitectura no divulgada públicamente. | Evitar afirmar MoE sin confirmación oficial. |
| Anthropic | Claude | N/D | Arquitectura no divulgada públicamente. | Tratar como modelo cerrado sin especificación pública de MoE. |
Observación: los números anteriores deben usarse como fotografía de mercado basada en divulgaciones públicas. En modelos cerrados, los rumores de arquitectura no sustituyen la fuente oficial, el paper técnico, la model card o el repositorio publicado por el proveedor.
Lectura de los principales players
Google — Gemini 1.5
Google afirmó que Gemini 1.5 usa una nueva arquitectura MoE para mejorar la eficiencia de entrenamiento y serving. El caso es estratégico porque asocia MoE a modelos multimodales y de contexto largo en entorno comercial vía Google AI Studio y Vertex AI.
Meta — Llama 4
Meta declaró que Llama 4 Scout y Maverick son sus primeros modelos Llama construidos con MoE. La combinación de multimodalidad, open-weight y especialistas coloca a la familia Llama en una posición importante para integradores.
Mistral — Mixtral
Mixtral 8x7B popularizó MoE open-weight. El modelo tiene 47B parámetros totales y 13B activos, convirtiéndose en un ejemplo didáctico de cómo MoE separa la capacidad total y el costo activo.
DeepSeek — V3
DeepSeek-V3 es uno de los ejemplos más citados de escala MoE: 671B parámetros totales y 37B activados por token. El interés del mercado proviene de la relación entre desempeño, costo y arquitectura lo suficientemente abierta para el análisis técnico.
Qwen — Qwen3 MoE
La familia Qwen3 trajo variantes densas y MoE. El Qwen3-235B-A22B, con 235B totales y 22B activos, se convirtió en referencia para el uso open-weight en razonamiento, código y aplicaciones multilingües.
Databricks y Snowflake
DBRX y Arctic muestran que MoE también es un tema enterprise: no solo para chat, sino para datos, SQL, RAG, gobernanza, entrenamiento personalizado y modelos corporativos.
Moonshot/Kimi y MiniMax
Kimi K2 y MiniMax-M1/Texto-01 muestran una tendencia fuerte en modelos abiertos y asiáticos: MoE, long context, foco en agentes, código y tool-use con parámetros activos controlados.
Dense x MoE
La decisión entre modelos densos y MoE no es binaria. En muchos entornos, el mejor portafolio combina modelos densos pequeños para tareas de baja complejidad, modelos densos grandes para previsibilidad y modelos MoE para workloads de alta capacidad, agentes, código, long context o escenarios de alto throughput.
| Criterio | Modelo denso | Modelo MoE |
|---|---|---|
| Costo por token | Más directamente proporcional al tamaño activo del modelo. | Puede ser menor de lo que el tamaño total sugeriría, ya que activa pocos especialistas. |
| Memoria | Normalmente necesita cargar el modelo completo, pero la arquitectura y el serving son más simples. | También necesita gestionar muchos pesos; la memoria y la distribución de los experts importan mucho. |
| Latencia | Más previsible en lotes pequeños. | Puede oscilar por enrutamiento, balanceo, comunicación all-to-all y caché. |
| Calidad | Buena estabilidad y simplicidad operacional. | Puede ganar capacidad y especialización, pero depende de un enrutamiento y entrenamiento bien balanceados. |
| Operación | Más fácil para equipos más pequeños. | Exige un stack maduro: expert parallelism, observabilidad y red de alto rendimiento. |
| Mejor uso | Clasificación, resumen, atención, tareas estandarizadas, edge o menor costo. | Agentes, código, reasoning, long context, alto throughput y modelos más grandes. |
Error común: no venda MoE como "IA que piensa con varios cerebros" sin explicar el costo, el enrutamiento y los parámetros activos. La narrativa correcta para negocios es eficiencia de escala: más capacidad potencial con computación selectiva.
Infraestructura para ejecutar MoE
Desde el punto de vista de infraestructura, MoE es atractivo porque reduce los parámetros activos por token, pero no elimina la necesidad de memoria para pesos, red de alta velocidad y orquestación. El costo real depende del batch size, del tamaño de contexto, de la precisión de los pesos, de la cuantización, del KV cache, de la comunicación entre GPUs y de la distribución de los experts.
Capas de infraestructura crítica
- GPU y memoria: modelos con cientos de miles de millones de parámetros exigen memoria agregada, incluso cuando pocos parámetros están activos por token.
- Red de baja latencia: el expert parallelism puede generar comunicación all-to-all entre GPUs y nodos.
- Serving engine: vLLM, TensorRT-LLM, SGLang, TGI y stacks propietarios necesitan soportar un enrutamiento eficiente.
- Cuantización: FP8, INT8, INT4 y variantes reducen la memoria, pero exigen pruebas de calidad.
- Observabilidad: medir tokens/s, TTFT, latencia p95/p99, uso de experts, errores, costo por millón de tokens y saturación de red.
- Datos y storage: RAG, logs, datasets, checkpoints y objetos necesitan storage de alta capacidad y gobernanza.
| Capa | Función | Punto de atención |
|---|---|---|
| Compute GPU | Ejecutar experts, atención y MLPs | VRAM, NVLink, PCIe, FP8/INT8, multi-GPU |
| Red | Sincronizar experts y lotes | InfiniBand/Ethernet 100/200/400G, latencia, all-to-all |
| Storage | Model weights, snapshots, datasets, RAG | S3, NFS/Lustre, throughput, versionamiento |
| Serving | Cola, batching, caché, enrutamiento | Autoscaling, p95/p99, fallback, costo por token |
| Gobernanza | Seguridad, auditoría, LGPD, datos | Aislamiento por cliente, logs, encriptación, IAM |
Implicación para el data center: MoE aumenta la importancia de la conectividad interna de alta capacidad, la energía previsible, el enfriamiento adecuado, un clúster GPU bien diseñado y storage escalable. Para ofertas de LLMaaS y bare metal GPU, la arquitectura del data center pasa a ser parte del producto.
Impacto para negocios y productos de IA
Para el cliente final, la sigla MoE solo importa cuando mejora resultado, costo, latencia o capacidad. El papel de una empresa de tecnología es traducir la arquitectura a beneficios concretos: automatización más rápida, agentes más precisos, menor costo de inferencia e infraestructura más adecuada.
Aplicaciones con mayor adherencia
- LLMaaS corporativo: ofrecer modelos vía API con control de costo, aislamiento y observabilidad.
- Agentes de IA: ejecutar tareas con herramientas, memoria, RAG, workflows y gobernanza.
- RAG empresarial: combinar modelos MoE con bases documentales, contratos, tickets, CRM y datos internos.
- Vibe coding y automatización: usar modelos fuertes en código para acelerar el desarrollo e integraciones.
- Atención y copilotos: usar enrutamiento entre modelos: pequeños para tareas simples, MoE para tareas complejas.
| Oferta | Mensaje comercial | Entregable posible |
|---|---|---|
| LLMaaS | IA escalable con costo por token controlado. | API gestionada, dashboard, límites, logs, modelos por perfil. |
| GPU Bare Metal | Infraestructura dedicada para modelos abiertos y MoE. | Clústeres H100/H200/MI300, red, storage, soporte. |
| RAG Empresarial | Conocimiento interno con seguridad y auditoría. | Pipeline de datos, vectorial, S3/NFS, políticas LGPD. |
| Agentes | Workflows inteligentes con gobernanza. | Agentes por departamento, tool-use, aprobaciones, informes. |
| Consultoría IA | Elección técnica entre dense, MoE y modelos cerrados. | Assessment, POC, benchmark y plan de producción. |
Recomendaciones para EnQ Digital
EnQ Digital puede usar el tema "Players LLM x MoE" como contenido de autoridad para conectar tres narrativas: tecnología de IA, infraestructura de data center y transformación digital. El diferencial está en explicar la arquitectura de forma ejecutiva y, al mismo tiempo, mostrar dominio técnico de GPU, red, storage, cloud privada y LLMaaS.
Plan de contenido recomendado
- Post 1: "¿Qué es MoE?" — analogía de los especialistas y el router.
- Post 2: "Players LLM x MoE" — tabla con confirmados públicamente.
- Post 3: "¿Por qué MoE cambia el costo de la IA?" — parámetros totales x activos.
- Post 4: "Infra para IA" — GPU, red, storage, energía y cooling.
- Post 5: "Cómo ayuda EnQ" — LLMaaS, bare metal, cloud, colocation y conectividad.
Propuesta de valor (mensaje clave para ventas): EnQ Digital conecta IA, cloud, data center y conectividad para empresas que quieren transformar modelos de lenguaje en productos reales, con infraestructura segura, escalable y observable.
Checklist para una POC MoE/LLM
- Definir caso de uso: RAG, agente, atención, código, análisis de documentos o automatización.
- Seleccionar modelos: cerrado, open-weight, dense pequeño, dense grande o MoE.
- Medir calidad: precisión, alucinación, adherencia a instrucciones, seguridad y benchmark interno.
- Medir operación: latencia p95/p99, tokens/s, TTFT, costo por millón de tokens y uso de GPU.
- Validar gobernanza: LGPD, aislamiento, logs, encriptación, IAM y retención de datos.
- Proyectar escala: capacidad de GPU, storage, red, backup, observabilidad y soporte.
Glosario esencial
| Término | Definición objetiva |
|---|---|
| MoE | Mixture of Experts: arquitectura que divide partes del modelo en especialistas y activa solo algunos por token. |
| Router/Gate | Componente que decide qué especialistas procesan cada token. |
| Parámetro total | Cantidad total de pesos del modelo, incluyendo experts que pueden no ser activados en cada token. |
| Parámetro activo | Cantidad de parámetros usados para procesar un token o entrada en una pasada. |
| Top-k | Número de especialistas elegidos por el enrutador por token. |
| Expert parallelism | Distribución de los especialistas entre GPUs o servidores para viabilizar el entrenamiento/inferencia. |
| All-to-all | Patrón de comunicación frecuente en MoE cuando los tokens necesitan ser enviados a experts diferentes. |
| KV cache | Memoria usada para acelerar la generación en modelos autoregresivos; crece con el contexto y el batch. |
| Dense model | Modelo en el que la mayor parte de la red relevante se activa de forma uniforme en cada token. |
Fuentes y lectura recomendada
- Shazeer et al. (2017) — Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. arXiv:1701.06538.
- Fedus, Zoph & Shazeer (2021/2022) — Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. arXiv:2101.03961 / JMLR.
- Google — Introducing Gemini 1.5, Google's next-generation AI model. Blog oficial de Google.
- Mistral AI — Mixtral 8x7B model card y "Mixtral of Experts". Docs y publicación oficial de Mistral.
- DeepSeek — Introducing DeepSeek-V3 y DeepSeek-V3 Technical Report.
- Qwen / Alibaba — Qwen3 blog, Qwen3 Technical Report y model cards Qwen3-235B-A22B.
- Meta — The Llama 4 herd: natively multimodal AI innovation. Blog oficial Meta AI y model cards Llama 4.
- xAI — Open Release of Grok-1 y repositorio xai-org/grok-1.
- Databricks — Introducing DBRX: A New State-of-the-Art Open LLM. Blog oficial Databricks.
- Snowflake — Snowflake Arctic: enterprise-grade LLM y dense-MoE hybrid architecture.
- AI21 — Jamba: Hybrid Transformer-Mamba MoE architecture. AI21 research/blog.
- Moonshot AI — Kimi K2 technical report, GitHub/Hugging Face y plataforma Kimi API.
- MiniMax — MiniMax-Text-01 / MiniMax-M1 repositorios, model cards y reportes técnicos.
- OpenAI — GPT-4 Technical Report: arquitectura y detalles de entrenamiento no divulgados en el reporte público.
Nota de verificación: el mapa de players debe revisarse periódicamente. Los proveedores alteran nomenclatura, disponibilidad, precios, contexto, endpoints y licencias. Para una propuesta comercial, validar siempre la model card y los términos de uso vigentes del proveedor.