Faire tourner un modèle d'IA sur votre machine : la règle que personne ne donne

Faire tourner un modèle de langage sur votre propre machine résout d'un coup plusieurs problèmes que l'abonnement à une API ne résoudra jamais.

Vos données ne sortent pas. Aucun moyen de paiement international n'est nécessaire. Une coupure de connexion n'interrompt rien. Le modèle ne sera pas retiré du service dans dix-huit mois. Et le coût marginal d'une requête est nul.

La question n'est donc pas de savoir si c'est souhaitable, mais si c'est possible avec ce que vous avez — et à quelle vitesse.

Presque tous les guides répondent à cette question par une liste de matériel recommandé. C'est la mauvaise approche, parce qu'elle escamote la règle qui décide réellement de tout, et que nous n'avons vue formulée nulle part clairement.

La règle que personne ne donne

Pour produire chaque token, un modèle doit relire l'intégralité de ses poids depuis la mémoire.

Relisez cette phrase, elle contient tout. Pas une partie des poids : la totalité, à chaque token généré. Un modèle qui occupe quatre gigaoctets en mémoire doit donc faire transiter quatre gigaoctets pour produire un seul mot — puis recommencer pour le suivant.

Conséquence directe : la vitesse de génération est gouvernée par la bande passante mémoire, pas par la puissance de calcul.

Cela donne une formule que vous pouvez appliquer avant d'acheter quoi que ce soit :

Tokens par seconde ≈ bande passante mémoire (Go/s) ÷ taille du modèle en mémoire (Go)

C'est une borne haute théorique. En pratique, comptez 60 à 80 % de ce résultat, le reste partant en surcoûts d'exécution. Mais l'ordre de grandeur est fiable, et il suffit à décider.

Ce que cela donne concrètement

Situation	Bande passante	Modèle en mémoire	Vitesse estimée
Portable récent, mémoire classique	~50 Go/s	4 Go	~12 tokens/s
Mémoire unifiée milieu de gamme	~300 Go/s	4 Go	~75 tokens/s
Mémoire unifiée milieu de gamme	~300 Go/s	35 Go	~8 tokens/s
Carte graphique dédiée	~1 000 Go/s	4 Go	très rapide

Pour situer ces chiffres : une dizaine de tokens par seconde suffit à un usage confortable en lecture — c'est à peu près le rythme auquel on lit. En dessous de cinq, l'attente devient pénible. Au-dessus de trente, la vitesse cesse d'être le sujet.

Vous pouvez donc, dès maintenant, estimer ce que votre machine actuelle est capable de faire. Cherchez la bande passante mémoire de votre processeur ou de votre carte graphique — c'est une caractéristique publiée —, divisez par la taille du modèle, et vous savez.

Deux questions, pas une

L'erreur la plus répandue consiste à confondre deux contraintes qui n'ont rien à voir.

« Est-ce que ça tient ? » est une question de capacité. Le modèle doit entrer dans la mémoire disponible. S'il n'entre pas, rien ne se passe — ou plutôt, quelque chose de pire se passe, nous y venons.

« Est-ce que c'est assez rapide ? » est une question de bande passante. Le modèle tient, mais à quel rythme les poids circulent-ils ?

Tous les guides traitent la première et ignorent la seconde. C'est ainsi qu'on achète du matériel qui fait tourner un modèle... à trois tokens par seconde.

Le piège qui coûte cher

Voici la conséquence la plus contre-intuitive de tout ce qui précède, et elle inverse les intuitions d'achat.

Imaginons un modèle qui occupe 40 gigaoctets. Comparons deux machines.

Une carte graphique puissante avec 24 Go de mémoire dédiée. Le modèle n'entre pas. Le logiciel place alors une partie des poids dans la mémoire de la carte et le reste dans la mémoire du système — et à chaque token, la portion manquante doit transiter par le bus qui relie les deux. Ce bus plafonne à quelques dizaines de gigaoctets par seconde, soit un ordre de grandeur en dessous de la mémoire de la carte. Le débranchement se fait au maillon le plus lent, et la vitesse s'effondre.

Une machine à mémoire unifiée de 64 Go, nettement moins puissante en calcul brut. Le modèle entre entièrement. Aucun transfert entre deux mémoires, parce qu'il n'y en a qu'une, partagée par le processeur et la partie graphique.

La seconde machine sera beaucoup plus rapide que la première sur ce modèle, malgré une puissance de calcul très inférieure.

C'est la raison pour laquelle les machines à mémoire unifiée se sont imposées dans les usages locaux, alors qu'elles perdent nettement sur les mesures de calcul brut. Sur ce travail précis, ce n'est pas le calcul qui décide.

