VRAM - planificación de modelos locales
Cuanto ocupa un modelo antes de descargarlo, si cabe junto a otro y cuando merece la pena bajar de cuantización. La cuenta se hace en cinco minutos y evita descargar 40 GB para descubrir que no arranca.
La cuenta, en orden
- Pesos del modelo. Tamaño del GGUF que se va a cargar, tal cual aparece en disco.
- Cache KV. Crece con el contexto y con el número de capas. Es lo que se olvida y lo que rompe la planificación.
- Overhead del servidor. Entre 0,5 y 1,5 GB segun backend y flags.
- Modelo de visión, si aplica. Un
mmprojextra para procesar imagenes. - Margen. Dejar 1-2 GB libres: si la GPU se llena, el driver empieza a mover memoria y el rendimiento se cae en picado.
Regla práctica de cache KV: para un modelo de 7B con contexto de 8K en f16, cuenta 1-2 GB; el mismo modelo a 32K se va por encima de 4 GB. Bajar la cache a q8_0 o q4_0 recorta aproximadamente a la mitad y a la cuarta parte, con perdida pequeña en la mayoría de tareas.
Referencia de tamanos
Cifras orientativas para modelos densos, sin cache KV:
| Parámetros | Q4_K_M | Q5_K_M | Q6_K | Q8_0 |
|---|---|---|---|---|
| 7-8B | ~4,5 GB | ~5,5 GB | ~6,5 GB | ~8,5 GB |
| 13-14B | ~8 GB | ~9,5 GB | ~11 GB | ~15 GB |
| 27-32B | ~16 GB | ~19 GB | ~22 GB | ~29 GB |
Los MoE son otra historia: el total de pesos puede ser enorme y aún así correr en menos VRAM, porque solo activan una parte por token. Un MoE de 35B con 3B activos puede ocupar como un 13B, pero la cache KV se calcula sobre el total de capas.
Cuando dos modelos no caben
Ejemplo típico de laboratorio con 16 GB:
| Modelo | Peso | Contexto | Total con cache | Cabe |
|---|---|---|---|---|
| 27B Q4 | 16 GB | 8K | ~18 GB | No |
| 27B Q4 | 16 GB | 2K | ~16,5 GB | Al limite |
| 7B Q5 (texto) | 5,5 GB | 8K | ~7 GB | Si |
7B Q5 (visión) + mmproj | 7 GB | 8K | ~9 GB | Si |
| 7B texto + 7B visión a la vez | — | — | ~16 GB | Solo con contexto corto |
De ahi sale la regla de diseño: si el equipo tiene 16 GB, un modelo principal y un modelo de visión no conviven. Se levanta uno, se trabaja, se para y se levanta el otro.
Visión: la cuantización pesa más
Para OCR y lectura de capturas, Q4 degrada bastante más que en texto: aparecen caracteres cambiados y lineas perdidas. Merece la pena subir a Q5_K_M o Q6_K aunque el fichero crezca un par de GB.
Además del modelo principal hace falta el proyector multimodal (mmproj), que se declara aparte y suma entre 0,5 y 1,5 GB.
Cuantizaciones, en una línea cada una
| Cuantización | Uso |
|---|---|
| Q8_0 | Casi sin perdida; solo si sobra VRAM |
| Q6_K | Calidad alta, buen equilibrio en 14B o menos |
| Q5_K_M | El punto dulce general, y el mínimo recomendable para visión |
| Q4_K_M | Estándar cuando la VRAM aprieta |
| Q3 y menos | Solo para pruebas: el modelo empieza a repetir y a inventar |
Errores de planificación frecuentes
- Contar solo los pesos y olvidar la cache KV: el modelo entra, la primera conversación larga revienta.
- Olvidar que el contexto reservado cuenta desde el arranque, aunque no se use.
- Cargar dos modelos “pequeños” porque cada uno cabe solo: 7 + 7 + caches supera los 16 GB igual.
- Ignorar la RAM del sistema: con GPU llena, el modelo se descarga a RAM y la velocidad cae a un decimo.
- Comparar velocidades sin fijar contexto y cuantización: dos cifras de tokens por segundo solo son comparables en igualdad de condiciones.
Como medirlo de verdad
# Ver VRAM ocupada por proceso en Linux
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
# Consumo y velocidad de inferencia que reporta llama.cpp al arrancar
./llama-server -m <MODELO>.gguf -c 8192 -ngl 99 --verboseEl propio servidor imprime al arrancar el reparto entre pesos, cache y buffers. Ese número es el que vale, no la estimación.