LLM Calculadora de VRAM para alojamiento propio

Alojar por tu cuenta un LLM implica ejecutar la inferencia en hardware que controla el operador, en lugar de a través de una API de terceros, lo que cambia el coste, el control de los datos y el perfil de privacidad. El hecho de que un modelo pueda ejecutarse depende de la memoria.

LLM Calculadora de compatibilidad

La calculadora estima la VRAM o la memoria unificada que necesita un modelo para ejecutarse localmente, en función del modelo, su precisión, la longitud de contexto y el hardware de destino. Indica si una configuración encaja, el reparto de memoria entre pesos, caché KV y sobrecarga, y los modelos que puede ejecutar una GPU o un Mac determinados. Los formatos de cuantización y los anchos de precisión siguen la documentación de Transformers de Hugging Face. ¹

Consulta nuestra metodología de cálculo de VRAM de LLM autoalojado para conocer todos los cálculos que hay detrás de estas estimaciones.

Hardware para alojamiento propio: GPU y Apple Silicon

Dos cifras deciden el hardware. La capacidad es el factor que determina si cabe, y la decodificación está limitada por el ancho de banda de memoria, por lo que los tokens por segundo escalan aproximadamente con los GB/s de la tarjeta.

Las filas anteriores muestran una muestra de cada nivel. La calculadora incluye 34 tarjetas en total, añadiendo la A100, la L40S, la RTX A6000, la AMD Radeon RX 7900 XTX y la línea AMD Instinct. En 24 a 32 GB, un modelo de 70B necesita una cuantización agresiva y un contexto corto, o dos tarjetas. Un modelo de 671B necesita 640 GB (8×80 GB) como mínimo estándar. La RTX PRO 6000 es la mejor tarjeta individual de clase estación de trabajo, y su precio de mercado subió a unos $13,000 a mediados de 2026 desde un PVP de $8.565.²

Apple Silicon y memoria unificada: En Apple Silicon, la CPU y la GPU comparten un mismo grupo de memoria, y la GPU direcciona aproximadamente el 75 % de la RAM total de forma predeterminada a través de recommendedMaxWorkingSetSize de Metal, un poco menos en los Mac más pequeños. El límite se puede aumentar con sudo sysctl iogpu.wired_limit_mb=, dejando de 8 a 16 GB para macOS. ^{3 4} Un Mac de 128 GB expone aproximadamente 96 GB a la GPU. El M3 Ultra, con hasta 512 GB, expone aproximadamente 384 GB, suficiente para un modelo de clase 400B a 4 bits con margen de caché KV en un solo dispositivo y sin el coste de replicación multi-GPU. ⁵ Esa vía de dispositivo único para modelos grandes es la ventaja de Apple, aunque AMD Strix Halo (128 GB) y NVIDIA DGX Spark (128 GB) ahora también ofrecen memoria unificada grande a bajo coste. ⁶

LLM Motores de servicio

La elección del motor de servicio se divide por carga de trabajo, no por una única mejor herramienta. Los motores de servicio en producción utilizan atención paginada y procesamiento por lotes continuo para muchos usuarios simultáneos en GPU de centros de datos, mientras que los entornos de ejecución locales se dirigen a un solo usuario en un equipo de escritorio, un portátil o una única GPU. La diferencia aparece bajo carga. Con 64 solicitudes simultáneas, vLLM sirvió aproximadamente 44 veces más tokens por segundo que llama.cpp, cuyo tiempo hasta el primer token superó los 3 minutos. Para un solo usuario, ambos son comparables. ⁷

La calculadora modela ocho motores divididos en los dos grupos:

Dentro del nivel de producción, RadixAttention de SGLang reutiliza prefijos entre solicitudes, TensorRT-LLM congela su presupuesto de activación cuando se compila el motor, y LMDeploy sirve W4A16 y MXFP4 de forma rentable para InternLM, Qwen y DeepSeek. ⁸ En el lado local, ExLlamaV2 con TabbyAPI ajusta un ancho de bits fraccionario medio para llenar exactamente una tarjeta, y MLX usa la memoria unificada de Apple, por lo que el presupuesto es la RAM total. Hugging Face TGI es la única salida. Pasó al modo de mantenimiento en diciembre de 2025 y su repositorio de GitHub se archivó (solo lectura) el 21 de marzo de 2026, dirigiendo a los usuarios a vLLM, SGLang y llama.cpp. ^{9 10}

