llama.cpp vs Ollama en 2026 : Quel runtime choisir ?

Ollama et llama.cpp sont souvent comparés comme s’ils étaient des moteurs d’inférence rivaux. Le véritable choix se fait entre un service de gestion de modèles et un kit d’outils que vous pilotez directement.

Ollama encapsule une version spécifique et corrigée de llama.cpp à l’intérieur d’un planificateur, d’un magasin de modèles et d’une API, si bien que le modèle nommé devient l’unité opérationnelle. llama.cpp direct inverse cette logique : le processus llama-server et ses drapeaux constituent l’unité, et chaque décision concernant le contexte, le cache KV et la répartition sur GPU est faite par vous et visible dans une commande.

Ce guide compare les deux outils de la même manière que se prend la décision en pratique : installation et commandes quotidiennes, gestion du cycle de vie des modèles, contrôle d’exécution, API, performance, modes de défaillance et sécurité. Il se termine par des déclencheurs concrets pour conserver Ollama, passer à llama-server, et une voie de migration à risque faible entre les deux. Si vous êtes encore en train de choisir entre des approches locales, auto-hébergées et cloud à un niveau plus élevé, commencez par l’aperçu de l’hébergement de LLM; pour le paysage plus large des outils locaux au-delà de ce duo, la comparaison de l’hébergement local de LLM couvre vLLM, LM Studio, LocalAI, et plus encore.

llama.cpp vs Ollama : la réponse courte

Si vous avez seulement besoin d’un backend fiable pour Open WebUI, d’un assistant de codage ou de quelques scripts locaux, Ollama est généralement le choix le moins dispersant. Si vous continuez à vous demander ce qu’Ollama a sélectionné, alloué, modifié ou masqué, vous avez probablement atteint le point où llama-server est le système le plus clair.

Ce que la comparaison signifie réellement en 2026

llama.cpp est un projet d’inférence en C et C++ avec des backends CPU et GPU, des outils de modèles GGUF, des programmes en ligne de commande et un serveur HTTP. Son programme de service direct prend en charge les complétions de chat compatibles OpenAI, les réponses, les embeddings, les requêtes multimodales, l’appel de fonctions, la sortie structurée, le batch processing continu, le décodage spéculatif, les points d’accès de surveillance et une interface web intégrée.

Ollama est un service de niveau supérieur. Il maintient un magasin local de modèles, donne aux modèles des noms stables, télécharge et importe des artefacts, applique des modèles et des valeurs par défaut, sélectionne un backend disponible, planifie les processus de modèles et décharge les modèles inactifs. Son API native rapporte également des informations de temporisation et de chargement qui sont pratiques pour les applications locales.

L’affirmation fréquemment répétée que “Ollama est juste une enveloppe autour de llama.cpp” est directionnellement utile mais techniquement incomplète. Ollama épinglé le source de llama.cpp, applique des correctifs de compatibilité et lance un serveur via son propre planificateur, mais il a aussi un comportement de produit que llama.cpp ne définit pas ; sur la puce Apple, Ollama peut utiliser son moteur MLX. Le chemin de la requête rend cette différence concrète :

Cela mène au modèle mental le plus utile :

• Avec Ollama, le modèle nommé est l’unité que vous pilotez.
• Avec llama.cpp direct, le processus serveur et ses drapeaux sont l’unité que vous pilotez.

Installation et la surface de commandes quotidiennes

Ollama optimise les cinq premières minutes. Après l’installation, la récupération et le démarrage d’un modèle sont intentionnellement succincts :

ollama run qwen3:8b

Le nom du modèle représente plus que ses poids. Ollama peut associer un modèle (template), des paramètres, une invite système, une licence, un adaptateur et une version minimale d’exécution à ce nom. ollama list, ollama show, ollama ps et ollama stop fournissent une surface de gestion cohérente.

llama.cpp direct commence plus près du métal. Vous pouvez télécharger un binaire de version de release, compiler une version spécifique au backend, utiliser un conteneur ou utiliser le nouveau chemin de téléchargement Hugging Face, comme le détaille le guide de démarrage rapide de llama.cpp. Un serveur GGUF local pourrait démarrer ainsi :

