Requisitos de VRAM para LLM: la tabla maestra 2026 (todos los modelos, todas las cuantizaciones)

Requisitos de VRAM para LLM: la tabla maestra 2026 (todos los modelos, todas las cuantizaciones)

Aquí está el dato que pilla a todo el mundo por sorpresa: DeepSeek-V3.2 tiene 671 mil millones de parámetros, pero solo 37 mil millones se activan en cada token. Entonces, ¿cuánta VRAM necesita en realidad? Los 671 mil millones completos, unos 382 GB en Q4. Los requisitos de VRAM de los LLM casi nunca siguen la intuición, y la diferencia entre "parámetros activos" y "lo que hay que cargar en memoria" es exactamente donde se disparan los presupuestos de hardware. Esta guía te da la tabla maestra (todos los modelos abiertos principales, cada nivel de cuantización, la cifra en GB y la GPU que lo ejecuta) más la fórmula para calcular cualquier modelo tú mismo en unos diez segundos.

Puntos clave

• La VRAM de los pesos ≈ parámetros × bytes por parámetro: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Súmale la KV cache y un 15-20% de sobrecarga.
• Los modelos Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) tienen que cargar cada experto en la VRAM. Los "parámetros activos" te dan velocidad, no memoria.
• La KV cache es el coste oculto. Llama 3.3 70B necesita unos 2.6 GB de caché con un contexto de 8K y unos 41 GB con 128K, por encima de los pesos.
• Q4_K_M es la opción por defecto más sensata: calidad casi completa con más o menos una cuarta parte del tamaño de FP16.
• Un modelo de 12B como Gemma 4 cabe en una tarjeta de 8 GB en Q4. Un modelo denso de 70B necesita unos 40 GB. Un MoE de última generación de 671B necesita un pequeño servidor.

Requisitos de VRAM por modelo: la tabla maestra de LLM

La respuesta corta: en Q4_K_M, los modelos pequeños (menos de 14B) caben en tarjetas de consumo de 8-12 GB, los modelos medianos (24-32B) piden 16-24 GB, un modelo denso de 70B necesita unos 40 GB, y los modelos MoE de última generación se disparan a cientos de gigabytes porque cada experto tiene que estar residente en memoria. Aquí tienes el panorama completo en un solo sitio. Todas las cifras son la memoria solo para los pesos, calculadas a partir del número de parámetros de cada modelo y verificadas con las fichas oficiales de Meta AI, Qwen y Hugging Face.

Hay dos cosas que sacar de esta tabla. Primero, la cuantización es la palanca más potente que tienes: bajar de FP16 a Q4 recorta el tamaño en unas 4 veces con una pérdida de calidad casi imperceptible. Segundo, las filas de MoE parecen brutales porque lo son. Qwen3-30B-A3B activa solo 3B parámetros por token, así que corre a la velocidad de un modelo diminuto, pero aun así necesitas tener los 30B completos en memoria para que cada experto esté listo. ¿Quieres los detalles modelo a modelo detrás de estas cifras? Nuestro análisis a fondo de Gemma 4 12B y el resumen de los mejores LLM de código abierto de 2026 cubren los benchmarks y las licencias.

La fórmula de VRAM: calcula cualquier modelo tú mismo

Para calcular el tamaño de cualquier modelo, multiplica su número de parámetros por los bytes por parámetro de tu cuantización, y luego suma un poco para la KV cache y la sobrecarga en tiempo de ejecución. Eso es todo. Los pesos son el término dominante, y la aritmética es lo bastante simple como para hacerla en una servilleta.

La ecuación central para los pesos:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Los valores de bits por peso que necesitas (son las tasas efectivas para los archivos GGUF k-quant, que llevan algo de metadatos de bloque además de la profundidad de bits nominal):

Ejemplo resuelto, Gemma 4 12B en Q4_K_M: 11.95 × 4.5 ÷ 8 = unos 6.7 GB para los pesos. Eso encaja con los aproximadamente 6.6 GB que indica la ficha oficial del modelo y explica por qué cabe en una tarjeta de 8 GB con margen para un contexto modesto. Haz la misma cuenta para un modelo de 70B en Q4 y obtienes 70 × 4.5 ÷ 8 = 39.4 GB, que es la razón por la que "necesitas dos tarjetas de 24 GB o una de 48 GB para un 70B" es la regla general que todo el mundo repite.

El panorama completo añade dos términos más: VRAM total ≈ pesos + KV cache + ~15-20% de sobrecarga. La sobrecarga cubre los búferes de activación, el contexto de CUDA y la fragmentación de memoria, y tu GPU también reserva medio gigabyte más o menos para el driver, así que nunca planees usar el 100% de la VRAM que indica la etiqueta.

Por qué la KV cache es la cifra que te muerde

La KV cache almacena las claves y los valores de atención de cada token que ya está en el contexto, y crece de forma lineal con la longitud del contexto. En prompts cortos es un error de redondeo. Si te acercas a un contexto largo, puede igualar o incluso superar a los propios pesos. Esta es, con diferencia, la razón más común por la que un modelo que "debería caber" lanza un error de memoria insuficiente a mitad de la generación.

