El precipicio VRAM: por qué tu modelo va a 7 tok/s en vez de 140
TL;DR: Si el modelo cabe en tu VRAM, va a 140 tok/s. Si no cabe, 7 tok/s. No hay punto medio. Y si le añades contexto largo, puede bajar a 0.9 tok/s. Lo medí todo.
El dato
Velocidad (tok/s)
140 ┤ ■ gemma4:e4b (4.5B, cabe entero)
│
50 ┤ ■ qwen3:14b (14.8B, cabe entero)
│
7 ┤ ■ qwen3-coder-30b (30.5B, offload)
7 ┤ ■ gemma4:26b (26B, offload)
│
0 ┤
└────────────────────────────────────────── VRAM usada
10 GB 15 GB 16 GB
20x de diferencia. No es una rampa. Es un precipicio.
¿Por qué pasa esto?
Tu GPU tiene VRAM (GDDR7, ultra rápida). Tu sistema tiene RAM (DDR5, ~20x más lenta).
| Situación | Dónde se procesa | Velocidad |
|---|---|---|
| Modelo ≤ VRAM | Todo en GPU | 50-140 tok/s |
| Modelo > VRAM | Parte GPU + parte RAM (offload) | 6-7 tok/s |
Ollama hace offload automáticamente cuando el modelo no cabe. No hay que configurar nada. Pero el offload tiene un coste: cada token generado requiere leer de RAM → GPU → procesar → escribir resultado. Y la RAM es el cuello.
La velocidad no depende de cuántos parámetros tiene el modelo. Depende de si cabe entero en tu VRAM.
| Modelo | Params | Actives | Cabe en 16GB? | Tok/s |
|---|---|---|---|---|
| gemma4:e4b | 4.5B | 4.5B | ✅ Sí | 139.6 |
| qwen3:14b | 14.8B | 14.8B | ✅ Sí | ~50 |
| qwen3-coder-30b | 30.5B | 3B MoE | ⚠️ Offload | 7.2 |
| gemma4:26b | 26B | ~3.8B MoE | ⚠️ Offload | ~6 |
El coder-30b solo activa 3B por token (MoE), menos que el e4b (4.5B). Pero va 20x más lento. ¿Por qué? Porque los 30.5B totales están en memoria (14.5 GB GPU + 3.8 GB RAM), y hay que mover datos entre ambas.
El segundo cliff: contexto largo
El contexto de conversación también consume memoria. Medí cómo degrada la velocidad en el qwen3-coder-30b:
| Contexto | Output tok/s | RAM offload | Veredicto |
|---|---|---|---|
| 4K (default) | 7.2 | 3.8 GB | 🟢 Óptimo |
| 8K | 4.3 | — | 🟢 Óptimo |
| 32K | 3.5 | 6.8 GB | 🟡 Aceptable |
| 65K | 2.5 | 10.2 GB | 🟠 Degradado |
| 128K | 0.9 | 17.3 GB | 🔴 Inusable |
VRAM GPU se mantiene constante en ~14.5 GB. Ollama manda todo el contexto extra a RAM. A 128K necesitas 14.5 GB GPU + 17.3 GB RAM = 31.8 GB totales para un modelo que teóricamente soporta 256K.
El contexto es el asesino silencioso. Tu modelo va a 7 tok/s con contexto corto. Pero si le pasas un documento largo, cae a 0.9 tok/s sin avisar.
Comparativa: mismo contexto 4K, diferentes modelos
| Modelo | Params activos | VRAM | Offload | Output tok/s | Ratio vs e4b |
|---|---|---|---|---|---|
| gemma4:e4b | 4.5B | 9.8 GB | 0 GB | 139.6 | 1.0x |
| qwen3:14b | 14.8B | 9.3 GB | 0 GB | ~50 | 0.36x |
| qwen3-coder-30b | 3B MoE | 14.5 GB | 3.8 GB | 7.2 | 0.05x |
| gemma4:26b | ~3.8B MoE | ~15 GB | 2 GB | ~6 | 0.04x |
Conclusión: MoE con 3B activos vs dense con 4.5B — similar en cómputo por token. Pero el MoE necesita offload y va 20x más lento. Los parámetros activos no importan tanto como dónde están.
Reglas prácticas
- Si el modelo cabe en VRAM, úsalo. Siempre será más rápido.
- Si no cabe, pregunta si lo necesitas de verdad. 7 tok/s es usable. 0.9 no.
- Para contexto largo (>32K), usa un modelo pequeño que quepa entero. e4b a 128K teóricamente va a seguir rápido. coder-30b a 128K va a 0.9.
- No mires los parámetros totales. Mira cuánta VRAM necesita el modelo quantizado.
- 16GB es suficiente para 95% de use cases. Pero necesitas saber qué modelo elegir.
Anterior: Qué modelo instalar según tu GPU Siguiente: MoE explicado: 30B parámetros que solo usan 3B