llama-server \
  --model /srv/models/qwen3-8b-q4_k_m.gguf \
  --alias qwen3-8b \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 32768 \
  --n-gpu-layers all \
  --flash-attn on

La documentation actuelle de llama.cpp montre également la commande unifiée llama serve dans son guide de démarrage rapide. Les noms d’exécutables empaquetés peuvent varier selon la distribution, alors vérifiez la version de release ou le paquet que vous avez installé plutôt que de copier un fichier de service aveuglément.

La commande plus longue n’est pas automatiquement un inconvénient. C’est un enregistrement exécutable de l’environnement d’exécution que vous avez choisi de créer. Mettez-le dans une unité systemd, un fichier Compose ou un script shell, et la configuration devient révisable au lieu d’être dispersée à travers un manifeste de modèle, des variables d’environnement, des options API et des valeurs par défaut du planificateur.

Le compromis pratique d’installation

Ollama est plus facile à installer de manière cohérente sur les postes de développement. Il est aussi plus facile à expliquer à quelqu’un qui doit utiliser un modèle mais ne devrait pas avoir besoin de comprendre le déchargement de tenseurs, les modèles de chat ou la mémoire KV.

llama.cpp est plus facile à rendre précis. Vous choisissez la compilation, le backend, la version, le fichier et les drapeaux, ce qui est précieux lorsqu’un nouveau noyau GPU corrige votre charge de travail ou qu’un récent commit le brise. Cette liberté signifie aussi que vous êtes responsable des mises à niveau, de la supervision du service et des tests de régression.

Gestion des modèles : noms de bibliothèque ou fichiers ordinaires

Ollama traite les modèles de manière similaire aux images de conteneur. Un nom familier pointe vers un manifeste et des blobs adressés par contenu, et ollama pull résout les couches requises. C’est excellent pour une configuration reproductible des postes de travail et pour les applications qui doivent faire référence à qwen3:8b plutôt qu’à un long chemin de système de fichiers.

Un Modelfile rend la personnalisation reproductible :

FROM ./qwen3-8b-q4_k_m.gguf
PARAMETER num_ctx 32768
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM Vous êtes un assistant technique précis.

ollama create qwen3-8b-local -f Modelfile
ollama run qwen3-8b-local

Ollama peut importer un GGUF local, donc choisir Ollama ne vous limite pas à la bibliothèque publique Ollama. L’étape d’importation, cependant, remet l’artefact au magasin de modèles d’Ollama. Si vous conservez également le GGUF original pour llama.cpp ou LM Studio, tenez compte de la copie supplémentaire gérée, à moins que votre couche de stockage ne la déduplique.

llama.cpp peut simplement pointer vers le GGUF que vous avez déjà. Il peut également télécharger une quantification sélectionnée depuis Hugging Face :

llama-server -hf ggml-org/Qwen3-8B-GGUF:Q4_K_M

Cette approche orientée fichier fonctionne particulièrement bien pour tester de nouvelles quantisations. Téléchargez un fichier, modifiez un chemin et lancez-le ; il n’y a pas d’étape de création et aucune question sur le blob vers lequel un nom de modèle résout.

Les modèles (templates) font partie du modèle, même s’ils ressemblent à de la configuration

Les poids ne définissent pas tout le comportement de chat. Le modèle de chat (chat template) contrôle la façon dont les messages système, utilisateur, assistant, pensée et outil deviennent des jetons. Les séquences d’arrêt et le comportement de l’analyseur peuvent changer le résultat à nouveau.

La bibliothèque soignée d’Ollama réduit ce risque car ses modèles nommés portent des métadonnées testées, et les versions récentes (Ollama est passé de 0.30 à 0.33.3 entre juin et septembre 2026) respectent de plus en plus directement les paramètres par défaut définis dans le GGUF plutôt que de vous obliger à les redéclarer dans un Modelfile. Un GGUF importé manuellement peut toujours nécessiter un TEMPLATE, un analyseur ou un rendu correct, tandis que llama.cpp lit normalement le modèle de chat GGUF embarqué et vous permet de le remplacer. Aucun exécutable ne peut réparer des métadonnées de modèle incorrectes ou manquantes par magie.

