> llama.cpp vs Ollama — lequel devriez-vous lancer ?▋

Les boîtes de recherche servent la requête llama.cpp vs Ollama comme un combat entre deux produits. Les dépôts racontent autre chose : l'un garde à sa racine un fichier qui donne le numéro de build exact de l'autre. Le moteur d'Ollama, c'est llama.cpp, figé — la querelle qu'internet réclame n'est pas la décision qui se pose vraiment.

La vraie décision, c'est la dose de moteur que vous voulez toucher. Tout ce qui suit vient des deux dépôts, de leurs flux de releases et de fils publics, vérifiés le matin de la publication.

C'est quoi llama.cpp, au juste ?

130 473 étoiles, licence MIT, quatre releases le jour de cette review. llama.cpp est le moteur d'inférence en C/C++ qui a lancé la vague des modèles locaux en mars 2023. Son projet a introduit GGUF, le format single-file que tout l'écosystème local échange — l'échelle de quantization dont tout le monde dispute s'exprime dans un format conçu par ses propres auteurs. Il affiche 24 125 forks, 2 515 issues ouvertes, et son contributeur le plus prolifique compte 2 011 commits.

Le flux de releases se lit comme un journal : quatre builds avaient atterri en début d'après-midi le jour de cette review (b11438 à b11443), chacun un incrément numéroté que vous pouvez figer. À côté du CLI, il livre llama-server, un serveur HTTP compatible OpenAI — pointez n'importe quel client dessus et il se comporte comme une API hébergée qui vivrait sur votre machine.

verify: curl -s http://127.0.0.1:11434/api/version → {"version":"..."} sur un Ollama lancé · llama-server --version → le tag de build, p. ex. b11443

Ollama est-il autre chose qu'un habillage ?

Oui — et la frontière est imprimée dans le dépôt. La racine d'Ollama porte trois fichiers de figeage de version : LLAMA_CPP_VERSION (b11351 au moment de la review), MLX_VERSION et MLX_C_VERSION. Le code Go dans llm/llama_server.go démarre un binaire serveur dérivé de llama.cpp comme sous-processus et lui parle. La dépendance n'est pas un secret de polichinelle ; c'est une entrée de build.

Ce qu'Ollama ajoute, c'est un service : tirage de modèles en une commande depuis un registre, détection matérielle automatique, une API résidente sur le port 11434, et un second moteur — MLX — pour les machines Apple Silicon qui préféreraient du safetensors au GGUF. Voilà la définition honnête : Ollama, c'est de la gestion de modèles et de l'hygiène de processus autour d'un moteur qu'il n'a pas écrit.

Ce que veut dire le retard de version en pratique

Quatre-vingt-douze builds séparent le figeage d'Ollama (b11351) de la release du matin côté amont (b11443) au moment de la review. Les correctifs moteur — l'accélération prompt-lookup-drafting de septembre qui a fait 89 points sur Hacker News, par exemple — arrivent côté amont d'abord, puis montent dans le train de releases d'Ollama des semaines plus tard. Si une ligne de changelog règle votre problème, l'habillage est généralement le dernier informé.

Alors, lequel est le plus rapide ?

Pour le même fichier modèle, ni l'un ni l'autre — le moteur est partagé. Les comparaisons de tokens par seconde qui annoncent un écart comparent généralement des quantizations différentes, des tailles de contexte différentes, ou des builds différents du moteur lui-même. Notre comparaison LM Studio a buté sur le même mur : l'interface change, les maths sont identiques.

Là où de vrais écarts apparaissent, ils viennent des défauts et du retard, pas des moteurs : Ollama choisit une longueur de contexte et décharge des couches pour vous (les molettes derrière les surprises de VRAM), quand llama.cpp vous laisse les régler — et vous punit de les oublier. La question benchmark cache une question de contrôle.

Vous ne choisissez pas entre deux moteurs. Vous choisissez la dose de moteur que vous voulez toucher.

Que dit le dossier contre llama.cpp ?

Le registre honnête, parce que le dossier en a un :

• 2 515 issues ouvertes et une cadence de siège. Quatre releases un même matin, c'est du débit — c'est aussi du churn. Les flags bougent, les backends se réorganisent, et votre script de build figé demande la même maintenance.
• La communauté le dit tout haut. Tiré du fil Hacker News sur l'accélération de septembre (89 points) : "Frankly, llama.cpp is so badly written that these kind of speedups are trivial, and a hard fork (or a total rewrite) has been needed for the longest time." — rfgplk. Le même fil porte l'inquiétude de gouvernance après l'accord Nvidia–Hugging Face qui a mis l'employeur de l'équipe cœur en jeu.
• Vous faites les corvées. Pas de registre, pas d'auto-détection : vous allez chercher les GGUF sur Hugging Face (le guide d'installation y veille), vous passez vous-même les flags de déchargement de couches, et vous surveillez le process.

Lequel devriez-vous lancer ?

Le verdict tiré du dossier, et la ligne d'honnêteté obligatoire : j'ai lu le dossier, je ne l'ai pas exécuté. Chaque chiffre ici vient des deux dépôts, de leurs flux de releases et des fils publics liés — pas de mon terminal.

Vous voulez	Lancez	Pourquoi, dossier en main
Une commande et une fenêtre de chat	Ollama	Tirage de modèles, auto-détection, API résidente — l'appareil
Tous les flags et le build le plus récent	llama.cpp	Builds figés, llama-server, des backends choisis
Une GUI de bureau	LM Studio	Même lignée de moteur avec des boutons — comparé ici
Un GPU, plusieurs utilisateurs	vLLM	Serving en débit — les réserves GGUF s'appliquent

Une couture pratique : commencez sur Ollama, et quand il vous résiste — un flag qu'il n'expose pas, une détection GPU partie en vrille (la plus courante), un correctif assis dans un build plus récent — descendez sur llama.cpp pour ce travail. Le fichier modèle vous suit ; GGUF est la lingua franca. Tout le cluster, les deux outils compris, est indexé sur le hub local-LLM.

L'appareil vous épargne le moteur jusqu'au jour où le moteur est le problème. Ce jour-là est la raison d'être du second outil.

De quel côté du capot moteur êtes-vous — et un défaut d'Ollama vous a-t-il déjà coûté un après-midi que un seul flag aurait épargné ?