La mayoría de la gente conoce estos motores a través de aplicaciones de usuario final que los integran. Ollama, LM Studio y AnythingLLM funcionan sobre llama.cpp (LM Studio también sobre MLX), y añaden modelos con un solo comando, una OpenAI-compatible API de localhost y, en el caso de AnythingLLM, RAG sobre PDFs y bases de código. Según las estrellas de GitHub como indicador aproximado de adopción el 2026-07-11, Ollama tiene 175.925 y vLLM 85.979, ambos de código abierto, y AnythingLLM 63.120. Las 5.053 de LM Studio provienen de su repositorio de CLI de código abierto (lmstudio-ai/lms), no de la aplicación de código cerrado, por lo que subestima la adopción real en equipos de escritorio. ^{11 12 13 14}

Un componente interactivo de panorama asigna estas herramientas a casos de uso. Las integraciones y la amplia compatibilidad corresponden a Ollama; el desarrollo y el alto rendimiento, a vLLM; las aplicaciones locales de RAG, a AnythingLLM; y la experimentación apta para principiantes, a LM Studio.

Modelos de lenguaje de gran tamaño de código abierto

Los modelos de pesos abiertos publican su arquitectura y sus archivos de pesos, de modo que cualquiera puede descargarlos, modificarlos y ejecutarlos, normalmente desde Hugging Face. La frontera autoalojable de mediados de 2026 ha superado con creces la era de Qwen2.5 y Llama-3:

Las columnas de totales y activos son la distinción fundamental. Los parámetros totales determinan la memoria y el número de GPU, y los parámetros activos determinan la computación. DeepSeek-V4-Flash y GLM-5.2 llegaron como pesos abiertos en 2026, Gemma 4 cambió la licencia de la familia a Apache 2.0, y GPT-OSS incluye expertos MoE en MXFP4 nativo. ^{15 16 17 18 19}

Los buques insignia propietarios (OpenAI GPT-5.6, Google Gemini 3.1 Pro, Anthropic Claude Opus 4.8, xAI Grok 4.5) no se pueden descargar ni autoalojar; son solo API, normalmente detrás de un endpoint compatible con OpenAI. Un despliegue solo local renuncia a todo aquello en lo que esos modelos son mejores en una tarea determinada. ^{20 21 22}

Cuantización y dimensionamiento de MoE

La cuantización en 2026 no consiste tanto en redondear pesos después del entrenamiento como en puntos de control que incluyen bits bajos desde el diseño, junto con decisiones de arquitectura que reducen la caché antes de que entre la cuantización.

Puntos de control nativos de bits bajos: Los modelos abiertos de vanguardia incluyen cada vez más cuantización consciente. GPT-OSS incluye sus expertos MoE en MXFP4 (E2M1 con una escala compartida de 8 bits, 4.25 bits por parámetro), por lo que el 120B cabe en unos 63 GB, una sola 80 GB GPU, mientras que una estimación ingenua en BF16 exigiría unos 234 GB repartidos en tres GPU. DeepSeek-V3 y R1 incluyen FP8 nativo a aproximadamente 1 byte por parámetro. Los pesos deben dimensionarse según el dtype real del punto de control, no según el recuento de parámetros. ^{23 24}

La trampa de los bits efectivos de GGUF: Los archivos GGUF mezclan precisiones, con escalas FP16 por bloque y tensores de embedding y salida sin cuantizar, por lo que el nombre es un mínimo, no el tamaño. Q4_K_M equivale a unos 4.9 bits efectivos (0.61 bytes por parámetro), no 4.0. Q8_0 son 8.5 bits (1.06 bytes por parámetro), no 8.0. Una calculadora basada en el número de bits subdimensiona los pesos en aproximadamente un 20 % en Q4 y un 6 % en Q8. Los cuantizadores IQ como IQ4_XS (unos 4.25 bits) igualan la calidad de Q4_K_M con un tamaño menor. ²⁵

Cuantización de la caché KV: Reducir el dtype de KV reduce linealmente toda la caché y es independiente de la precisión de los pesos. La caché KV en FP8 (e4m3) la reduce a la mitad (Llama-3-8B a 128k, lote 1, de 16.0 GiB en BF16 a 8.0 GiB en FP8) con una calidad prácticamente gratuita. INT4 la reduce a una cuarta parte, pero requiere una evaluación. En vLLM es una sola opción (--kv-cache-dtype fp8). ²⁶