Si le même modèle quantifié semble nettement moins bon après un changement d’exécutable, ne concluez pas qu’un moteur a endommagé les poids. Comparez d’abord le modèle (template), la limite de contexte, les valeurs d’échantillonnage, le mode de pensée, l’analyseur d’outils et la révision de l’exécutable, une variable à la fois, avant de toucher au modèle lui-même.

Cycle de vie des modèles et basculement

Le planificateur d’Ollama est l’une de ses raisons d’être les plus fortes. Par défaut, un modèle inactif reste chargé pendant cinq minutes ; une valeur keep_alive au niveau de la requête peut le garder résident indéfiniment, changer la durée ou le décharger immédiatement. ollama ps affiche les modèles chargés, la répartition sur les processeurs, l’allocation du contexte et l’expiration.

# Garde un modèle chargé.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

# Le décharge immédiatement.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": 0
}'

Un processus llama-server --model ... traditionnel charge un modèle et le conserve jusqu’à ce que le processus se termine. Ce comportement est prévisible et précieux pour un service dédié : il n’y a pas de chargement à froid surprise après un délai d’inactivité et aucun planificateur qui décide qu’un autre modèle mérite la mémoire.

llama.cpp dispose désormais également d’un mode routeur. Démarrer llama-server sans modèle peut exposer des modèles en cache, un répertoire GGUF ou des préréglages INI et charger dynamiquement des instances selon le nom du modèle demandé. Il comble partiellement l’ancienne lacune de cycle de vie : un seul modèle est résident par travailleur à la fois, un basculement est un déchargement et rechargement complet plutôt qu’instantané, et il n’y a pas de politique d’éviction ou de pool chaud — chaque requête alternée entre deux modèles paie un rechargement complet. Cela réduit l’écart par rapport à l’absence totale de mode routeur, mais ne rend pas les deux produits identiques ; Ollama offre toujours l’expérience de registre, de pool chaud et d’administration plus fluide. Pour le walkthrough de configuration complet, les limitations actuelles et une comparaison honnête avec Ollama et llama-swap, consultez le guide du mode routeur de llama-server. Si vous avez besoin d’un seul point d’accès entre llama.cpp, vLLM, SGLang et d’autres moteurs, llama-swap est une abstraction plus appropriée que de demander à l’un des deux exécutables de devenir un proxy universel de modèles.

Contrôle d’exécution : là où llama.cpp justifie le travail supplémentaire

L’avantage décisif de llama.cpp n’est pas qu’il est toujours plus rapide. C’est que vous pouvez exprimer directement le plan de mémoire et d’exécution, l’inspecter et changer une variable à la fois.

Précision du contexte et du cache KV

Pour llama.cpp direct, la taille du contexte et les types de cache K/V peuvent être définis par processus serveur :

llama-server \
  --model model.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --parallel 2 \
  --flash-attn on

K et V peuvent utiliser des types différents, et llama.cpp expose des contrôles supplémentaires pour l’allocation KV unifiée, les limites de contexte par slot, la réutilisation du cache de prompts et la persistance du cache. Ces drapeaux ne sont pas décoratifs sur un GPU de 16 Go ou 32 Go — ils déterminent si les requêtes à long contexte tiennent et combien de slots peuvent rester utiles, et les calculs de budget VRAM sous-jacents sont les mêmes quel que soit l’exécutable qui les applique ; voir Cache KV sur GPU de 16 Go pour la formule et les tableaux de types de cache par moteur.

Ollama expose le cas courant important avec OLLAMA_CONTEXT_LENGTH, l’option num_ctx et OLLAMA_KV_CACHE_TYPE. Son type de cache KV est toutefois un réglage global au serveur, plutôt qu’un choix par modèle nommé. Ollama met également à l’échelle la mémoire avec la parallélisme configurée et la longueur du contexte, ce qui peut faire qu’un changement d’concurrentie anodin consomme beaucoup plus de VRAM.

Ce comportement appartient principalement au guide des requêtes parallèles d’Ollama. Pour cette comparaison, la décision est plus simple : utilisez Ollama si une politique de cache globale est acceptable ; utilisez des services llama.cpp séparés si différents modèles nécessitent une précision de cache, un contexte ou une géométrie de slot différente.

Sélection de GPU et répartition multi-GPU