La fórmula, por token:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Toma Llama 3.3 70B: 80 capas, 8 cabezas KV, dimensión de cabeza 128, así que kv_dim es 1024. En FP16 eso es 80 × 2 × 1024 × 2 = 327,680 bytes por token, unos 0.31 MB. Multiplica por la longitud del contexto y la historia se escribe sola: a 8K tokens la caché es de unos 2.6 GB, a 32K son unos 10 GB, y a 128K se dispara a alrededor de 41 GB. Esa última cifra va encima de los 40 GB de pesos, así que un "modelo de 40 GB" se convierte sin avisar en un problema de 80 GB en cuanto llenas la ventana de contexto.

Hay dos salidas prácticas. La atención por grupos de consultas (grouped-query attention), que usan todos los modelos recientes, ya reduce bastante el kv_dim frente al antiguo diseño multi-head, así que los modelos modernos son mucho más generosos aquí que Llama 2. Y la mayoría de los motores de inferencia pueden cuantizar la KV cache a 8 bits o 4 bits, reduciendo su tamaño a la mitad o a una cuarta parte con un coste de calidad pequeño. Si estás sirviendo contextos largos en producción, la comparativa entre vLLM y SGLang explica qué backend gestiona esta memoria de forma más eficiente con paged attention.

Modelos MoE: por qué los "parámetros activos" no ahorran VRAM

Esta es la trampa que más dinero le cuesta a la gente. Un modelo Mixture-of-Experts como DeepSeek-V3.2 (671B en total, 37B activos, con la misma arquitectura que V3) o GLM-5.2 (744B en total, 40B activos) enruta cada token a través de un pequeño subconjunto de sus expertos. El marketing se apoya en la cifra de activos porque describe la velocidad: solo pagas el cómputo equivalente a 37B parámetros por token, así que la inferencia es rápida para el tamaño del modelo. Pero cada experto tiene que estar en memoria, listo para ser elegido, lo que significa que tu presupuesto de VRAM lo marca el número total de parámetros, no el de activos.

Así que la lectura honesta de la tabla de arriba es esta: GLM-5.2 corre a la velocidad de un modelo de 40B pero ocupa la memoria de uno de 744B. Por eso estos modelos abiertos de última generación necesitan un servidor de 8 GPU o una máquina grande de memoria unificada, aunque un solo forward pass sea barato. Qwen3-235B-A22B tiene la misma forma a menor escala: rápido por token, pesado de alojar.

La ventaja de MoE se nota en el hardware de memoria unificada. Un Mac Studio con 512 GB de memoria unificada puede alojar un modelo de 671B en Q4 y aun así ejecutarlo a velocidades utilizables, precisamente porque solo se activan 37B, así que la demanda de ancho de banda de memoria por token se mantiene razonable. Si es la primera vez que ejecutas estos modelos en local, empieza con nuestra guía para configurar un LLM local antes de gastar en hardware.

¿Qué cuantización deberías elegir?

Para casi todo el mundo, Q4_K_M es la opción correcta por defecto: mantiene una calidad casi completa mientras recorta el tamaño de FP16 en unas 4 veces. Sube a Q5_K_M o Q8 solo si te sobra VRAM y tienes una tarea sensible a la calidad, y recurre a FP16 solo cuando estés haciendo fine-tuning o comparando contra una referencia. Por debajo de Q4, la degradación de calidad se nota rápido, así que Q3 y niveles inferiores son un último recurso para meter un modelo en una tarjeta que de verdad se queda pequeña.

Una advertencia: la calidad de la cuantización no es igual en todos los modelos. Los modelos muy pequeños (menos de 4B) notan más el efecto de Q4 que los grandes, porque tienen menos redundancia de sobra. En un modelo de 70B, Q4 frente a Q8 es difícil de distinguir en la mayoría de tareas. En un modelo de 1.7B, la diferencia sí se nota.

¿Qué GPU necesitas en realidad?

Cruza la columna de Q4 de la tabla maestra con una tarjeta que tenga algo de margen para la KV cache. Aquí tienes el mapeo práctico desde el hardware de consumo económico hasta el centro de datos, con el nivel de modelo que cada categoría ejecuta cómodamente en Q4.

Apple Silicon merece una mención especial porque la memoria unificada cambia el cálculo. Un Mac no separa la VRAM de la RAM del sistema, así que una máquina de la serie M con 128 GB puede cargar modelos que necesitarían varias GPU discretas, a cambio de sacrificar el rendimiento máximo por la capacidad de meter pesos enormes en un solo escritorio. Para ver qué backends sacan más partido a cualquiera de estas tarjetas, nuestro resumen de las mejores herramientas para ejecutar LLM en local compara las diferencias de velocidad reales.

Cómo calculamos la VRAM para despliegues de clientes

En Techsy desplegamos modelos abiertos para clientes con la frecuencia suficiente como para que calcular la VRAM sea la primera conversación, antes de elegir el modelo, antes de los prompts, antes que nada. Nuestro método es aburrido a propósito, porque el modo de fallo (un OOM en producción bajo carga de contexto real) sale caro. Este es el proceso que seguimos de verdad.

