IA locale sur PC : le guide complet pour démarrer

Installer un modèle de langage sur sa propre machine prend aujourd'hui une dizaine de minutes et ne coûte rien. La vraie question n'est pas comment faire, elle est de savoir ce que votre matériel encaisse réellement et ce que vous perdez au passage. Voilà les deux réponses, chiffres à l'appui.

Pourquoi faire tourner une IA en local plutôt que dans le cloud ?

Une IA locale traite vos données sur votre machine, sans qu'aucun texte ne parte vers un serveur. C'est l'argument qui décide pour la plupart de ceux qui franchissent le pas : un contrat, un compte rendu médical, du code sous NDA ou les notes internes d'une PME ne quittent jamais le disque. Le reste suit naturellement. L'usage ne coûte plus rien une fois le matériel acheté, sans facture au token ni quota mensuel. Ça marche en avion, en déplacement ou avec une connexion qui tombe. Et personne ne peut décider du jour au lendemain de retirer le modèle que vous utilisiez, de changer son comportement ou de durcir ses filtres. Si le vocabulaire vous manque encore, notre explication d'un LLM pose les bases avant d'aller plus loin.

Un argument revient souvent et mérite d'être coupé court : le local ne serait pas automatiquement plus sobre. Votre carte graphique tire beaucoup pendant qu'elle génère, et l'empreinte réelle d'une requête IA dépend surtout de la taille du modèle et du nombre de tokens produits, pas de l'endroit où il tourne. Ce qui change vraiment, c'est la confidentialité et le contrôle.

De quel matériel avez-vous vraiment besoin ?

La mémoire vidéo décide de tout : un modèle doit tenir entièrement dans la VRAM pour tourner à vitesse normale. Son poids dépend du nombre de paramètres et de la quantification, cette compression qui remplace des poids en 16 bits par des entiers plus courts. Le format GGUF, utilisé par llama.cpp et donc par presque tous les outils grand public, accepte de 1,5 à 8 bits. En pratique tout le monde tourne en 4 bits (le Q4_K_M, quantification par défaut d'Ollama), qui divise le poids par environ quatre pour une dégradation que la plupart des usages ne perçoivent pas.

Les tailles de téléchargement de la bibliothèque Ollama sont le meilleur repère, puisqu'elles correspondent à des modèles déjà quantifiés :

• Qwen3.5 4B : 4 milliards de paramètres, 3,4 Go sur disque, confortable avec 8 Go de VRAM.
• Qwen3.5 9B : 9 milliards de paramètres, 6,6 Go sur disque, confortable avec 12 Go.
• Gemma 4 12B : 12 milliards de paramètres, 7,6 Go sur disque, confortable avec 16 Go.
• Qwen3.5 27B : 27 milliards de paramètres, 17 Go sur disque, confortable avec 24 Go.
• Gemma 4 31B : 31 milliards de paramètres, 20 Go sur disque, 24 Go de VRAM et c'est serré.
• Qwen3.5 122B : 122 milliards de paramètres, 81 Go sur disque, il faut une station de travail.

Retenez l'ordre de grandeur : environ 0,6 à 0,7 Go par milliard de paramètres en 4 bits, auxquels s'ajoutent 1 à 3 Go pour le cache de contexte, cette mémoire qui garde la conversation en cours et qui grimpe avec la longueur du contexte. Une carte de 8 Go fait donc tourner du 4B très à l'aise et du 9B avec un contexte modeste. À 16 Go on vise le 12B, ce que Google annonce d'ailleurs comme la cible de Gemma 4 12B. À 24 Go on attaque le 27B ou le 31B. Au-delà, il faut deux cartes ou du matériel professionnel.

Les Mac Apple Silicon jouent à part, avec leur mémoire unifiée : le GPU pioche directement dans la RAM système. Un MacBook à 32 Go fait donc tourner ce qui exigerait une carte à 32 Go de VRAM, ce qui n'existe pas côté PC grand public à prix raisonnable. Et si vous manquez de VRAM, llama.cpp sait répartir le modèle entre carte graphique et processeur, mais la vitesse s'effondre dès que la RAM système entre dans l'équation.

À quelle vitesse tourne un modèle local, concrètement ?

On mesure la génération en tokens par seconde, et l'écart entre matériels se compte en facteur 20, pas en pourcentage. Sur un modèle de 7 milliards de paramètres en 4 bits, les mesures llama-bench de la communauté llama.cpp donnent environ 290 tokens/s sur une RTX 5090, 186 sur une RTX 4090, 158 sur une RTX 3090 et 142 sur une RTX 4080. NVIDIA annonce de son côté environ 150 tokens/s pour un Llama 3 8B en 4 bits sur RTX 4090, ce qui recoupe l'ordre de grandeur. Côté Apple, le même modèle donne 83 tokens/s sur un M4 Max, 51 sur un M4 Pro, 24 sur un M4 de base et 14 sur le M1 d'origine.

Ces écarts s'expliquent moins par la puissance de calcul que par la bande passante mémoire : la génération relit tous les poids du modèle à chaque token produit. Le M1 de base plafonne à 68 Go/s quand le M4 Max monte à 546 Go/s, et le rapport de vitesse suit presque exactement. Corollaire utile : un modèle trois fois plus gros tourne à peu près trois fois moins vite sur la même carte. Un 27B qui donnerait 60 tokens/s en 7B tombera autour de 15 à 20.

En pratique, une vingtaine de tokens par seconde suffit pour une conversation confortable, où le texte s'affiche à peu près au rythme de la lecture. En dessous de dix, vous attendez. Un vieux portable sans carte dédiée tournera à quelques tokens par seconde sur un modèle de 4B : jouable pour du traitement en tâche de fond, pénible pour discuter.

Ollama, LM Studio ou llama.cpp : lequel installer ?

Trois outils se partagent le terrain en 2026, et deux d'entre eux reposent sur le troisième. llama.cpp est le moteur d'inférence écrit en C et C++ : c'est lui qui lit le GGUF, gère les backends CUDA, Metal, Vulkan et ROCm, et sait répartir un modèle entre GPU et processeur. Vous ne l'installez directement que si vous voulez régler vous-même la quantification, la taille de contexte et les drapeaux de compilation.

Ollama (version 0.32.7 au 10 août 2026) est l'option la plus directe pour qui aime la ligne de commande : ollama run gemma4:12b télécharge le modèle et ouvre le chat, une API HTTP locale permet de brancher vos propres scripts, et une application de bureau est fournie pour ceux qui ne veulent pas ouvrir un terminal. Attention à une nuance : Ollama propose aussi des modèles marqués :cloud, exécutés sur ses serveurs. Pratique pour un modèle trop gros pour votre machine, mais ce n'est plus du local, et vos données partent.

LM Studio vise le chemin le plus court avec une interface graphique : catalogue de modèles téléchargeables en un clic, moteurs llama.cpp et MLX (l'accélération Apple), serveur local exposant une API compatible OpenAI, et discussion avec vos documents entièrement hors ligne. Si plusieurs personnes partagent une machine ou que vous voulez une interface web à la ChatGPT branchée sur vos propres documents, Open WebUI se pose au-dessus d'Ollama et fonctionne intégralement sans connexion, avec ses bases de connaissances intégrées.

Où s'arrête une IA locale (et où elle suffit largement)

Un modèle de 8 ou 12 milliards de paramètres sur votre PC ne remplace pas un modèle frontière, et il faut le dire franchement. Il se trompe plus souvent sur les faits, perd le fil sur un raisonnement en plusieurs étapes, produit du code qui compile moins souvent, et sa connaissance du monde s'arrête à son entraînement. Si votre besoin est d'obtenir la meilleure réponse possible à une question difficile, les assistants en ligne restent devant, et l'écart ne se comble pas en changeant de réglage.

Là où un modèle local fait le travail sans discussion, c'est sur les tâches où le texte est fourni et où le modèle n'a rien à inventer : résumer un document, reformuler ou traduire, extraire des informations structurées (dates, montants, références) vers du JSON, classer et trier des messages, produire un premier brouillon à retravailler, ou répondre sur vos propres fichiers via du RAG, cette technique qui donne au modèle les extraits pertinents de vos documents avant qu'il ne réponde. Sur ces usages, la différence avec un modèle cloud est faible, et l'avantage de confidentialité est total.

Là où ça coince : le raisonnement long en plusieurs étapes, le code agentique sur un dépôt entier, les questions factuelles pointues ou récentes, et les très longs contextes. Les fenêtres annoncées atteignent 256 000 tokens sur Gemma 4 et Qwen3.5, mais remplir un contexte pareil dévore la VRAM via le cache et fait chuter la vitesse. Le réglage qui marche pour beaucoup de gens tient en une phrase : le local par défaut pour tout ce qui est sensible ou répétitif, le cloud pour les 10 % de questions vraiment difficiles.

FAQ

Peut-on faire tourner une IA locale sans carte graphique dédiée ?

Oui. llama.cpp répartit le modèle entre processeur et mémoire système, et un modèle de 2 à 4 milliards de paramètres reste utilisable. Comptez quelques tokens par seconde seulement, ce qui convient à du traitement en arrière-plan mais pas à une conversation.

Mes conversations partent-elles vraiment nulle part ?

Avec un modèle téléchargé et exécuté localement, rien ne sort de la machine, et vous pouvez le vérifier en coupant le réseau. Attention toutefois aux modèles marqués :cloud chez Ollama ou aux modèles distants proposés dans LM Studio : ceux-là envoient bien vos requêtes à un serveur.

Quel modèle installer en premier ?

Avec 16 Go de VRAM ou de mémoire unifiée, Gemma 4 12B est le point d'entrée le plus équilibré. Entre 8 et 12 Go, Qwen3.5 9B fait le travail. En dessous, Qwen3.5 4B tient dans 3,4 Go et reste correct sur du résumé et de la reformulation.

Q4, Q8 : quelle quantification choisir ?

Q4_K_M par défaut, c'est le meilleur compromis entre poids et qualité et c'est ce que servent les outils sans réglage. Passez en Q8 si votre VRAM est large et que vous cherchez le maximum de fidélité. Les paliers en dessous de 4 bits existent jusqu'à 1,5 bit, mais ne se justifient que si le modèle ne tient pas autrement.

Une IA locale peut-elle répondre sur mes propres documents ?

Oui, c'est même son terrain le plus solide. LM Studio et Open WebUI intègrent le RAG : vous déposez vos fichiers, l'outil les découpe et les indexe, puis fournit au modèle les extraits utiles au moment de répondre. Tout reste sur le disque.

Sources

• llama.cpp (dépôt GitHub) : le moteur d'inférence derrière la plupart des outils grand public, ses quantifications de 1,5 à 8 bits et ses backends CUDA, Metal, Vulkan et ROCm.
• llama.cpp : performances sur NVIDIA CUDA : tableau de mesures llama-bench carte par carte, tenu par la communauté du projet.
• llama.cpp : performances sur Apple Silicon : les mêmes mesures sur les puces M1 à M4, avec la bande passante mémoire de chaque modèle.
• Bibliothèque de modèles Ollama : taille de téléchargement et longueur de contexte de chaque modèle et de chaque variante.
• Google : guide développeur de Gemma 4 12B : architecture du modèle et matériel visé pour une exécution locale.