Faire tourner un LLM en local : le pas-à-pas complet

Faire tourner un LLM en local n'a plus rien d'exotique : une carte graphique de jeu et vingt minutes suffisent. Ce qui reste difficile, c'est de savoir quel modèle votre machine peut réellement porter, et de vérifier qu'il tourne bien là où vous croyez. Ce pas-à-pas traite les deux, dans l'ordre.

Étape 0 : décider si ça vaut le coup

Avant d'installer quoi que ce soit, trois raisons valables de passer au local, et une mauvaise.

La confidentialité. Vos données ne quittent pas votre réseau. Pour un cabinet qui traite des dossiers médicaux, un service RH qui manipule des candidatures, un cabinet d'avocats, ce seul point suffit à trancher.

Le coût marginal nul. Une fois la machine payée, une requête de plus ne coûte rien. Si vous traitez des volumes importants sur une tâche répétitive, le calcul bascule vite.

L'indépendance. Aucune dépréciation de modèle décidée sans vous, aucune hausse de tarif, aucune coupure de service. Le modèle que vous avez téléchargé aujourd'hui tournera à l'identique dans trois ans.

Et la mauvaise raison : « pour faire des économies » sans avoir compté. Une carte de 24 Go, l'électricité et le temps d'administration coûtent plus qu'un abonnement API pour un usage modéré. Faites le calcul avec vos chiffres, la méthode est dans maîtriser la facture d'API IA.

Étape 1 : mesurer ce que votre machine peut porter

C'est l'étape que tout le monde saute, et c'est celle qui décide de tout.

La règle de base : comptez environ 2 Go de mémoire vidéo par milliard de paramètres en pleine précision. La quantification divise ce chiffre : environ 1 Go par milliard en 8 bits, environ 0,5 Go par milliard en 4 bits.

La formule utile, avec la marge :

VRAM ≈ (paramètres en milliards × octets par paramètre) + cache de contexte

Un exemple concret. Un modèle de 8 milliards de paramètres en quantification 4 bits : 8 × 0,5 = 4 Go, plus environ 2 Go pour le contexte, soit 6 Go. Ça tient sur une carte de 8 Go.

Le cache de contexte est le piège de cette étape. Il n'est pas fixe : il grandit avec la longueur du contexte. Sur un modèle de 7 à 8 milliards de paramètres, comptez environ 0,3 Go à 4 000 jetons de contexte, 2,5 Go à 32 000, et une dizaine de gigaoctets à 128 000. Autrement dit, le contexte long que vous avez activé sans y penser peut à lui seul faire déborder votre carte. Si vous êtes juste, quantifier ce cache en 8 bits divise à peu près par deux ce poste.

Repères par palier à l'été 2026, étant entendu que ce paysage bouge tous les mois :

Une nuance qui change beaucoup de choses : les modèles dits à experts clairsemés n'activent qu'une fraction de leurs paramètres à chaque jeton. Un modèle de 80 milliards de paramètres dont 3 milliards seulement sont actifs se comporte, en débit, comme un bien plus petit. Leur poids en mémoire reste celui du modèle entier, mais ils rendent le contexte long beaucoup moins coûteux.

Étape 2 : la quantification en trois minutes

Quantifier, c'est stocker les poids du modèle sur moins de bits. On perd un peu de précision, on gagne beaucoup de mémoire.

Les niveaux que vous croiserez, du plus léger au plus fidèle :

• Q3_K_M : quand la mémoire manque vraiment. La dégradation commence à se voir.
• Q4_K_M : le réglage par défaut, et le bon choix dans neuf cas sur dix. Environ un quart de la taille d'origine pour moins de 5 % de qualité perdue.
• Q6_K et Q8_0 : pour qui a la mémoire et veut le maximum de fidélité.

La règle qui évite l'erreur la plus commune : un modèle de 8 milliards de paramètres en Q4 propre bat un modèle de 70 milliards en Q2 qui étouffe. La tentation de faire tourner le plus gros modèle possible en le compressant à l'extrême produit des résultats médiocres et lents. Choisissez la taille qui tient confortablement, pas celle qui rentre de justesse.

Étape 3 : installer et lancer

Ollama est le chemin le plus court. Il télécharge, quantifie, sert une API et gère la mémoire tout seul.

# Linux
curl -fsSL https://ollama.com/install.sh | sh

# macOS et Windows : installeur graphique sur ollama.com/download

Ensuite, récupérez un modèle dimensionné selon l'étape 1 et lancez-le :

ollama pull qwen3:8b
ollama run qwen3:8b

Le premier téléchargement pèse quelques gigaoctets. Une fois rendu, vous avez une invite : posez une question, vous devez voir la réponse s'écrire. Si vous en êtes là, la partie facile est finie.

Étape 4 : vérifier que ça tourne vraiment sur le GPU

