MoE inference: el call center con 256 especialistas y 8 atendiendo cada llamada — fundamentos, expert parallel y la economía de DeepSeek-V3

Este post entra en una decisión arquitectónica de la etapa Deploy del pipeline LLMOps de seis etapas. Complementa los de KV cache (que no cambia con MoE), FlashAttention (que sigue siendo el kernel de la atención, también dense en todos los MoE actuales), Quantization (FP8/NVFP4 sobre expert weights es lo que permite que DeepSeek-V3 entre en un cluster modesto) y Speculative decoding (MTP en DeepSeek-V3 es speculative decoding nativo).

Estás aquí: DEPLOY

TL;DR

Un Mixture of Experts (MoE) sustituye la capa FFN dense del transformer por N expertos paralelos más un router que selecciona los k expertos relevantes para cada token. La consecuencia operacional es que los parámetros totales del modelo (cuántos se han entrenado y cuántos hay que cargar en VRAM) se desacoplan de los parámetros activos por token (cuántos participan en cada forward). DeepSeek-V3 tiene 671 B totales pero solo 37 B activos por token; Qwen3-235B-A22B son 235 B totales y 22 B activos; Mixtral 8x22B son 141 B y 39 B; Llama 4 Maverick son 400 B y 17 B. El compute por token cae a 2·N_active FLOPs —la mitad del de un Llama-3-70B dense, en el caso de DeepSeek-V3—, pero la memoria sigue siendo proporcional a N_total: la sparsity del MoE es sparsity de compute, no de memoria. Como cada experto ve solo batch·k/N tokens por step, el régimen memory-bound persiste a batch mucho más alto que en dense. Servir DeepSeek-V3 671 B FP8 con baja latencia requiere expert parallel (EP) a escala —EP=32 en prefill y EP=144 en decode en el despliegue de DeepSeek de producción— donde el cuello dominante deja de ser HBM y pasa a ser el all-to-all del dispatch y combine entre GPUs. En mayo de 2026, las piezas que hacen viable esto son DeepEP (kernels CUDA all-to-all FP8-native, intra-nodo NVLink + inter-nodo RDMA), EPLB (balanceo replicando experts hot) y Wide-EP sobre NVL72 (72 GPUs en un dominio NVLink coherente). Este post desmonta el mecanismo, la matemática (FLOPs/token, bytes de all-to-all), la tabla actualizada de modelos MoE mayo 2026, los paralelismos (TP / EP / DP+EP / Wide-EP), los pitfalls operacionales (memory wall, cold experts, imbalance) y los números reales reproducibles en H100, B200 y GB200 NVL72.

La analogía: el call center con 256 especialistas

Un call center serio que atiende consultas técnicas complejas funciona con especialistas, no con generalistas. Tienes 256 operadores en plantilla, cada uno experto en su sub-dominio: jurídico-laboral, hipotecas, IRPF, sucesiones, etc. Pero cada llamada que entra solo necesita atención de ocho especialistas concretos (top-8 routing): la consulta de un cliente sobre desgravación de una hipoteca para su segunda vivienda hereda implica al de IRPF, al de hipotecas, al de plusvalías, etc. La recepcionista (el router) escucha el primer segundo de la llamada, decide cuáles son los ocho especialistas relevantes, los conecta en conferencia y combina sus respuestas con pesos.

Tres consecuencias inmediatas, idénticas a las del MoE en producción:

1. Pagas los 256 sueldos (todos los expertos están cargados en VRAM) pero solo gastas tiempo de 8 (solo k expertos participan en el forward de cada token). Tu coste de plantilla escala con N_total; tu coste por minuto de llamada escala con N_active.
2. Si todos los operadores caben en una oficina (una sola GPU), perfecto: solo hay que pasar el papel entre escritorios. Pero si no caben, hay que abrir sedes: la conferencia entre operadores de sedes distintas pasa por línea telefónica entre edificios (NVLink intra-nodo, InfiniBand inter-nodo) y esa línea se vuelve el cuello dominante cuando hay decenas de sedes coordinándose.
3. Si una semana los clientes preguntan todos por IRPF, los tres operadores de IRPF saturan mientras los de sucesiones se aburren. Necesitas un sistema que replique a los operadores hot en varias sedes para absorber picos, y que emparejen hot con cold para que ninguna sede idleice.

La recepcionista es el router. Las sedes son las GPUs. La conferencia entre sedes es el all-to-all (dispatch + combine). El sistema de replicación de operadores hot es EPLB. La línea telefónica buena es DeepEP. Y cuando alguien diseña un edificio donde caben las 72 sedes juntas con cables internos rapidísimos, eso es NVL72.