La règle pratique qui en découle : il vaut mieux beaucoup de mémoire un peu lente que peu de mémoire très rapide. L'inverse de ce que suggère l'intuition, et de ce que vend le marketing des cartes graphiques.

La quantification, ou l'art du compromis

Reste à faire entrer le modèle. C'est le rôle de la quantification.

Un poids de modèle est un nombre. Stocké en pleine précision, il occupe deux à quatre octets. La quantification consiste à le stocker sur moins de bits — quatre, parfois moins — en acceptant une perte de précision.

Le gain est spectaculaire : passer en quatre bits réduit l'empreinte mémoire d'environ 75 %. Un modèle qui demandait 28 gigaoctets en tient dans 7.

Le coût existe aussi, et il faut le dire : la qualité se dégrade. De façon généralement modérée en quatre bits — le format qui offre le meilleur équilibre selon un consensus assez large —, de façon nettement plus sensible en dessous. Les quantifications très agressives permettent de faire tourner de gros modèles sur du petit matériel, mais dégradent d'abord le raisonnement complexe, c'est-à-dire précisément ce pour quoi on prend un gros modèle.

Le conseil pratique tient en une ligne : commencez en quatre bits. C'est le réglage par défaut de la plupart des outils, et il est bien choisi. Ne descendez plus bas que si la mémoire l'impose, et testez alors sur vos propres tâches — la dégradation n'est pas uniforme selon les usages.

Et retenez l'effet secondaire, souvent oublié : en divisant la taille du modèle, la quantification divise aussi le temps de génération, puisque moins d'octets doivent transiter par token. Elle achète de la place et de la vitesse.

Quel matériel, concrètement

Trois configurations couvrent la quasi-totalité des situations réelles.

Ce que vous avez déjà. Un ordinateur portable récent avec 16 Go de mémoire fait tourner des modèles de 7 à 8 milliards de paramètres en quatre bits, à une vitesse utilisable. Ce n'est pas un modèle de pointe, mais c'est largement suffisant pour du résumé, de la reformulation, de l'extraction, de la classification et de la conversation courante. Commencez par là, avant tout achat.

Une machine à mémoire unifiée généreuse. C'est le meilleur rapport capacité-vitesse pour l'usage local, pour les raisons expliquées plus haut. Visez la mémoire avant la puissance : 32 Go ouvrent des modèles intermédiaires, 64 Go et plus permettent d'envisager les grands.

Une carte graphique dédiée, si et seulement si le modèle que vous visez entre entièrement dans sa mémoire. Dans ce cas, elle sera imbattable — sa bande passante dépasse largement celle d'une mémoire unifiée. Hors de ce cas, elle est le mauvais achat.

Un dernier paramètre à ne pas négliger : la fenêtre de contexte consomme aussi de la mémoire, en plus des poids, et cette consommation grandit avec la longueur des échanges. Prévoyez une marge au-delà de la taille du modèle, faute de quoi les longues conversations s'arrêteront brutalement.

Quelle taille de modèle pour quelle mémoire

Traduisons tout cela en décision. Les tailles ci-dessous supposent une quantification en quatre bits, et incluent une marge pour le contexte.

Mémoire disponible	Taille de modèle	Ce que vous pouvez en attendre
8 Go	3 à 4 milliards	Résumé, reformulation, classification, extraction simple. Conversation correcte.
16 Go	7 à 9 milliards	Le palier le plus rentable. Aide au code, rédaction, analyse de documents courts.
32 Go	20 à 30 milliards	Raisonnement plus solide, code de complexité moyenne, contextes plus longs.
64 Go et plus	50 à 70 milliards	S'approche des usages exigeants. C'est là que le local devient un vrai substitut.

Trois remarques sur ce tableau, qui comptent autant que le tableau lui-même.

Le palier des 16 Go est le meilleur investissement. C'est là que le rapport entre ce que vous obtenez et ce que vous payez est le plus favorable — et c'est la configuration de la plupart des ordinateurs vendus aujourd'hui. Beaucoup de gens qui croient devoir acheter du matériel ont déjà ce qu'il faut pour commencer.

Un modèle plus petit et bien choisi bat un modèle plus gros et générique. Sur une tâche précise — extraction structurée, classification, traduction dans un domaine —, un modèle de 3 milliards de paramètres spécialisé produit souvent de meilleurs résultats qu'un modèle généraliste de 30 milliards, dix fois plus vite. La course à la taille est un réflexe, pas une méthode.