Ollama vise à choisir une répartition judicieuse. Il rapporte si un modèle est entièrement sur GPU, entièrement sur CPU ou réparti, et son planificateur prend en compte la mémoire disponible lors du chargement des modèles. Pour un poste de travail à GPU standard, la répartition automatique est souvent exactement ce que vous voulez.

llama.cpp expose le plan. Vous pouvez sélectionner les appareils, spécifier les couches GPU, choisir des modes de répartition de tenseurs (couches, lignes ou expérimentaux), définir les proportions de tenseurs, sélectionner le GPU principal et conserver délibérément les poids des experts MoE sur le CPU. C’est beaucoup mieux pour les machines multi-GPU asymétriques et pour insérer un modèle trop volumineux dans un budget de mémoire connu.

Si vos notes opérationnelles contiennent des phrases telles que “mettre le cache KV sur ces appareils” ou “garder seulement les experts en mémoire système”, llama.cpp direct est l’outil naturel. Si la exigence est simplement “utiliser le GPU s’il tient”, Ollama économise du temps sans grand sacrifice.

Nouvelles fonctionnalités et cadence des backends

llama.cpp direct est là que les nouvelles architectures de modèles, types de quantification, noyaux GPU et options de serveur expérimentales de llama.cpp apparaissent en premier. C’est précieux pendant une semaine de sortie de modèle, lorsque le support peut dépendre d’un numéro de build spécifique plutôt que du dernier paquet stable.

Ollama épinglé délibérément une révision en amont et applique des correctifs de compatibilité. Cela peut retarder une fonctionnalité en amont, mais cela peut aussi protéger les utilisateurs de l’instabilité et l’intégrer avec le planificateur, les modèles et l’empaquetage multi-plateforme d’Ollama. Un accès plus rapide n’est pas la même chose qu’une fiabilité supérieure.

Ollama 0.30 a considérablement réduit un ancien écart en élargissant la compatibilité GGUF, en améliorant les performances NVIDIA et en activant Vulkan par défaut pour un support plus large d’AMD et d’Intel. La cadence de sortie d’Ollama depuis lors est restée rapide — 0.33.3 est sorti début septembre 2026, environ trois mois plus tard, ajoutant le rapport de jetons de prompts en cache et une autre mise à niveau du backend llama.cpp — alors considérez toute affirmation de version spécifique dans cet article, ou ailleurs, comme quelque chose à re-vérifier avec ollama --version plutôt que comme un fait permanent. Toute comparaison qui dit qu’Ollama ne peut pas exécuter un GGUF local arbitraire, ou que Vulkan nécessite toujours une option expérimentale, est désormais obsolète.

API, outils, vision et sortie structurée

Les deux exécutables sont des serveurs d’API locaux crédibles en 2026. Tous deux peuvent gérer des requêtes de chat courantes de style OpenAI, des outils, des modèles capables de vision, des embeddings, le streaming et la sortie structurée lorsque le modèle et le modèle (template) les supportent.

La différence réside dans la surface environnante :

Ne traitez pas “compatible OpenAI” comme une certification binaire. Ollama dit qu’il supporte certaines parties de l’API OpenAI, tandis que llama.cpp évite explicitement de faire une promesse de compatibilité forte. Avant de changer d’exécutable, testez les trames de streaming, les arguments d’appel d’outils, les champs de raisonnement, les compteurs d’utilisation, les corps d’erreur et tout point d’accès que votre client consomme réellement.

Ollama gagne généralement lorsque l’intégration de l’application est le travail. Ses SDK et intégrations documentées raccourcissent le chemin du succès. llama.cpp gagne lorsque le serveur lui-même est l’objet de l’ingénierie : sa vue des slots, les durées des jetons, les métriques, les schémas, les modèles, les adaptateurs et les points d’accès de bas niveau sont inhabituellement utiles lors du diagnostic.

Performance : mesurez le déploiement, pas la marque

Il est tentant de demander si llama.cpp ou Ollama est plus rapide. Sur un chemin GGUF, Ollama peut exécuter un llama.cpp épinglé et corrigé en dessous, donc une réponse universelle au niveau de la marque n’est pas utile. Les résultats changent avec la révision de build, le backend, l’attention flash, l’allocation du contexte, les slots parallèles, les tailles de lot, le type de cache, la résidence du modèle et si certaines couches sont retombées sur le CPU.

Une comparaison équitable commence avec le même GGUF et teste deux questions différentes :