El mecanismo desnudo

Una capa MoE clásica reemplaza el FFN dense (y = FFN(x) = down(act(up(x) · gate(x))) en SwiGLU) por:

1. Router: una proyección lineal g(x) = W_router · x produce N scores. Sobre esos scores se aplica softmax para tener probabilidades de afinidad.
2. Selección top-k: se eligen los k expertos con score más alto. Sus pesos softmax_topk se normalizan a suma 1.
3. Compute en paralelo: cada uno de los k expertos seleccionados ejecuta su FFN propio sobre x. Los N - k no seleccionados quedan ociosos para este token.
4. Combinación ponderada: la salida es y = Σ_{i ∈ topk} w_i · Expert_i(x).

Variantes que el mercado consolidó en 2025-2026:

• Shared experts: además de los k routed, hay s expertos que siempre se ejecutan (1 o 2). Capturan conocimiento general que todos los tokens necesitan. DeepSeek-V3 usa 1 shared + 8 routed; Mixtral usa 0 shared.
• Fine-grained experts: más expertos pequeños en lugar de pocos grandes (DeepSeek: 256 vs Mixtral: 8). Permite mejor especialización porque la combinación top-k cubre más sub-dominios.
• Auxiliary-loss-free routing (DeepSeek-V3): en lugar de añadir un loss de balanceo al entrenamiento, ajusta dinámicamente un bias en el routing. Mantiene balance sin contaminar el loss principal.

La atención sigue siendo dense en todos los modelos MoE actuales (Mixtral, DeepSeek, Qwen3-MoE, Llama 4, Kimi K2). Solo se reemplaza el FFN. Por eso FlashAttention v3/v4 se sigue usando tal cual; MLA de DeepSeek es una optimización ortogonal al MoE.

Los modelos MoE relevantes en mayo 2026

Tres observaciones operacionales:

1. El ratio activos/totales cae con cada generación: Mixtral 8x7B era 28 %, DeepSeek-V3 es 5.5 %, Llama 4 Maverick es 4.3 %. Lo que la industria descubrió es que el sparsity puede ser muy agresivo sin perder calidad, siempre que N sea suficientemente grande y el routing esté bien aprendido. La especialización fina vale más que la capacidad por experto.
2. Las cabezas de los proveedores grandes (OpenAI, Anthropic, Google) son MoE casi con seguridad, pero las arquitecturas no se publican. La única filtración semi-creíble (Hotz, jul 2023) afirmaba que GPT-4 era 8×~220 B MoE; sin confirmación oficial.
3. DeepSeek-V3 marca el punto de inflexión: open weights, frontier-class, MoE con sparsity agresivo y compatible con quantization FP8. Es el modelo que forzó al ecosistema (vLLM, SGLang, TensorRT-LLM) a optimizar wide-EP en 2025.

La matemática que importa

Tres números mueven toda la decisión arquitectónica con MoE.

Compute por token. Un transformer dense gasta aproximadamente 2N FLOPs por token en forward (con N = parámetros totales). Un MoE gasta 2·N_active FLOPs por token (los N_total - N_active expertos no participan). Para DeepSeek-V3: 2 × 37 B = 74 GFLOPs/token. Para Llama-3-70B dense: 2 × 70 B = 140 GFLOPs/token. DeepSeek hace la mitad del compute por token que Llama-3-70B, ofreciendo capacidad equivalente a un modelo casi 10 × mayor.

Memoria total. Pero todos los expertos deben estar cargados en VRAM en algún momento del forward. El sparsity es de compute, no de memoria. Memoria de pesos:

$$\text{Memoria}{\text{pesos}} \approx N{\text{total}} \cdot \text{bytes_por_param}$$

Para DeepSeek-V3 FP8 (1 byte): 685 GB. No cabe en 8×H100 SXM (640 GB). Necesitas o quantization adicional o 16+ GPUs. Para Mixtral 8x22B FP8: 141 GB → cabe holgado en 2×H100. Para Qwen3-235B-A22B FP8: 235 GB → cabe en 4×H100.

All-to-all bytes por capa MoE. Cuando los expertos están repartidos entre GPUs (EP), cada token debe viajar a las GPUs donde residen sus k expertos. El volumen por capa MoE es aproximadamente:

$$\text{bytes_a2a/layer} \approx 2 \cdot \text{batch} \cdot \text{seq_len} \cdot d_{\text{model}} \cdot k \cdot \text{bytes}$$

