Cómo se despliegan los modelos MoE: guía de self-hosting

Qwen3.5-9B cabe en 5,3 GB de VRAM. Su hermano MoE, Qwen3.5-35B-A3B, necesita 18,5 GB — y solo activa 3 mil millones de parámetros por token. ¿Qué está pasando?

Los modelos Mixture-of-Experts confunden a quienes los despliegan porque el número de “parámetros activos” es engañoso para la planificación de hardware. Ves “3B activos” y buscas una GPU de 8 GB. Pero luego el modelo no carga.

Esta guía explica las cuentas de VRAM, repasa cada modelo MoE que puedes autoalojar hoy y muestra cómo ejecutarlos en hardware práctico. Usaremos la familia Qwen 3.5 como ejemplo recurrente porque ofrece la comparación más clara posible: misma generación, mismos datos de entrenamiento, mismas capacidades — solo la arquitectura difiere.

En resumen: Los modelos Mixture-of-Experts como DeepSeek V3.1 (685B en total, 37B activos) y Qwen3.5-35B-A3B (36B en total, 3B activos) enrutan cada token a través de una fracción de sus expertos — pero los pesos de todos los expertos deben permanecer en memoria. Qwen3.5-9B (denso) cabe en 5,29 GB con Q4_K_M; su hermano MoE necesita 18,49 GB con la misma cuantización a pesar de activar menos parámetros (Unsloth GGUF, 2026). Por debajo de Q4_K_M, la calidad del enrutamiento se degrada — así que no bajes más.

¿Qué significa “Mixture of Experts” para el despliegue?

Desde principios de 2025, casi todos los principales modelos de IA frontera utilizan diseños MoE (NVIDIA Blog, 2025). En un modelo denso, cada parámetro participa en cada token. En un modelo MoE, una red de enrutamiento selecciona un subconjunto de “expertos” por token — pero todos los expertos deben estar cargados en memoria. Ese único hecho explica casi todas las sorpresas de despliegue que encontrarás.

Piénsalo de esta manera. Un modelo denso es un solo chef que usa todos los ingredientes de la cocina para cada plato. Un modelo MoE es un restaurante con 256 chefs, cada uno especialista, pero necesitas alquilar todo el edificio aunque solo 8 chefs cocinen en cada momento.

Qwen 3.5: la comparación perfecta

La familia Qwen 3.5 nos ofrece la comparación más limpia posible. Ambas variantes comparten los mismos datos de entrenamiento, las mismas capacidades (código, multilingüe, razonamiento, llamadas a herramientas, visión) y la misma ventana de contexto de 262K. La única diferencia es la arquitectura:

• Qwen3.5-9B — denso, 9,65 mil millones de parámetros. Cada parámetro se activa en cada token.
• Qwen3.5-35B-A3B — MoE, 35,95 mil millones de parámetros totales, 256 expertos, 8 activos + 1 compartido por token. Aproximadamente 3 mil millones de parámetros se activan por token.

Misma familia. Misma generación. Perfiles de despliegue totalmente diferentes. Eso es lo que MoE le hace a tu infraestructura.

Fuente: datos de modelos de Prositronic, fichas de modelos de Qwen / DeepSeek / Moonshot AI, 2025–2026

Observa el patrón. A medida que los modelos MoE crecen, la brecha entre parámetros totales y activos se amplía drásticamente. Kimi K2.5 tiene más de un billón de parámetros pero solo activa 32 mil millones por token — el 3,1% del total. A tu GPU no le importa esa proporción. Necesita contenerlos todos.

Requisitos de VRAM — Por qué los modelos MoE necesitan más de lo que esperas

Qwen3.5-35B-A3B necesita 3,5× más VRAM que Qwen3.5-9B con Q4_K_M a pesar de activar menos parámetros por token (Unsloth GGUF, Unsloth GGUF, 2026). La razón es sencilla: la VRAM para los pesos del modelo escala con los parámetros totales, no con los activos. Solo el KV cache escala con los parámetros activos.

La fórmula

Para cualquier modelo GGUF cuantizado, la VRAM se descompone en dos partes:

• Pesos del modelo = parámetros_totales × bits_por_peso / 8. Todos los expertos incluidos.
• KV cache = proporcional a parámetros_activos × longitud_de_contexto × tamaño_de_lote.

En un modelo denso, parámetros totales = parámetros activos, así que la distinción no importa. En MoE, importa enormemente. Así se ve con números reales de nuestros datos de modelos:

Modelo	Arquitectura	Parámetros totales	Parámetros activos	Tamaño Q4_K_M
Qwen3.5-9B	Denso	9,65B	9,65B	5,29 GB
Qwen3.5-35B-A3B	MoE (256 expertos)	35,95B	~3B	18,49 GB
DeepSeek V3.1	MoE (256 expertos)	684,53B	~37B	377,56 GB

