Benchmarks de LLM con 16 GB de VRAM usando llama.cpp (velocidad y contexto)
Velocidad de tokens de llama.cpp con 16 GB de VRAM (tablas).
Aquí estoy comparando la velocidad de varios LLM que se ejecutan en una GPU con 16GB de VRAM, y eligiendo el mejor para autoalojar.
He ejecutado estos LLM en llama.cpp con ventanas de contexto de 19K, 32K y 64K tokens.
GPU estilizada con bloques de VRAM y gráficos estilo benchmark
En esta publicación estoy registrando mis intentos de extraer el mayor rendimiento posible en términos de velocidad.
Tabla de comparación de velocidad de LLM (tokens por segundo y VRAM)
| Modelo | Tamaño | VRAM 19K | GPU/CPU 19K | T/s 19K | VRAM 32K | Carga 32K | T/s 32K | VRAM 64K | Carga 64K | T/s 64K |
|---|---|---|---|---|---|---|---|---|---|---|
| Qwen3.6-35B-A3B-UD-IQ3_XXS | 13.2 | 13.8GB | 96%/100% | 147.5 | 14.0GB | 96%/101% | 149.1 | 14.7GB | 96%/101% | 145.8 |
| Qwen3.6-35B-A3B-UD-IQ4_XS | 17.7 | 14.3GB | 62%/266% | 95.0 | 14.9GB | 58%/279% | 92.3 | 14.9GB | 57%/293% | 86.4 |
| Qwen3.5-35B-A3B-UD-IQ3_S | 13.6 | 14.3GB | 93%/100% | 136.4 | 14.6GB | 93%/100% | 138.5 | 14.9GB | 88%/115% | 136.8 |
| Qwen3.5-27B-IQ3_XXS-bartowsky | 11.3 | 12.8 | 98/100 | 44.9 | 13.5 | 98/100 | 44.9 | 14.5 | 45/415 | 23.6 |
| Qwen3.5-27B-UD-IQ3_XXS | 11.5 | 12.9 | 98/100 | 45.3 | 13.7 | 98/100 | 45.1 | 14.7 | 45/410 | 22.7 |
| Qwen3.5-27B-IQ4_XS.gguf | 15.0 | 14.6 | 49/406 | 20.5 | 14.7 | 37/465 | 17.4 | 14.7 | 23/533 | 13.3 |
| Qwen3.5-122B-A10B-UD-IQ3_XXS | 44.7 | 14.7 | 30/470 | 22.3 | 14.7 | 30/480 | 21.8 | 14.7 | 28/490 | 21.5 |
| Qwen3.5-122B-A10B-UD-IQ3_S | 46.5 | 14.7 | 25/516 | 19.4 | 14.7 | 24/516 | 19.5 | 14.7 | 24/516 | 19.6 |
| Mistral-Small-4-119B UD-IQ3_XXS | 42.8 | 14.8 | 28/585 | 30.4 | 14.7 | 27/574 | 28.5 | 14.9 | 20/590 | 31.5 |
| Qwen3-Coder-Next-UD-IQ4_XS | 38.4 | 14.6 | 32/460 | 41.1 | 14.7 | 29/440 | 41.3 | 14.8 | 32/460 | 38.3 |
| Nemotron Super 120b IQ3_XXS | 56.2 | 15.0 | 26/517 | 17.5 | 14.6 | 26/531 | 17.4 | 14.6 | 26/535 | 17.6 |
| gemma-4-26B-A4B-it-UD-IQ4_XS | 13.4 | 14.7 | 95/100 | 121.7 | 14.9 | 95/115 | 114.9 | 14.9 | 75/190 | 96.1 |
| gemma-4-31B-it-UD-IQ3_XXS | 11.8 | 14.8 | 68/287 | 29.2 | 14.8 | 41/480 | 18.4 | 14.8 | 18/634 | 8.1 |
| GLM-4.7-Flash-IQ4_XS | 16.3 | 15.0 | 66/240 | 91.8 | 14.9 | 62/262 | 86.1 | 14.9 | 53/313 | 72.5 |
| GLM-4.7-Flash-REAP-23B IQ4_XS | 12.6 | 13.7 | 92/100 | 122.0 | 14.4 | 95/102 | 123.2 | 14.9 | 71/196 | 97.1 |
19K, 32K y 64K son los tamaños de contexto.
La carga (load) de arriba es una Carga de GPU (GPU Load).
Si ve un número bajo en esta columna, significa que el modelo se está ejecutando principalmente en la CPU y no puede obtener una velocidad decente en este hardware. Ese patrón coincide con lo que las personas ven cuando demasiado poca parte del modelo cabe en la GPU o cuando el contexto devuelve el trabajo al host.
Sobre llama.cpp, rendimiento de LLM, OpenCode y otras comparaciones
Si desea rutas de instalación, ejemplos de llama-cli y llama-server, y las banderas que importan para VRAM y tokens por segundo (tamaño de contexto, lotes, -ngl), comience con Introducción rápida a llama.cpp con CLI y Servidor.
Para la imagen general del rendimiento (tasa de transferencia frente a latencia, límites de VRAM, solicitudes paralelas y cómo se ajustan los benchmarks entre hardware y entornos de ejecución), consulte Rendimiento de LLM en 2026: Benchmarks, cuellos de botella y optimización.
La calidad de la respuesta se analiza en otros artículos, por ejemplo:
- Mejores LLM para OpenCode - Probados localmente. Puede leer más sobre OpenCode en Introducción rápida a OpenCode: Instale, configure y use el agente de codificación de IA de terminal
- Comparación de la calidad de Traducción de Páginas de Hugo - LLM en Ollama
Hice una prueba similar para LLM en Ollama: Mejores LLM para Ollama en GPU de 16GB VRAM.
Si ejecuta Qwen 3.6 27B o 35B a través de llama.cpp y quiere llevar la velocidad de generación aún más allá, consulte Qwen 3.6 MTP vs Decodificación Estándar en GPU de 16GB — la decodificación especulativa MTP añade hasta 67 % de rendimiento de generación para el modelo denso de 27B, con tablas que muestran el costo de VRAM y el compromiso con la ventana de contexto en cada nivel de --spec-draft-n-max.
Por qué la longitud del contexto cambia los tokens por segundo
A medida que pasa de 19K a 32K o 64K tokens, la caché KV crece y la presión de VRAM aumenta. Algunas filas muestran una gran caída en los tokens por segundo en 64K, mientras que otras se mantienen planas, lo cual es la señal de revisar las cuantizaciones, los límites de contexto o la descarga de capas, en lugar de suponer que el modelo es “lento” en general. Para los cálculos de presupuesto detrás de estos números: la fórmula exacta de bytes KV por token, tablas de tipos de caché en 32K/64K/128K, y cómo calcular su propio margen de maniobra, consulte Caché KV en GPUs de 16 GB: Haciendo que el contexto largo quepa realmente.
Los modelos y cuantizaciones que he elegido para probar son para ejecutarlos yo mismo y ver si dan una buena ganancia en términos de relación costo/beneficio en este equipo o no. Así que no hay cuantizaciones q8 aquí con contexto de 200k :) …
GPU/CPU es una carga, medida por nvitop.
llama.cpp, al configurar automáticamente la descarga de capas a la GPU, está tratando de mantener 1GB libre.
Especificamos manualmente este parámetro mediante el parámetro de línea de comandos -ngl, pero no lo estoy ajustando aquí,
solo necesito entender que si hay una caída significativa del rendimiento al aumentar el tamaño de la ventana de contexto de 32k a 64k, podemos intentar aumentar la velocidad en 64k ajustando el número de capas descargadas.
Hardware de prueba y configuración de llama.cpp
Probé la velocidad de los LLM en un PC con esta configuración:
- CPU i-14700
- RAM 64GB 6000Hz (2x32GB)
- GPU RTX-4080
- Ubuntu con controladores NVidia
- llama.cpp/llama-cli, sin capas descargadas especificadas
- VRAM inicial utilizada, antes de iniciar llama-cli: 300MB
Ejecuciones adicionales con contexto de 128K (Qwen3.5 27B y 122B)
| Modelo | Carga 128K | T/s 128K |
|---|---|---|
| Qwen3.5-27B-UD-IQ3_XXS | 16/625 | 9.6 |
| Qwen3.5-122B-A10B-UD-IQ3_XXS | 27/496 | 19.2 |
Ejecuciones ajustadas
Para algunos modelos y cuantizaciones interesantes, intenté encontrar parámetros de línea de comandos especiales de llama-cpp para aprovechar mejor la VRAM. Esto es lo que pude lograr:
| Modelo | Contexto | Capas en GPU | Carga CPU/CPU | Velocidad |
|---|---|---|---|---|
| Qwen3.5-27B-IQ4_XS.gguf | 18k | 65 | 98%/100% | 38.0 |
| Qwen3.5-27B-IQ4_XS.gguf | 64k | 53 | 33%/488% | 15.7 |
Conclusiones para configuraciones de 16 GB de VRAM
- Mi favorito actual, Qwen3.5-27B-UD-IQ3_XXS, se ve bien en su punto óptimo de contexto de 50k (estoy obteniendo aproximadamente 36t/s)
- Qwen3.5-122B-A10B-UD-IQ3_XXS está superando en rendimiento al Qwen3.5 27B en contextos superiores a 64K.
- Puedo hacer que Qwen3.5-35B-A3B-UD-IQ3_S maneje contexto de 100k tokens, y cabe en la vram, por lo que no hay caída de rendimiento
- No usaré gemma-4-31B en 16GB de VRAM, pero gemma-4-26B podría estar medio bien…, necesito probarlo.
- Necesito probar lo bien que funcionan Nemotron cascade 2 y GLM-4.7 Flash REAP 23B. ¿serán mejores que Qwen3.5-35B q3? Dudo de ello, pero aún así, podría probarlo para confirmar la sospecha.
- Para saber por qué la franja de 25–34B es el estándar de 2026 una vez que tiene 24 GB, y por qué un Q4 Qwen3.8-27B no pertenece realmente a esta tarjeta de 16 GB, consulte La frontera eficiente de los modelos abiertos en 2026.