llama.cpp vs Ollama : le même moteur, 4 requêtes à la fois ou 1, et lequel choisir

Choisissez Ollama pour une commande par modèle, une application de bureau sur Mac ou Windows et des modèles qui se chargent et se déchargent seuls. Choisissez llama.cpp pour tous les réglages en main, 4 requêtes à la fois d’origine, sans rien envoyer nulle part. Sous le capot, le même moteur : Ollama lance en interne le serveur de llama.cpp.

C’est cette dernière phrase qui rend la comparaison intéressante, et nous ne l’avons pas prise pour argent comptant. llama.cpp v0.7.0 est la version stable du 15 octobre 2026 ; Ollama 0.40.10 est sorti en version stable le 23 octobre 2026. Nous avons lu le code des deux versions partout où il décide de la mémoire, des requêtes simultanées, du réseau et de votre vie privée. Nous ne les avons pas chronométrés l’un contre l’autre, donc pas de vainqueur en vitesse ici : avec le même fichier de modèle sur le même moteur, la vitesse dépend de la compilation et des réglages, et c’est justement sur ces réglages que les deux divergent.

llama.cppFiche logiciel→ OllamaFiche logiciel→

	llama.cpp	Ollama
Ce que c’est	Le moteur lui-même, avec un serveur, un chat en terminal et une page de chat	Un gestionnaire par-dessus : bibliothèque de modèles, service en arrière-plan, application de bureau
Version au 24 octobre 2026	v0.7.0 (compilation b11669), plus environ 16 compilations par jour sur le canal quotidien	0.40.10, qui embarque la compilation b11803 de llama.cpp
Code et licence	Open source, MIT	Open source, MIT
Fonctionne sur	Windows, macOS, Linux et Android ; compilations CPU, CUDA, ROCm, Vulkan, Metal, SYCL et OpenVINO	Windows 10 22H2 ou plus récent, macOS 14 ou plus récent, Linux ; NVIDIA, AMD, Vulkan et Apple Silicon (aussi avec MLX)
Fichiers de modèle	GGUF ; safetensors seulement après conversion	GGUF et safetensors ; sur Apple Silicon, MLX par défaut
D’où viennent les modèles	N’importe quel fichier GGUF, ou Hugging Face avec -hf	La bibliothèque d’Ollama avec ollama pull, ou votre propre fichier via un Modelfile
Requêtes simultanées, d’origine	4, qui partagent un même bloc de mémoire de contexte	1 par modèle ; les autres attendent dans une file de 512 au plus
Contexte d’origine	Le maximum du modèle, réduit jusqu’à ce qu’il tienne (jamais sous 4 096 jetons)	4 096 jetons sous 23 Gio de mémoire graphique, 32 768 à partir de 23 Gio, 262 144 à partir de 47 Gio
Modèle inactif	Reste chargé jusqu’à l’arrêt du serveur	Déchargé au bout de 5 minutes
Installation et première réponse	Une compilation ou brew install llama.cpp, puis llama serve -hf et un modèle	Installateur ou script d’une ligne, puis ollama run et un modèle
Fenêtre	Une page de chat dans votre navigateur, active d’origine	Application de bureau sur macOS et Windows ; terminal sous Linux
Écoute sur	127.0.0.1:9931 (8080 jusqu’à la v0.6.0)	127.0.0.1:11434
Clé et CORS	Pas de clé d’origine (--api-key en ajoute une) ; CORS ouvert à n’importe quelle page web	Aucune clé possible ; CORS ouvert seulement aux pages de localhost, 127.0.0.1 et 0.0.0.0
Envoie de lui-même	Rien	2 types d’appel avec ollama serve, 4 avec l’application ; OLLAMA_NO_CLOUD=1 en coupe 2

Le même moteur : ce que fait tourner Ollama 0.40.10

Ouvrez le code d’Ollama et la relation est écrite noir sur blanc. Un fichier à la racine du projet, LLAMA_CPP_VERSION, fixe le llama.cpp qu’il compile : la b11803, une compilation quotidienne du 21 octobre 2026. Quand vous chargez un modèle GGUF, Ollama 0.40.10 lance le serveur de llama.cpp, llama-server, dans un processus à part : sur 127.0.0.1, sur un port libre choisi par le système, avec sa page de chat désactivée et les téléchargements interdits (--offline). Ollama lui parle et vous renvoie les réponses par sa propre API, sur le port 11434. Par-dessus, il ajoute sa propre couche de compatibilité et un petit correctif au code de chargement des modèles et de vision de llama.cpp.