C'est l'étape que personne ne fait, et c'est celle qui explique 90 % des déceptions.

Le symptôme est toujours le même : « ça marche mais c'est lent ». La cause est presque toujours la même aussi : le modèle tourne en réalité sur le processeur, ou à moitié.

Ollama bascule silencieusement une partie des couches vers la mémoire système quand la carte est trop petite. Il ne prévient pas. Un modèle de 70 milliards de paramètres sur une carte de 24 Go passe ainsi de plus de 30 jetons par seconde à 3 ou 8, sans un message d'erreur.

Le contrôle, pendant que le modèle répond :

ollama ps          # colonne PROCESSOR : doit dire GPU, pas CPU ni un partage
nvidia-smi         # la mémoire occupée doit correspondre à votre estimation

Si la colonne indique un partage CPU/GPU, vous avez deux options : prendre un modèle plus petit, ou descendre d'un cran de quantification. Forcer le nombre de couches sur le GPU avec le paramètre num_gpu ne sert à rien si la mémoire n'y est pas.

Le même piège existe sur llama.cpp, sous une autre forme : l'option -ngl vaut zéro par défaut, ce qui fait tourner le modèle sur le processeur même sur une compilation GPU. Mettez -ngl 99 pour tout envoyer sur la carte.

Étape 5 : mesurer votre débit

Ne vous fiez pas à l'impression. Mesurez, une fois, et notez le chiffre.

ollama run qwen3:8b --verbose "Explique en trois phrases ce qu'est un jeton."

L'option affiche en fin de réponse le nombre de jetons produits et la durée, donc le débit en jetons par seconde. Les ordres de grandeur pour situer votre résultat : au-dessus de 30 jetons par seconde, la lecture est confortable et suit le rythme d'un lecteur humain ; entre 10 et 30, c'est utilisable pour du traitement en tâche de fond ; en dessous de 10, il faut revoir le dimensionnement.

Refaites la mesure après chaque changement de modèle ou de quantification. C'est le seul moyen de comparer autre chose que des impressions.

Étape 6 : brancher votre code dessus

Le vrai intérêt commence ici. Ollama expose une API compatible avec celle d'OpenAI, ce qui veut dire que votre code existant fonctionne en changeant deux lignes.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",              # ignorée, mais le champ doit exister
)

reponse = client.chat.completions.create(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "Résume ce texte en trois points."}],
)
print(reponse.choices[0].message.content)

Cette compatibilité est l'argument décisif, et il vaut au-delà du local : si votre code parle ce dialecte, vous pouvez basculer entre un modèle local et un fournisseur distant en changeant une URL. C'est exactement la couche d'abstraction qui vous évite d'être prisonnier d'un fournisseur.

Quand passer à llama.cpp ou vLLM

Ollama couvre le poste de travail et le petit serveur. Deux cas justifient d'en sortir.

llama.cpp quand vous voulez la maîtrise fine : choisir vos couches, régler le cache de contexte, compiler pour votre matériel exact, faire tourner sur du matériel modeste ou exotique. C'est d'ailleurs le moteur qui tourne sous Ollama.

vLLM quand plusieurs personnes ou plusieurs processus tapent sur le même modèle en même temps. Son traitement par lots continu multiplie le débit agrégé dans ce cas précis. Pour un utilisateur seul, il n'apporte rien de plus qu'Ollama et coûte nettement plus cher en administration.

Ce que le local ne fera pas pour vous

Trois limites à connaître avant de promettre quoi que ce soit à votre direction.

Vous n'aurez pas le niveau des meilleurs modèles fermés sur les tâches les plus difficiles. L'écart s'est beaucoup resserré, au point que le meilleur modèle à poids ouverts talonne désormais les modèles propriétaires de tête, comme nous le racontions à propos de la vague des modèles ouverts chinois. Mais sur un mono-GPU, vous faites tourner un modèle bien plus petit que ceux-là.

Vous héritez de l'exploitation. Mises à jour, sauvegardes, supervision, sécurité de l'accès. Ce n'est pas gratuit, c'est simplement payé en temps plutôt qu'en abonnement.

Le contexte long coûte de la mémoire, pas de l'argent. La contrainte change de nature mais ne disparaît pas, et les effets décrits dans ce que change le contexte long restent entiers.

Le chemin le plus court, en résumé

1. Comptez votre mémoire vidéo et calculez ce qu'elle porte, cache de contexte compris.
2. Prenez la taille qui tient confortablement en Q4_K_M, pas celle qui rentre de justesse.
3. Installez Ollama, tirez le modèle, lancez-le.
4. Vérifiez qu'il tourne sur le GPU. Vraiment.
5. Mesurez votre débit et notez-le.
6. Branchez votre code sur l'API compatible, et gardez cette couche d'abstraction.

Comptez une demi-journée pour la première fois, une demi-heure pour les suivantes.