Lo que descubrimos: Cuando construimos las páginas de despliegue de Prositronic, los modelos MoE necesitaron cálculos de VRAM y avisos de advertencia completamente diferentes. Un modelo con 3B de parámetros activos podría sugerir que correrá en una Raspberry Pi — hasta que te das cuenta de que los 36 mil millones de pesos deben caber en memoria. Tuvimos que añadir un aviso dedicado MOE_EXPERT_CPU_OFFLOAD en cada página de despliegue MoE.

Fuente: datos de modelos de Prositronic / Unsloth GGUF, 2026. La franja verde muestra cuánta VRAM necesitaría el modelo MoE si solo se cargaran los parámetros activos.

La franja verde en la barra del MoE es reveladora. Si pudieras cargar solo los 3B de parámetros activos, necesitarías aproximadamente 1,6 GB. En cambio, necesitas 18,49 GB porque los 256 expertos — 35,95 mil millones de parámetros — deben estar residentes para que el enrutador seleccione entre ellos.

Para modelos MoE más grandes, las configuraciones multi-GPU se vuelven inevitables. DeepSeek V3.1 con Q4_K_M pesa 377,56 GB. Kimi K2.5 supera los 500 GB. Ninguna GPU de consumo se acerca. ¿Significa esto que no puedes ejecutarlos en absoluto? No del todo — para eso existe la descarga de expertos (lo cubriremos en una sección posterior).

Tus modelos MoE — Una comparación de despliegue

Las configuraciones con un solo experto activo ofrecen un rendimiento entre un 50% y un 80% superior a las configuraciones con 8 expertos activos (Chitty-Venkata et al., 2025). Hoy hay disponibles seis familias de modelos MoE para despliegue autoalojado, que van desde 36B hasta más de un billón de parámetros totales. Así se comparan:

Modelo	Total	Activos	Expertos (usados/total)	Tamaño Q4	VRAM mínima
Qwen3.5-35B-A3B	35,95B	~3B	8+1 / 256	18,49 GB	24 GB
Qwen3-235B-A22B	235B	~22B	8 / 64	~130 GB	Multi-GPU
DeepSeek V3.1	684,53B	~37B	8+1 / 256	377,56 GB	Multi-GPU
Kimi K2.5	1.016B	~32B	8 / 384	~550 GB	Multi-GPU
Llama 4 Scout	~109B	~17B	1 / 16	~60 GB	2× 48 GB
Llama 4 Maverick	~400B	~17B	1 / 128	~220 GB	Multi-GPU

Enrutamiento fino vs enrutamiento grueso

Observa la división arquitectónica. DeepSeek V3.1 y Qwen3.5-35B-A3B usan 256 expertos pequeños (enrutamiento fino) — cada experto es un especialista estrecho. Llama 4 Scout usa solo 16 expertos grandes (enrutamiento grueso) — cada experto es un generalista que maneja un rango más amplio de tokens. ¿Qué significa eso para ti?

Los modelos de enrutamiento fino pueden ser más precisos en cómo asignan cómputo. Pero necesitan más gestión de memoria y su enrutamiento es más sensible a la cuantización. Los modelos de enrutamiento grueso son más simples de desplegar pero menos flexibles. Llama 4 Scout activa solo 1 experto por token (no 8), lo que hace que su patrón de acceso a memoria sea más predecible pero limita la especialización.

Impacto de la cuantización en modelos MoE

FP8 logra un rendimiento entre un 25% y un 30% superior a FP16 en los tamaños de lote más grandes en GPUs H100 (Chitty-Venkata et al., 2025). Pero no dejes que eso te tiente hacia una cuantización extrema. Los modelos MoE son más sensibles a la cuantización agresiva que los modelos densos porque los pesos del enrutador deben mantener alta precisión para seleccionar correctamente los expertos.

El enrutador es el cerebro de un modelo MoE. Examina cada token y decide qué expertos deben procesarlo. Cuando cuantizas un modelo denso a Q2, todos los parámetros se degradan uniformemente. Cuando cuantizas un modelo MoE a Q2, el enrutador empieza a elegir los expertos equivocados. El resultado no es una degradación gradual de calidad — es un precipicio.

Los modelos MoE de última generación sufren una pérdida de precisión no despreciable con cuantización extrema por debajo de 4 bits; los investigadores han desarrollado métodos como MiLo (Mixture of Low-rank compensators) para recuperar la precisión, pero estos añaden complejidad (Huang et al., 2025). Para despliegue práctico, nuestra recomendación es sencilla: no bajes de Q4_K_M.

MXFP4: la excepción

