LM Studio vs Ollama vs llama.cpp : quel runner pour les plebs ?

Il n’y a pas de mauvaise réponse parmi ces trois-là. Chaque fois qu’un pleb demande lequel choisir, une petite guerre civile éclate dans les réponses, et c’est surtout du bruit. llama.cpp, Ollama et LM Studio sont tous excellents. Ils servent des plebs différents, aux tempéraments différents et au matériel différent.

Crédit rapide avant d’aller plus loin, parce que se tenir sur les épaules de géants, c’est toute la game. llama.cpp est le moteur d’inférence C++ que Georgi Gerganov a écrit, et c’est la fondation sur laquelle presque tous les runners LLM locaux que vous connaissez sont bâtis. Ollama, porté par Michael Chiang et Jeffrey Morgan, enveloppe llama.cpp dans un démon, une CLI et une API HTTP pour que ça fonctionne tout simplement. LM Studio, bâti par l’équipe d’Element Labs, enveloppe les mêmes idées dans une interface graphique de bureau soignée, particulièrement affûtée sur Apple Silicon. Des outils adjacents comme vLLM et MLX comptent aussi et nous les aborderons en fin de billet, mais ils répondent à d’autres problèmes.

Ce billet vous aide à choisir le bon dans les 15 prochaines minutes, non pas en déclarant un gagnant, mais en vous jumelant à l’outil qui convient à votre vie. Si vous bâtissez une pile d’IA souveraine pour votre propre matériel, c’est ici que tout commence : le runner.

Les trois en un coup d’œil

Un seul tableau ne tranche pas pour vous — mais il resserre la conversation. Passons à l’analyse honnête de chacun.

llama.cpp — la fondation

Ce que c’est. llama.cpp est le moteur d’inférence. Quand Ollama fait tourner un modèle, c’est llama.cpp en dessous. Quand LM Studio charge un GGUF, le code qu’il exécute descend de llama.cpp. Quand un nouveau format de quantification ou une optimisation CPU apparaît dans le monde du LLM local, c’est ici qu’il débarque en premier, habituellement. Georgi Gerganov a démarré ce projet comme une expérience « est-ce que je peux faire tourner LLaMA sur mon MacBook » et c’est devenu la pièce d’infrastructure la plus importante de l’IA grand public.

À qui il convient. Aux plebs puissance. Le genre de pleb qui compile déjà son nœud Bitcoin depuis les sources, qui lit les messages de commit pour le plaisir, et qui veut avoir trois jours d’avance quand un nouveau modèle sort. Aussi : quiconque opère un serveur d’inférence dédié dans son Hashcenter domestique et veut grapiller chaque token par seconde. Et quiconque pourrait éventuellement contribuer une quantification, une intrinsèque CPU ou une correction de bogue en amont.

Compromis honnêtes. C’est l’expérience la plus brute des trois. Pas d’interface graphique. Vous apprendrez -ngl (couches GPU), -c (taille de contexte), --mmap, -b (batch), --rope-freq-base et une douzaine d’autres drapeaux. C’est gratifiant ou agaçant, selon votre tempérament. Pas de catalogue de modèles organisé — vous chassez les fichiers GGUF sur Hugging Face vous-même et vous décidez du niveau de quantification. La documentation est bonne mais suppose que vous êtes à l’aise avec un README et que vous rapporterez vos propres problèmes.

Cas d’usage phare. Une boîte d’inférence dédiée. Compilation sur mesure avec les bonnes intrinsèques CPU pour votre silicium (AVX-512 sur les Intel grand public récents, AMX sur Xeon Sapphire Rapids, NEON sur ARM). Expériences de quantification exotiques — essayer IQ3_XXS sur un modèle 70B pour le caser dans 24 Go de VRAM. Bancs d’essai de nouveaux modèles avant que les wrappers n’aient rattrapé. Vous pouvez aussi lever llama-server et il servira une API compatible OpenAI que n’importe quel client pourra interroger.

Le travail de Gerganov est la raison même pour laquelle le reste de ce billet existe. Si vous choisissez llama.cpp directement, vous êtes au plus près de la source. Respectez la filiation et rappelez-vous : le fichier quant que vous téléchargez, la correction de tokenizer dont vous bénéficiez, le noyau GPU qui a gagné 12 % le mois dernier — la plupart sont d’abord passés par llama.cpp.