La atención como ahorro de memoria: Multi-head Latent Attention (MLA, empleada por DeepSeek) almacena en caché un único latente compartido de bajo rango (unos 576 elementos por token y capa) en lugar de claves y valores por cabeza, aproximadamente 30 veces más pequeño que la lectura nominal de 128 cabezas. Eso es lo que permite que un modelo de 671B sirva un contexto de 128k con unos 8.6 GiB de KV. La atención de ventana deslizante y local-global (Gemma 2 y 3, GPT-OSS, Llama 4) limita la mayoría de las capas a una ventana fija en lugar del contexto completo, reduciendo la KV de contexto largo entre 10 y 40 veces frente a una estimación ingenua totalmente global. Estas son fijas por familia de arquitectura, no parámetros ajustables. ²⁷

Descarga y particionado: Cuando los pesos superan la memoria de la GPU, la descarga mueve las partes inactivas, como los expertos MoE no utilizados, entre la memoria de la GPU y la RAM del sistema, más lenta, sacrificando tokens por segundo a cambio de poder ejecutarse. ²⁸ El particionado divide un modelo entre varios dispositivos o niveles de memoria, que es como un modelo de 671B ocupa un nodo de 8 GPU. Ambos amplían el alcance de un hardware fijo a costa del ancho de banda.

Ventajas y desventajas del alojamiento propio

El argumento a favor del alojamiento propio es el control de los datos, el coste a gran volumen y la libertad de configuración. El argumento en contra es el coste del hardware, la carga operativa y la brecha de los modelos propietarios.

Residencia de datos y cumplimiento: La transferencia transfronteriza de datos es el motor del cumplimiento. Según el RGPD, enviar datos personales fuera de la UE puede activar salvaguardas legales, obligaciones contractuales o restricciones. La Ley de IA de la UE añade una segunda capa, pero se está aplicando de forma gradual y no está plenamente en vigor. A mediados de 2026, las prohibiciones (aplicables desde el 2 de febrero de 2025) y las obligaciones de los modelos de IA de propósito general (GPAI) (desde el 2 de agosto de 2025) ya están en vigor, mientras que los requisitos de alto riesgo en materia de gestión de riesgos, auditabilidad y gobernanza se han aplazado al 2 de diciembre de 2027 para los sistemas independientes de alto riesgo del anexo III y al 2 de agosto de 2028 para los sistemas integrados del anexo I en virtud del paquete Ómnibus Digital 2025-26. ^{29 30 31} Ejecutar la inferencia dentro de la jurisdicción, en una red controlada, mantiene los datos sensibles fuera de las manos de terceros, lo que constituye el argumento de la IA soberana para las finanzas, la sanidad y el sector público.

Coste y control: El alojamiento propio comienza siendo caro, con GPU de consumo o un servidor pequeño, pero la inferencia local puede reducir las API tarifas recurrentes para equipos que generan un alto volumen de solicitudes. También elimina la dependencia del proveedor y los límites impuestos a la ventana de contexto, la configuración de inferencia y la integración, y da acceso directo a los pesos para el ajuste fino con datos privados.

Las contrapartidas: La memoria de la GPU es el límite vinculante, y algunas cargas de trabajo siguen necesitando de 16 a 48 GB de VRAM, fuera del alcance de equipos pequeños. El despliegue añade gestión de dependencias, resolución de problemas de CUDA y kernels, supervisión y actualizaciones que un proveedor en la nube asumiría de otro modo. El rendimiento es responsabilidad del operador, desde el procesamiento por lotes y el particionado hasta la utilización del hardware. Y los modelos propietarios más potentes siguen siendo solo API, por lo que un despliegue local acepta una brecha de capacidades en las tareas en las que lideran.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Metodología de cálculo de VRAM para LLM autoalojados

La huella de memoria de un modelo es la suma de cuatro términos que se calculan de forma independiente y se suman, no una única cifra derivada del número de parámetros:

VRAM_total = Weights + KV cache + Activations + Overhead

El error de estimación más común reduce los tres últimos términos a un margen fijo del 20 % sobre los pesos. Eso se aproxima en un tamaño de modelo y es incorrecto en los demás, porque los tres términos escalan de forma diferente. ³²

Pesos: La memoria de los pesos es parámetros por bytes por parámetro. BF16 y FP16 almacenan 2.0 bytes por parámetro, y FP8 e INT8 almacenan aproximadamente 1.0. La trampa está en 4 bits, que no son 0.5 bytes por parámetro. El INT4 agrupado real (GPTQ, AWQ) se sitúa entre 0.52 y 0.55, y GGUF Q4_K_M equivale a unos 0.61 bytes por parámetro (4.9 bits efectivos, no 4.0). GGUF Q8_0 son 8.5 bits (1.06 bytes por parámetro), no 8.0. Suponer 0.5 infravalora un modelo de 70B en unos 8 GB, lo que cambia el veredicto de ajuste. ²⁵