Hay una excepción. Qwen3.5-35B-A3B ofrece una cuantización MXFP4_MOE de 20,11 GB que aplica cuantización MX de 4 bits específicamente a las capas de expertos mientras mantiene las capas de atención y enrutamiento a mayor precisión. Este enfoque selectivo preserva la calidad del enrutamiento mientras sigue comprimiendo la mayor parte del modelo. Si tu hardware soporta MXFP4 (NVIDIA Blackwell y posteriores), es una alternativa sólida a Q4_K_M.

Fuente: Unsloth GGUF, 2026. Las cuantizaciones por debajo de Q4_K_M (en rojo) arriesgan la degradación del enrutador.

Cuantización dinámica: un enfoque más inteligente

La estrategia de cuantización dinámica de Unsloth comprime selectivamente las capas de expertos MoE a anchos de bits más bajos mientras mantiene las capas de atención y enrutamiento a mayor precisión. Por eso ves el prefijo “UD” en muchos nombres de archivos de cuantización — significa “Unsloth Dynamic”. El enfoque aprovecha el hecho de que los expertos contribuyen de manera desigual a la calidad del modelo: los expertos compartidos y las capas de enrutamiento son objetivos de alto valor para su preservación, mientras que los expertos raramente activados toleran más compresión.

Estrategias de descarga de expertos

DeepSeek V3.1 en su cuantización TQ1_0 corre en una sola GPU de 24 GB con descarga MoE más 96–128 GB de RAM del sistema, logrando aproximadamente 1–2 tokens por segundo (benchmarks de la comunidad, 2025). La descarga de expertos es la técnica clave para ejecutar modelos MoE grandes en hardware limitado. Almacena los pesos de los expertos inactivos en la RAM del sistema o en NVMe y los carga en la GPU bajo demanda.

Descarga a CPU con llama.cpp

El enfoque más práctico para configuraciones con una sola GPU. En llama.cpp, puedes descargar todas las capas de expertos MoE a la CPU mientras mantienes las capas de atención y enrutamiento en la GPU:

llama-server \
  --model Qwen3.5-35B-A3B-UD-Q4_K_M.gguf \
  -ot ".ffn_.*_exps.=CPU" \
  --n-gpu-layers 999 \
  --ctx-size 8192 \
  --jinja

El flag -ot ".ffn_.*_exps.=CPU" le dice a llama.cpp que coloque todas las capas feed-forward de expertos en la CPU mientras mantiene todo lo demás en la GPU. Esto es más efectivo que usar --n-gpu-layers solo, que descarga bloques transformer completos en lugar de separar las capas de expertos específicamente.

Multi-GPU: tensor parallelism gana

Tensor parallelism logra ganancias de rendimiento de 2×+ de 1 a 4 GPUs en H100, superando tanto a pipeline parallelism como a expert parallelism (Chitty-Venkata et al., 2025). Si tienes múltiples GPUs conectadas vía NVLink, tensor parallelism (TP) divide cada capa entre GPUs. Expert parallelism (EP) asigna diferentes expertos a diferentes GPUs. TP gana porque el ancho de banda de NVLink es suficientemente alto para hacer eficiente la división de capas, mientras que EP sufre de sobrecarga de balanceo de carga — algunos expertos reciben más tráfico que otros.

La decodificación especulativa oculta la latencia de descarga

Una técnica reciente llamada SpecMoEOff combina decodificación especulativa con descarga de expertos, logrando hasta 2,5× de mejora en el rendimiento de decodificación al generar tokens borrador mientras los pesos de los expertos se transfieren de la RAM a la GPU. Esto aún es experimental pero apunta hacia un futuro donde incluso modelos MoE de un billón de parámetros corran en hardware de estación de trabajo.

Características de rendimiento — Qué esperar

La latencia entre tokens varía casi un 100% entre los mejores y peores modelos MoE LLM (Chitty-Venkata et al., 2025). Los modelos densos tienen latencia por token predecible porque cada token sigue la misma ruta de cómputo. Los modelos MoE no — las decisiones de enrutamiento crean varianza. Si tu aplicación necesita tiempos de respuesta consistentes, esto importa.

Picos de latencia por expertos fríos

Cuando un token se enruta a un experto raramente usado, y los pesos de ese experto han sido desalojados de la caché de la GPU (o nunca se cargaron en una configuración de descarga), obtienes un pico de latencia. La GPU se detiene mientras espera a que los pesos del experto lleguen desde la RAM. Estos picos son impredecibles — dependen del contenido del prompt y de qué expertos activa.

El rendimiento varía según el prompt

