De combien de mémoire un LLM local a-t-il besoin ?

Avant de télécharger un modèle pour le faire tourner en local, il faut savoir s'il tient en mémoire. L'estimation est la somme de trois termes, comparée à ce que la machine peut réellement donner au modèle :

need = weights + KV cache + overhead fits if need <= 0.8 × usable memory

Les chiffres ci-dessous suivent l'estimation utilisée par le navigateur de modèles locaux de l'application de bureau osFoundry, vérifiée par rapport à ce que l'appli affiche pour un MacBook M3 de 16 Go.

Les poids

Les poids, c'est le nombre de paramètres multiplié par le nombre d'octets par poids, lequel dépend de la quantification :

Quant	Octets par poids
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 vaut 0.56 et non 0.5 parce que les K-quants stockent une échelle pour chaque petit bloc de poids, ce qui revient à environ 4.5 bits par poids.

Pour un modèle de 14B en Q4_K_M : 14 × 10⁹ × 0.56 = 7.84 × 10⁹ octets, soit environ 7.3 Gio.

Si vous ne reconnaissez pas le nom de la quantification, partez sur du FP16. C'est le choix pessimiste, vous ne conclurez donc jamais qu'un modèle tient alors que ce n'est pas le cas.

Le cache KV

Pendant la génération, le modèle garde les clés et les valeurs de chaque token du contexte. La taille est :

2 × layers × kv_heads × head_dim × context_tokens × bytes_per_element

Qwen2.5 14B a 48 couches, 8 têtes KV (il utilise le grouped-query attention) et une dimension de tête de 128. Avec un cache en FP16 :

Contexte de 4K : 2 × 48 × 8 × 128 × 4096 × 2 octets = 768 Mio
Contexte de 32K : 6 Gio

Le cache croît linéairement avec la longueur du contexte : un modèle qui tient largement à 4K peut cesser de tenir à 32K. Une estimation qui ne précise pas la longueur de contexte ne sert pas à grand-chose ; celle de la capture suppose 4K.

L'overhead

llama.cpp a aussi besoin de tampons de calcul et d'espace de travail. Une marge approximative : 10 % des poids plus environ 200 Mo. Pour le modèle de 14B, cela fait environ 0.9 Go.

En additionnant poids, cache et overhead, un modèle de 14B en Q4_K_M se situe entre 8 et 9 Go. L'appli affiche 8.4 Go.

La mémoire utilisable

C'est la partie où l'on se trompe le plus souvent.

GPU dédié : la VRAM de la carte est le plafond. Avec 12 Go de VRAM, c'est 12 Go, quelle que soit la quantité de RAM système.
Apple Silicon : la mémoire est unifiée, mais le GPU ne peut pas tout utiliser et le système a besoin de sa part. Compter 75 % de la RAM totale est une valeur de travail raisonnable : 16 Go donnent environ 12 Go.

On compare ensuite :

need ≤ 80 % de la mémoire utilisable : ça tient, avec de la marge pour le système et les autres applis
de 80 % à 100 % : juste ; ça se charge, mais fermez d'abord les autres applis
au-delà de 100 % : ça passe en swap sur le disque et devient inutilisable de lenteur

Sur le Mac de 16 Go, cela donne : Q4_K_M 8.4 Go (70 %, ça tient), Q5_K_M 10.4 Go (87 %, juste), Q6_K 12.3 Go et Q8_0 14.9 Go (trop gros).

Appliquée à plusieurs modèles en Q4_K_M, la limite sur cette machine se situe entre 20B (11.9 Go, juste) et 27B (15.9 Go, trop gros).

La vitesse suit le même chiffre

Générer chaque token oblige à lire une fois tous les poids en mémoire. La limite haute de la vitesse de génération est donc la bande passante mémoire divisée par la taille du modèle. Un M3 de base offre environ 100 Go/s : un modèle de 8.4 Go plafonne autour de 12 tokens par seconde, et un 8B de 4.9 Go autour de 20. Les valeurs réelles sont plus basses, mais le rapport entre les modèles se vérifie plutôt bien.