Antes de descargar un modelo para ejecutarlo en local, hay que saber si cabe en memoria. La estimación suma tres términos y el resultado se compara con lo que la máquina puede ofrecerle realmente al modelo:
need = weights + KV cache + overhead
fits if need <= 0.8 × usable memory
Los números de abajo siguen la estimación que usa el explorador de modelos locales de la aplicación de escritorio osFoundry, contrastada con lo que muestra la app en un MacBook M3 de 16 GB.
Pesos
Los pesos son el número de parámetros por los bytes que ocupa cada peso, y esos bytes dependen de la cuantización:
| Cuantización | Bytes por peso |
|---|---|
| FP16 / BF16 | 2.0 |
| Q8_0 | 1.0 |
| Q6_K | 0.82 |
| Q5_K_M | 0.69 |
| Q4_K_M | 0.56 |
| Q3_K_M | 0.44 |
| Q2_K | 0.31 |
Q4_K_M es 0.56 y no 0.5 porque las K-quants guardan una escala por cada bloque pequeño de pesos, lo que sale a unos 4.5 bits por peso.
Para un modelo de 14B en Q4_K_M: 14 × 10⁹ × 0.56 = 7.84 × 10⁹ bytes, unos 7.3 GiB.
Si no reconoces el nombre de la cuantización, asume FP16. Es la opción pesimista, así que no darás por bueno algo que luego no cabe.
Caché KV
Durante la generación, el modelo guarda las claves y los valores de cada token del contexto. El tamaño es:
2 × layers × kv_heads × head_dim × context_tokens × bytes_per_element
Qwen2.5 14B tiene 48 capas, 8 cabezas KV (usa grouped-query attention) y una dimensión de cabeza de 128. Con una caché en FP16:
- Contexto de 4K: 2 × 48 × 8 × 128 × 4096 × 2 bytes = 768 MiB
- Contexto de 32K: 6 GiB
La caché crece de forma lineal con la longitud del contexto, así que un modelo que cabe de sobra con 4K puede dejar de caber con 32K. Una estimación que no indica la longitud de contexto sirve de poco; la de la captura asume 4K.
Overhead
llama.cpp también necesita buffers de cómputo y espacio temporal. Un margen aproximado es el 10 % de los pesos más unos 200 MB. Para el modelo de 14B son unos 0.9 GB.
Si sumas pesos, caché y overhead, un modelo de 14B en Q4_K_M queda entre 8 y 9 GB. La app muestra 8.4 GB.
Memoria utilizable
Aquí es donde más se equivoca la gente.
- GPU dedicada: el techo es la VRAM de la tarjeta. Con una de 12 GB, son 12 GB, tengas la RAM de sistema que tengas.
- Apple Silicon: la memoria es unificada, pero la GPU no puede usarla toda y el sistema operativo necesita su parte. Contar el 75 % de la RAM total es un número de trabajo razonable, así que con 16 GB salen unos 12 GB.
Después se compara:
- need ≤ 80 % de la memoria utilizable: cabe, con margen para el sistema y otras apps
- entre el 80 % y el 100 %: justo; carga, pero cierra antes las demás apps
- más del 100 %: pasa a paginar en disco y se vuelve inutilizable de lento
En el Mac de 16 GB, eso da: Q4_K_M 8.4 GB (70 %, cabe), Q5_K_M 10.4 GB (87 %, justo), Q6_K 12.3 GB y Q8_0 14.9 GB (se pasan).
Aplicada a varios modelos en Q4_K_M, el corte en esta máquina cae entre 20B (11.9 GB, justo) y 27B (15.9 GB, demasiado grande).
La velocidad depende del mismo número
Para generar cada token hay que leer todos los pesos de la memoria una vez, así que el límite superior de velocidad de generación es el ancho de banda de memoria dividido entre el tamaño del modelo. Un M3 base tiene unos 100 GB/s, de modo que un modelo de 8.4 GB llega como máximo a unos 12 tokens por segundo, y uno de 8B de 4.9 GB a unos 20. Los valores reales quedan por debajo, pero la proporción entre modelos se mantiene bastante bien.
Así, la estimación de tamaño responde dos preguntas a la vez: si el modelo llega a cargarse y, de hacerlo, más o menos a qué velocidad escribirá.



Top comments (0)