Faire tourner un LLM local sur PC oblige à regarder trois limites différentes : la VRAM de la carte graphique, la RAM du système et la taille du contexte réellement utilisé. Mélanger ces trois chiffres conduit vite à acheter trop cher, ou à choisir un modèle qui démarre mais devient inutilisable dès que la conversation s’allonge.
Je préfère partir d’un besoin précis : résumer des documents, écrire du code, discuter hors ligne ou indexer une base personnelle. Ensuite seulement viennent le nombre de paramètres, la quantification et le matériel. Cette méthode évite le faux raccourci « plus gros modèle = meilleure expérience ».
LLM local, VRAM et RAM : les trois questions à séparer
Les poids du modèle doivent être chargés quelque part. La VRAM offre généralement l’accès le plus rapide au GPU. Lorsque tout ne tient pas, certains moteurs déportent une partie du calcul ou des poids vers la RAM. Cela peut rendre un modèle exécutable, mais pas nécessairement agréable.
Le contexte ajoute une autre consommation : il contient les jetons de la consigne, de la conversation, des documents injectés et de la réponse en cours. Plus il grandit, plus le cache associé peut consommer de mémoire. Une fenêtre annoncée à 32 000 ou 128 000 jetons n’est donc pas une invitation à la remplir systématiquement.
| Ressource | Ce qu’elle porte | Symptôme d’une limite |
|---|---|---|
| VRAM | poids, couches calculées sur GPU, cache et buffers | chargement impossible, déport, erreur mémoire |
| RAM | poids déportés, contexte, système et applications | ralentissements, échange disque, instabilité |
| Contexte | instruction, historique et documents | réponses lentes, mémoire accrue, information noyée |
Commencer par l’usage, pas par le classement d’un modèle
Un assistant local destiné à reformuler quelques paragraphes ne demande pas le même compromis qu’un outil de développement qui doit parcourir plusieurs fichiers. Avant de télécharger un modèle, j’écris une fiche très courte :
- langue principale et domaines traités ;
- longueur typique des documents ;
- besoin de code, de vision ou d’appels d’outils ;
- nombre d’utilisateurs simultanés ;
- données qui ne doivent pas quitter la machine ;
- temps de réponse acceptable ;
- licence compatible avec l’usage envisagé.
Cette fiche permet de tester un petit modèle avant de viser plus haut. Dans beaucoup de tâches cadrées, un modèle plus compact avec un bon prompt et un contexte propre produit une expérience plus stable qu’un modèle trop gros constamment déporté sur le processeur.
Estimer la place des poids sans promettre un chiffre magique
Le nombre de paramètres donne un ordre de grandeur, pas une mesure complète. À précision équivalente, davantage de paramètres signifie généralement davantage de mémoire pour les poids. La quantification réduit cette empreinte en représentant les valeurs avec moins de bits. Elle peut aussi modifier la qualité, la vitesse et la compatibilité selon le format et le moteur.
Les outils de l’écosystème llama.cpp documentent le format GGUF, tandis que Transformers décrit plusieurs méthodes de quantification. Ces sources montrent pourquoi une simple étiquette « 4 bits » ne suffit pas : les méthodes, les métadonnées et les composants non quantifiés comptent aussi.
Je relève donc la taille réelle du fichier, le format, la quantification exacte et la mémoire annoncée par le moteur au chargement. J’ajoute une marge pour le cache, les buffers, le contexte, l’interface et les autres applications. Copier la taille du téléchargement dans la colonne « VRAM nécessaire » est trop simpliste.
Ce que change l’offload entre GPU et processeur
Des moteurs locaux permettent de placer certaines couches sur le GPU et le reste en RAM. C’est utile pour tester un modèle qui dépasse la VRAM. Le compromis apparaît ensuite : chaque transfert et chaque calcul côté processeur peut réduire le débit de génération.
Il faut distinguer trois états :
- tout tient dans la VRAM : cas généralement le plus simple pour exploiter le GPU ;
- une partie est déportée : compromis parfois acceptable selon le processeur, la RAM et la tâche ;
- calcul surtout sur CPU : fonctionnement possible, mais le temps par jeton peut devenir la limite principale.
Je mesure au minimum le temps de chargement, le nombre de jetons générés par seconde et la mémoire maximale observée. Sans ces trois données, « ça tourne » ne décrit pas vraiment l’expérience.
Le contexte : une capacité maximale, pas un objectif
Une grande fenêtre de contexte est utile lorsque le modèle doit relier plusieurs passages éloignés. Elle ne garantit pas que chaque détail sera utilisé correctement. Un historique rempli de répétitions, de sorties obsolètes et de documents entiers peut diluer les éléments importants.
Pour un usage quotidien, je commence avec le contexte le plus court qui couvre la tâche. Je retire les échanges devenus inutiles, je segmente les documents et je demande des réponses bornées. Pour une base documentaire, un système de recherche ciblée peut être plus efficace que l’injection permanente de centaines de pages ; le dossier BlackFury sur les gains et coûts cachés de l’IA locale replace ce choix dans la maintenance globale.
Une méthode de test reproductible en six passages
- choisir trois tâches représentatives et conserver exactement les mêmes entrées ;
- noter le modèle, le fichier GGUF ou le format utilisé et sa licence ;
- commencer avec un contexte modeste ;
- relever VRAM, RAM, temps de chargement et débit ;
- augmenter progressivement le contexte sans changer le reste ;
- comparer la qualité utile, pas seulement la vitesse.
Je conserve aussi la version du moteur, le pilote graphique et les paramètres. Une mise à jour peut changer la consommation ou la compatibilité. Cette discipline rejoint le guide ComfyUI et FLUX.1-dev en local : une expérience locale devient utile quand ses versions et ses limites sont documentées.
Trois profils de configuration à raisonner
| Profil | Approche raisonnable | Priorité |
|---|---|---|
| PC sans GPU dédié | petit modèle quantifié, contexte court, attentes mesurées | RAM rapide et patience |
| GPU milieu de gamme | modèle compact ou moyen, quantification adaptée, offload limité | équilibre qualité et débit |
| GPU riche en VRAM | modèle plus grand ou contexte accru après mesure | ne pas gaspiller la marge |
Ces profils ne sont pas des recommandations d’achat. Deux cartes affichant la même VRAM peuvent avoir des performances et des pilotes différents. Deux modèles de même taille peuvent aussi se comporter différemment selon l’architecture, la quantification et le moteur.
Les erreurs que je veux éviter
- acheter une carte uniquement à partir du nombre de paramètres ;
- oublier que Windows, le navigateur et les outils utilisent déjà de la RAM ;
- remplir la fenêtre de contexte parce qu’elle existe ;
- confondre taille du fichier et mémoire totale en exécution ;
- comparer des débits obtenus avec des prompts et contextes différents ;
- télécharger un modèle sans lire sa carte et sa licence ;
- exposer une interface locale sur Internet sans authentification.
Verdict BlackFury
Pour dimensionner un LLM local sur PC, je ne cherche pas le plus gros modèle que la machine peut lancer une fois. Je cherche le plus petit ensemble qui répond correctement aux tâches réelles, avec un contexte propre et une marge de mémoire.
La VRAM décide souvent de la quantité de travail gardée près du GPU. La RAM détermine la capacité de déport et la stabilité du système. Le contexte influence à la fois la mémoire, la vitesse et la qualité de l’attention portée aux informations. Les trois doivent être mesurés ensemble, mais jamais confondus.