1. Démarrage à froid : inclure le temps de chargement du modèle et la latence de la première réponse.
2. Service chaud : précharger le modèle, puis mesurer le traitement du prompt et la génération séparément.

Utilisez d’abord une requête et un slot. Alignez la taille du contexte, le type de cache K/V, la température, top-p, la graine, la sortie maximale et le modèle de chat ; confirmez le déchargement complet sur GPU depuis les journaux ou la sortie d’état. Augmentez la concurrence seulement ensuite, car Ollama et llama.cpp allouent et planifient le travail parallèlement de manière différente.

Pour Ollama, la réponse finale de l’API native inclut les durées de chargement, d’évaluation du prompt et de génération, et les versions récentes rapportent également directement les jetons de prompts en cache dans cette réponse — utile pour confirmer si la réutilisation du préfixe s’est réellement produite avant d’attribuer un gain de vitesse à l’exécutable. Pour llama.cpp, activez le rapport de performance ou les métriques Prometheus et inspectez la configuration de démarrage. Un gain de débit de cinq pour cent est meaningless si une exécution a silencieusement utilisé un contexte plus court, un type de cache différent ou un modèle différent.

Mon attente pour le même GGUF supporté sur un GPU est généralement une parité proche, pas une victoire garantie de llama.cpp. llama.cpp direct peut gagner après un réglage délibéré ou en adoptant une optimisation plus récente ; Ollama peut être aussi rapide lorsque son moteur sélectionné et ses valeurs par défaut s’alignent avec la charge de travail. Mesurez après configuration, pas avant.

Modes de défaillance qui exposent la vraie différence

Le modèle utilise inattendement le CPU

Avec Ollama, exécutez ollama ps et inspectez PROCESSOR, CONTEXT et la taille chargée. Un contexte plus grand, un autre modèle résident ou un chemin GPU non supporté peut expliquer la répartition. Vérifiez les journaux du service plutôt que de supposer que le GPU a été ignoré.

Avec llama.cpp, commencez par llama-server --list-devices, puis lisez le journal de démarrage pour la répartition des tenseurs et les tailles de tampons. Si vous avez défini un nombre exact de couches, d’appareils ou de répartition, la commande elle-même est une preuve de votre intention ; c’est beaucoup plus facile à reproduire dans un rapport de bug.

Un contexte plus long cause une erreur de mémoire insuffisante

Ollama choisit des longueurs de contexte par défaut en fonction de la VRAM disponible, et la documentation actuelle recommande au moins 64K pour les charges de travail des agents et de codage. Cette recommandation n’est pas une promesse que votre modèle, votre parallélisme et votre cache tiendront. Réduisez num_ctx, réduisez la parallélisme, choisissez le cache KV q8_0 si approprié, ou utilisez une quantification de poids plus petite. Confirmez le tableau de mémoire réel avec nvidia-smi avant et après une longue requête pour savoir si le modèle, le cache ou les deux sont la contrainte.

Avec llama.cpp, réduisez --ctx-size, changez --cache-type-k et --cache-type-v, baissez --parallel, ou ajustez le déchargement. Parce que chaque choix est explicite, il est plus facile de construire des profils séparés pour le long contexte et la haute concurrence plutôt que d’imposer un compromis unique à tous les modèles.

L’API se connecte, mais les réponses sont malformées

C’est souvent un problème de modèle (template) ou d’analyseur, surtout avec les nouveaux modèles de raisonnement et d’appel d’outils. Vérifiez que le GGUF contient le modèle de chat attendu et que l’exécutable reconnaît l’architecture. Comparez une requête de chat simple avant de déboguer le framework d’agent superposé.

Sur Ollama, inspectez ollama show --modelfile <nom> et les capacités rapportées. Sur llama.cpp, inspectez les messages de modèle de démarrage, utilisez --jinja et testez /v1/chat/completions directement. Épinglé la version de l’exécutable qui fonctionne avant de changer une autre variable.

Les requêtes deviennent lentes après changement de modèle

Ollama peut devoir décharger un modèle et en charger un autre, donc séparez le temps de file d’attente du temps de génération. Préchargez le modèle important avec une requête vide et définissez une valeur keep_alive intentionnelle plutôt que de dépendre du défaut de cinq minutes.