Empezamos con las cuentas de la tabla y después medimos. Tras cargar un modelo comprobamos el consumo real residente en lugar de fiarnos de la estimación:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

La lección que se repite siempre: los equipos calculan para los pesos y se olvidan de la KV cache, y luego se preguntan por qué un modelo que cargó bien se cae a la tercera petición larga en una demo. Nosotros calculamos para los pesos más la KV cache en el contexto máximo que la aplicación va a usar de verdad, más margen, y limitamos --ctx-size para que una petición descontrolada no tumbe la máquina por OOM. Para cualquier cosa de cara al cliente, preferimos ejecutar un 32B cuantizado que nunca se caiga antes que un 70B en FP16 que se quede sin memoria bajo carga.

Si estás valorando si autoalojar un modelo abierto o quedarte con una API gestionada, ese equilibrio (coste de hardware y carga operativa frente a precio por token y control) es justo lo que nuestro equipo analiza en un proyecto de integración de IA. Si te viene bien que alguien haga las cuentas con tu carga de trabajo real, pide una consultoría gratuita y lo calculamos juntos.

Preguntas frecuentes

¿Cuánta VRAM necesito para ejecutar un modelo de 70B?

Un modelo denso de 70B como Llama 3.3 70B necesita unos 40 GB de VRAM para los pesos en Q4_K_M, así que cuenta con una tarjeta de 48 GB (RTX 6000 Ada) o dos de 24 GB. Suma varios gigabytes más para la KV cache si usas un contexto largo, lo que empuja los requisitos prácticos hacia 48 GB o más.

¿Cuánta VRAM necesitan Llama, Qwen o DeepSeek?

Depende por completo de la variante. Llama 4 Scout necesita unos 62 GB en Q4, Qwen3-32B unos 18 GB, y Qwen3-8B menos de 5 GB. DeepSeek-V3.2, un MoE de 671B, necesita unos 382 GB porque hay que cargar cada experto. Para los modelos MoE, comprueba siempre el número total de parámetros, no el de activos.

¿Puedo ejecutar un LLM en una GPU de 8GB?

Sí, sin problema. Una tarjeta de 8 GB como una RTX 4060 ejecuta modelos de hasta unos 12B parámetros en Q4_K_M. Gemma 4 12B ocupa unos 6.8 GB, dejando margen para un contexto modesto. Para cualquier cosa más grande, o cuantizas más fuerte, o mantienes el contexto corto, o pasas a una tarjeta mayor.

¿Qué puede ejecutar una GPU de 24GB como la RTX 4090?

Una tarjeta de 24 GB gestiona modelos densos de hasta unos 32B en Q4_K_M con margen para un contexto razonable, así que Qwen3-32B y Mistral Small 3.2 24B van cómodos. También ejecuta el MoE Qwen3-30B-A3B, que carga 30B de pesos pero genera a la velocidad de un modelo de 3B gracias a la activación dispersa.

¿La cuantización perjudica la calidad del modelo?

En Q4_K_M y por encima, la pérdida de calidad es pequeña y a menudo imperceptible en tareas reales, sobre todo en modelos de más de 13B. La diferencia crece cuanto más bajas y cuanto más pequeños son los modelos, así que Q4 en un 70B sale casi gratis mientras que Q4 en un 1.7B se nota. Q8 es prácticamente sin pérdidas si tienes la memoria.

¿Los modelos MoE necesitan menos VRAM que los densos?

No, y este es el malentendido más común. Un modelo Mixture-of-Experts tiene que mantener cada experto en la VRAM, así que su memoria la marca el número total de parámetros. La cifra de parámetros activos solo describe la velocidad de inferencia. GLM-5.2 corre a la velocidad de un modelo de 40B pero necesita la memoria de uno de 744B.

¿La memoria unificada es lo mismo que la VRAM?

A efectos prácticos, para cargar modelos, sí. Apple Silicon y algunos otros sistemas comparten un único grupo de memoria entre CPU y GPU, así que un Mac de 128 GB puede cargar modelos que de otro modo necesitarían varias GPU discretas. La contrapartida es el ancho de banda: la memoria unificada suele dar menos rendimiento máximo que una GPU de centro de datos de gama alta, así que los tokens por segundo son menores.

¿Puedo descargar parte de un modelo a la RAM del sistema o a la CPU?

Sí. Motores como llama.cpp y Ollama te dejan mantener algunas capas en la GPU y el resto en la RAM del sistema con una opción como --n-gpu-layers. Esto te permite ejecutar un modelo demasiado grande para tu VRAM, pero cada capa en la CPU ralentiza mucho la generación, así que úsalo para hacer posible un modelo, no para que vaya rápido.

¿Cómo calculo la VRAM para un modelo que no está en la tabla?

Multiplica el número de parámetros en miles de millones por los bits por peso de tu cuantización, y luego divide entre 8. Para Q4_K_M usa unos 4.5 bits, así que un modelo de 40B necesita 40 × 4.5 ÷ 8 = unos 22.5 GB para los pesos. Suma un 15-20% de sobrecarga más tu KV cache para obtener el requisito real.