(el factor 2 es dispatch + combine). Para DeepSeek-V3 con d_model = 7168, k = 8, batch = 4096, FP8 (1 byte): cada layer MoE mueve ~470 MB; multiplicado por 61 layers MoE en DeepSeek-V3, el step completo agrega ~29 GB de tráfico inter-GPU solo en MoE comms. Es del orden de la HBM bandwidth de una GPU en un único step. Por eso el ancho de banda y la topología NVLink/InfiniBand determinan cuán grande puede ser EP sin que el comm sature.

Régimen memory-bound persistente. Aquí está la consecuencia menos intuitiva. En dense, subir el batch mueve la operación de memory-bound a compute-bound: con suficientes tokens por batch, los pesos se aprovechan para más operaciones. En MoE, cada experto ve solo batch · k / N tokens. Para Qwen3-235B (k=8, N=128) con batch=128, cada experto procesa 8 tokens por step. Para llegar al régimen compute-bound de los tensor cores (arithmetic intensity ~100-200 FLOPs/byte) se necesitan batches del orden de miles —~1600 según estimaciones recientes para Qwen3 (Memory-Bound MoE Serving, arXiv:2512.09277)—. La consecuencia operacional: MoE escala throughput con batch de forma más lineal que dense, pero también necesita batches mucho mayores para acercarse a su techo de compute.

Expert parallel y el cuello del all-to-all

Hay tres formas principales de paralelizar un MoE entre GPUs:

Tensor Parallel (TP, Megatron-style). Divide cada matriz weight a lo ancho/alto entre GPUs. Cada GPU procesa todos los tokens y todos los layers. Comms por layer: 2 all-reduces. Funciona bien para dense; para MoE deja sin explotar la sparsity del routing (cada GPU mantiene fragmentos de todos los expertos).

Expert Parallel (EP). Divide los expertos enteros entre GPUs: 256 expertos / 32 GPUs = 8 expertos por GPU. Cada token, tras el routing, viaja a las GPUs donde residen sus k expertos top-k. Comms por layer MoE: un all-to-all dispatch (tokens hacia expertos) más un all-to-all combine (outputs de vuelta). El costo crece con el EP-size y se convierte en el cuello cuando EP > 8.

DP + EP / Wide-EP. Replica el modelo en grupos DP; dentro de cada grupo, EP shardea expertos. Wide-EP lleva EP a la dimensión completa de un rack (NVL72, 72 GPUs en dominio NVLink coherente). Cada experto recibe más tokens por step → mejor intensidad aritmética en los GEMMs de cada experto → throughput por GPU sube. vLLM reporta 1.8× throughput por GPU con wide-EP vs setups menores en DeepSeek-V3 (blog vLLM, dic 2025).

Tabla rápida de decisión:

El despliegue de DeepSeek de producción combina Prefill EP=32 (4 nodos × 8 GPUs) con Decode EP=144 (18 nodos × 8 GPUs). La separación prefill/decode encaja conceptualmente con Disaggregated serving: prefill es compute-bound y se beneficia de EP moderado; decode es memory-bound y se beneficia de Wide-EP que aumenta los tokens por experto por step.

DeepEP, EPLB y Wide-EP: las piezas que destrababan 2025

DeepEP (DeepSeek, abierto en febrero 2025) es una librería de kernels CUDA all-to-all optimizada específicamente para MoE EP. Cuatro propiedades importantes:

• FP8 dispatch nativo: los tokens viajan en FP8, reduciendo a la mitad el ancho de banda consumido.
• Mixing intra-nodo NVLink + inter-nodo RDMA: el kernel decide la ruta óptima según topología.
• Bypass de CPU: el dispatch GPU→GPU pasa por RDMA sin tocar el host.
• Alineado con group-limited gating de DeepSeek-V3: el routing prefiere expertos del mismo grupo de nodos cuando es posible, minimizando inter-node traffic.

En 2025 Tencent contribuyó optimizaciones que añadieron +30 % en los kernels normales. Hay un port para ROCm de AMD.

EPLB (Expert Parallelism Load Balancer) resuelve el problema del imbalance en runtime: aunque el modelo esté bien balanceado en distribución global, un batch concreto puede activar mucho ciertos expertos (prompts en un solo idioma, dominio). EPLB replica los expertos hot en varias GPUs (redundant experts) y los empaqueta heurísticamente con cold experts para minimizar varianza de carga. Tiene dos modos: hierarchical (para prefill con EP medio) y global (para decode con Wide-EP). Está integrado en SGLang y vLLM.