Un processus llama.cpp dédié évite les basculements surprise car son modèle reste résident. Si vous adoptez le mode routeur, le chargement du modèle devient dynamique à nouveau — et chaque basculement entre deux modèles différents est un déchargement et rechargement complet sans pool chaud — alors surveillez l’état de chargement et la latence de démarrage à froid comme vous le feriez avec Ollama.

La sécurité n’est pas un différenciateur à moins que vous ne la configuriez

Les deux serveurs se lient à localhost par défaut, ce qui est le comportement correct pour un poste de travail. Changer l’hôte en 0.0.0.0 transforme un service d’inférence local privé en service réseau, et aucun produit ne devrait être exposé à Internet public simplement parce qu’une règle de pare-feu l’a permis par accident.

llama.cpp peut imposer des clés API et peut terminer le TLS, bien qu’un proxy inversé soit toujours utile pour la politique, les limites de débit et les journaux. L’API locale d’Ollama ne requiert pas de clé API ; mettez-le derrière un proxy authentifié ou une frontière de réseau privé si des clients distants ont besoin d’accès. Si vous avez besoin d’un accès distant à Ollama, le guide Ollama derrière un proxy inversé couvre la configuration Caddy et Nginx avec vérifications de streaming et de délai. Les modèles capables d’outils augmentent les conséquences d’exposer l’application environnante, même lorsque le serveur d’inférence lui-même n’exécute pas les outils.

Quand conserver Ollama

Conservez Ollama lorsque son automation supprime plus de travail qu’elle ne masque. Il est particulièrement fort pour les postes de développement partagés, les applications de bureau locales, les démonstrations, les outils de codage et les petits services qui alternent entre plusieurs modèles populaires.

Ollama est aussi le défaut plus approprié lorsque vous voulez que vos collègues reproduisent une configuration nommée sans apprendre les drapeaux de llama.cpp. Un Modelfile, une étiquette de modèle et deux commandes constituent un contrat opérationnel utile. L’aide-mémoire Ollama couvre ce flux de travail quotidien en plus de détail.

Ne migrez pas simplement parce que llama.cpp direct semble plus technique. Si votre modèle tient, l’API se comporte correctement, la latence est stable et vous n’avez pas besoin d’un contrôle manquant, remplacer Ollama crée de la maintenance sans créer de capacité.

Une mise en garde qui mérite un suivi dans le temps : la direction produit d’Ollama a commencé à dériver vers une infrastructure centralisée. Ollama Turbo est un service cloud d’accélération à accès conditionné à l’inscription, superposé à ce qui était originellement un outil local-first et privacy-first, et ce n’est pas le seul changement récent qui échange le contrôle local contre une couche de commodité hébergée. Si la raison pour laquelle vous avez choisi Ollama au départ était d’éviter d’envoyer des prompts aux serveurs de quelqu’un d’autre, ce raisonnement mérite une re-vérification périodique plutôt qu’une décision unique — voir [La dégénérescence d’Ollama : Les premiers signes](https://www.glukhov.org/fr/llm-hosting/ollama/ollama-enshittification/ “Aperçu des premiers signes de dégénérescence d’Ollama : monétisation cloud de Turbo, télémétrie, comportement de démarrage automatique et régressions de performance.”}) pour les changements spécifiques et ce qu’il faut surveiller. llama.cpp direct n’a pas d’offre d’abonnement hébergée équivalente vers laquelle dériver, ce qui est en soi un point de données lorsque vous pesez le contrôle à long terme contre la commodité à court terme.

Quand passer à llama-server

Passez à llama-server direct lorsque l’une ou plusieurs de ces affirmations sont vraies :

• Vous avez besoin d’une nouvelle fonctionnalité ou d’une correction de modèle de llama.cpp avant qu’elle n’atteigne Ollama.
• Vous devez épinglier un commit et un backend de build précis de llama.cpp.
• Différents modèles nécessitent des types de cache K et V différents ou des mises en page de slot différentes.
• Vous avez besoin d’une répartition multi-GPU délibérée plutôt que d’une sélection automatique.
• Vous testez le décodage spéculatif, le MTP, les échelles LoRA, la mise en cache des prompts ou des échantilleurs peu communs.
• Les métriques natives, l’état des slots ou les entrailles du serveur sont nécessaires pour le diagnostic.
• Vous voulez que les fichiers GGUF originaux restent le catalogue de modèles autoritaire.
• Un modèle doit rester résident pour la durée de vie d’un processus supervisé.

Le déclencheur de migration le plus clair est l’inspection répétée. Si chaque incident commence par découvrir ce qu’Ollama a choisi avant que vous ne puissiez diagnostiquer le modèle, rendez ces choix explicites dans une définition de service llama.cpp.

Une migration à risque faible d’Ollama à llama.cpp

Ne commencez pas en reproduisant chaque fonctionnalité d’Ollama. Migratez un modèle et un client, conservez le point d’accès actuel jusqu’à ce que la comparaison soit complète, et gardez le même GGUF si possible.

1. Enregistrez ollama --version, ollama show <modèle>, ollama show --modelfile <modèle> et ollama ps.
2. Localisez ou téléchargez le GGUF équivalent et tout projecteur multimodal.
3. Démarrez un llama-server avec un alias explicite, un contexte, un déchargement GPU, des types de cache et un nombre de slots.
4. Envoyez une requête de chat simple, une requête de sortie structurée et un appel d’outils directement à chaque API.
5. Testez le client réel, y compris le streaming et la gestion des erreurs.
6. Comparez la latence de chargement à froid, la vitesse de prompt chaude, la vitesse de génération, la VRAM et le format de réponse.
7. Remplacez seulement alors l’URL du service ou ajoutez un proxy devant les deux backends.

Pour un test fumée simple de style OpenAI :

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3-8b",
    "messages": [
      {"role": "user", "content": "Return exactly: runtime-ok"}
    ],
    "temperature": 0,
    "max_tokens": 16
  }'