Ollama — le « sweet spot » pour la plupart des plebs

Ce que c’est. Ollama prend llama.cpp et l’enveloppe dans trois choses qui comptent : un démon en arrière-plan (service qui démarre au boot), une CLI conviviale et une API HTTP au format OpenAI. Plus un registre de modèles pour que ollama pull llama3.1 fonctionne sans chichi. L’équipe d’Ollama Inc. — Michael Chiang, Jeffrey Morgan et les contributeurs autour d’eux — a concentré son effort sur les pièces qui rendent une infrastructure LLM locale aussi naturelle que n’importe quel autre service sur votre réseau.

À qui il convient. Environ 80 % des plebs. Quiconque veut faire tourner Open WebUI par-dessus et offrir une interface style ChatGPT à toute la maisonnée. Quiconque aime que ses services vivent dans systemd et se comportent. Quiconque veut brancher le même endpoint local dans VS Code Continue, Home Assistant, un script shell, un flux n8n et un chatbot en CLI, tout en même temps. Si vous n’avez pas de raison solide de choisir autrement, choisissez Ollama.

Compromis honnêtes. Moins de boutons à régler que llama.cpp brut. Vous pouvez fixer la taille de contexte, la température, le nombre de couches GPU et une poignée d’autres paramètres via les Modelfiles, mais vous n’avez pas chaque drapeau. La prise en charge des modèles tout neufs accuse d’ordinaire deux à dix jours de retard sur llama.cpp — les mainteneurs d’Ollama doivent mettre à jour leur runner, tester, puis publier. Le registre est organisé par Ollama, même si vous pouvez toujours ollama create à partir de n’importe quel GGUF sur disque, alors ce plafond reste souple.

Cas d’usage phare. Serveur LLM domestique du quotidien. Vous l’installez une fois sur un rig de minage reconverti en Hashcenter ou un poste de travail de rechange, vous pointez Open WebUI dessus, et chaque appareil de votre LAN a maintenant accès à un modèle privé. Il s’entend bien avec les configurations multi-GPU — les versions récentes répartissent automatiquement sur vos cartes, sans grand effort. Il s’entend bien avec les proxys inverses et Tailscale, ce qui vous permet de rejoindre votre modèle depuis votre téléphone hors de la maison, sans rien exposer à l’Internet en clair.

Si vous lisez ce billet, Ollama est probablement la réponse. Commencez par le guide d’installation en 10 minutes et voyez si ça colle. Si oui, c’est réglé. Si non, vous saurez précisément pourquoi, ce qui rendra le choix suivant trivial.

LM Studio — GUI d’abord, excellence sur Mac

Ce que c’est. LM Studio est une application de bureau, bâtie sur Electron, pour parcourir des modèles locaux, discuter avec eux et, éventuellement, exécuter un serveur compatible OpenAI. C’est ce qui se rapproche le plus d’un « ChatGPT installé sur votre portable » dans le monde du LLM local. L’équipe de LM Studio livre discrètement de la finition pendant que le reste de l’écosystème débat des fichiers de configuration.

À qui il convient. Aux plebs qui pensent en GUI. Aux plebs qui veulent évaluer beaucoup de modèles rapidement — « est-ce que ce 13B code bien ? et ce 14B ? et ce merge ? » — sans enchaîner une douzaine de commandes CLI. Et surtout, aux utilisateurs de Mac Silicon. LM Studio est bien réglé pour le matériel Apple, avec un support MLX de première classe dans les versions récentes en parallèle du chemin GGUF. Si vous possédez un MacBook avec 64 Go ou plus de mémoire unifiée, LM Studio est l’une des façons les plus agréables de l’exploiter.

Compromis honnêtes. L’application elle-même est propriétaire (quoique gratuite pour l’usage personnel, avec un palier affaires), ce que certains plebs excluront par principe et c’est légitime. La découverte de modèles se fait dans son navigateur Hugging Face intégré, ce qui est pratique mais vous canalise vers ce qui est facile à trouver plutôt que vers ce qui est meilleur. Vous pouvez toujours charger n’importe quel GGUF local, mais la plupart ne le feront pas. C’est aussi moins scriptable qu’Ollama — LM Studio expose bien un serveur, mais le serveur n’est pas le produit, l’application l’est.

