LLM Calculadora de VRAM para Autohospedaje
Autohospedar un LLM significa ejecutar la inferencia en hardware controlado por el operador en lugar de a través de una API de terceros, lo que cambia el costo, el control de datos y el perfil de privacidad. El 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, según el modelo, su precisión, la longitud de contexto y el hardware objetivo. Indica si una configuración se ajusta, la distribución de memoria entre pesos, caché KV y sobrecarga, y los modelos que una GPU o Mac determinados pueden ejecutar. Los formatos de cuantización y los anchos de precisión siguen la documentación de Hugging Face Transformers. 1
Consulte nuestra metodología de cálculo de VRAM para LLM autohospedados para conocer las matemáticas completas detrás de estas estimaciones.
Hardware para autohospedaje: GPUs y Apple Silicon
Dos números deciden el hardware. La capacidad es la puerta de ajuste, y la decodificación está limitada por el ancho de banda de la memoria, por lo que los tokens por segundo escalan aproximadamente con los GB/s de la tarjeta.
Las filas anteriores muestran cada nivel. La calculadora incluye en total 34 tarjetas, añadiendo la A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX y la línea AMD Instinct. Con 24 a 32 GB, un modelo de 70B necesita una cuantización intensa más 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 única de clase estación de trabajo, y su precio en el mercado subió a aproximadamente $13,000 a mediados de 2026 desde un MSRP de $8,565.2
Apple Silicon y memoria unificada: En Apple Silicon, la CPU y la GPU comparten un único pool de memoria, y la GPU puede acceder aproximadamente al 75% de la RAM total por defecto a través de Metal’s recommendedMaxWorkingSetSize, un poco menos en Macs 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 en KV en un solo dispositivo sin el impuesto de replicación multi-GPU. 5 Esa ruta de dispositivo único para modelos grandes es la ventaja de Apple, aunque AMD Strix Halo (128 GB) y NVIDIA DGX Spark (128 GB) ahora ofrecen memoria unificada de gran tamaño a bajo costo. 6
LLM motores de servicio
La elección del motor de servicio se divide por carga de trabajo en lugar de una única mejor herramienta. Los motores de servicio de producción utilizan atención paginada y procesamiento por lotes continuo para muchos usuarios simultáneos en GPUs de centro de datos, mientras que los tiempos de ejecución locales se centran en un solo usuario en un escritorio, portátil o GPU única. 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. 7
La calculadora modela ocho motores en los dos campos:
Dentro del nivel de producción, RadixAttention de SGLang reutiliza prefijos entre solicitudes, TensorRT-LLM congela su presupuesto de activación cuando se construye el motor, y LMDeploy sirve W4A16 y MXFP4 de manera rentable para InternLM, Qwen y DeepSeek. 8 En el lado local, ExLlamaV2 con TabbyAPI ajusta un ancho de bits promedio fraccional para llenar exactamente una tarjeta, y MLX utiliza la memoria unificada de Apple, por lo que la RAM total es el presupuesto. Hugging Face TGI es la única salida. Pasó a modo de mantenimiento en diciembre de 2025 y su repositorio de GitHub fue archivado (solo lectura) el 21 de marzo de 2026, y se redirige a los usuarios a vLLM, SGLang y llama.cpp. 9 10
La mayoría de las personas conocen estos motores a través de aplicaciones de usuario final que los envuelven. Ollama, LM Studio y AnythingLLM se ejecutan todos sobre llama.cpp (LM Studio también sobre MLX), añadiendo modelos de un solo comando, una API de localhost compatible con OpenAI y, para AnythingLLM, RAG de documentos sobre PDFs y bases de código. Según las estrellas de GitHub como proxy aproximado de adopción a 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 CLI de código abierto (lmstudio-ai/lms) en lugar de la aplicación de código cerrado, por lo que subestima la adopción real en 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, los desarrolladores y el alto rendimiento a vLLM, las aplicaciones RAG locales a AnythingLLM, y la experimentación amigable para principiantes a LM Studio.
Modelos de lenguaje grandes de código abierto
Los modelos de peso abierto publican su arquitectura y archivos de pesos, por lo que cualquiera puede descargarlos, modificarlos y ejecutarlos, normalmente desde Hugging Face. La frontera autohospedable 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 crucial. Los parámetros totales determinan la memoria y el número de GPUs, y los parámetros activos determinan la computación. DeepSeek-V4-Flash y GLM-5.2 llegaron como pesos abiertos en 2026, Gemma 4 re-licenció la familia bajo Apache 2.0, y GPT-OSS envía expertos MoE en MXFP4 nativo. 15 16 17 18 19
Los buque insignia propietarios (OpenAI’s GPT-5.6, Google’s Gemini 3.1 Pro, Anthropic’s Claude Opus 4.8, xAI’s Grok 4.5) no se pueden descargar ni autohospedar; son solo API, normalmente tras un endpoint compatible con OpenAI. Un despliegue exclusivamente local renuncia a lo que esos modelos hagan mejor en una tarea determinada. 20 21 22
Cuantización y dimensionamiento de MoE
La cuantización en 2026 se trata menos de redondear pesos después del entrenamiento y más de puntos de control que se distribuyen con pocos bits por diseño, junto con elecciones de arquitectura que reducen la caché antes de que entre la cuantización.
Puntos de control nativos de pocos bits: Los modelos abiertos de frontera cada vez más se distribuyen conscientes de la cuantización. GPT-OSS distribuye sus expertos MoE en MXFP4 (E2M1 con una escala compartida de 8 bits, 4.25 bits por parámetro), por lo que los 120B caben en aproximadamente 63 GB, una 80 GB GPU, mientras que una estimación ingenua en BF16 exigiría aproximadamente 234 GB en tres GPUs. DeepSeek-V3 y R1 se distribuyen en 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 número de parámetros. 23 24
La trampa de los bits efectivos de GGUF: Los archivos GGUF mezclan precisión, con escalas FP16 por bloque y tensores de embedding y salida sin cuantizar, por lo que el nombre es un mínimo más que el tamaño. Q4_K_M tiene aproximadamente 4.9 bits efectivos (0.61 bytes por parámetro), no 4.0. Q8_0 tiene 8.5 bits (1.06 bytes por parámetro), no 8.0. Una calculadora basada en el número de bits subestima los pesos en aproximadamente 20% en Q4 y 6% en Q8. Los IQ-cuantizados como IQ4_XS (aproximadamente 4.25 bits) ahora igualan la calidad de Q4_K_M con un tamaño menor. 25
Cuantización de la caché KV: Reducir el dtype de la KV escala toda la caché linealmente y es independiente de la precisión de los pesos. La KV en FP8 (e4m3) la reduce a la mitad (Llama-3-8B a 128k, lote 1, de 16.0 GiB BF16 a 8.0 GiB FP8) con una calidad prácticamente gratuita. INT4 la reduce a un cuarto pero requiere evaluación. En vLLM es una bandera (--kv-cache-dtype fp8). 26
Atención como ahorrador de memoria: La Atención Latente Multi-cabeza (MLA, usada por DeepSeek) almacena en caché un único latente compartido de bajo rango (aproximadamente 576 elementos por token por 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 a un modelo de 671B servir un contexto de 128k con aproximadamente 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 respecto a una estimación ingenua totalmente global. Estos son fijos por familia de arquitectura, no parámetros ajustables. 27
Descarga y particionado: Cuando los pesos exceden 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, intercambiando tokens por segundo por la capacidad de ejecutarse en absoluto. 28 El particionado divide un modelo entre varios dispositivos o niveles de memoria, que es como un modelo de 671B abarca un nodo de 8 GPUs. Ambos amplían el alcance del hardware fijo a costa del ancho de banda.
Ventajas y desventajas del autohospedaje
El argumento a favor del autohospedaje es el control de datos, el costo a gran volumen y la libertad de configuración. El argumento en contra es el costo de hardware, la carga operativa y la brecha con los modelos propietarios.
Residencia de datos y cumplimiento: La transferencia de datos transfronteriza es el motor del cumplimiento. Bajo el GDPR, 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á implementando gradualmente en lugar de estar completamente en vigor. A mediados de 2026, las prohibiciones (aplicables desde el 2 de febrero de 2025) y las obligaciones para modelos de IA de propósito general (GPAI) (desde el 2 de agosto de 2025) ya se aplican, mientras que los requisitos de alto riesgo en torno a la gestión de riesgos, auditabilidad y gobernanza se aplazan, hasta el 2 de diciembre de 2027 para los sistemas autónomos de alto riesgo del Anexo III y el 2 de agosto de 2028 para los sistemas integrados del Anexo I, según el 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 salud y el sector público.
Costo y control: El autohospedaje comienza siendo caro, con GPUs de consumo o un pequeño servidor, pero la inferencia local puede reducir los costos recurrentes de API para equipos que generan altos volúmenes de solicitudes. También elimina el bloqueo de proveedor y los límites impuestos en la ventana de contexto, configuraciones de inferencia e 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 aún necesitan de 16 a 48 GB de VRAM, fuera del alcance de equipos más pequeños. El despliegue añade gestión de dependencias, resolución de problemas de CUDA y kernels, monitorización y actualizaciones que de otro modo manejaría un proveedor de nube. 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 capacidad en las tareas donde lideran.
Añadir como fuente preferidaMetodología de cálculo de VRAM para LLM autohospedados
La huella de memoria de un modelo es la suma de cuatro términos que se calculan independientemente y se suman, no una única cifra escalada a partir del número de parámetros:
VRAM_total = Weights + KV cache + Activations + Overhead
El error de estimación más común colapsa los tres últimos términos en un margen fijo del 20% sobre los pesos. Eso es aproximado para un tamaño de modelo y erróneo para los demás, porque los tres términos escalan de manera diferente. 32
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 los 4 bits, que no son 0.5 bytes por parámetro. Los INT4 agrupados reales (GPTQ, AWQ) están en 0.52 a 0.55, y GGUF Q4_K_M tiene aproximadamente 0.61 bytes por parámetro (4.9 bits efectivos, no 4.0). GGUF Q8_0 tiene 8.5 bits (1.06 bytes por parámetro), no 8.0. Suponer 0.5 subestima un modelo de 70B en aproximadamente 8 GB, lo que invierte un veredicto de ajuste. 33
La mezcla de expertos dimensiona cada experto, no los activos: Todos los pesos de los expertos permanecen residentes en VRAM aunque solo unos pocos se activen por token. Mixtral-8x7B necesita aproximadamente 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 GPUs, y los parámetros activos determinan la computación. Una calculadora que dimensione según parámetros activos encaja falsamente modelos MoE grandes.
Caché KV: La caché de 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 usan atención de consulta agrupada (GQA), donde muchas cabezas de consulta comparten unas pocas cabezas KV, por lo que se almacenan en caché pares n_kv_heads, lo que reduce la caché de 4 veces (Llama-3-8B) a 8 veces (Llama-3-70B) en comparación con la atención multi-cabeza 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 el número de cabezas, ya que familias como Gemma (head_dim 256) y Qwen3 (128) se dimensionarían erróneamente en aproximadamente 2 veces. La caché crece linealmente con la longitud de contexto y el tamaño del lote, y en contextos largos rivaliza o supera los pesos. Llama-3-8B almacena en caché 128 KiB por token, por lo que en contexto de 128k y lote 1, una caché KV FP16 es 16.0 GiB, igual a los 16 GB de pesos BF16. Una caché KV FP8 la reduce a la mitad. 34
La sobrecarga es un mínimo fijo, no un porcentaje: La sobrecarga del framework es un mínimo fijo por GPU (contexto CUDA y kernels, aproximadamente de 1 a 2 GB por GPU) más una pequeña fracción acotada, no una proporción de los pesos. Un 20% fijo subestima los modelos pequeños, donde solo el contexto 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 partes es el modelo preciso, y el 20% fijo sirve como estimación rápida. 35
Activaciones y el motor de servicio: El término de activación es transitorio. Durante la decodificación, un token a la vez, 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 un ajuste de utilización de memoria, aproximadamente 10% en el valor predeterminado de 0.90, y ajustan los pesos y la KV dentro del resto. Los tiempos de ejecución 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 manera se desvía en unos pocos GB.
Múltiples GPUs no se dividen limpiamente: Dos tarjetas de 24 GB no son 48 GB de espacio utilizable. Bajo paralelismo de tensores los pesos y la caché KV se dividen entre las N tarjetas (W/N y KV/N), pero las activaciones, el contexto 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 impuesto de replicación es la razón por la que un 70B que necesita 43 GB de pesos cabe en dos tarjetas de 24 GB con un contexto corto, y por la que la verificación segura es el total por GPU en lugar del total dividido por el número de GPUs.
Los cuatro términos interactúan en el límite de ajuste. Una configuración se considera 'Encaja' cuando la memoria requerida es igual o inferior al 90% de la utilizable, 'Ajustado' en el 10% superior de la capacidad, y 'No encaja' por encima de la utilizable. Los servidores paginados ya reservan ese 10% mediante el ajuste de utilización. Los ejemplos siguientes usan Llama-3 en hardware común, con llama.cpp en las tarjetas de consumo:
En un contexto de 128k, la caché KV iguala los pesos, por lo que la longitud de contexto, no el número de parámetros, decide el ajuste. La última fila encaja porque los pesos Q4 (~405 GB) caben dentro de 640 GB en contexto 8k. El beneficio de MLA está en contextos largos, donde mantiene la KV de un modelo 671B lo suficientemente pequeña como para servir 128k.
Lecturas adicionales
- LLM Cuantización: BF16 vs FP8 vs INT4
- LLM Motores de Inferencia: vLLM vs LMDeploy vs SGLang
- GPU Benchmark de Concurrencia: H100 vs H200 vs B200 vs MI300X
- Multi-GPU Benchmark: B200 vs H200 vs H100 vs MI300X
- Los 60+ mejores proveedores de GPU en la nube
- LLM en la nube vs LLM locales
- LLM Precios: Los 15+ mejores proveedores comparados
- LLM Guía de ajuste fino para empresas
Preguntas frecuentes
Un LLM autohospedado es un LLM utilizado para aplicaciones de LLM que se ejecuta completamente en hardware que tú controlas (como tu ordenador personal o servidor privado) en lugar de depender de un servicio en la nube de terceros.
Las técnicas incluyen el uso de frameworks como llama.cpp, bibliotecas como Hugging Face transformers, aplicaciones amigables (Ollama, LM Studio), cuantización de modelos (por ejemplo, GGUF, GPTQ) para reducir necesidades de recursos, paralelismo de modelos para distribuir modelos grandes en múltiples dispositivos, y motores de inferencia optimizados (como vLLM).
Sí, herramientas como vLLM, Ollama y LM Studio pueden ejecutar servidores locales capaces de manejar múltiples solicitudes (a menudo simultáneas). Esto es similar a cómo operan las APIs en la nube, a menudo utilizando procesamiento por lotes para eficiencia.
No, no necesitas permiso de acceso externo ni claves de API de un proveedor para un LLM autohospedado. Dado que lo alojas tú mismo, tienes acceso directo; opcionalmente, puedes configurar tu propia autenticación para tu servidor local si es necesario.
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 Autohospedaje}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Recuperado el 12 de Julio de 2026}
}Enlaces de referencia
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.