La marge de contexte n'est pas optionnelle. Un modèle de 8 Go dans une machine de 8 Go ne fonctionnera pas : il faut de la place pour le système, pour l'application, et pour le contexte qui grandit à chaque échange. Comptez au moins 30 % de marge au-dessus de la taille du modèle.

Les trois outils

L'écosystème s'est considérablement simplifié. Trois options couvrent tous les besoins, et elles reposent toutes sur la même fondation.

llama.cpp est le moteur d'exécution écrit en C++ qui fait tourner presque tout le reste. Vous ne l'utiliserez directement que si vous voulez régler finement les performances, expérimenter des quantifications ou intégrer un modèle dans une application. C'est la couche la plus puissante et la moins confortable.

Ollama l'enveloppe dans une interface en ligne de commande d'une simplicité désarmante. Il gère le téléchargement des modèles, le choix de la quantification et la répartition sur le matériel disponible. Il expose surtout une interface compatible avec celle d'OpenAI — ce qui signifie qu'une application écrite pour une API commerciale fonctionne souvent en changeant une seule adresse. C'est le choix par défaut pour la plupart des gens.

LM Studio propose la même chose avec une interface graphique : catalogue de modèles, téléchargement en un clic, fenêtre de conversation intégrée, et serveur local exposant lui aussi une interface compatible. C'est l'option à recommander à qui ne vit pas dans un terminal.

Tous trois lisent le même format de modèles quantifiés, ce qui vous permet de passer de l'un à l'autre sans retélécharger.

Votre premier modèle, en dix minutes

Voici le chemin le plus court, sans détour.

Installez Ollama ou LM Studio. Les deux s'installent comme n'importe quel logiciel, sur les trois grands systèmes d'exploitation.

Téléchargez un modèle de 7 à 8 milliards de paramètres en quatre bits. L'outil vous proposera le format adapté à votre machine. Comptez quelques gigaoctets de téléchargement — à faire quand votre connexion est bonne, une fois pour toutes.

Posez-lui vos vraies questions. Pas « écris un poème » : les tâches que vous confieriez réellement à une IA. Un résumé de document, une extraction d'information, une reformulation, une aide au code sur votre propre projet.

Mesurez. La plupart des outils affichent la vitesse en tokens par seconde. Comparez-la à ce que la formule prédisait — l'écart vous renseignera sur votre configuration.

Puis décidez. Si la qualité suffit pour cette tâche, vous venez de supprimer une ligne de dépense et une dépendance. Si elle ne suffit pas, vous savez maintenant précisément où se situe la limite, ce qui vaut mieux que de le supposer.

Ce que le local fait mieux, et ce qu'il fait moins bien

Soyons équilibrés, l'enthousiasme des guides sur le sujet dessert souvent le lecteur.

Ce que le local fait mieux. La confidentialité est absolue — rien ne quitte la machine, ce qui est décisif pour du code propriétaire, des dossiers médicaux ou des documents juridiques. Le coût marginal est nul, donc les usages répétitifs et volumineux deviennent économiquement libres. Aucune dépendance à une connexion, à un moyen de paiement ou à une décision commerciale extérieure. Et le modèle reste disponible indéfiniment, dans la version exacte que vous avez validée.

Ce que le local fait moins bien. Les modèles exécutables sur du matériel accessible restent en retrait des meilleurs modèles commerciaux sur les tâches difficiles — raisonnement long, travail agentique autonome, fiabilité sur les cas limites. La vitesse est inférieure, souvent nettement. Et vous devenez responsable de la maintenance, des mises à jour et du dépannage.

La conclusion raisonnable n'est pas de choisir un camp. Elle est de router : le local pour le volume, le répétitif et le sensible ; l'API pour les tâches difficiles et occasionnelles. C'est la configuration qu'adoptent la plupart des équipes qui ont testé sérieusement les deux.

Le cas des connexions difficiles

Un point que les guides écrits depuis des pays à connexion abondante ne traitent jamais, et qui change l'arbitrage pour une partie de nos lecteurs.

L'exécution locale déplace la dépendance à la connexion du moment de l'usage vers le moment de l'installation. Vous téléchargez quelques gigaoctets une fois, quand la liaison le permet. Ensuite, le modèle fonctionne hors ligne, indéfiniment, à la même vitesse, que votre connexion soit excellente, médiocre ou absente.

Pour un usage professionnel dans un contexte où la liaison est irrégulière, ce n'est pas un confort mais une différence de nature : un service qui dépend d'une API distante est indisponible dès que le réseau l'est, et cette indisponibilité arrive au pire moment.