Cas d’usage phare. Vous avez un MacBook Pro M4 Max avec 64 Go de RAM. Vous avez entendu parler de Llama 3.1 70B en Q4 et vous voulez voir s’il tourne vraiment sur votre machine et s’il est bon. Avec LM Studio : ouvrez l’application, cliquez sur la loupe, tapez le nom du modèle, choisissez une quantification, cliquez sur télécharger, cliquez sur charger, commencez à taper. Temps total écoulé : 10 minutes, dont l’essentiel en téléchargement. Pas de terminal. Pas de fichiers de configuration. C’est un vrai superpouvoir d’exploration.

Respect à l’équipe de LM Studio pour livrer cette finition. Bâtir une application de bureau multiplateforme qui reste à jour d’un écosystème qui bouge vite, c’est du vrai travail, et ils le font discrètement, et bien.

Quand en utiliser plus d’un

Rien ne vous empêche d’utiliser les trois. Une configuration courante dans un Hashcenter de pleb :

• Ollama tourne comme service systemd sur votre boîte d’inférence principale. C’est le endpoint toujours allumé. Tout ce qui, dans la maison, a besoin d’un LLM local lui parle.
• llama.cpp compilé depuis les sources sur la même machine, ou sur une seconde, pour des expériences précises — une nouvelle quantification, un modèle qu’Ollama n’a pas encore empaqueté, un banc d’essai.
• LM Studio sur votre MacBook ou votre bureau pour du clavardage décontracté, du parcours de modèles et pour montrer à de la famille non technique de quoi il s’agit sans leur expliquer curl.

Les fichiers GGUF peuvent être partagés entre outils, à condition de faire attention. Les trois peuvent lire du GGUF depuis un répertoire partagé; Ollama stocke ses blobs par empreinte de contenu dans son propre dossier (~/.ollama/models), tandis que LM Studio et llama.cpp lisent de simples fichiers .gguf depuis le chemin que vous leur indiquez. Vous pouvez créer des liens symboliques entre eux ou simplement garder deux copies — le disque est bon marché, votre temps ne l’est pas.

Outils adjacents (brièvement)

vLLM. Orienté serveur, inférence en lots, gourmand en GPU, de niveau production. Si vous servez plusieurs utilisateurs concurrents depuis un seul Hashcenter — une petite équipe, un outil interne d’entreprise, une communauté de Bitcoiners souverains partageant un rig — vLLM l’emporte sur le débit. Ce n’est pas un outil de tous les jours pour pleb. C’est ce vers quoi on monte quand la boucle mono-requête d’Ollama devient votre goulot d’étranglement.

MLX. Le cadriciel d’apprentissage machine natif d’Apple. Si vous êtes tout-Apple-tout-le-temps et que votre machine est du Silicon récent, MLX peut battre les runners basés sur GGUF sur certaines charges. LM Studio vous expose déjà ce chemin. Sous Linux ou Windows, MLX n’est pas pertinent.

KoboldCpp. Un fork de niche de llama.cpp avec son propre serveur et son UI, historiquement centré sur l’écriture créative à long contexte et le jeu de rôle. Il a une communauté dédiée et certaines fonctionnalités que l’amont n’a pas. Si vous êtes dans cette communauté, vous savez déjà pourquoi.

text-generation-webui (oobabooga). Le couteau suisse. Plusieurs backends, une interface web Gradio, de nombreuses extensions, populaire dans la scène créative / jeu de rôle. Installation plus lourde qu’Ollama, plus personnalisable. Si vous voulez chaque bouton dans un navigateur, c’est votre affaire. Pour la plupart des plebs, c’est plus que nécessaire.

Matrice de décision : lequel choisir ?

Quatre profils. Choisissez celui qui vous ressemble le plus.

« Je veux juste un ChatGPT sur mon propre matériel — service fiable au quotidien, utilisé aussi par les enfants et le conjoint »

Choix : Ollama + Open WebUI.

