Faire tourner un LLM sur votre propre machine : le TP

On nous pose souvent la question : « combien ça coûte, un serveur pour faire tourner un LLM ? » La bonne réponse, dans neuf cas sur dix, c’est : commencez par ne rien acheter. L’ordinateur sur lequel vous lisez cette page fait probablement tourner un modèle très correct, ce soir, gratuitement.

Ce guide est un TP. Vous l’exécutez sur votre propre machine, du début à la fin, sans carte bancaire et sans compte à créer. À l’arrivée vous aurez un modèle qui répond en local, une interface web propre, et la capacité d’interroger vos propres documents. Surtout, vous saurez ce que votre matériel encaisse vraiment, ce qui est la seule façon honnête de décider si vous avez besoin d’investir ensuite.

Ce que votre machine peut encaisser

C’est la seule question qui compte avant de commencer, et elle se résume à une contrainte : la mémoire. Un modèle de langage doit être chargé entièrement dans une mémoire accessible par l’unité de calcul. S’il n’y tient pas, le système se met à échanger avec le disque et les performances s’effondrent d’un facteur dix ou vingt.

La règle pratique tient en une ligne : prenez la taille du fichier annoncée, ajoutez 20 %, et vérifiez que vous avez cette quantité de mémoire libre. Sur un Mac Apple Silicon, la mémoire est unifiée, donc c’est votre RAM totale moins ce qu’occupe le système. Sur un PC avec une carte graphique dédiée, c’est la VRAM de la carte qui compte, et à défaut la RAM avec des performances nettement moindres.

Tailles relevées sur la bibliothèque Ollama au 17 août 2026. Elles bougent : vérifiez avant de télécharger.

Un mot sur le choix du modèle pour le français. Mistral reste une valeur sûre, conçu en France et parfaitement à l’aise dans notre langue. Les familles Qwen et Gemma sont devenues très solides en multilingue et se mettent à jour beaucoup plus souvent, ce qui compte quand on veut du récent.

Étape 1 : installer Ollama

Ollama est le moyen le plus court d’arriver à un modèle qui répond. Il télécharge les modèles, les charge en mémoire et expose une API locale, sans configuration.

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

# macOS : via Homebrew (ou le .dmg sur ollama.com)
brew install ollama

# Windows : telecharger l'installeur sur ollama.com/download

# Verifier que le service repond
ollama --version
curl http://localhost:11434/api/tags

Une remarque de prudence, parce qu’on la doit : curl | sh exécute un script distant avec vos droits. C’est la méthode que documente l’éditeur, elle est courante, mais rien ne vous empêche de télécharger le script d’abord et de le lire avant de le lancer. Sur une machine professionnelle, c’est même la bonne habitude.

Notez le port 11434. Par défaut Ollama n’écoute que sur localhost, donc rien n’est exposé à votre réseau. Gardez-le ainsi tant que vous n’avez pas mis d’authentification devant, nous y revenons plus bas.

Étape 2 : votre premier modèle

Choisissez dans le tableau ci-dessus une taille compatible avec votre mémoire, puis lancez-la. Le premier appel télécharge le modèle, les suivants sont immédiats.

# Modele confortable sur 16 Go de RAM
ollama run mistral

# Machine plus modeste : 8 Go
ollama run qwen3:4b

# Lister ce qui est installe, et ce qui tourne
ollama list
ollama ps

# Liberer la memoire sans desinstaller
ollama stop mistral

# Supprimer completement un modele
ollama rm mistral

Une fois dans l’invite, tapez une vraie question métier, pas « bonjour ». Demandez un résumé d’un paragraphe que vous collez, une reformulation en langage client, une extraction de dates depuis un texte. C’est là que vous verrez si le modèle tient la route pour votre usage réel.

Étape 3 : comprendre la quantification

C’est le concept qui explique pourquoi un modèle de 27 milliards de paramètres peut peser 17 Go et non 54. Les paramètres du modèle sont à l’origine stockés en 16 bits. La quantification les réencode sur moins de bits, typiquement 4, ce qui divise la taille par trois ou quatre au prix d’une perte de qualité généralement faible.

Le réflexe utile : à mémoire égale, un gros modèle fortement quantifié bat presque toujours un petit modèle en pleine précision. Entre qwen3:14b en Q4 et qwen3:4b en fp16, qui occupent une place comparable, le premier donnera de meilleurs résultats sur la quasi-totalité des tâches.

Étape 4 : mesurer au lieu de deviner

« C’est lent » n’est pas un diagnostic. La bonne unité est le nombre de tokens générés par seconde. En dessous de 5 tokens par seconde, la lecture devient pénible. Autour de 15 à 20, vous lisez au fil de la génération. Au-delà de 30, c’est confortable.

# Dans l'invite ollama run, activer les statistiques
>>> /set verbose
>>> Redige un paragraphe de 200 mots sur la sauvegarde informatique.

