LLM local : faut-il choisir Ollama ou llama.cpp ?

Quel outil choisir pour un LLM local : Ollama ou llama.cpp ?

Choisissez Ollama si vous gérez des postes de développement ou un service interne de modèles de taille modeste. Ses commandes de gestion, ses configurations nommées et son API destinée aux applications raccourcissent le chemin entre le téléchargement d’un modèle et son utilisation. Il reste à dimensionner la mémoire et à contrôler les accès, mais les consignes d’installation de chaque utilisateur comportent moins de décisions liées au service d’inférence.

Choisissez llama.cpp si vous êtes responsable de la configuration de l’inférence. Il convient mieux lorsqu’il faut sélectionner un fichier GGUF précis, examiner une nouvelle quantification, ajuster la répartition sur les GPU ou régler les requêtes simultanées et l’allocation du contexte. Vous obtenez un déploiement dont vous pouvez décrire précisément les paramètres, à condition d’en assurer vous-même la maintenance.

Conservez votre moteur actuel s’il atteint vos objectifs de réactivité et de qualité pour la charge prévue. Migrer d’Ollama vers llama.cpp au seul motif qu’un benchmark publié par quelqu’un d’autre affiche de meilleurs résultats sur un portable ne suffit pas. Changez lorsque vous pouvez nommer le réglage qui vous manque ou le problème mesuré que vous cherchez à résoudre.

Comparatif vérifié à partir de la documentation en ligne des deux projets le 16 octobre 2026. Les critères retenus sont l’installation, la maîtrise des fichiers de modèles, le comportement des API, les requêtes simultanées et la prise en charge du matériel. Cet article ne présente pas de test de performances réalisé par nos soins.

Ces fonctionnalités sont décrites dans le guide de la CLI d’Ollama, son guide d’importation GGUF et la documentation du serveur llama.cpp. Les deux logiciels locaux sont gratuits, à distinguer des offres hébergées d’Ollama ; les licences des modèles restent un sujet distinct. Dépôt Ollama, dépôt llama.cpp.

Une même filiation, des responsabilités différentes

Ollama ajoute une couche de gestion des modèles et de service autour de l’inférence ; llama.cpp donne directement accès aux outils d’inférence. L’inférence consiste à transformer les poids d’un modèle et votre entrée en tokens de sortie. Pour l’exploiter, il faut aussi trouver les modèles, nommer les configurations, les charger, recevoir les requêtes et retirer les anciens fichiers.

Ollama cite llama.cpp dans son dépôt. Le réduire à une « simple surcouche » serait toutefois excessif : son code actuel comprend aussi des travaux sur d’autres moteurs d’exécution, dont des composants MLX. Une origine commune ne signifie pas que chaque modèle utilise le même moteur, la même révision ou le même chemin d’exécution. Code source et remerciements d’Ollama.

Pour trancher, demandez-vous quelle part de cette mécanique doit figurer dans vos instructions de déploiement. Si un développeur a besoin d’un nom de modèle documenté et d’un point d’accès, la mise en paquet d’Ollama facilite le travail. Si le responsable de l’infrastructure doit réunir la somme de contrôle du fichier, la compilation du moteur d’exécution et les paramètres mémoire, une configuration directe de llama.cpp permet de les expliciter plus facilement.

Installation et gestion des modèles : l’avantage d’Ollama au quotidien

Ollama : rendre l’installation reproductible

Ollama permet d’exécuter des modèles en local, avec une bibliothèque de modèles gérée et une API de service. Il propose des téléchargements pour macOS, Windows et Linux. Sa CLI couvre les opérations courantes dont un responsable informatique a besoin : pull, run, ls, rm, ps et stop. Un Modelfile, fichier texte qui décrit une configuration de modèle, permet d’associer un modèle de base et des instructions sous un même nom. Guide de démarrage d’Ollama, référence de la CLI.

Pour un projet pilote d’assistance au développement partagé, documentez une fois le modèle approuvé, sa configuration et son point d’accès. Un développeur ne devrait pas avoir à apprendre à répartir la charge sur les GPU pour simplement connecter une application. C’est le meilleur argument en faveur d’Ollama face à llama.cpp.

La limite apparaît lorsque le workflow prévu par l’outil ne permet pas d’exprimer le comportement attendu du serveur. Ne supposez pas qu’une option de llama.cpp puisse être transmise telle quelle à Ollama. Vérifiez les paramètres disponibles dans votre version avant de bâtir un déploiement autour de l’un d’eux.

llama.cpp : un accès direct, sans obligation de compiler

llama.cpp est une boîte à outils d’inférence comprenant une interface en ligne de commande, un serveur HTTP et une interface web. Son README actuel propose un installateur, des versions précompilées, Docker et la compilation à partir des sources. Il décrit également llama cli -hf et llama serve -hf pour charger des modèles directement depuis Hugging Face, la plateforme d’hébergement de modèles. Compiler les sources est une possibilité, pas un préalable. Installation et démarrage de llama.cpp.

Utiliser directement llama.cpp ne signifie pas non plus devoir lancer indéfiniment un processus indépendant pour chaque modèle. La documentation du serveur décrit un routeur avec des répertoires de modèles et des préréglages de configuration. La différence tient à la part de ce fonctionnement que vous choisissez et entretenez vous-même. Documentation du routeur du serveur.

Avantage à Ollama pour l’installation et la gestion courante des modèles. Sur ce critère, ne retenez llama.cpp que si une configuration explicite apporte quelque chose à votre workflow. Si vous cherchez surtout un espace de travail sur ordinateur pour vos modèles, le comparatif Ollama vs LM Studio correspond mieux au besoin.

GGUF et quantification : llama.cpp donne la maîtrise des fichiers

Les deux outils exécutent des modèles GGUF ; llama.cpp offre un accès plus direct à leur préparation et à leur sélection. GGUF est un format de fichier qui contient les poids et les métadonnées d’un modèle. La quantification stocke les poids avec une précision réduite pour limiter leur empreinte, au prix d’un compromis sur la qualité qui dépend du modèle et de la tâche.

L’outil de quantification de llama.cpp décrit des formats comme Q4_K_M, Q5_K_M et Q8_0, ainsi que des réglages fondés sur une matrice d’importance ou appliqués par tenseur. Une matrice d’importance aide à déterminer quelles parties du modèle ont besoin de plus de précision ; les réglages par tenseur permettent de traiter différemment les tableaux de poids. Ces possibilités comptent lorsqu’un modèle téléchargé tel quel n’atteint pas votre objectif de mémoire ou de qualité. Guide de quantification de llama.cpp.

Ollama peut importer un GGUF déjà préparé avec une ligne FROM dans un Modelfile. Sa documentation actuelle précise que l’importation d’un GGUF ne quantifie pas le modèle et renvoie d’abord vers des outils comme llama-quantize. Cette répartition du travail est utile : préparer le fichier avec llama.cpp, puis diffuser une configuration nommée avec Ollama. Documentation sur l’importation dans Ollama.

Par exemple, après avoir placé un modèle textuel compatible en un seul fichier à l’emplacement ./team-model.gguf, les commandes suivantes créent une configuration Ollama avec une allocation de contexte choisie :

cat > Modelfile <<'MODEL'
FROM ./team-model.gguf
PARAMETER num_ctx 8192
MODEL
ollama create team-local -f Modelfile
ollama run team-local

Le nom du fichier et celui du modèle sont libres. Le réglage du contexte sert ici d’exemple, pas de recommandation pour toutes les charges. La syntaxe provient de la référence du Modelfile.

L’extension .gguf ne garantit pas à elle seule la compatibilité. L’architecture du modèle et son gabarit de conversation doivent aussi être pris en charge. Ce gabarit définit les règles qui transforment les messages en entrée conforme aux attentes du modèle. Les modèles multimodaux peuvent également exiger des composants distincts pour la vision ou l’audio. Le guide de quantification de llama.cpp explique le rôle des fichiers de projection supplémentaires. Obtenir une réponse textuelle correcte ne suffit pas à valider les entrées image ou l’utilisation d’outils.

Avantage à llama.cpp pour la quantification personnalisée et la sélection précise des fichiers de modèles. Ollama reste adapté si le modèle préparé fonctionne et si vous préférez son mode d’exploitation. Choisissez les poids indépendamment du moteur à l’aide de notre sélection des meilleurs LLM locaux en 2026.

Serveur et compatibilité API : Ollama facilite les usages courants

Ollama est le choix le plus simple pour une application qui utilise une API documentée de modèles locaux ; llama.cpp prend l’avantage lorsque la configuration du serveur exige des réglages fins. Ollama propose son API native ainsi que des routes compatibles avec OpenAI. llama.cpp fournit lui aussi des fonctions compatibles avec OpenAI pour les complétions de chat, les réponses et les embeddings. Cette compatibilité désigne une interface de requête familière, pas un comportement identique pour chaque fonctionnalité. Documentation de l’API Ollama, référence du serveur llama.cpp.

Une limite précise peut peser dans la décision de migrer : l’API Responses d’Ollama ne conserve pas d’état. Elle ne prend en charge ni previous_response_id ni conversation. Si votre application utilise ces champs pour que le serveur mémorise une conversation, changer uniquement l’URL de base ne suffit pas. Vérifiez le comportement documenté du serveur cible et décidez où conserver l’historique.

La configuration du contexte constitue une autre limite. Pour modifier la taille du contexte d’un modèle local, le guide de compatibilité OpenAI d’Ollama renvoie vers un Modelfile. Ce paramètre est distinct du plafond de tokens en sortie : autoriser une réponse plus longue n’augmente pas automatiquement la longueur d’entrée acceptée.

Dans un déploiement direct de llama.cpp, le serveur donne accès aux alias de modèles, aux paramètres de gabarit de conversation, aux clés API et à des métriques facultatives. Ces réglages sont utiles lorsqu’un assistant interne doit garder le même nom de modèle dans l’API pendant que vous remplacez le fichier sous-jacent. Ils représentent aussi davantage de configuration à vérifier et à préserver lors des mises à niveau.

Requêtes simultanées : llama.cpp offre des réglages plus explicites

Ollama peut traiter des requêtes qui se chevauchent ; llama.cpp expose plus directement les réglages d’ordonnancement et de mémoire. Charger plusieurs modèles en même temps et traiter plusieurs requêtes en même temps sont deux opérations différentes. Garder un modèle de code chargé à côté d’un modèle d’embeddings ne consomme pas la mémoire de la même façon que plusieurs conversations partageant un seul modèle chargé.

Ollama documente OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS et OLLAMA_MAX_QUEUE. Le nombre de requêtes parallèles par modèle vaut 1 par défaut, et le traitement parallèle dépend de la mémoire disponible. Augmenter la limite de la file d’attente permet de faire patienter davantage de requêtes ; cela ne crée pas de capacité d’inférence. Documentation sur les requêtes simultanées dans Ollama.

llama.cpp documente le décodage parallèle, le traitement continu par lots et les emplacements de traitement du serveur, ou slots. Le traitement continu par lots permet d’accueillir de nouvelles requêtes à mesure que celles en cours se terminent. Un slot est un emplacement destiné à une requête en cours de traitement. Les réglages comprennent --parallel et --kv-unified-per-slot, ainsi que les paramètres de répartition sur les GPU et de cache. Réglages du serveur llama.cpp.

Dimensionner le contexte avant d’augmenter le parallélisme

Prenons un projet pilote à titre d’illustration : 4 requêtes simultanées × 8 192 tokens de contexte = 32 768 positions de tokens. Il s’agit d’une capacité de contexte, pas d’une mesure de RAM. Le cache KV, qui stocke l’état d’attention du modèle, consomme de la mémoire en plus des poids et des autres allocations de travail. Son empreinte en octets dépend de l’architecture et de la précision du cache.

Avec le fichier compatible team-model.gguf de l’exemple précédent, une installation actuelle de llama.cpp permet d’exprimer directement cette configuration :

llama serve -m ./team-model.gguf \
  --alias team-local \
  --host 127.0.0.1 --port 8080 \
  --parallel 4 \
  --kv-unified-per-slot 8192

Ces paramètres ont été choisis pour le projet pilote : ce ne sont ni des résultats de benchmark ni les valeurs par défaut du projet. Selon la documentation du serveur, sans valeur explicite pour --ctx-size, la capacité du pool KV partagé correspond au nombre de slots multiplié par la limite de chaque slot. Conservez le service pilote sur l’interface de boucle locale tant que les contrôles d’accès ne sont pas prêts.

Avec Ollama, configurez le parallélisme et le contexte dans l’environnement du service, puis vérifiez le contexte effectif et la répartition CPU/GPU avec ollama ps. La page consacrée au contexte décrit des valeurs par défaut qui dépendent du matériel : consignez donc l’allocation réellement utilisée. Configuration du contexte dans Ollama.

La vitesse se mesure sur une charge donnée

Le nom du projet ne suffit pas à désigner un vainqueur pour tous les tests de latence ou de débit. Avant toute comparaison, utilisez les mêmes poids, la même quantification, le même gabarit, le même contexte, le même moteur d’exécution et le même matériel. Distinguez ensuite le temps d’attente, le délai avant le premier token, la vitesse de génération et les requêtes terminées sous charge.

Pour un assistant de support interne, une réponse isolée rapide ne prouve pas que les collaborateurs pourront l’utiliser ensemble. Rejouez des questions courtes et des requêtes sur de longs documents représentatives de l’usage prévu. Mesurez séparément les démarrages à froid, puis notez les versions des moteurs et la date. Un écart de vitesse publié n’est exploitable que s’il précise qui a testé, à quelle date, sur quel matériel, avec quel modèle et quelle charge.

Avantage à llama.cpp pour régler précisément le traitement des requêtes simultanées. Gardez Ollama si ses paramètres permettent d’atteindre votre objectif de service et si la simplicité d’exploitation vaut davantage que des réglages supplémentaires.

Apple Silicon et GPU : adapter le moteur d’exécution à la machine

Ollama facilite les déploiements courants sur les postes de travail ; llama.cpp donne davantage de contrôle pour les configurations spécialisées. Les deux prennent en charge l’accélération par GPU Apple. Ollama documente la prise en charge de Metal, tandis que llama.cpp fait d’Apple Silicon une plateforme de premier plan avec Metal, Accelerate et des optimisations ARM. Matériel pris en charge par Ollama, matériel pris en charge par llama.cpp.

Sur Mac, commencez par l’application ou les binaires natifs. La documentation d’Ollama indique que Docker Desktop sur macOS ne fournit pas d’accélération GPU. Déplacer une installation native fonctionnelle dans un conteneur peut donc modifier le chemin d’exécution que vous pensiez comparer. Limite de l’accélération GPU avec Docker pour Ollama.

Pour les autres postes, Ollama documente la prise en charge de NVIDIA, d’AMD via ROCm et de Vulkan lorsque ce moteur d’exécution est installé. llama.cpp propose CUDA pour NVIDIA, HIP pour AMD, ainsi que Vulkan et SYCL, avec des instructions de compilation pour choisir le moteur. Vérifiez la combinaison exacte du système d’exploitation, du GPU et du pilote : le seul nom du fabricant ne garantit pas la compatibilité. Guide GPU d’Ollama, guide de compilation de llama.cpp.

La première vérification concrète concerne la répartition : les poids sont-ils sur le GPU, sur le CPU ou partagés entre les deux ? Multiplier les réglages ne résoudra pas le problème si le modèle et son contexte dépassent la mémoire allouée. Choisissez une configuration qui tient en mémoire, puis évaluez si la qualité des réponses vous convient.

Ce que Muse Spark Open change dans le choix

La mention de llama.cpp par Meta ouvre une piste documentée à examiner ; elle ne justifie pas à elle seule de remplacer Ollama. Dans son annonce de Muse Spark Open du 15 octobre 2026, Meta cite llama.cpp parmi les moteurs d’inférence pris en charge. L’utilisation directe de llama.cpp devient donc pertinente pour évaluer ce nouveau modèle sans présumer qu’un autre environnement intègre une prise en charge équivalente. Annonce de Meta.

Le matériel compte. Meta annonce 816B de paramètres au total et 42B de paramètres actifs, et son exemple sur ordinateur utilise deux Mac Studio Apple M5 Ultra avec MLX. Cet exemple n’est pas un benchmark de llama.cpp, et le nombre de paramètres actifs ne dispense pas de vérifier les besoins en mémoire du modèle complet. Description du matériel et du modèle par Meta.

Pour votre déploiement, vérifiez ensemble la compilation exacte, le fichier du modèle, la quantification, le gabarit et les types d’entrée nécessaires. La prise en charge d’un moteur mentionnée lors d’un lancement ne prouve ni celle de votre version installée d’Ollama ni la capacité du modèle à tenir sur un portable de développement ordinaire. L’annonce ouvre une nouvelle piste d’évaluation au responsable de l’infrastructure ; les déploiements sur les postes de travail exigent toujours leur propre validation.

Passer d’Ollama à llama.cpp : migrer aussi la configuration

Le travail de migration consiste à préserver le comportement, pas simplement à copier les poids. L’historique de votre application, son index de recherche documentaire et le traitement de ses requêtes peuvent résider en dehors des deux moteurs. Gardez ces frontières claires pendant le remplacement du service de modèles.

Ne migrez pas si votre service actuel fonctionne et si personne n’a besoin des réglages supplémentaires. Vous pouvez aussi préparer un GGUF avec llama.cpp et continuer à le servir avec Ollama. Les deux projets peuvent intervenir à des étapes différentes d’un même workflow.

Ollama vs llama.cpp vs vLLM : quand dépasser le poste de travail ?

Évaluez vLLM lorsque le trafic partagé soutenu ou l’inférence distribuée devient le besoin principal. vLLM est un moteur de service d’inférence dont la documentation met en avant le traitement continu par lots, la gestion du cache et les possibilités d’exécution distribuée. Ces fonctionnalités méritent un examen lorsque vous exploitez un service reposant sur des accélérateurs dédiés. Documentation de vLLM.

Le traitement continu par lots ne suffit pas à tracer la frontière, puisque llama.cpp le prend également en charge. Il n’existe pas non plus de nombre universel de collaborateurs à partir duquel migrer devient obligatoire. Un service recevant occasionnellement des requêtes courtes n’a pas la même charge qu’un groupe plus restreint qui lui confie en permanence de longues tâches de programmation.

La règle de décision est mesurable : si votre installation actuelle n’atteint pas votre objectif de réactivité lors de pics de demande représentatifs, et si vLLM propose le réglage ou la capacité de déploiement qui manque, évaluez-le. Si l’installation atteint l’objectif, conservez-la. Le comparatif Ollama vs vLLM approfondit ce choix de service d’inférence.

Dès lundi, passez à une action concrète : choisissez un workflow local, fixez son modèle et son contexte, définissez la demande simultanée attendue, puis rejouez-la avant d’élargir l’accès. Le résultat vous dira s’il faut changer de moteur ou simplement mieux le configurer.

Questions fréquentes

Utilisez la checklist d’audit des workflows d’IA en entreprise pour choisir le premier workflow privé qui mérite un service d’inférence local, et abonnez-vous à la newsletter pour suivre les évolutions des outils.