C’est la réponse par défaut. Installé une fois, tourne comme service, survit aux redémarrages, parle le format API d’OpenAI, donc chaque client du monde fonctionne avec lui. Placez Open WebUI devant et votre maisonnée a un clone privé de ChatGPT, zéro télémétrie, zéro frais mensuel. Commencez par l’installation d’Ollama en 10 minutes et bâtissez à partir de là.

« Je suis sur Mac et je veux expérimenter beaucoup de modèles rapidement »

Choix : LM Studio.

Surtout sur Apple Silicon. La boucle télécharge-parcours-chat est imbattable pour l’exploration. Si vous voulez éventuellement brancher votre Mac dans une pile domestique plus large, le mode serveur de LM Studio vous y mènera, mais la raison première de le choisir est : vous voulez essayer beaucoup de modèles avec un minimum de friction, et vous aimez les interfaces graphiques.

« Je veux l’avant-garde, le maximum de réglages, peut-être contribuer un format de quantification en amont »

Choix : llama.cpp depuis les sources. Gardez Ollama comme solution stable de repli.

Clonez le dépôt. Lisez le Makefile. Compilez avec les bons drapeaux pour votre CPU et votre GPU. Lancez llama-server quand vous voulez une API, llama-cli quand vous voulez un REPL, ou utilisez les bindings Python si vous bâtissez quelque chose de sur mesure. Gardez Ollama installé sur la même boîte comme chemin ennuyeux-qui-fonctionne quand vous voulez simplement clavarder sans penser aux drapeaux de compilation. Les deux coexistent sans souci — ports différents, processus différents. Bonus : comprendre llama.cpp directement vous rend bien meilleur pour déboguer les wrappers quand quelque chose cloche.

« Je sers une maisonnée ou une petite équipe avec un rig à 4 GPU »

Choix : Ollama aujourd’hui. Prévoyez une montée vers vLLM quand vous le dépasserez.

Le support multi-GPU d’Ollama a mûri et il répartira volontiers les modèles sur quatre cartes automatiquement. Pour une maisonnée ou une petite équipe (disons dix requêtes concurrentes ou moins), c’est amplement suffisant. Le jour où vous remarquez des délais de file d’attente aux heures de pointe — plusieurs personnes qui le sollicitent simultanément, de longs prompts qui s’empilent — c’est votre signal pour évaluer vLLM comme couche de service, tout en gardant Ollama comme gestionnaire de modèles. Vous voudrez aussi probablement réfléchir aux choix de quantification à cette échelle, car la mémoire compte davantage quand vous servez beaucoup.

Trois outils, trois bonnes réponses

Il n’y a pas de gagnant. llama.cpp est la fondation bâtie par Georgi Gerganov sur laquelle repose tout l’écosystème du LLM local. Ollama, de Michael Chiang, Jeffrey Morgan et leur équipe, est le wrapper qui rend cette fondation aussi naturelle que n’importe quel autre service sur votre réseau. LM Studio, de l’équipe d’Element Labs, est l’application de bureau soignée qui abaisse la barrière d’exploration, surtout sur Apple Silicon. Trois projets. Trois philosophies. Trois bonnes réponses pour trois plebs différents.

Choisissez selon votre tempérament et votre infrastructure, pas selon l’allégeance tribale. Un pleb du terminal qui opère un Hashcenter Linux atterrira sur Ollama ou llama.cpp brut. Un pleb qui promène son MacBook et explore la scène atterrira sur LM Studio. Un pleb à esprit contributeur atterrira sur llama.cpp lui-même. Tous les trois sont auto-souverains. Tous les trois gardent vos données sur votre matériel. C’est ce qui compte.

Pour le contexte complet — runner, UI, modèles, chauffer avec l’inférence et le plus large manifeste pour une IA souveraine — retournez au Guide du pleb pour l’IA auto-hébergée. Choisissez votre runner. Branchez-le à votre Hashcenter. Empilez des sats. Empilez des tokens. Restez souverain.

Références externes :
– llama.cpp : github.com/ggerganov/llama.cpp
– Ollama : ollama.com
– LM Studio : lmstudio.ai
– vLLM : github.com/vllm-project/vllm
– MLX : developer.apple.com/machine-learning/mlx
– text-generation-webui : github.com/oobabooga/text-generation-webui