Tout le monde utilise ChatGPT. Pour écrire, coder, résumer, débugger. C’est utile, c’est rapide, et c’est là. Mais à un moment, on se pose une question simple : est-ce qu’on est obligé d’envoyer nos données à San Francisco pour avoir une réponse ?
La réponse, c’est non. Et comprendre pourquoi et surtout comment c’est comprendre ce qu’on appelle l’inférence LLM.
Le problème avec “envoyer à OpenAI”
Soyons directs. Quand tu utilises ChatGPT, Claude ou Gemini en version gratuite ou payante, tu envoies tes prompts sur les serveurs d’une entreprise américaine. Ces entreprises ont des CGU. Ces CGU ont des clauses. Ces clauses disent des choses que personne ne lit.
Le problème n’est pas que ces entreprises sont forcément malveillantes. Le problème, c’est que tu n’as aucun contrôle. Tes questions médicales, tes données financières, ton code propriétaire, ta stratégie business, tout ça transite quelque part. Et en dehors de leur politique de confidentialité affichée, tu n’as aucun moyen de vérifier ce qu’il en est fait réellement.
Ajoutons à ça : ces services ne sont pas gratuits à long terme. Le plan free a des limites, le plan pro coûte entre 20 et 50€/mois, et l’API facturable au token monte vite quand on automatise des workflows. Et puis, il y a des garde-fous; normaux, légitimes, mais qui bloquent des usages techniques parfaitement valides.
La solution existe : faire tourner un modèle soi-même. C’est l’inférence. Et c’est le sujet de cet article.
L’entraînement vs l’inférence
Avant d’aller plus loin, une distinction fondamentale que beaucoup de gens confondent.
Un modèle de langage a deux grandes phases de vie :
L’entraînement : c’est la phase où le modèle apprend. On lui donne des milliards de tokens de texte, et il ajuste des milliards de paramètres pour minimiser ses erreurs de prédiction. C’est coûteux, long, et ça nécessite des clusters GPU de datacenter. GPT-4 a coûté des centaines de millions de dollars à entraîner. Ce n’est pas pour toi, ce n’est pas pour moi.
L’inférence : c’est la phase où le modèle utilise ce qu’il a appris pour répondre à une question. Le modèle est figé, ses paramètres ne changent plus. On lui donne un prompt en entrée, il génère une réponse token par token. C’est là que se passe tout ce qu’on vit comme utilisateur final.
Quand tu interroges ChatGPT, OpenAI fait de l’inférence sur ses serveurs avec leur modèle entraîné. L’idée, c’est de faire pareil, mais chez toi, avec un modèle open source.
Comment ça marche concrètement
À l’intérieur d’un LLM, il y a des milliards de nombres (les poids du modèle) organisés en matrices,quelques milliards pour un modèle compact comme un 7B, plusieurs centaines pour les plus grands. Ces matrices représentent, d’une certaine manière, la “connaissance” compressée du modèle.
L’inférence, c’est une série de multiplications matricielles appliquées à la représentation numérique de ton prompt. Concrètement : le prompt est découpé en tokens (morceaux de mots), chaque token est converti en vecteur numérique (embedding), ces vecteurs traversent les couches attention du transformer qui produisent des logits,des scores sur tous les tokens possibles. Un algorithme de sampling choisit le token suivant, et la boucle recommence jusqu’à ce que le modèle produise une réponse complète.
Ce qui rend ça exigeant en ressources, c’est la taille de ces matrices. Un modèle comme Llama 3.1 70B a 70 milliards de paramètres. En float16 (demi-précision), ça représente ~140 Go de VRAM pour le charger tel quel. C’est là qu’intervient la quantization, une technique qui réduit la précision des poids (ex. 4 bits au lieu de 16) pour faire tenir le modèle en mémoire avec un coût limité en qualité. On en parlera dans un article dédié.
Ce qu’il faut retenir : plus le modèle est gros, meilleure est la qualité, mais plus tu as besoin de VRAM. La VRAM, c’est la mémoire de ta carte graphique, et c’est la ressource critique de l’inférence locale.
Faire tourner un modèle soi-même
La bonne nouvelle : en 2026, c’est devenu accessible. Des outils comme Ollama ou llama.cpp permettent de lancer un modèle en local en quelques commandes.
Avec Ollama, c’est littéralement :
# Installer Ollama
curl -fsSL https://ollama.com/install.sh | sh
# Mistral 7B,modèle open source français, bon compromis qualité/taille (4.1 Go en Q4)
ollama run mistral:7b
# Ou Qwen2.5 7B si tu veux plus de fenêtre de contexte (4.7 Go)
ollama run qwen2.5:7b
# API compatible OpenAI directement :
ollama serve
# → disponible sur http://localhost:11434
Un mot sur la provenance des modèles : Mistral vient de France, Llama de Meta, Qwen d’Alibaba. La question des poids “souverains” mérite un article à part,ici, “souveraineté” veut surtout dire que tes données ne quittent pas ta machine.
Tu peux ensuite interroger ton modèle local exactement comme tu interrogerais l’API d’OpenAI, même format de requête, même structure JSON. La différence : les données ne quittent jamais ta machine.
Sur un laptop avec une RTX 3060 12 Go, un modèle 7B en Q4 tourne à 20–30 tokens/seconde. C’est suffisant pour une utilisation personnelle fluide. Sur un GPU dédié, les chiffres montent vite.
Ce qui change tout côté serveur, c’est un outil comme llama.cpp compilé avec support CUDA, qui permet de charger plusieurs couches du modèle directement en VRAM et d’atteindre des débits de production. C’est ce qu’on utilise sur EVA, mais j’y viens.
Mais soyons honnêtes.
Un modèle 7B en local, c’est pas GPT-4o. Un 14B non plus. Même un 70B quantizé en Q4 va rater des raisonnements complexes que Claude ou ChatGPT gèrent sans transpirer. La qualité, ça coûte des paramètres, et des paramètres, ça coûte de la VRAM.
Ce qu’on peut faire tourner sur une machine perso aujourd’hui, c’est bien. C’est même très bien pour beaucoup d’usages : résumer, coder un script, répondre à des questions factuelles. Mais pour du raisonnement complexe, de la planification multi-étapes, ou du code avancé… l’écart reste réel.
La bonne nouvelle : cet écart se mesure. Les benchmarks existent, et on va les éplucher dans les prochains articles,sur du vrai matériel, avec des modèles comparables. Pas pour conclure “le local c’est nul”, mais pour savoir quand ça suffit et quand ça ne suffit pas.
On n’a pas toujours besoin de travailler avec Einstein. Parfois, un simple docteur House fait très bien l’affaire :)
Mon infra,et merci l’UPPA
Je vais être transparent sur le contexte dans lequel j’écris ces articles.
Dans le cadre de mon alternance à l’UPPA (Université de Pau et des Pays de l’Adour), j’ai la chance d’administrer EVA,un cluster de calcul composé de 4 nœuds Proxmox équipés avec une NVIDIA L40S 48 Go de VRAM. Pour contextualiser : la L40S, c’est ce qu’on trouve dans les serveurs d’inférence professionnels. 48 Go de VRAM, ça permet de faire tourner un Qwen2.5 72B quantizé confortablement, avec du débit.
Et bientôt,très bientôt,deux NVIDIA DGX SPARK vont rejoindre l’infrastructure. Pour ceux qui ne connaissent pas : un DGX, c’est la station de travail IA de référence de NVIDIA. C’est-à-dire 2 × 128 Go de mémoire unifiée LPDDR5x, partagée entre CPU et GPU,différent de la VRAM HBM d’une L40S en termes de bande passante, mais qui ouvre des possibilités de chargement intéressantes qu’on explorera. En gros, le genre de machine qui fait vraiment plaisir a n’importe quel ingénieur IA. C’est un peu comme passer d’une voiture de sport à une supercar.
Alors oui, merci l’UPPA. Sincèrement. Avoir accès à ce type de matériel en tant qu’alternant, c’est rare, et ça permet de faire des choses sérieuses, pas juste de la théorie. Les prochains articles sur l’inférence s’appuieront directement sur des benchmarks réels sur cette infrastructure.
L’idée derrière cette série d’articles, c’est de documenter ce qu’on apprend en exploitant EVA : comment on optimise le débit d’inférence, comment on gère la VRAM sur plusieurs nœuds, comment on expose des modèles à des équipes de recherche sans que ça devienne un chaos opérationnel. Du concret, du terrain, avec du vrai matériel.
Conclusion
Cet article, c’est le point d’entrée. Si tu sors d’ici en ayant compris la différence entre entraînement et inférence, pourquoi la VRAM est la ressource clé, et ce que ça change de faire tourner un modèle soi-même,c’est gagné.
La suite : on va rentrer dans le détail de la quantization, parler de llama.cpp vs vLLM, mesurer des débits réels sur L40S, et explorer comment on structure un service d’inférence multi-utilisateurs qui ne s’effondre pas sous la charge. Pas des benchmarks synthétiques, de la prod.
À bientôt.