La VRAM que necesitas para un LLM se calcula así: parámetros × bytes por peso, más espacio para la caché KV y la sobrecarga de ejecución. El resultado es de unos 2 GB por cada mil millones de parámetros a 16 bits, 1 GB a 8 bits y 0.5–0.6 GB a 4 bits, más un 10–30%. Por eso, un modelo 70B a 4 bits necesita aproximadamente 42–50 GB.
Fórmula de VRAM: pesos, caché KV y sobrecarga
La memoria de GPU que usa un LLM es la suma de tres partes. La primera representa la mayor parte. Puedes calcular mentalmente la VRAM de un LLM:
- Pesos: parámetros × bytes por peso. Un formato de 16 bits (FP16 o BF16) usa 2 bytes, uno de 8 bits (INT8 o FP8) usa 1 byte y los formatos de 4 bits requieren unos 0.5–0.6 bytes después de contar los factores de escala almacenados.
- Caché KV: el estado de atención que se conserva para cada token ya procesado. Crece con la longitud del contexto y el número de solicitudes simultáneas (consulta la sección sobre la caché KV más adelante).
- Sobrecarga: el contexto de CUDA, los búferes de activación y la fragmentación del asignador. Como referencia, reserva entre 10% y 30% adicional sobre los pesos. No se trata de una especificación.
VRAM (GB) ≈ parámetros (miles de millones) × bytes por peso + caché KV (GB) + sobrecarga
Estimación rápida: total ≈ pesos × 1.1 a 1.3
Ejemplo: un modelo 70B a 4 bits tiene 70 × 0.55 = 38.5 GB en pesos. Multiplica por 1.1–1.3 y obtendrás unos 42–50 GB. Cabe con poco margen en una sola tarjeta de 48 GB cuando el contexto es corto, pero no cabe en una de 24 GB. Usa el mismo cálculo para determinar la VRAM de un LLM antes de rentar o comprar una GPU.
Una nota sobre las unidades: aquí GB equivale a 10^9 bytes, mientras que nvidia-smi muestra MiB (2^20 bytes). Por eso, pueden aparecer diferencias de hasta un 7%.
Requisitos de VRAM para LLM según tamaño y cuantización
La tabla aplica la fórmula a cantidades habituales de parámetros. Elige el tamaño del modelo y la precisión para consultar la memoria aproximada de los pesos. Las cifras solo incluyen los pesos, así que debes sumar la caché KV y la sobrecarga.
| Tamaño del modelo | FP16 / BF16 | INT8 / FP8 | 4 bits (≈ 0.55 bytes) |
| 7B | ≈ 14 GB | ≈ 7 GB | ≈ 3.9 GB |
| 8B | ≈ 16 GB | ≈ 8 GB | ≈ 4.4 GB |
| 14B | ≈ 28 GB | ≈ 14 GB | ≈ 7.7 GB |
| 32B | ≈ 64 GB | ≈ 32 GB | ≈ 18 GB |
| 70B | ≈ 140 GB | ≈ 70 GB | ≈ 38 GB |
| 120B | ≈ 240 GB | ≈ 120 GB | ≈ 66 GB |
La cuantización es el ajuste que más influye. Almacenar cada peso en 8 bits en lugar de 16 reduce a la mitad su memoria. Con 4 bits, baja aproximadamente a una cuarta parte. La desventaja es la pérdida de precisión: suele ser pequeña a 8 bits y más perceptible a 4 bits o menos. Prueba el modelo cuantizado con tus propios prompts antes de adoptarlo. Entre los formatos comunes de 4 bits están GGUF (usado por llama.cpp), AWQ y GPTQ. La cuantización de LLM es la opción más económica para cargar un modelo mayor en la misma tarjeta.
Cómo cambia el uso de VRAM con la longitud del contexto
La caché KV almacena los vectores de clave y valor de cada token que el modelo ya leyó en todas las capas. Así evita calcularlos de nuevo para cada token nuevo. Crece linealmente con la longitud del contexto, aumenta con el número de secuencias simultáneas y depende de la arquitectura. Esta es la fórmula:
Bytes de la caché KV = 2 × capas × kv_heads × head_dim × context_tokens × bytes_per_value
(el 2 corresponde a una clave más un valor)
Como ejemplo, toma Qwen3-32B. Su configuración oficial indica 64 capas, 8 cabezas KV y una dimensión de cabeza de 128. En BF16, el cálculo es 2 × 64 × 8 × 128 × 2 bytes = 262,144 bytes, es decir, 256 KiB por token.
| Longitud del contexto | Caché KV (BF16) | Equivalente en GiB | Con caché KV de 8 bits |
| 4k (4,096) | ≈ 1.1 GB | 1 GiB | ≈ 0.5 GB |
| 32k (32,768) | ≈ 8.6 GB | 8 GiB | ≈ 4.3 GB |
| 128k (131,072) | ≈ 34.4 GB | 32 GiB | ≈ 17.2 GB |
La configuración de Qwen3-32B admite de forma nativa 40,960 posiciones. Por eso, la fila de 128k muestra cómo escala la caché, no un valor predeterminado compatible. La caché no es una diferencia menor: a 128k, la caché BF16 ocupa unos 34 GB, cerca de la mitad de los 65.5 GB de los pesos BF16.
Dos medidas ayudan a controlar la caché. La atención de consultas agrupadas (GQA) permite que muchas cabezas de consulta compartan unas pocas cabezas KV. Qwen3-32B tiene 64 cabezas de atención, pero solo 8 cabezas KV, por lo que su caché es 8× menor que con atención multicabeza completa. También puedes guardar la propia caché con menor precisión: llama.cpp ofrece opciones de tipo para las cachés K y V, incluida q8_0, y vLLM documenta una caché KV FP8 mediante la opción –kv-cache-dtype fp8. Una caché de 8 bits ocupa la mitad que una de 16 bits.
Modelos Mixture-of-Experts: los parámetros activos no determinan la VRAM
Un modelo Mixture-of-Experts (MoE) dirige cada token por unas pocas subredes expertas. Sin embargo, cualquier token puede dirigirse a cualquier experto, así que todos deben permanecer en memoria. Los parámetros activos determinan el cálculo por token y los parámetros totales determinan la memoria necesaria.
gpt-oss-120b es el ejemplo más claro. La ficha del modelo indica 117B parámetros, de los cuales 5.1B están activos por token. Su configuración muestra 128 expertos y usa 4 por token. Los pesos MoE se sometieron a un entrenamiento posterior con cuantización MXFP4. Según la ficha, el modelo cabe en una sola GPU de 80 GB. Los shards del checkpoint suman unos 65 GB, cerca de la estimación de la fórmula para un modelo de aproximadamente 4 bits. Almacenar 117B parámetros en FP16 requeriría unos 234 GB.
Qwen3-30B-A3B-Instruct-2507 muestra el mismo patrón a menor escala: 30.5B parámetros totales, 3.3B activados y 128 expertos, con 8 activos. Necesita tanta memoria como un modelo denso 30B, unos 61 GB en BF16 o 17 GB a 4 bits, pero calcula cada token como un modelo cercano a 3B. gpt-oss-120b también tiene una caché KV pequeña para su tamaño: su configuración muestra 36 capas, 8 cabezas KV y una dimensión de cabeza de 64. Además, limita una de cada dos capas a una ventana deslizante de 128 tokens. El ahorro real depende del runtime.
Qué modelos caben en 24, 48 y 96 GB de VRAM
La respuesta práctica sobre cuánta VRAM necesitas para usar un LLM depende de la capacidad disponible. La siguiente tabla incluye modelos cuyos tamaños proceden de sus fichas o repositorios oficiales, con la precisión necesaria para que quepan.
| Memoria de GPU | Modelo y precisión | Pesos aproximados | Espacio para caché KV y sobrecarga |
| 24 GB | gpt-oss-20b, MXFP4 de fábrica | ficha del modelo: funciona con 16 GB | ≈ 8 GB, con buen margen |
| 24 GB | Qwen3-30B-A3B-Instruct-2507, 4 bits | ≈ 17 GB | ≈ 7 GB, contexto moderado |
| 24 GB | Qwen3-32B, 4 bits | ≈ 18 GB | ≈ 6 GB, solo contexto corto |
| 48 GB | Qwen3-32B, 8 bits | ≈ 33 GB | ≈ 15 GB, admite contexto de 32k |
| 48 GB | Qwen3-30B-A3B-Instruct-2507, 8 bits | ≈ 31 GB | ≈ 17 GB, admite contexto de 32k |
| 48 GB | Modelo denso de clase 70B, 4 bits (según la fórmula) | ≈ 39 GB | ≈ 9 GB, solo contexto corto |
| 96 GB | Qwen3-32B, BF16 | 65.5 GB (tamaño del repositorio) | ≈ 30 GB, contexto largo o procesamiento por lotes |
| 96 GB | gpt-oss-120b, MXFP4 de fábrica | ≈ 65 GB (shards del checkpoint) | ≈ 30 GB, contexto largo o procesamiento por lotes |
| 96 GB | Modelo denso de clase 70B, 8 bits (según la fórmula) | ≈ 70 GB | ≈ 26 GB, admite contexto de 32k |
Se observan tres patrones. Una tarjeta de 24 GB requiere 4 bits para modelos cercanos a 30B parámetros, salvo gpt-oss-20b, que cabe con buen margen. Una tarjeta de 48 GB ejecuta un modelo 32B a 8 bits con espacio para un contexto útil. Con 96 GB puedes mantener un modelo 32B en BF16 o cargar gpt-oss-120b con memoria disponible.
Cómo elegir un GPU VPS: qué cabe en 96 GB de VRAM
El GPU VPS de Contabo incluye una NVIDIA RTX PRO 6000 Blackwell Server Edition dedicada con 96 GB de GDDR7, además de 18 vCPU, 96 GB de RAM del sistema y 900 GB de almacenamiento NVMe. Según la publicación de lanzamiento, cuesta €999 al mes sin IVA. La publicación de lanzamiento del GPU VPS contiene todas las especificaciones. La comparación de precios del GPU VPS contrasta el precio con otros proveedores. Al aplicar las tablas anteriores, tres configuraciones tienen sentido en esta tarjeta:
- Un modelo grande con mayor precisión: Qwen3-32B en BF16 (65.5 GB) o gpt-oss-120b (unos 65 GB) deja cerca de 30 GB para la caché KV y la sobrecarga.
- Un modelo mediano con contexto largo: Qwen3-32B a 8 bits (unos 33 GB) más una caché KV BF16 de 128k (unos 34 GB) suma aproximadamente 67 GB y deja cerca de 29 GB libres. Considera el límite de contexto nativo del modelo.
- Varios modelos pequeños en paralelo: cuatro modelos de la clase de 16 GB, como gpt-oss-20b, ocupan unos 64 GB y dejan cerca de 30 GB para sus cachés.
En un servidor GPU para cargas de IA, los 96 GB dedicados importan más que la cantidad de vCPU. Cuando todos los pesos caben en la memoria de la GPU, evitas el lento offloading a CPU descrito más adelante.
Cuando se agota la VRAM: offloading, cuantización y varias GPU
Si el modelo no cabe, sigue estos pasos en orden:
- Reduce la precisión. Pasar de 16 a 8 bits, o de 8 a 4 bits, produce el mayor ahorro individual. Aquí es donde la cuantización de LLM ofrece el primer beneficio.
- Acorta el contexto y cuantiza la caché KV. Reducir la ventana de contexto o almacenar la caché en 8 bits libera memoria sin modificar los pesos.
- Descarga capas a la CPU y a la RAM del sistema. llama.cpp permite elegir cuántas capas permanecen en la GPU mediante la opción -ngl y ejecuta el resto en la CPU. Funciona, pero la velocidad disminuye mucho porque la RAM del sistema es bastante más lenta que la memoria de la GPU. Para conocer runtimes adecuados para CPU, consulta la guía de Llamafile y la guía de KoboldCpp.
- Divide el modelo entre varias GPU mediante paralelismo de tensores. Esto aumenta la memoria disponible, pero requiere una conexión rápida entre las tarjetas para escalar bien.
Cómo revisar el uso de VRAM en tu servidor
Las estimaciones son un punto de partida. Mide el consumo con nvidia-smi. Observa cómo aumenta memory.used al cargar los pesos y de nuevo cuando el servidor asigna la caché KV:
nvidia-smi
nvidia-smi –query-gpu=memory.used,memory.total –format=csv -l 1
nvidia-smi –query-compute-apps=pid,process_name,used_memory –format=csv
El primer comando muestra una captura instantánea, el segundo registra la memoria cada segundo mientras se carga un modelo y el tercero enumera la memoria por proceso. Algunos servidores de inferencia reservan desde el inicio una parte considerable de la memoria de GPU. Por eso, memory.used puede aparecer elevado incluso cuando el servidor está inactivo. Compáralo con tu cálculo en lugar de tomarlo como el consumo mínimo. Si ejecutas contenedores, configura primero la GPU y después monitorea el uso a lo largo del tiempo. Para seguir el proceso de principio a fin, consulta la guía de inferencia de LLM en un GPU VPS.
Preguntas frecuentes sobre los requisitos de VRAM para LLM
¿Cuánta VRAM necesito para ejecutar un modelo 7B?
Un modelo 7B necesita unos 14 GB para los pesos a 16 bits, 7 GB a 8 bits y cerca de 4 GB a 4 bits. Suma entre 10% y 30% para la caché KV y la sobrecarga. Un modelo 7B a 4 bits puede ejecutarse en una GPU de 8 GB con un contexto moderado.
¿Cuánta VRAM necesita un modelo 70B?
Un modelo 70B necesita unos 140 GB para los pesos a 16 bits, 70 GB a 8 bits y cerca de 38.5 GB a 4 bits. Con una sobrecarga del 10–30%, un modelo 70B a 4 bits requiere unos 42–50 GB. Planea usar una GPU de 48 GB con contexto corto o una de 96 GB para tener más margen.
¿La cuantización reduce el uso de VRAM?
Sí. La cuantización almacena cada peso con menos bits. Con 8 bits, la memoria de los pesos se reduce a la mitad frente a 16 bits; con 4 bits, baja aproximadamente a una cuarta parte. El costo es cierta pérdida de precisión, normalmente pequeña a 8 bits. Prueba el modelo cuantizado con tus propias tareas.
¿Puedo ejecutar un LLM en una CPU en lugar de una GPU?
Sí. Runtimes como llama.cpp ejecutan modelos en la CPU mediante la RAM del sistema, y el mismo cálculo de pesos se aplica a la RAM. La velocidad es mucho menor que en una GPU. Por eso, la inferencia en CPU es adecuada para modelos pequeños, pruebas y cargas con poco tráfico, no para producción.
¿Cuánta VRAM adicional usa una ventana de contexto más larga con caché KV?
Depende de la arquitectura. En Qwen3-32B con BF16, la caché KV ocupa 256 KiB por token: cerca de 1 GB con 4k tokens, 8.6 GB con 32k y 34 GB con 128k por secuencia. Una caché de 8 bits reduce esas cifras a la mitad.
Aviso: las especificaciones, funciones y precios de los productos mencionados en este artículo pueden cambiar y variar según la región, el periodo de facturación y las promociones activas. Consulta el sitio web oficial de cada proveedor o marca para conocer las cifras actuales, los precios y los tipos de cambio en moneda local.