Puis vérifiez le service lui-même :

# llama.cpp
llama-server --version
llama-server --list-devices
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/v1/models

# Ollama
ollama --version
ollama ps
curl http://127.0.0.1:11434/api/ps
curl http://127.0.0.1:11434/v1/models

Si l’application dépend de la forme de la réponse /api/chat native d’Ollama, changer l’URL de base ne suffit pas. Migratez d’abord le client vers une route compatible OpenAI ou ajoutez un adaptateur. Le [guide de migration d’Ollama à vLLM](https://www.glukhov.org/fr/llm-hosting/comparisons/ollama-to-vllm-migration/ “Apprenez quand migrer d’Ollama à vLLM. Signaux de migration, étapes de planification, configuration Docker Compose et une liste de contrôle pratique pour déplacer votre serveur LLM local.”}) discute le même principe de contrat d’abord pour un saut d’exécutable plus important.

Verdict final

Ollama est le meilleur appareil de modèles local. Il fournit un catalogue de modèles, des recettes reproductibles, une répartition automatique judicieuse, des API pratiques et une gestion du cycle de vie sans exiger que chaque utilisateur devienne un opérateur d’inférence.

llama.cpp est l’instrument de précision meilleur. llama-server expose assez du plan d’exécution pour rendre les VRAM contraints, le long contexte, le matériel inhabituel, le support de nouveaux modèles et les expériences contrôlées compréhensibles plutôt que mystérieux.

Pour la plupart des gens, la bonne séquence n’est pas Ollama ou llama.cpp pour toujours. Commencez avec Ollama, apprenez quelles contraintes comptent réellement, et déplacez la charge de travail affectée vers llama.cpp direct lorsque vous pouvez nommer le contrôle dont vous avez besoin. C’est une raison beaucoup plus forte que de courir après un benchmark mesuré avec les valeurs par défaut de quelqu’un d’autre.

Références

• Projet llama.cpp et backends supportés
• Fonctionnalités, drapeaux, points d’accès et mode routeur de llama-server
• FAQ Ollama : contexte, keep-alive, concurrence et cache KV
• Référence Modelfile Ollama
• Importation de modèles GGUF et Safetensors dans Ollama
• Compatibilité de l’API OpenAI Ollama
• Changements GGUF, NVIDIA et Vulkan de Ollama 0.30
• Comment Ollama épinglé et corrige llama.cpp
• Support matériel d’Ollama
• Longueurs de contexte par défaut d’Ollama
• Releases Ollama (GitHub)