Wide-EP en NVL72 es el setup pico de 2026: 72 GPUs Blackwell en un dominio NVLink coherente (1.8 TB/s bidireccional por GPU, intra-rack). Cada experto recibe muchos más tokens por step → mejor intensidad aritmética → mejor throughput por GPU. Combinado con NVFP4 sobre weights de expertos y FP8 sobre attention, SGLang reportó en GB200 NVL72 26 156 tok/s/GPU en prefill y 13 386 tok/s/GPU en decode para DeepSeek-V3 (LMSYS, sep 2025), un 3.8× prefill y 4.8× decode vs H100.

Pitfalls operacionales

Fragmentación de HBM por expert weights. Con EP=8 en 1 nodo, cada GPU mantiene N/8 expertos, cada uno una tupla de matrices (gate, up, down). Si N=256, son 32 FFNs por GPU. El allocator puede fragmentar; en algunos casos hace falta --gpu-memory-utilization más conservador del habitual.

Cold experts. En distribuciones reales algunos expertos se activan <1 % de tokens. EPLB compensa replicando hot, pero los cold se quedan ocupando HBM sin participar — memoria “muerta”. Cuando la demanda real diverge mucho de la distribución de entrenamiento, esto se nota.

Continuous batching. Funciona con MoE pero la batch size efectiva por experto es batch_total · k / N. Con N grande y batch moderado, cada experto ve poquísimos tokens por step. Hace falta batch_total mucho mayor que en dense para igualar el throughput por GPU.

Speculative decoding + MoE. Interactúa bien. La sparsity del MoE mantiene el régimen memory-bound a batch alto, que es justo el régimen donde speculative decoding gana más. DeepSeek-V3 integra MTP (Multi-Token Prediction) — speculative decoding nativo del modelo, sin draft externo, con acceptance ~85-90 % en el segundo token (ver Speculative decoding para el mecanismo).

MLA y FlashMLA, no son MoE. DeepSeek-V3 combina MoE con Multi-head Latent Attention (MLA), una variante de atención que reduce el KV cache ~10× respecto a MHA estándar. MLA y MoE son ortogonales: MLA optimiza la atención, MoE optimiza el FFN. Para serving de DeepSeek se usa el kernel FlashMLA específico (no FA3 directamente).

DSA (DeepSeek Sparse Attention) en DeepSeek-V3.2-Exp (sep 2025) introduce sparsity también en attention. Primera vez en frontier que la sparsity es a la vez en attention y FFN.

Implicaciones en hardware on-premise

En una RTX 4090 (24 GB). Los MoE grandes están fuera de alcance. Lo que sí entra: Mixtral 8x7B AWQ-INT4 (~24 GB pesos, sin margen para KV cache → realmente requiere TP=2 sobre dos 4090); DeepSeekMoE 16B BF16 (~33 GB, no cabe entero; INT4 ~8 GB, cabe con margen). El caso interesante es llama.cpp con --n-cpu-moe: offload de expert weights a RAM (CPU), atención y shared experts en GPU. Permite correr DeepSeek-V3 IQ4 (~400 GB) en una workstation con 1-2 GPUs + 512 GB de RAM con throughput modesto pero abre la puerta a un setup low-budget.

En un cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo). Aquí entran cómodamente:

• Mixtral 8x22B FP8 (~141 GB) con TP=2 o EP=4. Latencia baja, throughput excelente.
• Qwen3-235B-A22B FP8 (~235 GB) con TP=4 o EP=4. Cabe holgado.
• Llama 4 Scout 109B FP8 (~110 GB) con TP=2 o TP=4. Diseñado por Meta para servir bien en un nodo H100.

Lo que no cabe en 4×H100: DeepSeek-V3 FP8 (~685 GB) sin quant agresiva. Opciones: (1) escalar a 8-16 H100; (2) usar AWQ INT4 sobre routed experts + FP16 sobre activated (~400 GB) que cabe en 8×H100; (3) esperar Blackwell o usar AMD MI300X (192 GB/GPU → DeepSeek-V3 FP8 en 4×MI300X).

La regla de pulgar en mayo 2026: un nodo de 4×H100 sirve cómodamente MoEs hasta ~200 B totales en FP8; para DeepSeek-V3 hay que escalar a 2 nodos o esperar B200 NVL72 (donde el modelo entero entra con espacio para batches enormes).

Lo que no hemos cubierto

