Calculadora de VRAM para GGUF: comprueba antes de descargar
Tamaño del modelo, cuant y contexto de entrada — pesos, caché KV y veredicto por tarjeta de salida. La calculadora responde si cabe antes de empezar la descarga.
ggml_backend_cuda_buffer_type_alloc_buffer: failed to allocate 3412 MiB. El archivo se descargó sin problemas. La tarjeta nunca pudo con él — y la aritmética que lo predecía cabía en el margen de un recibo. El flujo habitual va al revés: lanzar la descarga, mirar la barra de progreso y dejar que el error de memoria haga las cuentas. Ese orden es el que la herramienta de hoy rechaza. La calculadora de VRAM para GGUF está en línea: tamaño del modelo, cuantización y contexto de entrada — pesos, caché KV y un veredicto para cada tarjeta común de salida. O al revés: parte de tu presupuesto de VRAM hacia el cuant más alto que cabe. Todo se ejecuta en tu navegador, nada se sube, y se une al hub run-LLMs-locally junto al resto del cluster.
Tiene dos modos, porque la pregunta llega en dos formas:
- «¿Cuánta VRAM necesita este modelo?» — parámetros, cuant, contexto y arquitectura de entrada; el desglose y un veredicto tarjeta a tarjeta (6 a 96 GB) de salida.
- «¿Qué cabe en mi VRAM?» — presupuesto, tamaño del modelo y contexto de entrada; cada cuant de Q2_K a F16 con su propio veredicto.
¿Cuánta VRAM necesita un modelo GGUF?
Tres partes, siempre las mismas:
VRAM ≈ pesos + caché KV + sobrecarga
pesos = params × bits-por-peso / 8
caché KV = 2 × capas × kv_dim × contexto × 2 bytes (f16)
sobrecarga ≈ 0,7 GB CUDA/ejecución + ~5% de buffers de cómputo
Ejemplo trabajado, el más común: un modelo 8B en Q4_K_M con 32k de contexto. Pesos: 8 × 4,85 / 8 = 4,85 GB. Caché KV: 2 × 32 capas × 1024 kv-dim × 2 bytes = 128 KB por token × 32 768 = 4,0 GB. Con sobrecarga: ~9,8 GB en total — el «Q4 8B» que todo el mundo llama modelo-para-tarjeta-de-8-GB falla por un 23 % en cuanto le das contexto largo. El cuant nunca fue el culpable; el contexto, sí. Ese modo de fallo tiene su propia nota de campo, porque también se come la RAM del sistema al hacer offload.
¿Qué cuant cabe en mi tarjeta?
El modo 2 existe porque la pregunta invertida es la que la gente tiene de verdad: una tarjeta fija y un modelo en mente. Un 7B con 4096 de contexto contra un presupuesto de 8 GB devuelve exactamente esto:
| Cuant | Pesos | Total (est.) | Veredicto |
|---|---|---|---|
| Q4_K_M | 4,24 GB | ~5,7 GB | cabe con margen |
| Q6_K | 5,77 GB | ~7,3 GB | justo |
| Q8_0 | 7,44 GB | ~9,0 GB | offload parcial a CPU, mucho más lento |
Una pantalla, y el eterno debate del foro «¿Q4 o Q8?» se reduce a la respuesta de tu hardware en vez de la del de al lado.
De dónde salen los números
La tabla de bits-por-peso viene de los formatos de cuant ggml de llama.cpp — los mismos números con los que se construyen los archivos de Hugging Face:
| Cuant | bpw | Cuant | bpw |
|---|---|---|---|
| Q2_K | 3,35 | Q5_K_M | 5,69 |
| Q3_K_M | 3,91 | Q6_K | 6,59 |
| IQ4_XS | 4,25 | Q8_0 | 8,50 |
| Q4_K_M | 4,85 | F16 | 16,0 |
La mitad de la caché KV usa la geometría pública de cada familia. La atención agrupada por consulta (GQA) es toda la historia: un 8B de clase Llama-3 guarda 8 cabezas KV × 128 dims × 32 capas, o sea 128 KB por token — mientras que un Llama 2 13B, sin GQA, quema 640 KB por token, cinco veces más, siendo un modelo de una generación anterior. El desplegable de arquitectura cubre las cuatro formas comunes más un modo personalizado para lo que se lea en cualquier config.json.
El tamaño del archivo te decía qué ibas a descargar. Nunca te dijo qué podías ejecutar.
Lo que las estimaciones ignoran a propósito
Tres cosas, a propósito. El enrutado mixture-of-experts: la inferencia solo toca los expertos activos, pero la herramienta cobra el set completo de pesos, así que los totales MoE leen altos. La cuantización mixta: Q4_K_M es en sí un promedio entre tensores, y un archivo real cae a unos puntos porcentuales del valor de la tabla. Y el padding del lado CUDA varía según la versión del backend — los 0,7 GB fijos son una cifra intermedia, no una constante de la naturaleza. Cuando una decisión vale más de unos cientos de MB, sáltate las estimaciones y lee la cabecera del archivo con el gguf_dump.py de llama.cpp — las calculadoras que leen cabeceras hacen justo eso. Esta se queda en aritmética a propósito: tres entradas que puedes recalcular a mano y un veredicto con el que puedes discutir.
La herramienta vive en github.com/mrsaynothing/gguf-vram-calculator — un archivo HTML, cero dependencias, cero build. Se sienta junto a la guía local de GGUF, llama.cpp vs Ollama y la lista de mejores LLM locales, con la contraparte de servicio en ¿puede vLLM ejecutar GGUF?.
Si un veredicto contradice tus tiempos de carga, abre una issue en el repositorio con el modelo, el cuant y el contexto — la tabla debe sobrevivir al contacto con hardware real, y donde no lo haga hay una fila que corregir.