S'y ajoute la question du paiement. Souscrire une API étrangère suppose un moyen de paiement international accepté, ce qui n'est pas acquis partout. Un modèle téléchargé ne suppose rien de tel.

Ces deux contraintes, invisibles depuis San Francisco, suffisent à elles seules à justifier l'exécution locale pour beaucoup d'acteurs francophones — indépendamment de tout calcul de coût.

Questions fréquentes

Ai-je besoin d'une carte graphique ?

Non, pour commencer. Un processeur récent avec assez de mémoire fait tourner des modèles de 7 à 8 milliards de paramètres à une vitesse utilisable. La carte graphique devient intéressante quand le modèle visé entre entièrement dans sa mémoire dédiée — sinon, elle n'apporte rien, voire dégrade.

Combien de mémoire pour un modèle donné ?

Multipliez le nombre de paramètres par le nombre d'octets par paramètre : environ un demi-octet en quatre bits. Un modèle de 8 milliards de paramètres occupe donc environ 4 Go, un modèle de 30 milliards environ 15 Go. Ajoutez une marge pour le contexte.

Pourquoi mon modèle est-il si lent alors que ma machine est puissante ?

Presque toujours parce qu'il ne tient pas entièrement en mémoire rapide et qu'une partie transite par un bus lent. Vérifiez la taille réelle du modèle chargé et la mémoire disponible. Une quantification plus agressive ou un modèle plus petit résout le problème immédiatement.

Puis-je remplacer mon abonnement par du local ?

Pour une partie de vos usages, oui, dès aujourd'hui. Pour la totalité, probablement pas encore si vous dépendez des tâches les plus difficiles. La bonne question n'est pas « tout ou rien » mais « quelle proportion » — et elle se mesure en une journée de tests.

Les modèles locaux sont-ils bons en français ?

Cela varie beaucoup d'un modèle à l'autre, et les évaluations publiées portent massivement sur l'anglais. Testez systématiquement sur vos propres textes français avant de conclure. C'est un test d'une demi-heure qui évite une mauvaise surprise.

Est-ce légal d'utiliser ces modèles commercialement ?

Cela dépend de la licence de chaque modèle, et elles diffèrent réellement. Lisez le fichier de licence du dépôt officiel avant tout usage professionnel — il fait rarement plus de deux pages, et c'est la seule source qui engage.

Ce qu'il faut retenir

La question n'est pas « quel matériel faut-il ? » mais « que puis-je faire avec ce que j'ai ? ».

Une seule règle décide : chaque token exige de relire tous les poids du modèle, donc la vitesse vaut la bande passante divisée par la taille du modèle. Elle vous permet d'estimer, avant tout achat, ce que votre machine actuelle produira.

Deux contraintes distinctes en découlent, et les confondre coûte cher : la capacité détermine si le modèle tourne, la bande passante détermine à quelle vitesse. Un modèle qui déborde de la mémoire rapide s'effondre en performance, quelle que soit la puissance de la machine.

Le reste est affaire d'essai. Installez, testez sur vos vraies tâches, mesurez. Vous saurez en une soirée ce qu'aucun guide ne peut vous dire à votre place.

---

Note de méthode

La relation entre bande passante mémoire et vitesse de génération est un résultat établi : l'inférence des modèles de langage est limitée par la mémoire et non par le calcul, chaque token nécessitant la lecture complète des poids. La formule que nous proposons en est la traduction directe, et constitue une borne haute théorique — les performances réelles se situent en deçà, avec des écarts qui varient selon les implémentations.

Les ordres de grandeur de bande passante et de vitesse cités proviennent de sources techniques secondaires et de spécifications constructeurs. Nous les donnons comme repères de calcul, non comme mesures. La bande passante de votre matériel précis est une caractéristique publiée : vérifiez-la plutôt que de vous fier à nos exemples.

Nous ne recommandons aucun modèle de matériel particulier et ne citons aucune référence commerciale. Les gammes évoluent trop vite pour qu'une recommandation datée rende service, et la règle exposée dans l'article permet d'évaluer n'importe quelle configuration.

Les caractéristiques des outils cités — moteur d'exécution, interfaces compatibles, formats de modèles — sont celles rapportées par leur documentation et la littérature technique disponible au 8 août 2026.

Sources

• Silicon Showdown: Performance, Efficiency, and Ecosystem Barriers in Consumer-Grade LLM Inference — arXiv 2605.00519
• Documentation du projet llama.cpp
• Ollama — documentation officielle
• LM Studio — documentation officielle