mrsaynothing.dev
llama.cpp vs Ollama : un moteur, deux doses de moteur
La racine du dépôt d'Ollama porte le nom de build de son moteur — il fait tourner llama.cpp, épinglé à b11351 alors qu'en amont b11443 sortait le même matin. Le dossier, lu et non exécuté.
Les moteurs de recherche servent « llama.cpp vs Ollama » comme s'il s'agissait d'un duel entre deux produits. Les dépôts racontent autre chose : l'un garde à la racine un fichier qui nomme le numéro de build exact de l'autre. Le moteur d'Ollama est llama.cpp — épinglé, versionné, une entrée de build. La bagarre que veut internet n'est pas la décision à laquelle vous faites face. La vraie décision, c'est la dose de moteur que vous voulez toucher.
La racine du dépôt d'Ollama porte un fichier nommé LLAMA_CPP_VERSION qui épingle son moteur — il fait tourner llama.cpp, donc la vitesse brute est quasi un match nul pour un même fichier de modèle.
En amont, b11443 est sorti le matin de la revue ; Ollama épingle b11351 — l'emballage suit toujours le moteur. Les nouveaux flags arrivent d'abord dans llama.cpp.
Verdict du dossier : Ollama pour le quotidien, llama.cpp quand un flag masqué par l'emballage vous manque — plus vLLM comme porte de sortie pour le serving GPU.
LE GARAGE
Même bloc sous les deux portes. Réglez la dose de moteur que vous voulez toucher — les étagères répondent.
L'ÉLECTROMÉNAGER · ollama
LA SALLE DES MOTEURS · llama.cpp
Électroménager complet. Pulls, détection et API résidente restent ; le moteur ronronne dessous au pin d'Ollama. Le fichier GGUF vous suit le jour où vous dépassez l'étape.
CE QUE LLAMA.CPP EST VRAIMENT
130 473 étoiles, licence MIT, quatre releases le matin de cette revue. llama.cpp a lancé la vague du local en mars 2023. Il a introduit GGUF, le format que l'écosystème échange.
24 125 forks, 2 515 issues ouverts, un contributeur vedette à 2 011 commits. Le flux des releases se lit comme un journal : quatre builds en début d'après-midi (b11438 à b11443), chacun épinglable.
vérif : curl -s http://127.0.0.1:11434/api/version → un Ollama actif répond · llama-server --version → le tag du build, p. ex. b11443
OLLAMA EST-IL PLUS QU'UN EMBALLAGE ?
Oui — et la frontière est imprimée dans le dépôt. Trois fichiers d'épinglage de version : LLAMA_CPP_VERSION (b11351 au moment de la revue), MLX_VERSION, MLX_C_VERSION. llm/llama_server.go lance le serveur dérivé de llama.cpp comme un sous-processus.
La dépendance est une entrée de build, pas un secret de polichinelle. Ce qu'Ollama ajoute, c'est le service : pulls du registre, auto-détection, une API résidente sur le port 11434, MLX pour Apple Silicon.
Ollama est la gestion de modèles et l'hygiène de processus enroulées autour d'un moteur qu'il n'a pas écrit.
92 builds séparent le pin d'Ollama de la release matinale d'en amont. Les correctifs du moteur atterrissent d'abord en amont, puis prennent le train d'Ollama des semaines plus tard.
L'accélération prompt-lookup-drafting de septembre a fait 89 points sur Hacker News — des semaines avant qu'Ollama ne la livre. Si une ligne de changelog corrige votre problème, l'emballage est le dernier informé.
ALORS, LEQUEL EST PLUS RAPIDE ?
Pour le même fichier de modèle, aucun des deux — le moteur est partagé. Les écarts annoncés comparent généralement des quantizations, des tailles de contexte ou des builds de moteur différents.
Les vrais écarts viennent des défauts et du retard : Ollama choisit le contexte et décharge les couches pour vous — les boutons derrière les surprises de VRAM ; llama.cpp vous laisse les régler, et punit l'oubli.
La question du benchmark cache une question de contrôle.
Vous ne choisissez pas entre deux moteurs. Vous choisissez la dose de moteur que vous voulez toucher.
CE QUE LE DOSSIER DIT CONTRE LLAMA.CPP
- 2 515 issues ouverts et un rythme de siège. Quatre releases un même matin, c'est du débit — c'est aussi du remous. Les flags bougent, les backends se réorganisent, et votre script de build épinglé exige le même entretien.
- La communauté le dit tout haut. Dans le fil Hacker News sur l'accélération de septembre (89 points), l'utilisateur rfgplk : « Franchement, llama.cpp est si mal écrit que ce genre d'accélérations est trivial, et un hard fork (ou une réécriture totale) est nécessaire depuis longtemps. » Le même fil porte une inquiétude de gouvernance depuis que l'accord Nvidia-Hugging Face a mis l'employeur de l'équipe cœur sur la table.
- Vous faites les corvées. Pas de registre, pas d'auto-détection : vous allez chercher les fichiers GGUF vous-même, vous passez les flags d'offload des couches vous-même, et vous gardez le processus à l'œil.
TROUVEZ VOTRE LIGNE
| Vous voulez | Exécuter | Pourquoi, d'après le dossier |
|---|---|---|
| Une commande et une fenêtre de chat | Ollama | Pulls de modèles, auto-détection, API résidente — l'électroménager |
| Tous les flags et le build le plus récent | llama.cpp | Builds épinglés, llama-server, backends au choix |
| Une GUI de bureau | LM Studio | La même lignée de moteur, avec des boutons |
| Un GPU, plusieurs utilisateurs | vLLM | Serving en débit — les réserves GGUF s'appliquent |
La couture pratique : commencez sur Ollama ; quand il vous résiste — flag manquant, détection GPU qui déraille, un correctif dans un build plus récent — descendez à llama.cpp pour ce travail.
Le fichier de modèle vous suit ; GGUF est la lingua franca. L'électroménager vous épargne le moteur jusqu'au jour où le moteur devient le problème.
Ce jour-là est la raison d'être du second outil.
fin du garage moteur · rien de tiré · tout est local