Calculadora LLM en local

Cómo calcula la memoria

La memoria que pide un modelo es la suma de sus pesos, su caché KV y el margen del motor. La calculadora la compara con la memoria que la plataforma deja usar, no con la que trae. Todo se expresa en GiB, la unidad en la que se vende la VRAM y la RAM.

• Pesos: parámetros totales × bits por peso / 8. Un MoE carga todos sus expertos aunque use pocos por token. Los bits por peso son los efectivos de cada formato: Q4_K_M ocupa 4,89 bits según la tabla de llama.cpp medida con Llama 3.1 8B, y un MLX de 4 bits con grupos de 64 ocupa 4,5.
• Caché KV: elementos por token × bytes por elemento × contexto × peticiones simultáneas. Los elementos salen del config.json de cada modelo. Las capas de ventana deslizante solo guardan la ventana si el motor lo hace, la atención latente (MLA) guarda un vector comprimido por capa y las capas lineales o Mamba guardan un estado de tamaño fijo.
• Margen del motor: búferes de cálculo y contexto del backend. Es una cifra fija por motor, anotada junto al resultado.

Con contextos largos, la caché KV decide el contexto máximo. Gemma 3 27B, por ejemplo, tiene una ventana de 1.024 tokens en 52 de sus 62 capas. A 32.768 tokens su caché en FP16 ocupa unos 2,9 GiB; contar todas las capas como atención completa daría 15,5 GiB.

Por qué el motor de inferencia cambia el resultado

El mismo modelo con el mismo formato puede caber en un motor y no en otro, porque cada uno reserva la memoria de una manera. Estas son las reglas que aplica la calculadora, leídas en el código o la documentación de cada versión:

Cuando un motor no documenta un comportamiento, la calculadora asume el caso más caro. Dos detalles sorprenden al contrastar la documentación con el código: vLLM reserva por defecto el 92 % aunque su documentación diga 0,9, y oMLX deja 6 GiB libres aunque su README hable de 8.

Colibri se calcula aparte, porque no carga el modelo en memoria. Deja en RAM la parte densa y lee del SSD los expertos que elige el router. Por eso la calculadora compara tu RAM con el mínimo que publica el proyecto y tu disco libre con el tamaño del modelo.

Su velocidad la marca el disco: el techo en frío divide la lectura del SSD entre los GB de expertos que lee cada token. El proyecto solo documenta ese dato para GLM-5.2 (12,7 GB) y DeepSeek V4.1 Flash (4,5 GB), y en OLMoE lo derivamos de su configuración. El mecanismo está explicado en qué es Colibri y cómo lee expertos del disco.

Cuánta memoria puede usar cada plataforma

En una GPU dedicada el modelo tiene toda la VRAM, multiplicada por el número de tarjetas. En memoria unificada no, y la diferencia es grande:

• Mac con Apple Silicon: macOS deja a la GPU 2/3 de la RAM con 32 GiB o menos y 3/4 por encima, según el código del kernel descompilado en la discusión 2182 de llama.cpp. Un Mac de 128 GB ofrece unos 96 GiB. El límite se sube con sudo sysctl iogpu.wired_limit_mb y vuelve al valor por defecto al reiniciar.
• AMD Ryzen AI Max+ 395: en Windows, AMD permite dedicar hasta 96 GB de 128 a la GPU. En Linux la GPU usa por defecto la mitad de la RAM, y el límite del kernel se puede ampliar.
• NVIDIA DGX Spark: no hay un reparto fijo. El sistema ve unos 119,7 GiB de los 128 GB y la GPU usa lo que quede libre.
• Solo CPU: la calculadora descuenta 4 GB para el sistema operativo. Es un supuesto, no una medida.

Cómo estima la velocidad de generación

Generar texto con una sola petición está limitado por el ancho de banda de la memoria: cada token obliga a leer los pesos activos y la caché KV de esa conversación. El techo teórico es el ancho de banda dividido entre esos bytes, y la velocidad real queda por debajo.

La fracción real se calibró con 132 mediciones publicadas de llama-bench en GPUs NVIDIA, AMD, Apple y CPU. No es constante. Por debajo de 30 tok/s de techo, los motores rinden un 84 % del techo (mediana); entre 120 y 250 tok/s, solo un 58 %. Los modelos pequeños sobre memoria rápida chocan antes con el cálculo.

La calculadora muestra el rango intercuartílico del tramo que corresponde y no extrapola más allá del mayor techo medido, 523 tok/s.

Los modelos MoE tienen su propia calibración, con 53 mediciones publicadas de gpt-oss, Qwen3, GLM-4.7-Flash, DeepSeek R1 y otros. Rinden un 41 % de su techo (mediana), frente al 58-84 % de los densos, porque cada token paga el enrutado y la atención aunque lea pocos pesos. No hay mediciones de MoE con MLX, así que en Mac se aplica la misma calibración medida con llama.cpp.

Auto-alojar frente a la API

Auto-alojar tiene un coste fijo alto, el hardware amortizado, y un coste marginal bajo, la electricidad. La API es lo contrario: cero fijo y un precio por token. Por eso auto-alojar solo compensa a partir de cierto volumen, el punto de equilibrio que calcula la herramienta.

El rendimiento, el consumo y el precio se rellenan con la plataforma elegida hasta que escribas tu propio valor. Los precios son los oficiales cuando el fabricante los publica. Son el PVPR de la tienda de NVIDIA en España, la Apple Store de España para cada memoria o, en su defecto, el precio de lanzamiento en dólares.

Qué no calcula

La calculadora no estima la velocidad de procesado del prompt ni el rendimiento con peticiones en lote, y no reparte un modelo entre GPU y RAM cuando no cabe. Esos casos dependen del hardware y de la configuración de cada motor más que de una fórmula. Los datos de modelos, plataformas y motores se verificaron el 15 de septiembre de 2026.

Fuentes:

1. Tabla de bits por peso de llama.cpp v0.4.1
2. Mediciones de llama.cpp en Apple Silicon
3. Mediciones de llama.cpp con Vulkan
4. Mediciones de gpt-oss con llama.cpp
5. Límite de memoria de la GPU en macOS
6. Longitud de contexto en Ollama v0.34.0
7. Caché KV cuantizada en vLLM v0.29.0
8. Caché KV cuantizada en SGLang v0.5.19
9. Techo de memoria de oMLX v0.6.4
10. Conversión a EXL3 en ExLlamaV3 v1.5.0
11. Memoria gráfica variable de AMD
12. Hardware de NVIDIA DGX Spark
13. Requisitos por modelo de Colibri v1.11.0