MoE por dentro: 30B totales, 3B activos
Un modelo de 30B que genera más rápido que uno de 7B. Suena a magia hasta que entiendes la arquitectura: no todos los parámetros se despiertan en cada token. En un modelo MoE (Mixture of Experts) solo una fracción trabaja a la vez, y esa fracción es la que decide la velocidad.
Lo medimos con tres modelos locales y los números forman un patrón clarísimo.
La idea, en una frase
Un MoE tiene muchos "expertos" (bloques de parámetros) y un router que, por cada token, elige unos pocos. El modelo sabe mucho (30B totales) pero trabaja poco por token (~3B activos). Resultado: calidad de grande, velocidad de chico.
Los números (local, Mac M4 Max, Ollama)
Mismo prompt (~2.000 tokens), tres modelos:
| Modelo | Parámetros activos | Decode (tok/s) | Prefill (tok/s) |
|---|---|---|---|
qwen2.5:0.5b | 0,5B | 326 | 5.655–11.766 |
qwen2.5:7b | 7B | 78 | 861–929 |
qwen3-coder:30b (MoE) | ~3B | 91–93 | — |
Léelo otra vez: el MoE de 30B totales genera a 91-93 tok/s, más rápido que el denso de 7B (78 tok/s), porque solo activa ~3B. Y el de 0,5B vuela (326 tok/s) porque activa 0,5B.
El patrón: la velocidad de decodificación la manda la cantidad de parámetros activos, no el tamaño total. Es la razón por la que un MoE es la opción natural para servir un modelo grande en una GPU que no es enorme.
Prefill vs decode: leer es mucho más rápido que escribir
En los mismos datos aparece la otra mitad de la historia:
| Modelo | Prefill (leer) | Decode (escribir) | Ratio |
|---|---|---|---|
qwen2.5:7b | 861–929 tok/s | 72–79 tok/s | ~12× |
qwen2.5:0.5b | 5.655–11.766 tok/s | 308–326 tok/s | ~18–36× |
Y con un prompt largo (6.038 tokens), el qwen2.5:7b hizo el prefill a 1.223,8 tok/s y luego decodificó a 53,9 tok/s.
Dos consecuencias:
- El prompt es barato; la respuesta es cara. Procesar 10.000 tokens de contexto es mucho más rápido que generar 1.000 de salida. Por eso el prefix caching ataca justo la fase de lectura: es donde hay más margen.
- El arranque en frío se nota. El primer token del
qwen3-coder:30blocal tardó 4.007 ms; el siguiente, 34,9 ms. La primera petición paga compilación y carga; el resto vuela.
Por qué esto importa para servir tu propio modelo
- Más calidad por GB. Un MoE de 30B puede caber (y volar) donde un denso de 30B necesitaría dos GPUs.
- Costos por token más bajos en tareas donde la velocidad activa importa, porque aprovechas la GPU con menos cómputo por token.
- La decisión de modelo no es "el más grande". Es "el más grande que puedas servir con una latencia aceptable". El MoE mueve esa frontera.
Lo que no medimos (y hay que decirlo)
La calidad no está medida: comparamos velocidad entre arquitecturas, no precisión. Un MoE de 3B activos puede ser rapidísimo y quedarse corto en tareas difíciles; por eso el informe final deja la calidad como el hueco principal antes de cualquier migración. → El informe que dijo "no migren todavía"
El contexto completo de serving está en la guía Inference Engineering: de cero a producción.
¿Has probado un MoE para servir tu propio modelo? Cuéntame en los comentarios qué tan grande lo pediste y qué tan rápido te respondió.