Estima la VRAM que necesita un LLM y comprueba si cabe en tu GPU.
Compara el coste de API por solicitud y mensual en OpenAI, Anthropic y Gemini, con la fecha de verificación.
Abrir →Pega un documento y mira el troceado RAG y el coste de embeddings en vivo. Nada se sube.
Abrir →Convierte entre unidades de 12 categorías: longitud, peso, temperatura, área, volumen y más.
Abrir →Aún no hay comentarios. ¡Sé el primero!
La calculadora de VRAM de LLM estima cuánta memoria necesitas para EJECUTAR un modelo de lenguaje grande en local o autoalojado. Total ≈ pesos + caché KV + sobrecarga de ejecución, donde pesos = parámetros × bits por peso ÷ 8 y caché KV = 2 × capas × cabezas KV × dimensión de cabeza × bytes por elemento × contexto × secuencias concurrentes. Elige un modelo, una cuantización y un dispositivo y te dice si cabe, el margen, el contexto más largo que cabe y un techo de velocidad de generación.
Total ≈ pesos + caché KV + sobrecarga de ejecución. Pesos = parámetros × bits por peso ÷ 8; por ejemplo, un modelo de 8000 millones de parámetros necesita unos 15 GiB en FP16 (16 bits) y unos 4,6 GiB en Q4_K_M (unos 4,9 bits). La caché KV crece con la longitud del contexto y el número de secuencias simultáneas, así que ajusta ambos.
Por cada token procesado el modelo guarda las Key y Value de cada capa para no recalcularlas al generar. Tamaño = 2 × capas × cabezas KV × dimensión de cabeza × bytes por elemento × longitud de contexto × secuencias, así que es proporcional a la longitud del contexto. Los modelos con atención por consultas agrupadas (menos cabezas KV) o ventanas deslizantes necesitan mucho menos.
Menos bits hacen los pesos más pequeños y normalmente más rápidos, a costa de la calidad. Q8_0 se acerca al original, Q5_K_M y Q6_K son compromisos habituales, Q4_K_M es el punto de partida usual cuando la memoria escasea, y la pérdida de calidad se nota por debajo de Q3. La tabla muestra si cada nivel cabe con tus ajustes actuales.
Hay que cargar todos los expertos, así que los pesos usan los parámetros TOTALES, no los parámetros activos para cada token. La velocidad de generación, en cambio, depende de los parámetros ACTIVOS, por eso los modelos MoE suelen usar mucha memoria sin ser especialmente lentos.
Normalmente no. Por defecto el sistema deja que la GPU use solo una parte de la memoria unificada (aproximadamente de dos tercios a tres cuartos), así que elegir «Memoria unificada de Apple» considera utilizable el 75 %. Elige «Proporción utilizable personalizada» para ajustarla a tu configuración real.
Se supone que los pesos y la caché KV se reparten a partes iguales entre las tarjetas y cada tarjeta paga su propia sobrecarga fija de ejecución, así que el total es algo mayor que con una sola tarjeta. El reparto real (paralelismo de tensores o de tuberías) y la sobrecarga de comunicación dependen del motor, así que deja margen extra.
Es una estimación de planificación solo para INFERENCIA: pesos, caché KV y una sobrecarga ajustable. El uso real varía según el motor (vLLM, llama.cpp y otros), el procesamiento por lotes, la versión de CUDA y los ajustes de KV paginada. El entrenamiento y el ajuste fino necesitan mucha más memoria (gradientes, estado del optimizador, activaciones) y quedan fuera de esta herramienta.
Generar cada token lee una vez los pesos activos, así que con un tamaño de lote de 1 el techo es aproximadamente «ancho de banda de memoria ÷ bytes de pesos leídos por token». Es un límite teórico que ignora los límites de cómputo, las lecturas de la caché KV y la sobrecarga del software, así que la velocidad real suele ser menor. Solo aparece después de introducir el ancho de banda de tu dispositivo.
| Cuantización | bpw | Pesos | Total | ¿Cabe? |
|---|---|---|---|---|
| FP32 | 32 | 29,92 GiB | 34,91 GiB | No |
| FP16 | 16 | 14,96 GiB | 18,45 GiB | Sí |
| Q8_0 | 8.5008 | 7,95 GiB | 10,74 GiB | Sí |
| FP8 | 8 | 7,48 GiB | 10,23 GiB | Sí |
| Q6_K | 6.5633 | 6,14 GiB | 8,75 GiB | Sí |
| Q5_K_M | 5.7036 | 5,33 GiB | 7,87 GiB | Sí |
| Q5_K_S | 5.5704 | 5,21 GiB | 7,73 GiB | Sí |
| Q4_K_M | 4.8944 | 4,58 GiB | 7,03 GiB | Sí |
| Q4_K_S | 4.6672 | 4,36 GiB | 6,80 GiB | Sí |
| Q3_K_L | 4.2979 | 4,02 GiB | 6,42 GiB | Sí |
| Q3_K_M | 3.996 | 3,74 GiB | 6,11 GiB | Sí |
| Q3_K_S | 3.6429 | 3,41 GiB | 5,75 GiB | Sí |
| Q2_K | 3.1593 | 2,95 GiB | 5,25 GiB | Sí |
Las especificaciones de los modelos proceden de los archivos config.json de Hugging Face y los metadatos de safetensors (verificadas el 2026-10-20); los valores de bpw de la cuantización son mediciones de llama.cpp en Llama-3.1-8B y difieren ligeramente en otros modelos.
Es una estimación de planificación de la memoria necesaria para EJECUTAR (inferir) un modelo, no para entrenarlo ni ajustarlo. El uso real varía según el motor (vLLM, llama.cpp, TensorRT-LLM…), el batching y la versión de CUDA, así que deja algo de margen.