La mezcla de expertos dimensiona todos los expertos, no solo los activos: Todos los pesos de los expertos permanecen residentes en VRAM aunque solo unos pocos se activen por token. Mixtral-8x7B necesita unos 28 GB en Q4 para los 46.7B parámetros completos, no los 13B activos. Los parámetros totales determinan la memoria y el número de GPU, y los parámetros activos determinan la computación. Una calculadora que dimensiona por parámetros activos da falsamente por válidos modelos MoE grandes.

Caché KV: La caché clave-valor es 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element. La mayoría de los modelos actuales utilizan atención de consulta agrupada (GQA), donde muchas cabezas de consulta comparten unas pocas cabezas KV, de modo que se almacenan en caché pares n_kv_heads, lo que reduce la caché 4 veces (Llama-3-8B) a 8 veces (Llama-3-70B) frente a la atención multicabeza completa. Tanto head_dim como n_kv_heads se leen del config.json de cada modelo, en lugar de derivarse del tamaño oculto y del número de cabezas, ya que familias como Gemma (head_dim 256) y Qwen3 (128) se dimensionarían mal en aproximadamente 2 veces. La caché crece linealmente tanto con la longitud de contexto como con el tamaño del lote, y en contextos largos rivaliza o supera a los pesos. Llama-3-8B almacena en caché 128 KiB por token, por lo que con un contexto de 128k y lote 1, una caché KV en FP16 es de 16.0 GiB, igual a los 16 GB de pesos en BF16. Una caché KV en FP8 reduce eso a la mitad. ³³

La sobrecarga es un mínimo, no un porcentaje: La sobrecarga del framework es un mínimo fijo por GPU (contexto de CUDA y kernels, aproximadamente de 1 a 2 GB por GPU) más una fracción pequeña y acotada, no una parte de los pesos. Un 20 % fijo subestima los modelos pequeños, donde solo el contexto de CUDA puede superar el 20 % de un modelo de 6 GB, y sobreestima los grandes, donde un modelo de 140 GB no necesita 28 GB de contexto. El mínimo por tramos es el modelo exacto, y el 20 % fijo sirve como estimación rápida. ³⁴

Activaciones y el motor de servicio: El término de activación es transitorio. Durante la decodificación, token a token, es pequeño y se integra en el mínimo de sobrecarga, pero el prellenado procesa todo el prompt de una vez, por lo que su pico de activación escala con el tamaño del lote y la longitud del prompt. El mínimo en sí depende del motor. Los servidores paginados (vLLM, SGLang) reservan una parte fija de cada tarjeta mediante una configuración de utilización de memoria, alrededor del 10 % con el valor predeterminado de 0.90, y encajan los pesos y la KV en el resto. Los entornos no paginados (llama.cpp, Ollama) mantienen en su lugar un búfer de cómputo fijo de aproximadamente 1 a 2 GB. Dimensionar ambos de la misma forma se desvía en unos pocos GB.

Varias GPU no se dividen de forma limpia: Dos tarjetas de 24 GB no son 48 GB de espacio útil. Bajo el paralelismo de tensores, los pesos y la caché KV se reparten entre las N tarjetas (W/N y KV/N), pero las activaciones, el contexto de CUDA y los búferes de comunicación NCCL se replican en cada tarjeta, por lo que la huella total es mayor que una estimación de un solo dispositivo con el mismo total. Ese coste de replicación es la razón por la que un modelo de 70B que necesita 43 GB de pesos cabe en dos tarjetas de 24 GB con un contexto corto, y por la que la comprobación segura es el total por GPU en lugar del total dividido por el número de GPU.

Los cuatro términos interactúan en el límite de ajuste. Una configuración se considera Encaja cuando la memoria necesaria es igual o inferior al 90 % de la utilizable, Ajustada en el 10 % superior de la capacidad y No encaja por encima de la utilizable. Los servidores paginados ya reservan ese 10 % mediante la configuración de utilización. Los ejemplos siguientes usan Llama-3 en hardware común, con llama.cpp en las tarjetas de consumo:

Con un contexto de 128k, la caché KV iguala a los pesos, de modo que la longitud de contexto, no el recuento de parámetros, decide el ajuste. La última fila encaja porque los pesos Q4 (~405 GB) se mantienen por debajo de 640 GB con un contexto de 8k. El beneficio de MLA se da en contextos largos, donde mantiene la caché KV de un modelo de 671B lo bastante pequeña como para servir 128k.

Lecturas adicionales

• Cuantización de LLM: BF16 vs FP8 vs INT4
• Motores de inferencia de LLM: vLLM vs LMDeploy vs SGLang
• Benchmark de concurrencia de GPU: H100 vs H200 vs B200 vs MI300X
• Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X
• Los 60+ mejores proveedores de GPU en la nube
• LLM en la nube vs LLM locales
• Precios de LLM: comparativa de los 15+ principales proveedores
• Guía de ajuste fino de LLM para empresas

Preguntas frecuentes

Cita esta investigación

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{LLM Calculadora de VRAM para alojamiento propio}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/self-hosted-llm}},
  note   = {AIMultiple. Recuperado el 31 de Agosto de 2026}
}

Registro de cambios

3 actualizaciones

1. 202612 de Jul

   Se añadió una sección de metodología de cálculo de VRAM para LLM autoalojados.

2. 26 de Ene

   Se añadió una sección, Privacidad y cumplimiento, a Ventajas de los LLM autoalojados.

3. 20254 de Dic

   Se añadió una lista de las 4 mejores herramientas autoalojadas a la introducción.

Enlaces de referencia

1.

Overview · Hugging Face

2.

RTX 5090 vs RTX PRO 6000 Blackwell: Consumer vs Pro GPU for AI (2026) | Spheron Blog

Spheron

3.

recommendedMaxWorkingSetSize | Apple Developer Documentation

4.

Adjust VRAM/RAM split on Apple Silicon · ggml-org/llama.cpp · Discussion #2182 · GitHub

5.

Apple reveals M3 Ultra, taking Apple silicon to a new extreme - Apple

Apple

6.

Personal AI Supercomputer Powered by Blackwell | NVIDIA DGX Spark

7.

llama.cpp vs. vLLM: Choosing the right local LLM inference engine | Red Hat Developer

Red Hat

8.

vLLM, Ollama, LM Studio, llama.cpp: Choosing the best LLM inference engine in 2026 [ Updated ] | BIZON

BIZON

9.

GitHub - huggingface/text-generation-inference: Large Language Model Text Generation Inference · GitHub

10.

Migrate from Hugging Face TGI to vLLM or SGLang on GPU Cloud: A 2026 Move-Off Guide | Spheron Blog

Spheron

11.

GitHub - lmstudio-ai/lms: LM Studio CLI · GitHub

12.

GitHub - ollama/ollama: Get up and running with Kimi-K2.6, GLM-5.2, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models. · GitHub

13.

GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs · GitHub

14.

GitHub - Mintplex-Labs/anything-llm: Stop renting your intelligence. Own it with AnythingLLM. Everything you need for a powerful local-first agent experience · GitHub

15.

DeepSeek V4 Ships 1M Context, Open-Weights

WinBuzzer

16.

Gemma 4: Our most capable open models to date

Google

17.

New Released - Overview - Z.AI DEVELOPER DOCUMENT

Mintlify

18.

Qwen 3.5 to 3.8: Alibaba Open-Weights Guide (2026)

Codersera Blogs

19.

Welcome GPT OSS, the new open-source model family from OpenAI!

Hugging Face

20.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

21.

Introducing Claude Opus 4.8 \ Anthropic

22.

Introducing Grok 4.5 | SpaceXAI

xAI

23.

MXFP4 · Hugging Face

24.

OpenAI gpt-oss LLMs use MXFP4: smaller, faster, cheaper

theregister

25.

Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct

26.

Quantized KV Cache - vLLM

27.

Decoding Multi-Head Latent Attention (Part 1): The KV Cache Memory Bottleneck, Solved.

Vizuara’s Substack

28.

https://arxiv.org/pdf/2312.17238

29.

EU Artificial Intelligence Act | Up-to-date developments and analyses of the EU AI Act

30.

EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes - Gibson Dunn

Gibson Dunn & Crutcher, LLP

31.

EU AI Act Update: Timeline Relief, Targeted Simplification, and New Prohibitions | Inside Privacy

32.

A Practical Guide to LLM Inference at Scale

The Neural Maze

33.

The State of FP8 KV-Cache and Attention Quantization in vLLM | vLLM Blog

vLLM

34.

How LLM Inference Works (Prefill, Decode & the GPU Memory Wall)

Into AI

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario