Ollama vs llama.cpp : sous le capot

Vous vous êtes déjà demandé comment un modèle de langage tourne réellement sur votre machine ? La réponse passe presque toujours par un seul moteur : llama.cpp. Et la majorité de ceux qui utilisent Ollama ne le sait pas, parce qu'Ollama utilise justement llama.cpp sous le capot. Mais les deux outils ne sont pas la même chose. L'un est le moteur, l'autre est la voiture : un moteur puissant à installer, mais la voiture met aussi les roues, le tableau de bord et la boîte automatique.

Dans cet article, nous ouvrons le capot. On voit ce qu'il y a dessous, quand la différence compte vraiment et comment choisir avec la tête, sans slogans.

Qu'est-ce que llama.cpp

llama.cpp est un moteur d'inférence écrit en C/C++ : il exécute les modèles de langage sur votre matériel — CPU, GPU grand public, Apple Silicon — avec un minimum de configuration et des performances au niveau de l'état de l'art. Il s'appuie sur la bibliothèque ggml et son objectif déclaré est l'inférence de LLM (et VLM) avec un setup minimal et des performances de pointe, en local comme dans le cloud. Le repository et le README de llama.cpp en décrivent la vision et les capacités.

La force de llama.cpp, c'est le contrôle. Il vous offre :

• La quantification entière 1,5/2/3/4/5/6/8 bits, pour réduire la mémoire et accélérer l'inférence.
• L'inférence hybride CPU+GPU : vous mettez sur la GPU seulement les couches qui tiennent en VRAM et le reste reste en RAM, ainsi les modèles plus grands que la VRAM tournent quand même.
• Un ensemble complet d'outils : llama-cli pour discuter, llama-server (aujourd'hui aussi llama serve) pour un serveur avec API compatible OpenAI et une interface web intégrée, llama-quantize pour convertir les poids, llama-bench pour mesurer les tokens par seconde, llama-imatrix pour les quantifications intelligentes.
• Des milliers de flags : threads, couches à offload, contexte, flash attention, décodage spéculatif, grammaires JSON, et bien plus.

En pratique, avec llama.cpp vous touchez aux vis : chaque comportement est un flag que vous décidez. C'est l'outil juste pour ceux qui veulent presser la dernière goutte de vitesse ou monter des pipelines d'inférence sur mesure.

Qu'est-ce qu'Ollama

Ollama est un runtime à un niveau plus haut, écrit en Go. C'est un daemon qui tourne en arrière-plan et qui met par-dessus trois choses : un modèle de packaging, une bibliothèque de modèles et une API. Le repository d'Ollama et la documentation officielle détaillent l'installation et les commandes.

• ollama pull qwen3 télécharge le modèle de la bibliothèque Ollama : un nom et c'est parti, sans chercher de fichiers GGUF, choisir la quantification, gérer les templates de conversation.
• ollama run qwen3 lance la discussion en un instant, avec une interface ligne de commande simple.
• Le serveur exposé en local parle API native et aussi API compatible OpenAI, ainsi vos outils et vos applications peuvent se connecter sans savoir qu'il y a un modèle local derrière.

Le point technique clé : pour une grande partie de l'inférence locale, Ollama utilise une version de llama.cpp qu'il fixe et patche. Donc les deux projets ne sont pas des builds interchangeables du même outil : Ollama ajoute packaging, téléchargement, templates, gestion des processus et API autour du moteur. Quand un nouveau modèle sort, Ollama le supporte au moment où les développeurs mettent à jour la version de llama.cpp qu'ils utilisent en interne.

La différence, en une phrase

llama.cpp est le moteur ; Ollama est la voiture qui le monte et vous fait partir. Même cœur, deux philosophies différentes.

	llama.cpp	Ollama
Ce que c'est	Moteur d'inférence C/C++	Runtime géré (Go)
Setup	Binaire ou build depuis le source, puis flags à la main	Une installation, puis ollama run
Modèles	Fichiers GGUF que vous téléchargez vous-même (Hugging Face)	Bibliothèque avec ollama pull
API	llama-server, compatible OpenAI	API native + compatible OpenAI
Interface	CLI + interface web du serveur	CLI simple, pas de GUI officiel
Contrôle	Total : chaque flag, builds custom	Valeurs par défaut sensées, moins de réglage
Pour qui	Tinkerers, performance maximale, setup custom	Démarrage rapide, développeurs, usage quotidien

La vitesse compte-t-elle ?

C'est ici que se cache le mythe à démentir. Puisqu'Ollama tourne sur llama.cpp, le moteur est le même : à modèle, quantification et flags égaux, la différence de vitesse pure est petite. Les différences réelles viennent de deux choses :

1. Les valeurs par défaut. Ollama choisit pour vous contexte, couches GPU et autres paramètres. Si ses défauts ne sont pas vos idéaux, vous laissez de la vitesse sur la table. Avec llama.cpp, c'est vous qui décidez.
2. Le modèle exact. Ollama sert ses versions des modèles ; vous pouvez avoir une quantification ou une architecture légèrement différente du GGUF que vous chargeriez à la main sur llama-server.

La règle pratique : pour l'usage quotidien (discussion, outils, prototypes), la vitesse d'Ollama est tout à fait adéquate. Si vous faites des benchmarks, ou si vous avez un grand modèle que vous voulez pousser à la limite, ou si vous optimisez pour un matériel précis, alors le contrôle de llama.cpp devient un avantage mesurable — et ici llama-bench vous donne les chiffres pour comprendre ce que vous sacrifiez.

Comment choisir (sans slogans)

Partez d'Ollama si vous voulez être opérationnel en minutes, vous connectez une application ou un outil existant via API, et vous ne voulez pas penser à des fichiers GGUF, des templates et des flags. C'est le bon chemin pour la majorité des cas, et c'est la norme de fait pour faire tourner de l'IA locale en production légère.

Descendez à llama.cpp si vous voulez la performance maximale sur un matériel précis, vous utilisez le décodage spéculatif ou des quantifications avancées, vous montez un service avec API OpenAI sans la couche supplémentaire du daemon, ou simplement vous amusez à ouvrir le capot. Le passage d'Ollama à llama.cpp est à bas risque : les deux exposent un endpoint compatible OpenAI, donc l'API de vos applications ne change pas.

Peuvent-ils coexister ? Oui. Beaucoup utilisent Ollama pour le travail quotidien et llama-server quand il faut du contrôle. Rien n'empêche d'avoir les deux sur la même machine.

En pratique : les commandes

Avec Ollama :

ollama pull qwen3
ollama run qwen3

Avec llama.cpp :

llama-server -m qwen3-q4_k_m.gguf -c 32768 -ngl 99
# ou, avec téléchargement direct depuis Hugging Face
llama serve -hf ggml-org/qwen3:Q4_0

Dans le deuxième cas, c'est vous qui choisissez le contexte (-c), les couches sur la GPU (-ngl) et la quantification (le fichier .gguf), tandis que dans le premier Ollama gère tout à votre place.

Le tableau d'ensemble

Ollama et llama.cpp ne sont pas des rivaux : ce sont deux niveaux de la même pile. Si le monde de l'IA locale vous intéresse, Ollama est le point d'entrée le plus simple ; llama.cpp est la porte de sortie quand vous voulez vraiment le contrôle. Comprendre que l'un contient l'autre vous enlève le doute « lequel est meilleur » et vous met une question plus utile : combien de contrôle me faut-il aujourd'hui, et combien ça me coûte de l'avoir.

Les deux ne s'excluent pas. Commencez avec le runtime simple, et quand une limite vous demande plus de puissance, ouvrez le capot : vous y trouvez déjà tout ce qu'il vous faut.

Sources

• llama.cpp — repository et README
• Ollama — repository
• Ollama — documentation officielle

Article généré par IA