Al terminar este artículo sabrás calcular con lápiz y papel cuánta memoria necesita un modelo antes de descargarlo. Haremos la cuenta completa para un 8B, un 32B y un 70B. Basta con un portátil de 8 GB para empezar, y la misma cuenta te dice cuándo hace falta algo más.
Qué necesitas
- Una calculadora o una hoja de cálculo. Nada más para hacer la cuenta.
- El archivo
config.jsondel modelo en Hugging Face. Lo usaremos para la caché. - Opcional: Ollama instalado, para comparar la cuenta con lo que mide tu máquina.
La fórmula es la misma que usa la calculadora de cada ficha en nuestro catálogo de productos. Si sigues los pasos, tus números y los de la web coinciden.
Paso 1: calcula lo que pesan los pesos
Un modelo es una lista de números. Cuántos hay lo dice el nombre (8B son 8.000 millones). Cuánto ocupa cada uno lo dice la cuantización:
pesos (GB) = parámetros (miles de millones) × bits por peso ÷ 8| Cuantización | Bits por peso | Qué es |
|---|---|---|
| Q4_K_M | 4,85 | 4 bits con algunas capas más precisas. La opción por defecto de Ollama |
| Q8_0 | 8,5 | 8 bits, prácticamente el original |
| FP16 | 16 | los pesos originales |
Los valores de Q4_K_M y Q8_0 son los de llama.cpp para esos tipos GGUF. Si quieres entender por qué 4 bits suele bastar, lo contamos en cómo elegir el archivo GGUF correcto.
Un 8B en Q4_K_M: 8,0 × 4,85 ÷ 8 = 4,85 GB. El mismo modelo en FP16 son 16 GB. La cuantización es la palanca más grande que tienes.
Paso 2: suma la caché de contexto
Mientras conversas, el modelo guarda dos vectores (K y V) por cada token, en cada capa. Esa es la caché de contexto. No depende de la cuantización del archivo. Depende de la arquitectura y de cuántos tokens permites:
caché por token (bytes) = capas × cabezas KV × dimensión de cabeza × 4
caché (GB) = caché por token × tokens de contexto ÷ 1.000.000.000El 4 sale de 2 vectores (K y V) por 2 bytes en FP16. Los tres valores están en el config.json del modelo: num_hidden_layers, num_key_value_heads y head_dim. Si falta head_dim, divide hidden_size entre num_attention_heads.
| Modelo | Capas | Cabezas KV | Dim. cabeza | Caché por token | Fuente (consultada 06-10-2026) |
|---|---|---|---|---|---|
| Llama 3.1 8B | 32 | 8 | 128 | 0,131 MB | config.json |
| Qwen 2.5 32B | 64 | 8 | 5.120 ÷ 40 = 128 | 0,262 MB | config.json |
| Llama 3.3 70B | 80 | 8 | 128 | 0,328 MB | config.json |
Los dos Llama los leemos de la copia de unsloth porque el repositorio de Meta pide registro. La arquitectura es la misma.
Fíjate en las cabezas KV: 8 en los tres. Sin esa técnica (atención agrupada), un 70B con 64 cabezas guardaría ocho veces más caché.
Paso 3: suma el motor y compara con tu memoria útil
Al total le sumamos 1,5 GB de motor (búferes de cálculo y runtime). Después restamos lo que se queda el sistema:
- VRAM dedicada (una tarjeta gráfica): memoria total menos 0,5 GB.
- Memoria unificada o RAM del sistema: menos 3 GB hasta 16 GB, menos 4 GB hasta 32 GB, menos 6 GB por encima.
Con eso tienes la memoria útil. La regla de la calculadora: cabe con holgura si lo necesario es el 85 % de la útil o menos. Entre el 85 % y el 100 % cabe justo. Por encima, no cabe.
Tres ejemplos completos
Hicimos la cuenta ejecutando las funciones de la web (memoryNeededGb, usableMemoryGb y fitStatus, en src/lib/hardware-math.ts) con Node el 06-10-2026. Los números de esta tabla son los que devuelve el código, redondeados.
| Ejemplo | Pesos | Caché | Motor | Total |
|---|---|---|---|---|
| Llama 3.1 8B, Q4_K_M, 8k tokens | 8,0 × 4,85 ÷ 8 = 4,85 GB | 0,131 × 8.192 = 1,07 GB | 1,5 GB | 7,42 GB |
| Qwen 2.5 32B, Q4_K_M, 8k tokens | 32,8 × 4,85 ÷ 8 = 19,88 GB | 0,262 × 8.192 = 2,15 GB | 1,5 GB | 23,53 GB |
| Llama 70B, Q4_K_M, 8k tokens | 70,6 × 4,85 ÷ 8 = 42,80 GB | 0,328 × 8.192 = 2,69 GB | 1,5 GB | 46,99 GB |
Una nota sobre el 32B: la calculadora usa 32,8 mil millones de parámetros y la ficha de Qwen dice 32,5. La diferencia son 0,2 GB. Para el 70B usamos 70,6, la cifra de Llama 3.1 70B, que comparte arquitectura con Llama 3.3.
Ahora, contra máquinas reales:
| Memoria | Útil | Umbral 85 % | 8B | 32B | 70B |
|---|---|---|---|---|---|
| GPU de 8 GB | 7,5 GB | 6,38 GB | cabe justo | no cabe | no cabe |
| GPU de 12 GB | 11,5 GB | 9,78 GB | holgado | no cabe | no cabe |
| GPU de 24 GB | 23,5 GB | 19,98 GB | holgado | no cabe (por 0,03 GB) | no cabe |
| Unificada de 32 GB | 28 GB | 23,8 GB | holgado | holgado | no cabe |
| Unificada de 64 GB | 58 GB | 49,3 GB | holgado | holgado | holgado |
El 32B en una tarjeta de 24 GB es el caso que más enseña. Con 8k de contexto se pasa por 30 MB. Baja a 4k y la caché cae a 1,07 GB: total 22,46 GB, cabe justo. El contexto decide.
Por qué el contexto pesa tanto
La caché crece en línea recta con los tokens. Para el 8B de arriba:
| Contexto | Caché | Total en Q4_K_M |
|---|---|---|
| 4k | 0,54 GB | 6,89 GB |
| 8k | 1,07 GB | 7,42 GB |
| 32k | 4,29 GB | 10,64 GB |
| 128k | 17,17 GB | 23,52 GB |
Que un modelo admita 128k tokens no significa que debas reservarlos. Pide el contexto que usa tu tarea. Un resumen de un correo cabe en 4k; un contrato de 60 páginas, no.
Memoria unificada frente a VRAM dedicada
Una tarjeta gráfica tiene su propia memoria (VRAM). El modelo tiene que caber ahí, y lo que no cabe se ejecuta en la CPU, mucho más despacio.
Los Mac con chip Apple, la DGX Spark (GB10, 128 GB) y los equipos con AMD Strix Halo usan memoria unificada. CPU y GPU comparten la misma memoria, así que un equipo de 64 GB puede dar casi todo ese espacio al modelo. Por eso la reserva es mayor: el sistema operativo vive en la misma memoria.
Lo que no te dice la ficha técnica: caber no es correr rápido. La velocidad depende del ancho de banda de memoria, y ahí una GPU dedicada suele ganar. Para eso está el catálogo de hardware por presupuesto.
Comprueba el consumo real
La cuenta es una estimación. Tu máquina tiene la última palabra:
ollama ps
# NAME SIZE PROCESSOR CONTEXT
# llama3.1:8b 9.2 GB 100% GPU 32768SIZE es la memoria que ocupa el modelo cargado. Si PROCESSOR dice algo distinto de 100% GPU, parte del modelo está en la CPU. Baja la cuantización o el contexto.
En una tarjeta NVIDIA dedicada, nvidia-smi lo confirma:
nvidia-smi --query-gpu=memory.used,memory.total --format=csvEn la GB10 esa consulta devuelve [N/A], porque la memoria es unificada. Ahí usa ollama ps.
Así se compara la cuenta con lo que medimos en nuestra GB10, siempre con llama3.1:8b en Q4_K_M:
| Contexto | Cuenta de la web | Medido (ollama ps) | Fecha |
|---|---|---|---|
| 4.096 | 6,89 GB | 5,3 GB | 09-09-2026 |
| 32.768 | 10,64 GB | 9,2 GB | 06-10-2026 |
| 131.072 | 23,52 GB | 22 GB | 09-09-2026 |
La cuenta sale siempre por encima: entre 1,4 y 1,6 GB de más. Los 1,5 GB de motor son generosos. Preferimos que te sobre memoria a que te falte.
Cuándo no hacer caso a la cuenta
- Modelos de mezcla de expertos (MoE). Cuentan todos los parámetros para la memoria, aunque solo trabajen unos pocos por token. Usa el total.
- Caché cuantizada. Algunos motores guardan la caché en 8 bits. Entonces ocupa la mitad y la fórmula te sobrestima.
- Otros servicios en la misma máquina. Si ya hay un modelo cargado, réstalo de tu memoria útil.
- Imágenes y visión. Los modelos multimodales añaden un codificador. Cuenta un margen extra.
Siguientes pasos
- Elige un modelo y mira su peso por cuantización en el explorador VRAM. Súmale la caché y el motor como aquí.
- Abre la ficha de tu máquina en productos: la calculadora hace la cuenta entera con esta fórmula.
- Antes de comprar, compara tramos en el catálogo de hardware para IA local.
Hablemos 15 minutos
Hacemos esta cuenta con los documentos y el contexto reales de tu equipo, y la medimos en hardware antes de recomendar nada. Si la quieres para tu empresa, pide una llamada de 15 minutos o mira cómo trabajamos en consultoría.