• MLA y FlashMLA en detalle: optimización de KV cache de DeepSeek, ortogonal al MoE.
• DeepSeek Sparse Attention (DSA) introducido en V3.2-Exp: la primera implementación productiva de sparsity en attention para frontier models.
• MoE durante entrenamiento: load balancing losses, drop policies, auxiliary terms vs aux-loss-free, MuonClip de Kimi K2.
• MoE + LoRA: cómo se hace fine-tuning de adapters sobre un MoE, qué pasa con el routing.
• LLM-d y otras plataformas open-source que materializan Wide-EP en Kubernetes.

Ver también

• KV cache: la memoria de trabajo — el KV cache estructuralmente es igual que en dense (la atención es dense en todos los MoE actuales); MLA es la optimización específica que DeepSeek aporta encima.
• PagedAttention deep dive — el manejo del KV cache en bloques físicos sigue siendo idéntico bajo MoE; solo el FFN cambia.
• FlashAttention v1/v2/v3/v4 — el kernel de attention se reusa tal cual; FlashMLA es la variante específica para MLA de DeepSeek que añade un paso de compresión latente al patrón FA.
• Quantization para inferencia LLM — FP8/NVFP4 sobre expert weights es lo que hace que DeepSeek-V3 entre en un cluster modesto y que NVL72 alcance sus números pico.
• Speculative decoding — MTP en DeepSeek-V3 es speculative decoding nativo; el régimen memory-bound persistente del MoE hace que speculative gane más en MoE que en dense a batch medio.
• Disaggregated serving: prefill y decode — el despliegue real de DeepSeek separa pools de prefill (EP=32) y decode (EP=144); la disaggregation es prerrequisito para Wide-EP.
• Continuous batching — la otra cara de la moneda. MoE necesita batches mucho mayores que dense para igual throughput por GPU porque cada experto ve batch · k / N tokens por step; el scheduler iterativo es lo que lo hace viable a escala.
• El pipeline LLMOps de seis etapas — el mapa maestro donde Deploy es la etapa 4.

Referencias

• Shazeer, N. et al. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. ICLR 2017. https://arxiv.org/abs/1701.06538
• Lepikhin, D. et al. GShard: Scaling Giant Models with Conditional Computation. ICLR 2021. https://arxiv.org/abs/2006.16668
• Fedus, W., Zoph, B., Shazeer, N. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. JMLR 2022. https://arxiv.org/abs/2101.03961
• Gale, T., Narayanan, D., Young, C., Zaharia, M. MegaBlocks: Efficient Sparse Training with Mixture-of-Experts. MLSys 2023. https://arxiv.org/abs/2211.15841
• Mistral AI. Mixtral of Experts. 2024. https://arxiv.org/abs/2401.04088
• DeepSeek-AI. DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models. 2024. https://arxiv.org/abs/2401.06066
• DeepSeek-AI. DeepSeek-V2. 2024. https://arxiv.org/abs/2405.04434
• DeepSeek-AI. DeepSeek-V3 Technical Report. 2024. https://arxiv.org/abs/2412.19437
• Tencent. Hunyuan-Large. 2024. https://arxiv.org/abs/2411.02265
• DeepEP repo: https://github.com/deepseek-ai/DeepEP
• EPLB repo: https://github.com/deepseek-ai/EPLB
• DeepSeek open-infra-index, V3/R1 Inference System Overview: https://github.com/deepseek-ai/open-infra-index
• vLLM blog, Large-Scale Serving DeepSeek (dic 2025): https://blog.vllm.ai/2025/12/17/large-scale-serving.html
• vLLM blog, WideEP en GB200 (feb 2026): https://blog.vllm.ai/2026/02/03/dsr1-gb200-part1.html
• LMSYS blog, DeepSeek 96 H100 PD+EP (may 2025): https://www.lmsys.org/blog/2025-05-05-large-scale-ep/
• LMSYS blog, DeepSeek GB200 NVL72 part II (sep 2025): https://www.lmsys.org/blog/2025-09-25-gb200-part-2/
• NVIDIA Dynamo + GB200 NVL72 para MoE: https://developer.nvidia.com/blog/how-nvidia-gb200-nvl72-and-nvidia-dynamo-boost-inference-performance-for-moe-models/
• Tensor Economics, MoE Inference Economics from First Principles: https://www.tensoreconomics.com/p/moe-inference-economics-from-first
• Cohere, Why MoE models get more from speculative decoding: https://cohere.com/blog/mixture-of-experts-models-get-more-from-speculative-decoding