Mejora medida Publicado el 22 de septiembre de 2026 · 1U · HERMES

qwen3:8b en una GPU de 8 GB: de 17 a 73 tokens por segundo sin cambiar de modelo

Mi asistente local tardaba 141 segundos en una pregunta y fallaba casos que por la mañana pasaba. No era el modelo ni el prompt: solo cabía en la GPU el 66 % del modelo, y el resto corría en la CPU.

LLM locales (Ollama, Qdrant, RAG)
Linux (Debian, Alpine, Arch)

El punto de partida

Hermes, mi asistente, usa qwen3:8b cuantizado a 4 bits con Ollama en la GPU de mi PC, una RTX de 8 GB. Por la tarde, una pregunta sencilla tardó 141 segundos y un caso de la batería de pruebas que por la mañana pasaba 5 de 5 falló 8 de 8.

La primera métrica que añadí fue una línea de log por llamada al modelo: tokens de entrada y salida, tiempo de carga, velocidad y reparto entre GPU y CPU. Con eso el problema saltó a la vista:

prompt=5282tok salida=371tok carga=2.8s total=44.9s velocidad=10.6tok/s reparto=6.12GiB 66%GPU

Quién se comía la VRAM

Con un juego y el navegador abiertos, solo cabía en la GPU el 66 % del modelo. La carga eran 2,8 s: lo de menos. El coste estaba en generar a 10 tokens por segundo con un tercio del modelo en la CPU.

nvidia-smi (la tabla de procesos, no --query-compute-apps, que se deja fuera los procesos gráficos) dijo quién ocupaba la memoria: Firefox 805 MiB, Steam 228, el escritorio unos 300, VS Code 145, Element 88. El cuello no era el modelo: era el escritorio.

Los ajustes

Cuatro variables de Ollama en su servicio de systemd y cerrar lo que sobraba. El reparto entre GPU y CPU se decide al cargar el modelo, así que hay que forzar una recarga después de liberar memoria.

OLLAMA_FLASH_ATTENTION=1      # necesaria para cuantizar la caché KV
OLLAMA_KV_CACHE_TYPE=q8_0     # la caché del contexto ocupa la mitad
OLLAMA_NUM_PARALLEL=1         # cada petición paralela añade su caché
OLLAMA_MAX_LOADED_MODELS=1    # que no se quede otro modelo en VRAM

Resultado

Escritorio normal, caché f16: 78 % en GPU, unos 20 tokens/s.
Flash attention y caché q8_0: 84 %, 33 tokens/s.
Además, navegador y Steam cerrados: 100 % en GPU y 73 tokens/s, 4,2 veces más rápido que al principio.
La batería de 40 casos × 3 semillas subió de 106 a 114 de 120, con la mediana de 12,2 s a 4,7 s.

Por qué también acertó más

La caché cuantizada no empeoró la calidad: la mejoró. No porque haga al modelo más listo, sino porque al no repartirse con la CPU los cálculos dejan de variar y los casos que estaban en el límite dejan de volcarse.