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).

Índice

Aquí comparo la velocidad de varios LLMs ejecutándose en una GPU con 16 GB de VRAM y selecciono el mejor para autoalojamiento.

He ejecutado estos LLMs en llama.cpp con ventanas de contexto de 19K, 32K y 64K tokens.

GPU estilizada con bloques de VRAM y gráficos de estilo de prueba de rendimiento

En esta publicación registro mis intentos de exprimir el máximo rendimiento posible en términos de velocidad.

Tabla de comparación de velocidad de LLM (tokens por segundo y VRAM)

Modelo Tamaño 19K VRAM 19K GPU/CPU 19K T/s 32K VRAM 32K Carga 32K T/s 64K VRAM 64K Carga 64K: T/s
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
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 anterior es una Carga de GPU. Si ves 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 la gente ve cuando demasiado poco del modelo cabe en la GPU o cuando el contexto empuja el trabajo de vuelta al host.

Acerca de llama.cpp, rendimiento de LLM, OpenCode y otras comparaciones

Si deseas rutas de instalación, ejemplos de llama-cli y llama-server, y las banderas que importan para la VRAM y los tokens por segundo (tamaño de contexto, agrupación, -ngl), comienza con Inicio rápido de llama.cpp con CLI y Servidor.

Para el panorama general de rendimiento (rendimiento frente a latencia, límites de VRAM, solicitudes paralelas y cómo encajan las pruebas de rendimiento a través del hardware y los entornos de ejecución), consulta Rendimiento de LLM en 2026: Pruebas de rendimiento, cuellos de botella y optimización.

La calidad de la respuesta se analiza en otros artículos, por ejemplo:

También ejecuté pruebas similares para LLMs en Ollama: Mejores LLMs para Ollama en GPU de 16 GB VRAM.

Por qué la longitud del contexto cambia los tokens por segundo

Al pasar de 19K a 32K o 64K tokens, la caché KV crece y la presión sobre la VRAM aumenta. Algunas filas muestran una gran caída en los tokens por segundo a 64K mientras que otras se mantienen estables, lo cual es la señal para revisar las cuantizaciones, los límites de contexto o la descarga de capas, en lugar de asumir que el modelo es “lento” en general.

Los modelos y cuantizaciones que he elegido para probar son para ejecutarlos yo mismo y ver si ofrecen una buena ganancia en términos de coste/beneficio en este equipo o no. Así que aquí no hay cuantizaciones q8 con contexto de 200k :) …

GPU/CPU es una carga, medida por nvitop.

llama.cpp al autoconfigurar las capas para descargarlas a la GPU intenta mantener 1 GB libre. Especificamos manualmente este parámetro vía la línea de comandos con el parámetro -ngl, pero aquí no lo estoy ajustando finamente, solo necesito entender que si hay una caída significativa de rendimiento al aumentar el tamaño de la ventana de contexto de 32k a 64k - podemos intentar aumentar la velocidad en 64k ajustando finamente el número de capas descargadas.

Hardware de prueba y configuración de llama.cpp

Puse a prueba la velocidad de 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 en contexto de 128K (Qwen3.5 27B y 122B)

Modelo Carga 128K 128K: T/s
Qwen3.5-27B-UD-IQ3_XXS 16/625 9.6
Qwen3.5-122B-A10B-UD-IQ3_XXS 27/496 19.2

Ejecuciones ajustadas finamente

Para algunos modelos y cuantizaciones interesantes, intenté encontrar parámetros especiales de línea de comandos de llama-cpp para aprovechar mejor la VRAM. Esto es lo que pude lograr:

Modelo Contexto Capas en GPU CPU/CPU carga 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 montajes de 16 GB VRAM

  • Mi favorito actual Qwen3.5-27B-UD-IQ3_XXS se ve bien en su punto dulce de 50k de contexto (estoy obteniendo aprox 36t/s)
  • Qwen3.5-122B-A10B-UD-IQ3_XXS está superando en rendimiento al Qwen3.5 27B en los contextos superiores a 64K.
  • Puedo empujar Qwen3.5-35B-A3B-UD-IQ3_S para manejar un 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 VRAM, pero gemma-4-26B podría ser medio-bien…, hay que probarlo.
  • Necesito probar qué tan bien funcionan Nemotron cascade 2 y GLM-4.7 Flash REAP 23B. ¿Serán mejores que Qwen3.5-35B q3? Lo dudo, pero aun así, podría probar para confirmar la sospecha.