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
8GBde VRAM, contexto32Ksuele ser el equilibrio más seguro - Si realmente quieres
64K, la cuantización deKV Cachesuele ser esencial - En inferencia full-GPU, subir a ciegas el número de hilos
CPUpuede 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:
32Ky64Kdefinen cuánto contenido quieres recordarKV Cachedetermina 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:
32Kes el rango predeterminado más práctico para8GB64Kno 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
CPUparece 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.