Et voici le plus amusant : au 24 octobre 2026, le llama.cpp d’Ollama est plus récent que la version stable de llama.cpp lui-même. La v0.7.0 correspond à la compilation b11669, du 15 octobre ; Ollama embarque la b11803, 134 commits plus tard. Les compilations quotidiennes de llama.cpp sont encore plus en avance : si vous avez besoin d’un modèle sorti hier, llama.cpp seul y arrive en premier.

L’autre moteur d’Ollama, c’est MLX, le framework d’Apple, qu’il utilise sur Apple Silicon dès que le modèle téléchargé est sa version MLX. Flint, un modèle pour coder, tourne désormais sur les deux moteurs : la 0.40.8 ne le faisait tourner que sur macOS, via MLX ; la 0.40.9 le fait aussi tourner sous Linux et Windows, car la b11803 est la compilation de llama.cpp qui a ajouté Flint. Son étiquette par défaut dans le catalogue d’Ollama contient maintenant deux versions, MLX pour les Mac Apple Silicon et un fichier GGUF pour llama.cpp ailleurs, et Ollama télécharge celle qui convient à votre machine.

Vous ne choisissez donc pas entre deux moteurs. Vous choisissez entre utiliser le moteur directement, avec toutes ses options, ou passer par un gestionnaire qui les choisit pour vous. La suite de cette page parle de ces choix.

4 requêtes à la fois, ou 1

Lancez llama serve et il ouvre 4 emplacements : jusqu’à 4 requêtes sont traitées en même temps. Dans le code de la v0.7.0, le nombre d’emplacements du serveur est en automatique par défaut, et automatique veut dire 4, avec un seul bloc de mémoire de contexte partagé par tous. Ce bloc partagé, c’est le détail à connaître : lancé avec -c 8192, il vous donne 8 192 jetons pour les 4 ensemble ; une longue conversation peut donc occuper tout le bloc, mais 4 longues conversations à la fois se le disputent. -np fixe un autre nombre d’emplacements ; le bloc est alors réparti à parts égales entre eux, sauf si vous ajoutez --kv-unified.

Ollama traite 1 requête par modèle à la fois : OLLAMA_NUM_PARALLEL vaut 1 par défaut, et les autres requêtes attendent dans une file de 512 au plus. Pour une personne qui discute, c’est exactement ce qu’il faut. Vous pouvez l’augmenter, et c’est là que le code montre le prix : Ollama demande à son llama-server interne un contexte de la taille choisie multipliée par le nombre de requêtes parallèles. Réglez-le sur 4 avec un contexte de 4 096 jetons et il réserve la mémoire de 16 384 jetons.

Quand est-ce que ça compte ? Avec une extension d’éditeur qui envoie des complétions pendant que vous discutez, un script qui pose des questions en parallèle, ou 2 personnes de la maison sur le même modèle. Avec une seule personne qui tape une question à la fois, les 4 emplacements restent presque toujours vides et les deux se comportent pareil. Et de combien llama.cpp est-il plus rapide avec 4 requêtes en cours ? Nous ne l’avons pas mesuré : cela dépend de la carte, du modèle et du nombre de requêtes qui arrivent ensemble.

Contexte : le maximum du modèle, ou 4 096 jetons

C’est le réglage d’origine qui change le plus ce que vous ressentez à l’usage, et les deux partent dans des directions opposées.

llama.cpp part du haut. Sa taille de contexte, -c, vaut 0 par défaut, c’est-à-dire le plus long contexte sur lequel le modèle a été entraîné. Ensuite, un mécanisme appelé --fit, actif d’origine, ajuste tout ce que vous n’avez pas fixé vous-même : il réduit le contexte jusqu’à un plancher de 4 096 jetons, puis déplace des couches de la carte graphique vers la mémoire système, en visant à laisser 1 024 Mio libres sur chaque périphérique. Vous obtenez le plus long contexte que votre machine peut tenir, parfois avec une partie du modèle sur le processeur, ce qui est plus lent.

Ollama part du bas, et décide selon la mémoire graphique qu’il trouve au démarrage : sous 23 Gio au total, 4 096 jetons ; à partir de 23 Gio, 32 768 ; à partir de 47 Gio, 262 144. Sur une carte de 8 ou 12 Go, cela fait 4 096 jetons pour n’importe quel modèle, même entraîné pour 262 144, sauf si vous, ou le Modelfile du modèle, indiquez un autre nombre. Un long document est alors coupé sans prévenir, et le modèle répond sur la partie qu’il a vue. OLLAMA_CONTEXT_LENGTH change la valeur pour tous les modèles ; num_ctx, pour un modèle ou une requête.