# Ollama affiche alors, entre autres :
#   eval count       : nombre de tokens generes
#   eval duration    : temps de generation
#   eval rate        : tokens par seconde  <-- la metrique utile

# Meme mesure via l'API, utile pour scripter une comparaison
curl -s http://localhost:11434/api/generate -d '{
  "model": "mistral",
  "prompt": "Explique le RAID 1 en trois phrases.",
  "stream": false
}' | python3 -c "import json,sys; d=json.load(sys.stdin); \
print(round(d['eval_count']/(d['eval_duration']/1e9),1), 'tokens/s')"

Étape 5 : une vraie interface

Le terminal va cinq minutes. Pour un usage quotidien, et surtout pour faire tester à des collègues, il faut une interface web. Open WebUI est le choix évident : il détecte Ollama automatiquement, gère les comptes, l’historique des conversations et l’import de documents.

# Linux : le conteneur parle a l'Ollama de la machine hote
docker run -d --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# macOS et Windows : --network=host n'existe pas, on publie le port
docker run -d -p 3000:8080 \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# Puis ouvrir http://localhost:3000 (ou :8080 avec --network=host)
# Le premier compte cree devient administrateur.

Étape 6 : interroger vos documents

C’est là que le TP devient intéressant, parce qu’un modèle généraliste ne connaît rien à votre entreprise. Le principe s’appelle le RAG, pour Retrieval-Augmented Generation : on découpe vos documents, on les transforme en vecteurs numériques, et à chaque question on va chercher les passages pertinents pour les donner au modèle avant qu’il réponde.

Open WebUI intègre tout le nécessaire. Il vous manque juste un modèle d’embeddings, un petit modèle spécialisé dans la transformation de texte en vecteurs.

# 1. Recuperer un modele d'embeddings (274 Mo, tres leger)
ollama pull nomic-embed-text

# 2. Dans Open WebUI : Parametres > Documents
#    Moteur d'embedding      : Ollama
#    Modele d'embedding      : nomic-embed-text
#    Taille des blocs        : 1000 caracteres
#    Chevauchement des blocs : 100 caracteres

# 3. Espace de travail > Base de connaissances > Creer
#    Deposer vos PDF, .docx, .md, .txt

# 4. Dans une conversation, appeler la base avec le diese
#    #ma-base Quelle est notre procedure de sauvegarde ?

Testez avec une vingtaine de documents avant d’en verser mille. Le RAG a une façon bien à lui d’échouer : il répond avec assurance en s’appuyant sur le mauvais passage. La seule parade est de vérifier les sources citées sur des questions dont vous connaissez déjà la réponse.

Ce qui coince en vrai

Quand le TP atteint ses limites

Ce montage est parfait pour comprendre, expérimenter et décider. Il cesse de l’être quand :

• Plusieurs personnes s’en servent en même temps. Un poste de travail sert un utilisateur correctement, pas dix en simultané.
• Il faut que ça réponde à 3 heures du matin. Votre portable dort, et c’est très bien ainsi.
• Les documents indexés deviennent sensibles. Un poste de travail n’a ni sauvegarde sérieuse, ni chiffrement au repos, ni journalisation des accès.
• Vous voulez brancher le modèle à vos outils métier. Là, ce n’est plus le modèle le sujet, c’est la plomberie autour.

Et Datacampus dans tout ça ?

Autant le dire franchement : nous ne vendons pas encore de serveurs d’inférence. Ce TP se fait donc sur votre matériel, et c’est la bonne façon de commencer.

En revanche, dès que le sujet devient collectif, la question se déplace vers ce qu’on branche autour du modèle : une base vectorielle qui tient la charge et qui est sauvegardée, des serveurs MCP pour exposer proprement vos systèmes internes à un agent, un n8n pour orchestrer tout ça. Cette couche-là, nous l’hébergeons et nous l’infogérons en France, et elle se marie très bien avec un modèle qui, lui, tourne chez vous.

TL;DR, ce qu’il faut retenir

• Votre machine actuelle suffit pour commencer. N’achetez rien avant d’avoir mesuré.
• La mémoire est la seule contrainte qui compte : taille du fichier plus 20 %.
• À mémoire égale, préférez un gros modèle quantifié en Q4 à un petit modèle en pleine précision.
• Mesurez en tokens par seconde. En dessous de 5, changez de modèle.
• Ollama pour servir, Open WebUI pour l’interface, nomic-embed-text pour vos documents.
• N’exposez jamais le port 11434 sur Internet, l’API n’a aucune authentification.
• Le poste de travail montre ses limites dès qu’il y a plusieurs utilisateurs ou des données sensibles.

FAQ — Faire tourner un LLM en local

Pour aller plus loin :
• Bibliothèque de modèles Ollama · Documentation Open WebUI
• Sur datacampus.fr : Héberger un LLM en local, le guide complet · Qu’est-ce que MCP ? · Connecter Claude et ChatGPT à un serveur MCP · n8n et l’automatisation souveraine · CLOUD Act et RGPD