Faire tourner une IA en local sur un PC sans carte graphique

Faire tourner une IA en local, concrètement

Faire tourner une IA en local, ça veut dire une chose précise : un modèle de langage (LLM) qui s'exécute entièrement sur votre machine, sans qu'aucune requête ne parte vers un serveur externe. Pas d'API, pas d'abonnement, pas de connexion obligatoire une fois le modèle téléchargé.

Trois raisons concrètes d'aller dans cette direction :

• Confidentialité — rien ne sort de la machine. Utile pour des documents internes, du code propriétaire, ou simplement par principe.
• Coût — pas de facturation à la requête ni d'abonnement mensuel. Le modèle est téléchargé une fois, gratuitement pour la quasi-totalité des modèles open source.
• Hors-ligne — ça fonctionne sans connexion internet, une fois le modèle sur le disque.

Ce que la plupart des guides sur le sujet ne disent pas clairement : ils sont écrits en supposant un GPU avec 12, 16 ou 24 Go de VRAM. C'est une configuration de passionné ou de poste de développement IA, pas celle de la majorité des gens qui ont un PC de bureau ou un laptop pro standard. Cet article est mesuré sur une configuration sans carte graphique du tout — inférence 100 % CPU — parce que c'est la situation la plus courante et la moins documentée.

Faut-il un GPU pour faire tourner une IA en local ?

Non. Ollama et llama.cpp tournent très bien en CPU pur. Ce que vous perdez, c'est de la vitesse — un GPU parallélise le calcul matriciel d'une façon qu'un CPU, même récent et multicœur, ne peut pas égaler. Ce que vous gagnez : aucune contrainte de VRAM, et la possibilité de faire tourner des modèles volumineux tant qu'ils tiennent en RAM, une ressource généralement bien plus abondante et bien moins chère que la VRAM d'un GPU dédié.

Sur CPU, la contrainte réelle n'est donc pas la VRAM — elle n'existe pas — mais la RAM. Le modèle entier doit y tenir, en plus de ce qu'utilisent déjà le système et vos autres applications.

Quelle configuration pour faire tourner une IA en local ?

Machine de test pour cet article :

La règle de calcul pratique, sans GPU : taille du fichier modèle (visible avec ollama list) + 1 à 2 Go de marge pour le système et le contexte, à comparer à votre RAM disponible. Sur cette machine à 32 Go, on a mesuré le chargement d'un modèle de 23 Go : il occupe environ 15,3 Go de RAM une fois chargé (mesuré, pas la taille du fichier telle quelle — un GGUF quantifié en mémoire n'occupe pas exactement la taille du fichier sur disque). Ça laisse une marge correcte, mais un deuxième modèle de cette taille ne tiendrait pas en même temps.

> mesure RAM (ollama.exe + llama-server.exe) pendant : ollama run qwen3.5:35b-a3b "reponds juste OK"

t=+0.0s   RAM = 4212 Mo
t=+2.1s   RAM = 4874 Mo
t=+4.2s   RAM = 8148 Mo
t=+6.2s   RAM = 10901 Mo
t=+8.3s   RAM = 13395 Mo
t=+10.3s  RAM = 15274 Mo
t=+12.4s  RAM = 17314 Mo   ← pic de cette phase
   [...]
t=+49.2s  RAM = 9999 Mo
t=+54.3s  RAM = 11566 Mo
t=+58.9s  RAM = 12487 Mo
t=+61.7s  process termine (reponse recue)

Capture réelle, échantillonnée toutes les 0,5s (extrait). Cette fois-ci le chargement a pris 61,7s au lieu des ~30s mesurés dans le benchmark principal — variance d'un run à l'autre. La RAM redescend puis remonte en cours de route : sur cette machine à 32 Go, un modèle de 23 Go laisse peu de marge, ce qui peut provoquer des allers-retours mémoire côté OS. Je le montre tel quel plutôt que de lisser une courbe plus propre.

Comment choisir son modèle ?

Pas de classement ici — un top 5 des modèles 2026 sera périmé dans trois mois. La logique de choix, elle, reste valable plus longtemps :

• La taille (en paramètres) détermine l'occupation RAM. Mettez-la en face de ce que vous avez réellement disponible, pas de ce que vous pourriez avoir un jour.
• La quantification (Q4_K_M, Q5_K_M, Q8_0…) réduit la taille du fichier en arrondissant la précision des poids du modèle. Plus le chiffre est bas, plus le fichier est petit et rapide, au prix d'une qualité de réponse qui se dégrade progressivement. Q4_K_M est un compromis courant et raisonnable pour un usage local.
• Dense ou MoE (mixture-of-experts) — c'est le point le plus contre-intuitif, et celui qui change vraiment la donne en CPU pur.

