LLM VRAM Calculator: Dimensiona la GPU antes de descargar el modelo.

Sume tres partes. Los pesos son el número de parámetros multiplicado por los bits por peso de la cuantización elegida, dividido entre 8 para obtener bytes y entre 2^30 para obtener GiB — un modelo de 8B ocupa unos 15 GiB en FP16, 8 GiB en Q8_0 y 4,6 GiB en Q4_K_M. La caché KV crece con la longitud del contexto (siguiente pregunta), y el runtime añade un búfer fijo, que esta calculadora fija en 1,5 GiB. El total tiene que caber en la memoria de la tarjeta con algo de margen; si no cabe, elija una cuantización menor o un contexto más corto antes de recurrir a una GPU mayor.

La cuantización guarda cada peso en menos bits que los 16 con los que se entrenó. FP16 conserva 16 bits por peso (bpw); Q8_0 usa unos 8,5 bpw y es prácticamente sin pérdidas; Q4_K_M usa unos 4,89 bpw —alrededor de un tercio del tamaño FP16— con un pequeño coste de calidad que la mayoría no nota en un chat. Los valores fraccionarios vienen de los diseños mixtos de llama.cpp, que mantienen algunos tensores sensibles en mayor precisión y guardan un factor de escala por bloque; por eso un archivo «de 4 bits» no es exactamente la mitad de uno de 8 bits.

Cada token del contexto guarda un vector clave y un vector valor en cada capa, así que la caché KV es 2 × capas × cabezas KV × dimensión de cabeza × tokens × 2 bytes en FP16. Para Llama 3.1 8B (32 capas, 8 cabezas KV, dimensión de cabeza 128) son 128 KiB por token: 1 GiB con 8.192 tokens y 16 GiB con los 131.072 completos — más que los propios pesos en Q4_K_M. La atención de consulta agrupada (8 cabezas KV en lugar de 32) divide la caché entre cuatro, y por eso Llama 3 admite contextos largos donde Llama 2 no podía. El deslizador de contexto dibuja la caché como su propio segmento de la barra para que vea adónde va la memoria.

La memoria de GPU se vende en gigabytes binarios: una RTX 4090 «de 24 GB» tiene 24 GiB, que son 25,77 GB. Un GB son 10^9 bytes y un GiB son 2^30 = 1.073.741.824 bytes, un 7,37 % más, así que dividir entre 10^9 haría parecer cada modelo un 7,4 % mayor de lo que es y daría veredictos erróneos justo en el límite. La calculadora divide entre 2^30 en todas partes, para que un veredicto compare lo mismo con lo mismo.

Los pesos y la caché KV no son todo: el runtime (llama.cpp, Ollama, vLLM) reserva búferes de cómputo para las activaciones, el contexto CUDA o Metal ocupa unos cientos de MiB y el controlador se reserva algo de memoria propia. 1,5 GiB es una estimación redonda que cubre todo eso para la mayoría de modelos en una sola tarjeta; el valor real varía según el runtime, el tamaño de lote y la GPU. Trátelo como un margen, no como una medida: si un veredicto queda a menos de medio GiB de un escalón, espere problemas.

No del todo en la GPU. Llama 3.1 70B en Q4_K_M necesita unos 40 GiB solo para los pesos, antes de la caché KV y el overhead del runtime, así que una sola tarjeta de 24 GiB no puede contenerlo. Cabe en una tarjeta de 48 GiB (RTX 6000 Ada, A6000) o repartido entre dos tarjetas de 24 GiB con división por capas; Q2_K, con unos 3,16 bpw, baja los pesos a unos 26 GiB, todavía demasiado para una tarjeta y con un coste de calidad visible. Los runtimes pueden descargar las capas restantes a la RAM del sistema, pero la velocidad de tokens cae entonces a lo que permite el ancho de banda de memoria de la CPU, normalmente unos pocos tokens por segundo.

Apple Silicon comparte un único conjunto de memoria entre CPU y GPU, así que un Mac con 64 GB puede cargar modelos que ninguna tarjeta de 24 GiB admite. Por defecto macOS deja que la GPU use aproximadamente el 75 % de la memoria unificada (unos 48 GiB en una máquina de 64 GB) y reserva el resto para el sistema; el sysctl iogpu.wired_limit_mb puede subir el límite bajo su propia responsabilidad. Introduzca como presupuesto unas tres cuartas partes de la memoria del Mac, y recuerde que el ancho de banda, no la capacidad, fija la velocidad de tokens: un M-series Max mueve unos 400 GB/s, una RTX 4090 alrededor de 1 TB/s.

No. La calculadora se ejecuta al 100 % en el cliente: los presets de arquitectura y la aritmética viajan con la página, y cada número se calcula en la pestaña de su navegador. No se sube nada a ningún servidor, no hay cuenta ni registro, y el enlace para compartir codifica su selección en el fragmento de la URL, que los navegadores nunca envían a un servidor.

Solo para los pesos: un modelo de 8B necesita unos 4,6 GiB en Q4_K_M, 7,9 GiB en Q8_0 y 14,9 GiB en FP16 (uno de 7B, unos 4,0, 6,9 y 13,0 GiB); uno de 14B, unos 8,0, 13,9 y 26,1 GiB; uno de 70B, unos 39,9, 69,3 y 130,4 GiB. Sume la caché KV de su contexto —con 8.192 tokens es 1 GiB para Llama 3.1 8B y 2,5 GiB para Llama 3.1 70B— más el overhead de 1,5 GiB del runtime, de modo que un 8B en Q4_K_M con 8k de contexto queda cerca de 7,1 GiB en total. Cada modelo popular tiene su propia página con su número real de capas y de cabezas KV, para que lea directamente el veredicto de ese modelo.

Los pesos tienen un tamaño fijo, pero la caché KV crece con cada token: cuesta 2 × capas × cabezas KV × dimensión de cabeza × 2 bytes por token en FP16. Para Llama 3.1 8B son 2 × 32 × 8 × 128 × 2 = 128 KiB por token, así que el contexto completo de 131.072 tokens necesita 16 GiB de caché frente a unos 4,6 GiB de pesos en Q4_K_M. La atención de consulta agrupada es lo que la mantiene así de pequeña —8 cabezas KV en lugar de 32 dejan la caché en una cuarta parte—, mientras que los modelos antiguos con atención multicabeza, con una cabeza KV por cada cabeza de consulta, se quedan sin memoria con contextos mucho más cortos.