Cómo ajustar llama.cpp con 8GB de VRAM: por qué 32K es más seguro y 64K necesita cuantización de KV Cache

Thu, 23 Apr 2026 12:13:04 +0800

Si 8GB de VRAM bastan para ejecutar LLMs locales con fluidez, especialmente con contextos largos, es una de las preguntas más comunes al usar llama.cpp.

Tres conclusiones clave:

Con 8GB de VRAM, contexto 32K suele ser el equilibrio más seguro
Si realmente quieres 64K, la cuantización de KV Cache suele ser esencial
En inferencia full-GPU, subir a ciegas el número de hilos CPU puede empeorar el rendimiento

1. Qué significan 32K, 64K y KV Cache

32K y 64K se refieren a longitud de contexto, es decir, cuántos tokens puede procesar el modelo a la vez. K significa miles: 32K son unos 32000 tokens, y 64K unos 64000 tokens. Cuanto más largo el contexto, más contenido previo puede ver el modelo.

KV Cache es una caché de resultados intermedios que el modelo mantiene para acelerar la generación autoregresiva. Una vez que el modelo leyó parte del contexto, no necesita recalcular todo desde cero cada vez. Guarda información intermedia y la reutiliza. K y V vienen de Key y Value en Transformers.

Estos términos aparecen juntos porque:

32K y 64K definen cuánto contenido quieres recordar
KV Cache determina cuánta VRAM extra hace falta para mantener esa memoria
cuanto más largo el contexto, más grande suele ser la KV Cache

Cuando la inferencia de contexto largo se ralentiza, el problema raíz suele ser que la caché creció hasta presionar el límite de VRAM.

2. Por qué 32K y 64K se comportan tan distinto

Usando unas 30000 letras chinas de The Three-Body Problem como stress test, la comparación entre 32K y 64K puede verse dramática: con tamaño de documento similar, 64K puede volverse mucho más lento.

La razón no es que el modelo empeore de repente. El problema real es tocar el límite de VRAM.

En 32K, pesos del modelo más caché quizá aún caben en 8GB, así que la mayoría del tráfico se queda en la memoria de la GPU. Al pasar a 64K, la caché crece, el uso total se acerca o supera el techo de VRAM, y parte de los datos se empuja a memoria compartida o del sistema.

En ese punto no colapsa el cómputo bruto, sino el ancho de banda.

Lo que parece “el contexto se duplicó y el rendimiento se hundió” suele ser que la ruta de datos salió de VRAM hacia memoria mucho más lenta.

3. Para 64K, la cuantización de KV Cache importa mucho

Para usuarios de 8GB de VRAM, una conclusión importante es que cuantizar KV Cache importa muchísimo.

Sin cambiar el modelo, cuantizar solo la caché reduce directamente el uso de memoria en contexto largo. Eso permite que parte de los datos que antes salían de VRAM vuelvan a caber. 64K seguirá siendo más pesado que 32K, pero es menos probable que caiga en la zona más lenta.

En simple:

32K es el rango predeterminado más práctico para 8GB
64K no es imposible
pero sin cuantización de caché, puede pasar de usable a difícil de usar

Prioridad habitual:

Revisar si la VRAM ya está cerca del techo
Decidir si activar cuantización de KV Cache
Solo después experimentar con ajustes de throughput

4. Baja utilización GPU no significa que esté inactiva

Este punto rompe la intuición.

Cuando Task Manager muestra 20% o 30% de GPU, mucha gente asume:

los parámetros están mal
el modelo no corre realmente en GPU
la GPU no se usa completa

Pero en inferencia llama.cpp, lo más probable es que el cuello de botella no sea cómputo del core, sino lecturas y escrituras de memoria.

Los cores GPU pueden terminar rápido un lote de cálculo y pasar el resto del tiempo esperando el siguiente lote de pesos o datos cacheados.

Por eso:

la utilización de cores no parece alta
pero la velocidad end-to-end no mejora

No es una GPU perezosa. Es una ruta de datos estrecha.

5. Aumentar parámetros de throughput ayuda solo si la VRAM aguanta

Si los cores GPU no están saturados, aumentar parámetros relacionados con throughput puede hacer que la GPU procese más datos a la vez y use mejor el paralelismo.

Puede mejorar velocidad, pero con una condición: debe quedar margen de VRAM.

Si ya estás en 64K, con una caché grande y VRAM casi agotada, subir esos parámetros puede terminar en:

crash
fallback a memoria compartida mucho más lenta

La secuencia más segura:

proteger primero el límite de VRAM
luego probar optimizaciones de throughput
tras cada cambio, revisar velocidad y estabilidad

6. Más hilos CPU no siempre son mejores

Es una trampa fácil.

Parece natural pensar que más hilos dan más velocidad. Pero si el modelo ya corre casi todo en GPU, forzar más hilos CPU puede empeorar claramente el rendimiento.

En inferencia full-GPU, la CPU es más scheduler y ayudante de preprocesamiento que motor principal. Demasiados hilos aumentan contención, overhead de scheduling y cambios de contexto, interrumpiendo el flujo de datos.

Resultado:

la CPU parece más ocupada
la velocidad general baja

En este setup, valores predeterminados o hilos más bajos suelen ser más fiables que maximizar todo.

7. Enfoque práctico para 8GB de VRAM

1. Trata 32K como objetivo predeterminado

Con una GPU de 8GB, no persigas 64K de inmediato. 32K suele equilibrar mejor velocidad, estabilidad y memoria.

2. Si quieres 64K, resuelve primero la caché

Confirma si KV Cache está cuantizada y si la VRAM ya está al límite.

3. No juzgues todo por utilización GPU

Baja utilización no implica ajustes incorrectos. Puede indicar que el cuello de botella es memoria.

4. Optimiza throughput sin cruzar el límite de VRAM

Estos parámetros pueden ayudar, pero solo con margen suficiente.

5. Sé conservador con hilos CPU

Si el modelo corre principalmente en GPU, más hilos CPU no son automáticamente mejores.

Conclusión

El valor de esta discusión no son solo números de benchmark, sino una verdad fácil de olvidar:

ajustar LLMs locales no consiste en poner cada valor al máximo. Consiste en entender si tu cuello de botella real es cómputo, capacidad de VRAM, ancho de banda de memoria o scheduling de CPU.

Para usuarios de 8GB, la estrategia más segura suele ser proteger primero el límite de VRAM y solo entonces decidir cuánto más empujar.

Si recuerdas una frase:

32K suele ser el rango de trabajo más estable para 8GB de VRAM; 64K es posible, pero solo si ya controlaste KV Cache y uso de VRAM.

GPU Tuning on KnightLi Blog