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. Para cifras medidas en un Mac real, consulta los benchmarks de LLM local en Apple Silicon.

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.

Modelos de decisión

Un modelo de decisión no escribe texto: recibe una situación y unas preguntas con sus opciones permitidas, y devuelve una probabilidad para cada opción. Sirve para enrutar tickets, marcar infracciones de una política, juzgar si una respuesta se apoya en sus fuentes o elegir el siguiente clic de un agente. Las etiquetas van en la petición, así que el mismo modelo hace todo eso sin reentrenarlo.

La calculadora incluye 14, entre ellos Clef y Clef-flash de Cloudflare, OpenJev, la familia d3 y los de Perplexity, H2O y Liquid. Casi todos parten de Qwen3.8-27B, Qwen3.5-9B o Qwen3.5-4B, así que ocupan lo mismo que su modelo base: los pesos más la caché KV del prompt. El contexto que eliges es la longitud del prompt de cada petición.

Lo que cambia es el motor. OpenJev y H2O Lightning leen la probabilidad de la letra de cada opción en el primer token: funcionan en un motor que devuelva esas probabilidades, con el script auxiliar que publican. Clef, pplx-decider, Kev y d1 añaden una cabeza de decisión propia, y d3 lee códigos de opción. Un motor de chat los carga, pero la respuesta sale sin sentido.

llama.cpp los ejecuta de forma nativa desde sus versiones del 2 y 3 de octubre de 2026, con el endpoint /v1/systemone. La calculadora marca qué motores sirven para cada modelo y avisa cuando la licencia no permite uso comercial, como en OpenJev (CC BY-NC 4.0).

La velocidad no se estima. Un modelo de decisión hace una sola pasada sobre el prompt, así que su coste es el prefill. El prefill depende del cómputo de la GPU, no del ancho de banda que calibra la herramienta, y por eso se citan las mediciones publicadas. Clef tarda 152 ms con un prompt de unos 800 tokens en Workers AI, y 26 s con 16.000 tokens en un Apple M5 Max con MLX de 4 bits.

Generación de voz (TTS)

El panel de voz compara 39 modelos abiertos de texto a voz, de Kokoro (82 millones de parámetros) a Fish Audio Drama 3 (35.900 millones). No usa la fórmula de los LLM, porque la cuenta de parámetros deja fuera piezas que también ocupan memoria. Fish S2 Pro suma un códec de 390 millones de parámetros y MOSS-TTS uno de 1.780 millones, y la memoria real depende de cómo se ejecute cada uno.

Por eso la memoria es la que publican sus autores o la comunidad para el tipo de plataforma que eliges. Drama 3 pide 48 GB en FP8 en una GPU dedicada y 26 GB con MLX de 4 bits en un Mac. Solo 13 de los 39 tienen una cifra publicada; para el resto, la calculadora usa los pesos en 16 bits y lo marca como estimación mínima.

Cada modelo indica si habla español y cómo: de forma oficial, solo con un modelo aparte o en modo experimental. 23 lo soportan de forma oficial, y Chatterbox es el único con un modelo afinado para el español de España. El filtro de uso comercial deja fuera las licencias no comerciales (Voxtral, Higgs TTS 3, Fish S2 Pro) y las que ponen condiciones, como un tope de ingresos.

La velocidad también son mediciones publicadas: el factor de tiempo real (RTF, segundos de cálculo por segundo de audio), las veces más rápido que el tiempo real y el tiempo hasta el primer audio. Casi todas se midieron en GPUs de servidor (H100, H200, L20), así que en una tarjeta doméstica espera cifras peores. Si hay una medición en tu plataforma, sale la primera.

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 plataformas y motores se verificaron el 15 de septiembre de 2026. El 12 de noviembre de 2026 se añadieron los modelos de decisión, los de voz y 14 modelos de chat publicados desde septiembre, como Nemotron 3.5, MiMo-V2.6-Flash o LFM2.5.

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
14. Clef y Clef-flash en Workers AI
15. Endpoint de decisión de llama-server
16. Ficha y mediciones de OpenJev
17. Requisitos de memoria de Fish Audio