Exécuter un modèle de langage sur sa propre machine est devenu accessible, et les raisons de le faire ne manquent pas : aucune donnée ne sort, aucun abonnement, aucun quota, et un fonctionnement hors ligne. Reste à savoir ce que la machine doit encaisser. La réponse tient dans un seul paramètre, et ce n’est pas celui auquel on pense.
Le facteur limitant n’est pas la vitesse de calcul mais la quantité de mémoire rapide disponible, et la vitesse à laquelle on peut la lire. Un modèle doit tenir entièrement dans cette mémoire ; s’il déborde, la vitesse ne se dégrade pas, elle s’effondre d’un facteur dix ou vingt.
Pourquoi c’est un problème de mémoire et pas de calcul
Pour produire un seul mot, le modèle doit lire l’intégralité de ses paramètres. Chacun d’eux intervient dans au moins une multiplication. Un modèle de sept milliards de paramètres implique donc de parcourir sept milliards de valeurs pour chaque fragment de texte produit.
Le calcul lui-même est trivial pour du matériel moderne. Le transport des données depuis la mémoire vers les unités de calcul, en revanche, ne l’est pas du tout. L’exécution d’un modèle de langage est ce qu’on appelle une charge limitée par la bande passante mémoire : les unités de calcul attendent.
Une conséquence directe et utile : la vitesse de génération se prédit assez bien en divisant la bande passante mémoire par la taille du modèle. Une mémoire capable de lire 500 gigaoctets par seconde, face à un modèle de 5 gigaoctets, produira de l’ordre de cent fragments de texte par seconde. Le nombre de cœurs de calcul n’entre pratiquement pas dans l’équation.
La quantification, ou comment diviser la taille par quatre
Les paramètres d’un modèle sont produits à l’entraînement sous forme de nombres à virgule flottante sur 16 bits, soit deux octets chacun. Un modèle de sept milliards de paramètres pèse donc quatorze gigaoctets, ce qui exclut d’emblée la plupart des machines grand public.
La quantification consiste à représenter ces paramètres sur moins de bits. On découpe les poids en petits groupes, on calcule pour chaque groupe un facteur d’échelle, et on encode chaque valeur sur quatre ou huit bits par rapport à ce facteur. La reconstruction au moment du calcul est approximative, mais l’erreur reste faible parce qu’elle est traitée localement, groupe par groupe.
| Précision | Octets par paramètre | Taille d’un modèle de 7 milliards | Qualité |
|---|---|---|---|
| 16 bits flottants | 2 | environ 14 Go | Référence |
| 8 bits | 1 | environ 7 Go | Écart généralement imperceptible |
| 4 bits | 0,5 en moyenne | environ 4 Go | Léger recul, acceptable en usage courant |
| 3 bits et moins | moins de 0,4 | environ 3 Go | Dégradation nette et visible |
Le palier à quatre bits constitue le compromis retenu par la plupart des utilisateurs. En dessous, la perte devient perceptible sur le raisonnement et sur la précision factuelle, deux capacités qui se dégradent avant la fluidité apparente du texte. Un modèle trop compressé continue d’écrire correctement tout en devenant nettement moins fiable, ce qui est la forme de dégradation la plus trompeuse.
Un arbitrage souvent mal posé
À budget mémoire égal, vaut-il mieux un gros modèle très compressé ou un modèle plus petit peu compressé ? L’expérience penche assez nettement pour la première option. Un modèle de treize milliards de paramètres en quatre bits rend généralement de meilleurs services qu’un modèle de sept milliards en huit bits, alors que les deux occupent une place comparable.
La règle cesse de valoir aux compressions extrêmes, où la dégradation devient trop coûteuse pour être compensée par la taille.
La mémoire du contexte, le poste qu’on oublie
Les poids du modèle ne sont pas seuls en mémoire. Pour éviter de tout recalculer à chaque nouveau mot, le système conserve un état intermédiaire pour chaque mot déjà traité. Cet état s’accumule au fil de la conversation.
Sur une question courte, ce poste est négligeable. Sur un document de plusieurs dizaines de milliers de mots, il peut atteindre plusieurs gigaoctets, parfois davantage que le modèle lui-même. C’est l’explication la plus fréquente d’un comportement déroutant : tout fonctionne au début de la session, puis la vitesse s’écroule au bout d’un long échange.
Deux parades existent. Compresser cet état intermédiaire sur huit bits, ce qui divise le poste par deux pour une perte de qualité très faible. Et limiter la taille de contexte configurée à ce dont vous avez réellement besoin, plutôt que de la pousser au maximum par réflexe.
Ce qu’il faut comme machine
| Mémoire rapide disponible | Taille de modèle réaliste | Usage |
|---|---|---|
| 8 Go | 3 à 4 milliards en 4 bits | Reformulation, résumé court, extraction simple |
| 12 à 16 Go | 7 à 9 milliards en 4 bits | Assistant généraliste, aide à la rédaction, code simple |
| 24 Go | 14 à 32 milliards en 4 bits | Raisonnement plus solide, documents longs |
| 48 Go et plus | 70 milliards en 4 bits | Proche des services en ligne sur beaucoup de tâches |
Le cas des machines à mémoire unifiée
Certaines architectures récentes partagent une seule mémoire entre le processeur et la partie graphique, avec une bande passante élevée. Elles présentent un avantage décisif pour cet usage : la mémoire disponible se compte en dizaines de gigaoctets au lieu des huit à vingt-quatre d’une carte graphique classique.
La contrepartie est une bande passante généralement inférieure à celle d’une carte dédiée haut de gamme. On peut donc y charger de très gros modèles, qui tourneront plus lentement. Selon que vous privilégiez la taille du modèle ou la vitesse de réponse, l’arbitrage change complètement.
Et sans carte graphique du tout
L’exécution sur le seul processeur central fonctionne, mais la bande passante de la mémoire système est cinq à dix fois inférieure à celle d’une mémoire graphique. Comptez quelques fragments de texte par seconde sur un modèle de sept milliards de paramètres, ce qui reste utilisable pour un traitement en arrière-plan et franchement pénible pour un échange interactif.
Ce qu’un modèle local fait bien, et ce qu’il fait mal
- Il excelle sur les tâches de transformation : reformuler, résumer, traduire, extraire des informations d’un texte fourni, classer. Le matériel de départ est présent dans la demande, le modèle n’a pas à le retrouver.
- Il tient correctement sur l’aide à la rédaction et sur le code courant, avec des rappels de syntaxe et des fonctions usuelles.
- Il déçoit sur les connaissances factuelles précises et récentes. Un petit modèle a très peu de place pour stocker des faits, et se met à inventer avec aplomb.
- Il échoue sur les raisonnements longs en plusieurs étapes, où l’écart avec les grands modèles reste considérable.
La conclusion pratique est qu’un modèle local se juge sur les tâches où le contexte est fourni, pas sur celles où il faut de la culture générale. Formulé autrement : il traite bien ce que vous lui donnez, et connaît mal ce que vous ne lui donnez pas.
Par où commencer
- Regardez d’abord votre mémoire disponible, pas la puissance de votre machine. C’est ce chiffre qui détermine ce que vous pouvez exécuter.
- Prenez un modèle en quatre bits qui occupe au maximum les deux tiers de cette mémoire, pour laisser la place au contexte.
- Commencez petit. Un modèle de trois ou quatre milliards de paramètres répond instantanément et suffit pour se faire une idée des usages qui vous concernent réellement.
- Réglez la taille de contexte à la baisse tant que vous n’en avez pas besoin. C’est le réglage qui fait le plus de dégâts quand il est laissé au maximum.
- Mesurez avant de conclure. La vitesse en fragments par seconde et le délai avant le premier mot sont deux indicateurs différents, et le second pèse davantage sur le confort d’usage.
L’exécution locale a cessé d’être une curiosité, mais elle reste gouvernée par une contrainte matérielle simple qu’aucune optimisation logicielle ne contourne : il faut lire tous les paramètres pour produire chaque mot. Tout le reste, quantification comprise, découle de cette seule phrase.