Ce qu'on a mesuré sur cette machine : les modèles MoE testés génèrent plus vite que les modèles denses plus petits, malgré une taille sur disque 4 à 5 fois supérieure. Un modèle MoE de 18-23 Go a tourné à 13-21 tokens/seconde, contre 8-11 tokens/seconde pour des modèles denses de 4-8 Go. Contre-intuitif, mais explicable : dans un modèle dense, chaque token traité active la totalité des paramètres du modèle. Dans un modèle MoE, le modèle est découpé en plusieurs "experts" spécialisés, et seule une petite fraction d'entre eux s'active pour un token donné — le reste ne calcule rien. Le fichier sur disque contient tous les experts (d'où sa taille), mais le calcul réel par token ne mobilise qu'une fraction des paramètres, souvent équivalente à un modèle bien plus petit. Résultat : un gros fichier, un chargement plus long, mais une génération aussi rapide qu'un modèle dense nettement plus léger.

> ollama list

NAME                       ID              SIZE      MODIFIED
qwen3.5:35b-a3b            3460ffeede54    23 GB     7 days ago
mistral:latest             6577803aa9a0    4.4 GB    3 weeks ago
hermes3:8b                 4f6b83f30b62    4.7 GB    3 weeks ago
qwen3:8b                   500a1f067a9f    5.2 GB    4 weeks ago
comall-coder-moe:latest    193106997274    18 GB     4 weeks ago
qwen3-coder:30b            06c1097efce0    18 GB     4 weeks ago
qwen3-embedding:0.6b       ac6da0dfba84    639 MB    4 weeks ago

Sortie réelle de ollama list sur la machine de test — les sept modèles utilisés pour les mesures de cet article.

Installer Ollama et lancer son premier modèle

Les étapes, dans l'ordre :

1. Télécharger l'installeur Windows depuis ollama.com et l'exécuter — interface graphique standard, aucune configuration particulière à ce stade.
2. Télécharger un premier modèle :

   ollama pull mistral

3. Lancer une première conversation :

   ollama run mistral

Précision honnête sur cette section : on n'a pas pu chronométrer une installation "à froid" dans un environnement neuf pour cet article. Cette machine tourne en Windows 11 Famille, qui n'a pas Windows Sandbox (réservé aux éditions Pro/Entreprise), et désinstaller/réinstaller Ollama sur l'installation existante aurait mis en jeu 53 Go de modèles déjà téléchargés pour un gain d'information limité. Les étapes ci-dessus sont les étapes officielles réelles ; le temps d'installation n'est volontairement pas chiffré ici plutôt que de donner un chiffre non vérifié.

> ollama run mistral "explique en 3 phrases ce qu'est la quantification"

La quantification est le processus de mesurer ou d'attribuer une valeur numérique à quelque chose pour en faciliter l'analyse et la comparaison. Elle consiste en l'attribution de nombres ou d'unités à un ensemble de données.

Sortie réelle de mistral:latest. À noter : c'est la définition de la quantification au sens mathématique général — pas le sens spécifique au machine learning (réduction de la précision des poids d'un modèle) qui nous intéresse dans cet article. Un modèle peut très bien répondre à côté sur un terme ambigu, même sans se tromper sur les faits.

Quelles performances réelles sur une machine sans GPU ?