La mémoire se comporte aussi différemment une fois la réponse terminée. Ollama décharge un modèle après 5 minutes sans requête et rend la mémoire, ce qui est bien agréable sur un portable qui fait aussi tourner un navigateur et un jeu. llama-server garde le modèle chargé jusqu’à ce que vous l’arrêtiez ; --sleep-idle-seconds le met en veille au bout d’un moment si vous préférez les manières d’Ollama.

Les installer, et la première réponse

Ollama, c’est 2 étapes : l’installateur sur macOS ou Windows, ou un script d’une ligne sous Linux, puis ollama run suivi du nom d’un modèle. Il télécharge le modèle depuis sa propre bibliothèque et ouvre un chat dans le terminal ; sur macOS et Windows, il y a aussi une application de bureau avec sa fenêtre de chat. Cette vidéo va de l’installation au premier modèle ; elle a été tournée avec une version antérieure, donc là où elle diffère, fiez-vous à cette page.

llama.cpp vous demande d’abord un choix : quelle compilation. La voie tranquille, c’est brew install llama.cpp, qui installe sur Mac et Linux la version stable v0.7.0 depuis le 16 octobre 2026. La page des versions sur GitHub propose 36 fichiers par compilation, selon le système et la carte graphique, et vous prenez celui qui correspond à la vôtre (avec NVIDIA, plus son fichier cudart) ; winget sous Windows et le script d’installation du projet vous donnent, eux, une compilation quotidienne. Ensuite, 1 commande :

llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192

Elle télécharge le modèle depuis Hugging Face, en compression Q4_K_M si vous n’en indiquez pas d’autre, et ouvre le serveur et une page de chat sur http://127.0.0.1:9931. Notre guide d’installation de llama.cpp passe en revue les compilations et les options, et le guide d’installation d’Ollama fait de même pour Ollama.

Si vous préférez les voir côte à côte avant de choisir, cette vidéo fait exactement cela. Elle a été tournée avec d’autres versions : là où elle diffère de cette page, c’est la page qui suit la v0.7.0 et la 0.40.10.

L’origine des modèles est une vraie différence. Les deux lisent le GGUF, le format créé par llama.cpp. llama.cpp charge n’importe quel fichier GGUF que vous lui donnez, depuis n’importe quel dossier, et -hf télécharge depuis Hugging Face dans le cache standard de Hugging Face, partagé avec les autres programmes qui l’utilisent : rien n’est téléchargé deux fois. Un modèle en safetensors doit d’abord être converti avec le script convert_hf_to_gguf.py du dépôt. Ollama télécharge depuis sa propre bibliothèque avec ollama pull, dans son format en couches sous ~/.ollama/models ; pour utiliser votre propre fichier, vous écrivez un Modelfile qui pointe vers un GGUF ou un dossier de safetensors, puis vous lancez ollama create.

Côté matériel, la liste la plus longue est celle de llama.cpp : des compilations prêtes pour le processeur seul, NVIDIA avec CUDA, AMD avec ROCm ou Vulkan, Intel avec SYCL ou OpenVINO, Apple Silicon avec Metal, et même les téléphones Android. Ollama couvre Windows 10 22H2 ou plus récent, macOS 14 ou plus récent et Linux, les cartes NVIDIA à partir de la capacité de calcul 5.0, AMD avec ROCm v7, et Vulkan, actif par défaut sous Windows et Linux. Sur un Mac Intel, les deux ne tournent que sur le processeur.

Une fenêtre, une page de chat ou juste un terminal

llama-server est livré avec sa propre page de chat, active d’origine, à la même adresse que l’API. Ouvrez http://127.0.0.1:9931 et elle est là : vos conversations et, depuis la v0.7.0, un gestionnaire de modèles. Vos discussions sont conservées dans le stockage de votre navigateur, pas dans un dossier de votre disque : effacer les données du site les supprime, et elles ne vous suivent pas dans un autre navigateur. --no-ui désactive la page si vous ne voulez que l’API.

La fenêtre d’Ollama, c’est son application de bureau sur macOS et Windows, qui garde vos discussions dans une petite base de données de votre dossier utilisateur. Sous Linux, Ollama est un service en arrière-plan et un terminal ; vous placez devant son API l’interface de chat de votre choix. Détail amusant : le llama-server qui tourne dans Ollama possède la même page de chat, et Ollama la désactive exprès.

Quelles portes sont ouvertes : 127.0.0.1:9931 contre 127.0.0.1:11434

D’abord la bonne nouvelle : d’origine, les deux n’écoutent que sur votre propre machine. llama.cpp v0.7.0 attend sur 127.0.0.1:9931 ; jusqu’à la v0.6.0, c’était le 8080, et les images Docker du projet utilisent toujours le 8080 à l’intérieur du conteneur. Ollama attend sur 127.0.0.1:11434. Personne sur votre wifi n’atteint l’un ou l’autre tant que vous ne l’ouvrez pas exprès : --host 0.0.0.0 pour llama.cpp, OLLAMA_HOST=0.0.0.0 pour Ollama.

La différence se joue dans votre navigateur. Le CORS décide quelles pages web peuvent utiliser un serveur local depuis votre navigateur, et ici c’est Ollama le plus strict. llama.cpp, d’origine, renvoie n’importe quelle origine et autorise les identifiants : une page web que vous visitez peut envoyer des requêtes à votre llama-server et lire les réponses tant qu’il tourne ; le serveur le signale lui-même au démarrage avec security: no API key is set and CORS allows all origins. Ollama n’accepte que les pages servies depuis localhost, 127.0.0.1 et 0.0.0.0 sur n’importe quel port, plus quelques schémas d’application, et répond 403 à toute autre origine.

Côté clés, c’est llama.cpp qui en a. --api-key, ou la variable LLAMA_API_KEY, oblige les clients à envoyer une clé, et --api-key-file en lit plusieurs dans un fichier. Le serveur local d’Ollama n’a aucune clé à vérifier : ses défenses, c’est d’écouter seulement sur votre machine, sa courte liste CORS et une vérification de l’en-tête Host de chaque requête. Un piège côté llama.cpp : la clé ne change pas le CORS. Dans notre test du guide d’installation, l’origine était toujours renvoyée avec une clé définie ; ce qui le ferme, c’est --cors-origins localhost.

Ce que chacun envoie de lui-même

Ici, llama.cpp gagne haut la main. Nous avons cherché dans le code de son moteur, de son serveur, de son chat en terminal et de sa page de chat des bibliothèques d’analyse, de télémétrie et de suivi : il n’y en a aucune, et la v0.7.0 n’ajoute aucun nouvel appel. Il ne vérifie pas les mises à jour et n’a pas de compte. Il ne sort sur internet que si vous le demandez : téléchargement de modèles, depuis Hugging Face avec -hf ou llama download et depuis n’importe quelle adresse avec --model-url ; modèles empaquetés en image de conteneur avec --docker-repo ; et llama update, qui ne fonctionne qu’avec les installations faites par le script du projet. Une fois vos modèles sur le disque, --offline lui interdit complètement le réseau.

Ollama n’a pas non plus de bibliothèque d’analyse dans son code. Avec ollama serve seul, comme sous Linux, il fait de lui-même 2 types d’appel vers ollama.com : un catalogue de modèles recommandés toutes les 4 heures et les fiches de ses modèles cloud au démarrage du serveur. OLLAMA_NO_CLOUD=1 coupe les deux. Avec l’application de bureau sur macOS ou Windows, 2 types de plus s’y ajoutent : une vérification des mises à jour toutes les heures, qu’aucun réglage n’arrête, et une requête sur le compte à l’ouverture de l’application.

La configuration la plus discrète, c’est donc llama.cpp avec --offline, puis ollama serve sans l’application et avec OLLAMA_NO_CLOUD=1. Chaque destination, avec sa source et sa date, figure sur notre fiche llama.cpp et notre fiche Ollama.

Lequel nous installerions, selon votre profil

• Première fois avec l’IA locale, sur n’importe quel ordinateur : Ollama. Une commande, un modèle qui se charge et se décharge tout seul et un CORS étroit dès le départ.
• Un Mac ou un portable Windows, et vous voulez une fenêtre : l’application de bureau d’Ollama. La page de chat de llama.cpp est bien, mais elle vit dans le navigateur.
• Des contextes longs sans bricoler : llama.cpp, qui part du maximum du modèle ; ou Ollama avec OLLAMA_CONTEXT_LENGTH réglé à la main.
• Une extension d’éditeur, des scripts ou 2 personnes sur un modèle : llama.cpp, avec ses 4 emplacements, --cors-origins localhost et une clé.
• Rien ne doit sortir de la machine : llama.cpp avec --offline.
• Un modèle sorti hier : une compilation quotidienne de llama.cpp, qui reçoit les nouvelles familles avant la version stable et avant Ollama.
• Une étagère de fichiers GGUF dans un dossier : llama.cpp les lit tels quels ; Ollama demande un Modelfile par modèle.

Si quelque chose coince en route, nous avons un guide pour quand llama.cpp ne fonctionne pas et un autre pour quand Ollama ne fonctionne pas. Vous hésitez encore avec une application de bureau ou un serveur pour beaucoup de monde ? Nos comparatifs LM Studio vs Ollama et vLLM vs Ollama couvrent ces cas, et le trouveur de modèle vous dit quels modèles tiennent sur votre machine.