Cuando un cliente pregunta «¿qué GPU para un LLM local?», en la mayoría de los casos tiene una sola pregunta en mente: ¿me cabe el modelo que quiero usar? La respuesta depende de tres números — el tamaño de los pesos del modelo, el tamaño de la KV cache para el contexto dado y el overhead del framework. Los tres se pueden calcular de antemano. Aun así, la mayoría de las decisiones de hardware se toman a ojo, y el resultado es o un servidor innecesariamente caro o un servidor que no da la talla.
Este artículo aporta cifras concretas: cuánta VRAM ocupa realmente un modelo de 7B, 13B, 34B y 70B en distintos formatos de cuantización, qué cabe en una tarjeta de 24 GB / 48 GB / 80 GB, y cuándo tiene sentido ir a multi-GPU.
La fórmula básica: pesos del modelo
La estimación más sencilla de VRAM para los pesos solos:
VRAM (GB) ≈ (número de parámetros en miles de millones × número de bits) / 8Ejemplos: - Modelo 7B, FP16 (16 bits): 7 × 16 / 8 = 14 GB (en la práctica con overhead ~16–18 GB) - Modelo 7B, Q4_K_M (4 bits): 7 × 4 / 8 = 3,5 GB — en la práctica por el overhead alrededor de 5–7 GB - Modelo 70B, FP16: 70 × 16 / 8 = 140 GB - Modelo 70B, Q4_K_M: 70 × 4 / 8 = 35 GB — en la práctica alrededor de 38–40 GB
La fórmula de los pesos es solo la base. A ella siempre se suma la KV cache, el overhead del framework de serving y, en el caso de la cuantización, también los buffers de descuantización.
Qué es la KV cache y por qué importa
Durante la inferencia el modelo genera tokens uno a uno. Para no tener que recalcular toda la secuencia con cada nuevo token, almacena resultados intermedios — los llamados pares clave-valor (key-value pairs) de cada capa de atención (attention layer). Esos resultados intermedios forman la KV cache.
La KV cache crece linealmente con la longitud de la secuencia. En despliegues en producción con requests concurrentes se convierte rápidamente en un problema tan grande como los propios pesos.
Tamaños orientativos de KV cache para modelos habituales:
- Modelo 7B, contexto de 8K, 1 request paralelo: ~1–2 GB
- Modelo 7B, contexto de 32K, 4 requests paralelos: ~8–16 GB
- Modelo 70B, contexto de 32K, 1 request: ~8–12 GB
- Modelo 70B, contexto de 128K, 1 request: ~40 GB
Las cifras dependen del número de capas de atención, del número de cabezas y grupos (los modelos modernos utilizan Grouped Query Attention, GQA, que reduce drásticamente la KV cache respecto a la antigua multi-head attention). Cada modelo tiene su propio multiplicador — consulte el fichero de configuración del modelo (config.json en el repositorio de HuggingFace) antes de elegir el hardware.
Consecuencia práctica: si planea contextos largos o un número mayor de usuarios concurrentes, la KV cache decide igual que los pesos. No es un detalle técnico — es la causa principal de los errores OOM en producción.
Qué cabe en 24 GB (RTX 4090, L4)
24 GB es el tier más común para despliegues on-prem de desarrollo y producción pequeña.
Qué cabe cómodamente: - 7B FP16 — pesos ~16–18 GB, el espacio restante para KV cache (~6 GB) es suficiente para contextos medios (8–16K) con pocas peticiones concurrentes - 7B Q8_0 — pesos ~8–9 GB, la KV cache tiene espacio de sobra incluso con contexto de 32K - 13B Q4_K_M — pesos ~8 GB, amplio espacio de KV cache con 8K - 13B Q8_0 — pesos ~14 GB, más ajustado, pero cabe con contextos cortos
Qué no cabe: - 13B FP16 — pesos ~26 GB, supera la capacidad - 34B en cualquier formato habitual — ni en Q4 los pesos (~17–20 GB) + KV cache caben en 24 GB con una carga de trabajo real
Para una tarjeta de 24 GB, Q4_K_M es prácticamente el estándar con modelos de 13B; con 7B tiene libertad para elegir Q8 o FP16 según el contexto que necesite.
Qué cabe en 48 GB (RTX 6000 Ada, A40, L40S)
48 GB abre un espacio significativo para modelos más grandes.
Qué funciona bien: - 13B FP16 — cabe cómodamente, el espacio restante para KV cache es suficiente con contexto de 16–32K - 34B Q4_K_M — pesos ~17–20 GB, suficiente para KV cache en producción - 34B Q8_0 — pesos ~30–34 GB, ajustado, pero funcional con contextos cortos - 70B Q4_K_M — pesos ~38–40 GB, el espacio restante para KV cache (~6–10 GB) limita a contextos cortos (4–8K) o 1 request paralelo
Qué no es ideal: - 70B FP16 — 140 GB, el triple de la capacidad - 70B Q8_0 — ~70–75 GB, sigue superando la capacidad
Una tarjeta de 48 GB puede servir un modelo de 70B en Q4_K_M, pero con contexto limitado. Para la mayoría de los casos de uso B2B — RAG sobre documentos, clasificación, extracción estructurada — un contexto más corto (hasta 8K) es suficiente.
Qué cabe en 80 GB (A100, H100, H200)
80 GB es el tier donde la mayoría de los despliegues en producción de modelos de 70B funcionan sin compromisos.
- 70B FP16 — pesos ~140 GB, tampoco cabe aquí. Necesita al menos dos tarjetas.
- 70B Q8_0 — pesos ~70–75 GB, cabe, quedan ~5–10 GB para KV cache — limita a contextos muy cortos o 1 request
- 70B Q4_K_M — pesos ~38–40 GB, espacio restante ~38–40 GB para KV cache — cómodo para contexto de 32K, 2–4 requests concurrentes
- 34B FP16 — pesos ~54–68 GB, cabe con un espacio razonable para KV cache
En una H100 80GB con un modelo 70B Q4_K_M usando vLLM o SGLang obtendrá serving en producción con un throughput adecuado para decenas de usuarios concurrentes.
Cuantización: dónde ahorrar sin perder calidad
La cuantización reduce la precisión de los pesos (de FP16/BF16 a INT8, INT4, etc.) a cambio de un menor footprint de VRAM y una inferencia más rápida. La pregunta no es «si cuantizar» — sino dónde se pierde calidad y dónde no.
Retención de calidad orientativa respecto a FP16:
- Q8_0 (GGUF): ~98–99 % — prácticamente indistinguible. Elección estándar cuando hay suficiente VRAM.
- Q4_K_M (GGUF): ~92–95 % — el punto óptimo. La mayoría de los casos de uso B2B (RAG, clasificación, extracción, lectura de documentos) no notará la diferencia.
- AWQ 4-bit: ~93–96 % — ligeramente mejor para coherencia de texto y código. Requiere GPU NVIDIA, se integra limpiamente con
vLLM. - GPTQ 4-bit: ~90–93 % — máximo throughput en el stack NVIDIA, calidad algo inferior a AWQ.
- Q2 (GGUF): degradación notable — perceptible en razonamiento complejo, generaciones largas y textos multilingües.
La diferencia de perplejidad entre Q4 y BF16 es inferior al 6 % en los benchmarks. Para la mayoría de los casos de uso industriales es despreciable. La pérdida se produce cuando el modelo necesita razonamiento preciso de varios pasos o genera textos largos y coherentes — ahí Q4 a veces pierde el hilo respecto a Q8.
Puede leer en detalle sobre los formatos de cuantización, sus diferencias y casos de uso en la visión general de cuantización GGUF, AWQ, GPTQ.
Multi-GPU: cuándo y cómo
Cuando el modelo no cabe en una sola tarjeta, tiene dos opciones: cuantizar o añadir GPUs. A veces necesita ambas.
Tensor parallelism — el modelo se divide por capas (o por cabezas de atención) entre varias GPUs. vLLM y SGLang lo gestionan de forma nativa. Con dos A100 80GB obtendrá efectivamente 160 GB de VRAM y podrá servir 70B FP16.
Pipeline parallelism — distintos bloques del modelo se ejecutan en GPUs diferentes en cadena. Menos eficiente que el tensor parallelism (tiempo de inactividad en la transición entre tarjetas), pero funciona también en tarjetas sin NVLink.
Recomendaciones prácticas: - 2× RTX 4090 (2× 24 GB = 48 GB): 34B Q4_K_M cómodamente, 70B Q4_K_M justo — cabe, pero la KV cache queda limitada - 2× A100 80 GB (2× 80 GB = 160 GB): 70B FP16 sin compromisos, 70B Q8_0 con KV cache amplia - NVLink entre tarjetas reduce significativamente el overhead de comunicación en tensor parallelism — para despliegues en producción preferir tarjetas con soporte NVLink (A100, H100, RTX 6000 Ada)
La mayoría de las GPUs de consumo (RTX 4090) no tienen NVLink — se comunican por PCIe, lo que aumenta la latencia en la distribución multi-GPU. Para fines de desarrollo es suficiente; para producción con bajas latencias vale la pena la inversión en GPUs de clase workstation.
Overhead del framework de serving
A los pesos y la KV cache se añade el overhead del propio sistema de serving. vLLM utiliza PagedAttention — gestiona la KV cache en páginas como el SO gestiona la memoria, lo que reduce la fragmentación del desperdicio típico del 60–80 % a menos del 4 %. Aun así, reserve espacio adicional:
- Overhead de `vLLM`: típicamente 1–3 GB extra para buffers de activación, prefetch y scheduling
- Overhead de `SGLang`: comparable a vLLM, más el árbol RadixAttention para el prefix caching
Regla general: calcule con una reserva de ~10–15 % sobre los pesos estimados + KV cache. Para una tarjeta de 24 GB, apunte a ~20–22 GB de utilización efectiva, no a 24 GB.
A diferencia de los frameworks de producción, Ollama usa llama.cpp bajo el capó — es excelente para el escritorio del desarrollador y experimentos de un solo usuario, pero no está diseñado para requests concurrentes. Para 8 usuarios paralelos, vLLM es notablemente más rápido (aprox. 2–3×). Encontrará más información sobre las diferencias entre soluciones de serving en la comparativa vLLM vs SGLang vs Ollama.
Referencia práctica: qué para qué
Resumen para los escenarios más habituales:
Workstation de desarrollo, usuario único: - Modelos 7B–13B, contexto corto → 1× RTX 4090 (24 GB) con Q4_K_M o Q8_0 - Modelo 34B → 2× RTX 4090 o 1× RTX 6000 Ada (48 GB) con Q4_K_M
Servidor de producción, 5–20 usuarios concurrentes: - 7B FP16 o Q8_0 → 1× A40 o L40S (48 GB) - 13B–34B Q4_K_M → 1× A40 o L40S - 70B Q4_K_M con contexto corto → 1× A100 80 GB o H100 80 GB - 70B Q4_K_M con contexto largo, mayor throughput → 2× A100 o 2× H100
On-prem empresarial, sector regulado: - Calidad sin compromisos → 70B Q8_0 o FP16 → 2× H100 80 GB (NVLink) - Si tiene sentido el on-prem para su caso de uso desde la perspectiva del RGPD y los costes, consulte también LLM on-prem para sectores regulados
Para cada una de estas decisiones se aplica lo mismo: la capacidad de cómputo es solo una cara de la ecuación. Igual de importante es lo que quiere del modelo — y lo que el modelo sabría si estuviera correctamente fine-tuneado con sus datos. Sobre cuándo instalar una GPU mayor y cuándo conviene más hacer fine-tuning de un modelo más pequeño hablamos en el artículo modelo pequeño fine-tuneado vs modelo base grande.
Preguntas frecuentes
¿Cabe un modelo de 70B en una RTX 4090?
No de forma útil. La RTX 4090 tiene 24 GB de VRAM. Los pesos de un modelo de 70B en Q4_K_M ocupan alrededor de 38–40 GB — casi el doble de la capacidad. Para hacer inferencia de un modelo de 70B necesita o bien dos tarjetas (2× 24 GB via PCIe tensor parallelism), o bien una tarjeta de 48 GB donde solo cabrá con un contexto muy limitado.
¿Cuál es la diferencia entre la VRAM de la GPU y la RAM del sistema en inferencia?
El modelo debe cargarse en la VRAM de la GPU — la RAM del sistema no puede sustituirla en la inferencia por GPU. La inferencia por CPU (via llama.cpp sin GPU) funciona desde la RAM del sistema, pero es órdenes de magnitud más lenta. Algunas soluciones (por ejemplo, llama.cpp con partial offloading) cargan parte de las capas en VRAM y dejan el resto en RAM — utilizable en la práctica para experimentos de desarrollo, no para producción.
¿Cuánta VRAM añade un contexto largo?
Depende del modelo. Orientativamente: con un modelo de 7B, cada 8K tokens de contexto añaden ~1–2 GB de KV cache. Con un modelo de 70B son ~5–10 GB por cada 8K tokens. Los modelos modernos con Grouped Query Attention (GQA) son notablemente más eficientes que los más antiguos. Antes de comprar el hardware, compruebe el parámetro num_key_value_heads en el fichero de configuración del modelo objetivo.
¿Es suficiente la cuantización Q4_K_M para documentos corporativos y RAG?
En la mayoría de los casos, sí. Para RAG sobre documentación corporativa (extracción de información, categorización, resumen) la diferencia entre Q4_K_M y FP16 es en la práctica difícil de medir. La degradación aparece en razonamiento complejo de varios pasos o en la generación de textos largos y coherentes. Si tiene dudas, pruebe el caso de uso concreto con Q4_K_M y compárelo con Q8_0 — el resultado suele sorprender.
¿Cuándo optar por multi-GPU en lugar de una tarjeta más grande?
Una tarjeta más grande suele ser la mejor opción cuando existe (menor overhead de comunicación, gestión más sencilla). Multi-GPU tiene sentido cuando: (1) el modelo físicamente no cabe en una sola tarjeta ni con cuantización agresiva, (2) necesita redundancia para alta disponibilidad, o (3) planea atender a un gran número de requests concurrentes y el throughput es la métrica principal.
*Elegir la GPU correcta para la inferencia local es a primera vista una cuestión técnica — en realidad es una decisión de arquitectura que afecta a los costes, la ventana de contexto, el número de usuarios concurrentes y la disponibilidad del sistema. En MP Industrial Solutions ayudamos a las empresas a pasar del caso de uso objetivo, pasando por la selección del modelo, hasta la recomendación de hardware concreta — también con el cálculo del TCO frente a la API en cloud. Si se está preparando para su primer despliegue on-prem o está revaluando un servidor existente, con mucho gusto analizamos sus cifras.*