Sept modèles installés sur cette machine, chacun testé sur un prompt court (une question simple) et un prompt long (~1000 caractères de contexte suivi d'une question). Deux mesures par test : le débit de génération en tokens/seconde, et le temps de chargement.

Méthodologie : 2 prompts fixes identiques pour tous les modèles, mesure via ollama run --verbose (champ eval rate). qwen3-embedding:0.6b exclu du tableau — c'est un modèle d'embeddings, il ne génère pas de texte.

Deux constats qui reviennent régulièrement dans les résultats :

1. Le chargement à froid coûte cher, le chargement à chaud ne coûte presque rien. Le modèle de 23 Go a mis 30 secondes à charger la première fois (lecture disque). Rappelé quelques minutes plus tard, tant qu'Ollama le garde en mémoire (keep_alive, 5 minutes par défaut), le chargement est tombé à 0,27 seconde. En usage réel, la lenteur du "premier prompt" n'est pas la vitesse du modèle — c'est le temps de lecture disque, qui ne se reproduit pas tant que vous enchaînez les questions.

2. Le temps mesuré avant la première réponse visible à l'écran est plus long que ce que les statistiques internes d'Ollama indiquent — de 0,5 à 5 secondes de plus, selon les tests. Cet écart correspond au démarrage du process ollama run lui-même (lancement, connexion au serveur local) : un coût fixe, invisible dans les statistiques de génération, mais bien réel pour quelqu'un qui regarde un terminal vide.

> ollama run mistral "explique en 3 phrases ce qu'est la quantification" --verbose

La quantification est le processus de mesurer, de qualifier ou de calculer une grandeur ou une quantité, en utilisant des unités ou des méthodes de mesure standardisées. Cela permet d'évaluer les quantités ou des ensembles d'objets et de les comparer ou d'analyser statistiquement.

total duration:       6.9561214s
load duration:        21.9575ms
prompt eval count:    17 token(s)
prompt eval duration: 98.067ms
prompt eval rate:     173.35 tokens/s
eval count:           79 token(s)
eval duration:        6.830568s
eval rate:            11.57 tokens/s

Sortie réelle de --verbose — c'est ce champ eval rate qui donne tous les tokens/seconde cités dans cet article.

Où est-ce que ça casse vraiment ?

Plutôt que des impressions générales, trois tâches concrètes testées sur deux modèles : mistral:latest (7B dense) et qwen3-coder:30b (MoE). Réponses exécutées et vérifiées, pas jugées à l'œil.

Tâche 1 — raisonnement en plusieurs étapes. Un problème de calcul de production avec un piège de lecture ("50 % de pièces en plus", pas "50 % de pièces"). Réponse correcte vérifiée à la main : 280.

• mistral:latest a mal interprété "50 % en plus" comme "50 % de", et a fait une erreur de calcul supplémentaire en route (120 − 6 annoncé comme 116,8). Résultat : 170, faux.
• qwen3-coder:30b a suivi le bon raisonnement à chaque étape et donné 280, correct.

Tâche 2 — génération de code non triviale. Une fonction Python avec une contrainte de tri explicite. Code généré exécuté sur un jeu de test avec des valeurs volontairement dans le désordre.

• mistral:latest a correctement exclu les quantités négatives ou nulles et calculé les bons montants, mais a complètement oublié le tri par valeur décroissante demandé dans la consigne — vérifié à l'exécution, l'ordre retourné est l'ordre d'insertion, pas l'ordre trié.
• qwen3-coder:30b a produit une fonction correcte sur tous les points, tri inclus, vérifiée à l'exécution.

Tâche 3 — résumé d'un document long. Résumer un vrai article du site (1062 mots, sur la réforme de la facturation électronique) en 5 phrases maximum, sans ajouter d'information absente du texte.

• mistral:latest a répondu en anglais sans qu'on le lui demande, et a inventé un chiffre : "grandes entreprises > 1,5 million" de chiffre d'affaires, alors que le texte source dit 1,5 milliard — une erreur d'un facteur 1000.
• qwen3-coder:30b a répondu en français, et tous les chiffres vérifiés (1,5 Md€, 250 M€, 15 000€, 50€, 500€, les deux dates) correspondent exactement au texte source.

Sur ces trois tâches, le modèle plus petit et dense a échoué de trois façons différentes, le modèle MoE plus gros a réussi à chaque fois. Ce n'est pas une limite du "local" en tant que tel — c'est une limite du choix de modèle. La même machine, avec un autre modèle, ne se trompe pas.

Mais le modèle qui a tout réussi jusque-là a, lui aussi, une vraie limite : la fenêtre de contexte par défaut. Sur un test avec un document combiné de ~3000 mots (plusieurs pages du site mises bout à bout) suivi d'une question portant sur une information tout au début du texte et une autre tout à la fin, qwen3-coder:30b a correctement répondu sur la partie de fin, mais a répondu "information non présente" pour la partie de début — alors qu'elle était bien dans le texte envoyé. Les statistiques internes de l'appel confirment la cause : prompt eval count: 2050 token(s), alors que le document dépassait largement ce nombre de tokens. La fenêtre de contexte par défaut d'Ollama a tronqué le prompt sans erreur ni avertissement, en ne gardant que la fin — le modèle n'a tout simplement jamais "vu" le début du document.

C'est la limite la plus piégeuse des trois : les deux premières se voient (une mauvaise réponse, un code qui ne trie pas). Celle-ci ne se voit pas — la réponse a l'air normale, elle est juste construite sur un texte tronqué en silence. Pour un document long, il faut augmenter explicitement le paramètre num_ctx plutôt que de faire confiance au réglage par défaut.

Passer à l'échelle entreprise

Tout ce qui précède décrit un usage personnel, sur une seule machine, avec les limites que ça implique : pas de garantie de disponibilité, pas de gestion multi-utilisateurs, une fenêtre de contexte à surveiller manuellement, et un modèle à choisir et remplacer soi-même à chaque évolution. Ça suffit pour explorer, tester, ou un usage individuel occasionnel.

Pour un usage d'équipe fiable — extraction automatique de certificats et factures, assistant documentaire connecté à un ERP, disponibilité garantie pendant les heures de production — la question change de nature : ce n'est plus "quel modèle je lance sur mon PC", mais "quelle infrastructure tient dans la durée, avec quelle maintenance". C'est le sujet de notre approche de l'IA privée : les données restent sur l'infrastructure du client, mais dimensionnée et maintenue pour un usage professionnel plutôt qu'un poste de travail individuel.

Dans un contexte industriel, ce genre de module d'IA documentaire prend tout son sens intégré directement à l'outil de production plutôt qu'à côté — c'est l'approche qu'on détaille sur notre page ERP sur mesure.

Si vous testez l'IA en local sur votre atelier et que vous voulez creuser ce qui a du sens à passer à l'échelle chez vous, on peut en discuter — un diagnostic de 45 minutes, sans engagement.