Algunos prompts activan el mismo pequeño conjunto de expertos repetidamente. Otros distribuyen la carga entre muchos expertos. Esto hace que el rendimiento de los modelos MoE sea fundamentalmente menos predecible que el de los modelos densos. Las secuencias más cortas (128 tokens) logran hasta un 30% más de rendimiento que las secuencias de 2048 tokens en modelos MoE (Chitty-Venkata et al., 2025).

El procesamiento por lotes también es menos eficiente. En un modelo denso, cada token del lote sigue la misma ruta de cómputo. En un modelo MoE, diferentes tokens del mismo lote se enrutan a diferentes expertos, creando patrones de acceso a memoria que las GPUs manejan con menor eficiencia.

Cuándo gana el modelo denso

Contrasta todo esto con Qwen3.5-9B. Es denso. Cada token toma la misma ruta de cómputo. La latencia es predecible. El rendimiento es consistente. No hay picos por expertos fríos. Sin sobrecarga de enrutamiento. No igualará a Qwen3.5-35B-A3B en benchmarks, pero para aplicaciones sensibles a la latencia — chat en tiempo real, asistentes de código interactivos, interfaces de voz — esa predecibilidad puede importar más que la capacidad bruta. Puedes desplegar y comparar ambos en Prositronic usando nuestro verificador de compatibilidad de hardware.

Preguntas frecuentes

¿Por qué mi modelo MoE necesita tanta VRAM si solo unos pocos expertos están activos?

Todos los pesos de los expertos deben residir en memoria para el enrutamiento instantáneo. Qwen3.5-35B-A3B carga 35,95 mil millones de parámetros pero activa aproximadamente 3 mil millones por token. El enrutador debe poder seleccionar cualquier experto en cualquier momento, así que cada experto permanece cargado aunque la mayoría esté inactiva en cualquier pasada hacia adelante.

¿Puedo ejecutar DeepSeek V3 en una sola GPU?

Sí, con descarga de expertos. La cuantización TQ1_0 cabe en una GPU de 24 GB con 96–128 GB de RAM del sistema, pero espera aproximadamente 1–2 tokens por segundo (benchmarks de la comunidad, 2025). Para velocidades utilizables necesitarás al menos dos GPUs de 48 GB o cuatro GPUs de 24 GB con la cuantización Q4_K_M y tensor parallelism.

¿Cuál es la cuantización mínima que debería usar para modelos MoE?

Q4_K_M. Por debajo de este umbral, la degradación de los pesos del enrutador provoca que los expertos se seleccionen incorrectamente, reduciendo la calidad de salida de forma más pronunciada que la cuantización equivalente en modelos densos. Los modelos MoE sufren una pérdida de precisión no despreciable con cuantización extrema por debajo de 4 bits (Huang et al., 2025).

¿Un modelo MoE es siempre mejor que un modelo denso de tamaño activo similar?

No para aplicaciones sensibles a la latencia. Qwen3.5-9B (denso) ofrece latencia por token predecible sin sobrecarga de enrutamiento. Qwen3.5-35B-A3B (MoE) obtiene puntuaciones más altas en benchmarks pero tiene latencia variable debido al enrutamiento de expertos. Elige denso cuando necesites tiempos de respuesta consistentes; elige MoE cuando necesites máxima capacidad por unidad de cómputo invertida.

¿Cuál es la diferencia entre MoE de enrutamiento fino y enrutamiento grueso?

DeepSeek V3 y Qwen3.5-35B-A3B usan 256 expertos pequeños (enrutamiento fino). Llama 4 Scout usa 16 expertos más grandes (enrutamiento grueso). El enrutamiento fino permite una especialización más precisa pero requiere más gestión de memoria. Los modelos de enrutamiento grueso son más simples de desplegar pero menos flexibles en cómo asignan el cómputo.

Próximos pasos

Esto es lo que debes recordar:

• MoE ≠ menos VRAM. Todos los pesos de los expertos deben cargarse sin importar cuántos estén activos por token.
• No bajes de Q4_K_M para modelos MoE. La calidad del enrutador se degrada pronunciadamente por debajo de la cuantización de 4 bits.
• La descarga de expertos es esencial para configuraciones con una sola GPU. Usa -ot ".ffn_.*_exps.=CPU" en llama.cpp.
• Los modelos densos ganan en predecibilidad de latencia. Elige según la tolerancia de tu aplicación a la varianza.
• Tensor parallelism supera a expert parallelism para despliegues multi-GPU, especialmente con NVLink.

Despliega tanto Qwen3.5-9B como Qwen3.5-35B-A3B en Prositronic para ver las diferencias de primera mano. Comienza con la página de despliegue de Qwen3.5-9B y la página de despliegue de Qwen3.5-35B-A3B, luego consulta la página de compatibilidad de hardware para encontrar la GPU adecuada para tu carga de trabajo.