🧠Mémoire LLM local : calculez vos besoins GPU (avant download)
Découvrez comment estimer la mémoire LLM local (quantification, cache KV, VRAM GPU) avant de lancer un LLM en local : méthode simple + exemples.
LLM local : savoir si votre ordinateur a assez de mémoire
Avant de télécharger un modèle d'intelligence artificielle, il y a une question très simple : est-ce que votre machine va réussir à le charger, puis à l'exécuter correctement ? La taille affichée sur la page de téléchargement ne dit pas tout. Pendant la génération, le modèle consomme aussi de la mémoire pour garder le contexte de la conversation et pour faire ses calculs. Et même la mémoire indiquée dans les caractéristiques de votre ordinateur n'est pas toujours disponible à 100 % pour l'inférence.
Résultat : il suffit parfois que « ça passe sur le papier » pour que, en pratique, le chargement échoue, que tout rame, ou que l'ordinateur devienne pénible à utiliser.
Pour estimer correctement, je vous conseille de regarder trois choses : les poids du modèle, le cache KV, et la mémoire de travail supplémentaire. Ensuite, on compare le total à la mémoire que votre matériel peut vraiment consacrer à l'inférence.
L'idée ci-dessous : faire le calcul avant l'installation, comprendre l'effet de la quantification et de la longueur de contexte, puis obtenir un ordre de grandeur de la vitesse. Évidemment, ce ne sont pas des mesures parfaites : ces chiffres servent surtout à éviter les mauvais choix, pas à remplacer un test sur votre configuration.
Comment calculer la mémoire nécessaire à un LLM local
La première estimation est une addition directe : mémoire nécessaire = poids du modèle + cache KV + mémoire de travail. Elle est plus fiable que la seule taille du fichier, parce qu'elle tient compte de ce qui se passe pendant la génération.
Les poids dépendent du nombre de paramètres et de la quantification
Les poids, ce sont les valeurs apprises par le modèle. Leur taille dépend du nombre de paramètres et du nombre d'octets utilisés pour stocker chaque poids. Un modèle de 14 milliards de paramètres, souvent noté « 14B », demandera donc plus de mémoire qu'un modèle de 8 milliards, à quantification comparable.
La quantification change la donne : elle réduit la précision de stockage pour diminuer l'empreinte mémoire. Voici des repères courants :
| Format | Octets approximatifs par poids |
|---|---|
| FP16 / BF16 | 2,00 |
| Q8_0 | 1,00 |
| Q6_K | 0,82 |
| Q5_K_M | 0,69 |
| Q4_K_M | 0,56 |
| Q3_K_M | 0,44 |
| Q2_K | 0,31 |
Prenons un modèle 14B en Q4_K_M. On multiplie 14 milliards de paramètres par 0,56 octet : on obtient environ 7,84 milliards d'octets, soit près de 7,3 Gio. Attention : ce n'est pas « exactement » quatre bits par poids, car certaines variantes K ajoutent des informations (liées notamment à des blocs et à la mise à l'échelle). En pratique, on peut considérer que Q4_K_M tourne autour de 4,5 bits par poids en moyenne.
Si le format de quantification n'est pas indiqué, partir sur FP16 est une hypothèse prudente. Ça peut surestimer la mémoire requise, mais c'est utile : ça évite de s'emballer sur un modèle « théoriquement compatible » qui ne chargera pas chez vous.
Le cache KV augmente avec la longueur du contexte
Pendant la génération, le modèle conserve des informations sur les tokens déjà traités : c'est le cache des clés et des valeurs, le cache KV. Sans ça, il recalculerait une partie du travail à chaque nouveau token. Ça accélère, mais ça consomme de la mémoire.
Une approximation de sa taille est :
2 × nombre de couches × nombre de têtes KV × dimension d'une tête × nombre de tokens de contexte × octets par élément
Le facteur 2 correspond aux clés et aux valeurs. Le coût exact dépend de l'architecture, du format de stockage du cache et surtout de la longueur de contexte réellement utilisée.
Exemple avec un Qwen2.5 14B : 48 couches, 8 têtes KV, dimension de tête de 128. Avec un cache FP16, on est autour de 768 Mio pour 4 096 tokens. Et à 32 768 tokens, on monte à environ 6 Gio. En gros, la mémoire du cache KV est proportionnelle au contexte : passer de 4K à 32K multiplie (à peu près) par huit.
C'est pour ça que le « contexte supporté » n'est pas un détail. Un modèle qui tient avec une petite conversation peut manquer de mémoire dès que vous passez à un long document ou que vous augmentez la fenêtre de contexte. La capacité annoncée n'est pas forcément une capacité confortable pour votre machine.
Il faut aussi réserver de la mémoire au moteur d'inférence
Le moteur (par exemple llama.cpp) utilise aussi des buffers et d'autres zones de travail. Ces besoins ne sont ni dans les poids, ni dans le cache KV.
Une règle pratique : prévoir environ 10 % de la taille des poids, plus autour de 200 Mo. Pour le modèle 14B de l'exemple, on est alors vers 0,9 Go.
Cette marge n'est pas une constante universelle. Elle dépend du moteur, de l'architecture, des réglages et du matériel. Mais elle sert à ne pas se contenter de la « taille du modèle téléchargé ».
En additionnant tout, un 14B en Q4_K_M tombe souvent dans une fourchette de 8 à 9 Go avec un contexte de 4K. Selon les hypothèses retenues, on peut voir un chiffre autour de 8,4 Go, mais il faudra accepter une certaine variabilité.
Quelle mémoire est réellement disponible pour le modèle
Ensuite, il faut regarder la mémoire que votre système peut réellement utiliser pour l'inférence. La capacité indiquée sur la fiche technique est une capacité totale, pas une réservation garantie. Le système d'exploitation, les applications ouvertes et d'autres usages du GPU grignotent une partie de la ressource.
Sur une carte graphique dédiée, le VRAM est la limite principale
Avec une carte graphique dédiée, le premier chiffre à vérifier est la VRAM. Une carte avec 12 Go de VRAM ne pourra pas « utiliser » les 32 Go de mémoire vive du reste de l'ordinateur comme si c'était de la VRAM.
Certains logiciels peuvent échanger des données entre mémoire système et mémoire graphique. Ça peut aider à démarrer, mais ça ne supprime pas la limite, et ça peut coûter cher en performances.
Il faut aussi tenir compte du moteur et du modèle : selon les cas, une partie du modèle peut être placée sur le processeur et une autre sur le GPU. Ça permet parfois de démarrer même si la VRAM seule ne suffit pas, mais l'estimation devient plus compliquée et la vitesse baisse souvent. Pour faire simple : comparez d'abord l'estimation à la VRAM, puis vérifiez que l'application choisie gère bien le déchargement vers la mémoire système.
Sur Apple Silicon, la mémoire est partagée, mais pas entièrement disponible
Sur Mac avec Apple Silicon, la mémoire est unifiée : elle est partagée entre CPU, GPU et système. C'est plus flexible que la VRAM séparée d'une carte graphique. Mais ce n'est pas non plus une « piscine » infinie : macOS et les applications en utilisent déjà une partie, et le GPU ne peut pas toujours exploiter l'intégralité de la capacité.
Pour une première estimation, réserver environ 75 % de la mémoire totale comme « espace utilisable » pour le modèle est un repère raisonnable. Sur 16 Go, ça fait environ 12 Go. Ce n'est pas une garantie (ça dépend de vos applis ouvertes et de la configuration), mais c'est plus réaliste que de considérer 16 Go comme entièrement disponibles.
Gardez une marge au lieu de viser la limite exacte
Une estimation peut se ranger dans trois zones :
- Jusqu'à 80 % de la mémoire utilisable : ça devrait tenir avec une marge correcte pour le système et les autres applis.
- Entre 80 % et 100 % : ça peut marcher, mais ça devient serré. Fermer des applis peut devenir nécessaire, et augmenter le contexte peut suffire à provoquer un manque de mémoire.
- Au-delà de 100 % : la configuration dépasse l'estimation. Le système peut parfois utiliser le stockage comme mémoire d'appoint, mais l'inférence devient généralement beaucoup trop lente pour un usage confortable.
Cette marge n'est pas une loi physique. C'est un repère d'usage : pendant que le modèle tourne, la machine doit rester utilisable. Si vous faites juste une petite expérience ponctuelle, vous pouvez tolérer plus de « serré ». Mais pour un usage quotidien (ou une démo en entreprise), autant privilégier la stabilité.
Comment vérifier si un modèle conviendra à votre machine
Une décision fiable ne se résume pas au nom du modèle. Il faut fixer les hypothèses, calculer les postes importants, puis comparer au « réellement utilisable » sur votre machine. Ça évite la confusion classique : « le fichier est téléchargeable » ≠« le modèle tournera ».
Faites une estimation en quatre Ă©tapes
- Relevez le nombre de paramètres. Il apparaît souvent dans le nom (8B, 14B...). Mais vérifiez quand même : deux variantes d'une même famille peuvent avoir des architectures différentes.
- Identifiez la quantification. Utilisez les octets par poids du format choisi. Si vous ne savez pas, commencez par une borne prudente en FP16, puis refaites le calcul avec la quantification envisagée.
- Fixez le contexte de travail. 4K n'a pas le même coût que 32K. Si vous devez analyser de longs documents, raisonner en 4K ne répond pas à votre besoin.
- Ajoutez le cache KV et les tampons, puis comparez. Sur carte dédiée, comparez à la VRAM. Sur mémoire unifiée, estimez la mémoire utilisable. Dans tous les cas, gardez une marge pour le système et vos applications.
Le calcul n'a pas besoin d'être parfait. Son but est surtout d'écarter les options manifestement trop ambitieuses. Après ça, le mieux reste de tester réellement le modèle avec le moteur prévu, sur une longueur de contexte et des prompts représentatifs de votre usage.
Exemple : un Mac de 16 Go et un modèle 14B
Sur un Mac de 16 Go, avec une estimation prudente, on peut viser environ 12 Go utilisables. Pour un Qwen2.5 14B, les besoins Ă contexte de 4K varient selon la quantification :
- Q4_K_M : ~8,4 Go
- Q5_K_M : ~10,4 Go
- Q6_K : ~12,3 Go
- Q8_0 : ~14,9 Go
Le Q4_K_M représente environ 70 % des 12 Go utilisables : il laisse une marge confortable. Le Q5_K_M monte à près de 87 % : ça peut fonctionner, mais il faut être prêt à fermer des applis gourmandes. Les formats Q6_K et Q8_0 dépassent l'estimation, donc ce sont de mauvais choix pour cette configuration dans ces conditions.
Et ce n'est pas seulement une question de « même modèle, différents formats ». À quantification Q4_K_M, une estimation sur cette machine place un 20B autour de 11,9 Go (proche de la limite), tandis qu'un 27B autour de 15,9 Go dépasse la capacité estimée. Le contexte, le moteur et ce qui tourne en arrière-plan peuvent faire bouger ces résultats : gardez ça comme des ordres de grandeur, pas comme une garantie.
Distinguez capacité, qualité et confort d'usage
Un modèle plus grand n'est pas automatiquement le « meilleur » choix. Tout dépend du travail à faire : qualité attendue, temps de réponse acceptable, coût opérationnel.
Pour une classification simple ou un assistant interne à faible risque, un modèle plus compact peut suffire. Il sera aussi souvent plus facile à déployer.
En équipe, la question revient souvent à ça : quel modèle répond correctement sans dépasser la mémoire disponible, et sans ralentir les postes ? Le plus utile reste de mesurer sur des tâches réelles, avec des prompts représentatifs, et des critères d'évaluation définis. Un modèle local aide à mieux maîtriser les données et à réduire la dépendance à un service distant, mais ça ne remplace ni la vérification de la qualité, ni la mise en place de règles d'usage et de traitement des données.
La mémoire permet-elle aussi d'estimer la vitesse
La taille du modèle donne aussi un indice sur la vitesse, surtout quand l'inférence est limitée par la bande passante mémoire. Pour produire un token, le système doit généralement lire les poids du modèle depuis la mémoire. Donc plus les poids sont volumineux, plus il faut déplacer de données pour chaque token.
Dans un scénario simplifié, la vitesse maximale ressemble à : bande passante mémoire / taille des poids. Avec une bande passante de 100 Go/s et un modèle de 8,4 Go, le plafond théorique est autour de 12 tokens par seconde. Avec un modèle 8B dont les poids occupent 4,9 Go, on tombe plutôt vers 20 tokens par seconde.
Mais ces chiffres ne sont pas des promesses. Ce sont des plafonds dans un modèle simplifié. Dans la réalité, le processeur ou le GPU fait d'autres calculs, il y a des transferts, le moteur d'inférence intervient, le cache et le contexte entrent en jeu, et la machine fait aussi d'autres tâches. Selon le matériel, un autre facteur peut devenir limitant avant même la bande passante mémoire.
Il faut aussi distinguer le temps de « pré-remplissage » du prompt et la génération token par token. Un long document peut demander un temps notable avant la première réponse. Donc le débit affiché pendant la génération ne décrit pas forcément l'expérience utilisateur totale.
Au final, le calcul de mémoire répond à deux questions utiles : est-ce que le modèle a une chance de tenir, et à quoi s'attendre comme ordre de grandeur de vitesse une fois lancé ? Sur une même machine, c'est un repère pratique pour comparer. Pour un usage de production, complétez avec des mesures de latence et de qualité sur vos scénarios.
Conclusion
Pour estimer si un LLM peut tourner localement, ne vous fiez ni au nombre de paramètres seul, ni à la taille du fichier. Additionnez les poids, le cache KV pour votre contexte, et les tampons du moteur, puis comparez au total à la mémoire réellement utilisable. Et gardez une marge : un modèle qui démarre « juste à la limite » n'est pas forcément confortable au quotidien.
Cette même estimation donne aussi un premier indice sur la vitesse, parce que la lecture des poids intervient à chaque token. Elle ne remplace pas un test réel, mais elle aide à trier avant même le téléchargement. Commencez par une quantification et une longueur de contexte adaptées à votre machine, puis validez avec vos tâches et votre niveau d'exigence.