L’écosystème des LLM locaux n’a pas besoin d’Ollama

• Ollama a d’abord été un outil pionnier pour simplifier l’exécution de LLM en local, mais a ensuite perdu la confiance de la communauté à cause de la dissimulation de ses sources et de son virage vers une approche centrée sur le cloud
• En minimisant le mérite de llama.cpp, son moteur principal, puis en basculant vers son propre backend ggml, le projet a subi une baisse de performances et la réintroduction de bugs
• Les critiques se sont poursuivies à cause d’une présentation trompeuse des noms de modèles, de la distribution d’applications GUI fermées et d’une structure Modelfile inefficace
• Un goulot d’étranglement dans le registre de modèles, des failles de sécurité et une logique de vendor lock-in entrent en conflit avec la philosophie du local-first
• Des alternatives open source comme llama.cpp, LM Studio, Jan offrent déjà de meilleures performances et davantage de transparence, et occupent désormais une place centrale dans l’écosystème des LLM locaux

---

Les problèmes d’Ollama et les alternatives dans l’écosystème des LLM locaux

• Origines d’Ollama et rôle initial

  • Ollama s’est fait remarquer comme le premier wrapper de llama.cpp simplifiant l’exécution de LLM en local
    • Les utilisateurs pouvaient exécuter des modèles sans compiler du C++ eux-mêmes ni configurer un serveur
  • Par la suite, le projet a masqué ses sources, induit les utilisateurs en erreur et s’est éloigné de la philosophie centrée sur le local pour évoluer vers une structure orientée cloud soutenue par du capital-risque
  • Les fondateurs sont Jeffrey Morgan et Michael Chiang, connus auparavant pour avoir développé Kitematic, une interface GUI pour Docker ensuite rachetée par Docker Inc.
  • Issu de Y Combinator (W21), le projet a été lancé publiquement en 2023 avec la promesse d’être le « Docker for LLMs »

• Attribution insuffisante à llama.cpp

  • Les capacités d’inférence d’Ollama reposent entièrement sur llama.cpp de Georgi Gerganov
  • Pendant plus d’un an, ni le README, ni le site web, ni les supports marketing ne mentionnaient llama.cpp, et même l’avis de licence MIT manquait
  • L’issue communautaire demandant le respect de la licence (#3185) est restée sans réponse pendant plus de 400 jours
  • Par la suite, un cofondateur a seulement ajouté en bas du README une ligne indiquant « llama.cpp project founded by Georgi Gerganov »
  • L’équipe d’Ollama a affirmé « nous réalisons beaucoup de patchs et nous allons progressivement basculer vers notre propre moteur », minimisant ainsi délibérément le crédit dû

Passage à un backend maison et baisse de performances

• Adoption d’un backend personnalisé basé sur ggml

  • Mi-2025, Ollama a quitté llama.cpp pour une implémentation maison basée sur ggml
  • Le changement a été justifié par des raisons de stabilité, mais a en pratique réintroduit des bugs déjà corrigés
  • De nombreux problèmes sont apparus : erreurs de sortie structurée, échecs sur les modèles de vision, plantages liés à des assertions GGML
  • Des modèles récents comme GPT-OSS 20B ne fonctionnaient pas ou rencontraient des problèmes de types de tenseurs non pris en charge
  • Gerganov a lui-même indiqué qu’Ollama avait mal forké ggml

• Résultats des comparaisons de performances

  • Dans des benchmarks communautaires, llama.cpp est 1,8 fois plus rapide qu’Ollama (161 contre 89 tokens/s)
  • Sur CPU aussi, l’écart de performances atteint 30 à 50 %
  • Lors d’un test sur Qwen-3 Coder 32B, llama.cpp a montré un débit supérieur de 70 %
  • Les causes avancées sont la structure en daemon d’Ollama, un offloading GPU inefficace et un backend obsolète

Présentation trompeuse des noms de modèles

• Cas de DeepSeek-R1

  • Ollama désigne des modèles distillés comme DeepSeek-R1-Distill-Qwen-32B simplement sous le nom « DeepSeek-R1 »
  • Il ne s’agit pourtant pas du véritable modèle à 671B de paramètres
  • Des utilisateurs ont ainsi cru avoir « exécuté DeepSeek-R1 en local », ce qui a porté atteinte à la réputation de DeepSeek
  • Les issues GitHub correspondantes (#8557, #8698) ont toutes été marquées comme doublons puis laissées sans résolution
  • Aujourd’hui encore, ollama run deepseek-r1 lance un modèle distillé

Lancement d’applications fermées

• Distribution non publique de l’application GUI

  • En juillet 2025, l’application GUI Ollama pour macOS et Windows a été publiée
  • Elle a été développée dans un dépôt privé puis distribuée sans licence, avec code source non publié
  • Pour un projet qui entretenait jusque-là une image open source, cela a représenté un virage brutal vers le fermé
  • La communauté a soulevé des soupçons de dépendances AGPL-3.0 et des inquiétudes de violation de licence
  • Le site plaçait un bouton de téléchargement à côté du lien GitHub, donnant l’impression qu’il s’agissait d’un projet open source
  • Après plusieurs mois de silence, l’application n’a été fusionnée dans le dépôt principal qu’en novembre 2025
  • XDA a critiqué le fait qu’« un projet se présentant comme open source devrait clairement indiquer ce qui est public ou non »

L’inefficacité de Modelfile

• Redondance avec le format GGUF

  • Le format GGUF contient déjà dans un seul fichier toutes les informations nécessaires à l’exécution d’un modèle
  • Ollama y ajoute un fichier de configuration distinct, Modelfile, à la structure proche d’un Dockerfile
  • Cela redéfinit des informations déjà présentes dans GGUF et crée une complexité inutile
  • Ollama ne reconnaît automatiquement qu’une liste de templates codés en dur, les nouveaux templates étant ignorés
  • Résultat : le format des instructions du modèle est cassé et l’utilisateur doit convertir manuellement

• Modification inefficace des paramètres

  • Pour modifier des paramètres, il faut extraire avec ollama show --modelfile, modifier, puis recréer avec ollama create
  • Ce processus implique une copie complète du modèle de 30 à 60 Go
  • La communauté dénonce cela comme une « duplication inefficace et inutile »
  • Avec llama.cpp, les paramètres peuvent être ajustés simplement via des arguments en ligne de commande

• Problèmes de compatibilité des templates

  • Ollama utilise la syntaxe de templates Go, différente des templates Jinja utilisés par les créateurs de modèles
  • LM Studio et llama.cpp prennent directement en charge Jinja, alors qu’Ollama impose une conversion
  • De nombreux problèmes de format de conversation cassé dus à des erreurs de conversion ont été signalés

Goulot d’étranglement du registre de modèles

• Retard dans l’enregistrement des modèles

  • Même lorsqu’un nouveau modèle est publié sur Hugging Face, il ne devient utilisable dans Ollama qu’après packaging et enregistrement manuels par l’équipe
  • Les formats de quantification pris en charge restent limités à Q4_K_M, Q8_0, etc.
  • Il en résulte un délai entre la sortie du modèle et son utilisation dans Ollama
  • Dans la communauté, des messages PSA se sont diffusés conseillant : « pour tester les nouveaux modèles, utilisez llama.cpp ou vLLM »

• Contraintes sur les quantifications

  • Ollama ne prend pas en charge les familles Q5, Q6 et IQ
  • Même quand les utilisateurs en font la demande, la réponse est de recourir à d’autres outils
  • La commande ollama run hf.co/{repo}:{quant} permet désormais d’appeler directement Hugging Face, mais les modèles sont encore copiés dans un stockage interne à base de hash sans possibilité de partage, et les problèmes de templates persistent

Virage vers le cloud et problèmes de sécurité

• Introduction de modèles cloud

  • Fin 2025, Ollama a ajouté des modèles hébergés dans le cloud
  • Bien qu’il s’agisse à l’origine d’un outil centré sur le local, certains modèles envoient les prompts vers des serveurs externes
  • Avec des modèles tiers comme MiniMax, les données peuvent être transmises à l’extérieur
  • Ollama précise « ne pas stocker les logs », mais les politiques des tiers restent floues
  • Dans le cas de modèles basés sur Alibaba Cloud, aucune garantie de conservation des données n’est donnée

• Failles de sécurité

  • CVE-2025-51471 : vulnérabilité permettant à un serveur de registre malveillant de voler des jetons d’authentification
  • Un correctif en PR existait, mais n’a pas été intégré pendant plusieurs mois
  • Pour un outil mettant en avant la confidentialité locale comme valeur clé, il s’agit d’un problème structurel grave

Une structure guidée par le capital-risque

• Un schéma qui se répète

  • Envelopper un projet open source pour acquérir une base d’utilisateurs → lever des fonds → passer à la monétisation
  • Les étapes suivies par Ollama
    • démarrage en open source, sur une base llama.cpp
    • minimisation des sources, présentation comme produit indépendant
    • incitation au lock-in via le registre de modèles et le format
    • sortie d’une GUI fermée
    • introduction de services cloud pour monétiser

• Mécanisme de vendor lock-in

  • Ollama stocke les modèles sous des noms de fichiers hashés, difficiles à réutiliser avec d’autres outils
  • Il est possible d’importer des GGUF, mais l’export est conçu de manière peu pratique
  • Les utilisateurs se retrouvent ainsi captifs de l’écosystème Ollama

Outils alternatifs

• llama.cpp

  • Fournit un serveur API compatible OpenAI (llama-server), une interface web, un contrôle fin des paramètres et un débit élevé
  • En février 2026, ggml.ai a rejoint Hugging Face, renforçant la durabilité du projet
  • Le projet est sous licence MIT et compte plus de 450 contributeurs

• Autres alternatives

  • llama-swap : prise en charge du chargement multi-modèles et du hot swap
  • LiteLLM : proxy compatible OpenAI entre plusieurs backends
  • LM Studio : interface GUI, basée sur llama.cpp, avec compatibilité GGUF complète
  • Jan, Msty : applications desktop open source conçues selon une approche local-first
  • koboldcpp, Red Hat ramalama : exécution de modèles orientée conteneurs, avec attribution claire des sources

Conclusion : la direction de l’écosystème des LLM locaux

• llama.cpp de Georgi Gerganov constitue la base de l’innovation en IA locale
  • Grâce à la collaboration communautaire, il permet d’exécuter de puissants modèles même sur du matériel grand public
• Ollama a grandi sur cette base, mais a perdu la confiance de la communauté à cause de la dissimulation des sources, de la baisse de qualité, de la fermeture du projet et du virage cloud
• Ce dont l’écosystème des LLM locaux a besoin, ce n’est pas d’Ollama, mais de llama.cpp
  • La véritable ouverture et les performances sont déjà assurées par des outils centrés sur la communauté

[shblue21]

Je suis plutôt d’accord, et pour un usage vraiment correct en local, j’ai l’impression que LM Studio est meilleur.

[kirinonakar]

J’ai moi aussi commencé avec Ollama au début, mais cela fait déjà longtemps que je suis passé à LM Studio ces derniers temps.

[GN⁺]

Avis Hacker News

• La plupart des utilisateurs de LLM locaux estiment que Ollama a résolu les problèmes d’UX
  On peut lancer un modèle avec une seule commande, et les pilotes ROCm sont aussi gérés automatiquement
  À l’inverse, llama.cpp sonne dès son nom comme une bibliothèque C++, ce qui le rend difficile d’accès pour l’utilisateur moyen
  Je n’ai pas envie de compiler moi-même un programme, je veux juste m’amuser avec

  • Désormais, llama.cpp inclut une GUI par défaut. Ce n’était pas le cas avant, mais l’époque a changé
  • Il existe beaucoup d’alternatives comme « LM Studio, Jan, Msty, koboldcpp… », mais je me demande quel est le véritable successeur capable de remplacer Ollama
    J’utilise un Mac Mini, mais un outil CLI me va aussi. La force d’Ollama, c’était la simplicité de l’installation et du téléchargement des modèles, donc j’attends un niveau de confort comparable d’un outil de remplacement
  • Suggestion : kobold.cpp ou LM Studio. LM Studio n’est pas open source, mais attribue correctement le mérite à llama.cpp
    Je pense que le contrôle qualité est important pour éviter d’intégrer un support de modèle cassé ou de téléverser des GGUF incorrects
  • D’accord. C’est une situation semblable à Docker
    Bien sûr, on peut utiliser runc directement, mais la plupart des gens choisissent docker run
    L’UX est un facteur clé de l’adoption technologique, et si un projet ne sait pas bien concevoir son interface, il n’y a rien de mal à créer un wrapper
  • Le fait qu’Ollama ait résolu un problème d’UX n’excuse pas une violation de licence

• Fatigué de répéter toujours le même argument, quelqu’un a rassemblé en une fois la chronologie et les sources qu’il connaissait

  • Merci d’avoir écrit cet article. J’ai moi aussi un peu contribué à llama.cpp, et le comportement des fondateurs d’Ollama a vraiment été décevant
    Comme alternative, je recommande llama-file. llamafile de Mozilla AI fonctionne comme un exécutable unique quel que soit l’OS, et c’est totalement open source
    Il repose sur CosmopolitanC créé par Justine Tunney, et utilise officiellement llama.cpp
  • Pour quelqu’un qui attache de l’importance à l’esprit du FOSS, c’était un article très instructif
  • Beaucoup disent y avoir appris des choses qu’ils ignoraient
  • Le résumé et la chronologie sont jugés excellents

• Ollama est 1000 fois meilleur en facilité d’usage
  llama.cpp est excellent, mais peu accueillant pour l’utilisateur lambda
  J’ai commencé avec Ollama, puis je suis passé à llama.cpp pour profiter des derniers correctifs
  Malgré tout, j’utilise encore Ollama pour gérer les modèles. C’est tellement pratique que j’ai fini par créer mes propres scripts pour gérer le répertoire de cache

  • Le billet de blog disait que les alternatives étaient intuitives, mais en pratique ce n’est pas le cas
    Pour une simple appli de chat, peut-être, mais dès qu’on a besoin d’une API compatible OpenAI et de la gestion des modèles, l’accessibilité chute brutalement
  • Beaucoup se plaignaient que la taille de contexte par défaut d’Ollama était trop petite, ce qui rendait les modèles idiots
    Pour la modifier de façon persistante, il fallait créer un nouveau fichier de modèle, ce qui était encore plus compliqué
    L’approche à la Docker est au contraire peu pratique pour l’utilisateur ordinaire, et les utilisateurs avancés seront mieux servis par llama.cpp
  • À noter que llama.cpp dispose maintenant d’un mode router, qui permet de changer de modèle à chaud
  • Les versions récentes sont devenues bien plus puissantes. Voir llama.cpp tools/serv
  • J’utilise LM Studio depuis 3 ans, et même à l’époque c’était déjà bien meilleur qu’Ollama

• Deux visions de la licence MIT sont résumées

  1. « Une ligne de crédit, et tout est permis »
  2. « C’est libre juridiquement, mais il existe une responsabilité morale envers la communauté »
     Le créateur de llama.cpp, Georgi Gerganov, n’a exprimé son mécontentement qu’au sujet de l’absence de crédit. Autrement dit, son attitude se rapproche de la première interprétation
  • La seconde interprétation n’a pas de sens selon certains. Si l’on veut des obligations de type GPL, il suffit d’utiliser la GPL
    La MIT est un document juridique, pas un guide moral
    Personnellement, je pense qu’il vaut mieux utiliser la GPL pour les logiciels destinés aux utilisateurs finaux
    Choisir la MIT puis se plaindre qu’une entreprise reprenne le code est contradictoire
    Les entreprises n’ont pas de morale ; seules les personnes en ont, selon eux
  • Si Georgi l’avait voulu, il aurait pu passer en GPL à tout moment. Mais il ne l’a pas fait
    Au final, les deux projets ont continué à progresser, et les utilisateurs ont gagné davantage de choix

• Autrefois, c’était pénible parce qu’on ne pouvait pas changer le dossier de modèles par défaut
  Pour enregistrer un modèle, il fallait passer par une procédure proche d’un Dockerfile, et le modèle était copié dans un stockage haché sans possibilité de changer son emplacement
  C’est pour cela que certains sont passés à LM Studio. Ce n’est pas entièrement open source, mais il expose le dossier des modèles et s’intègre à Hugging Face

  • C’est possible maintenant. On peut définir le chemin via la variable d’environnement OLLAMA_MODELS dans le fichier de configuration du serveur
  • J’ai moi aussi souffert de ce problème. Je voulais comparer LM Studio avant et après une mise à niveau SSD, mais le simple fait de retrouver et d’organiser l’emplacement des modèles était inutilement complexe et pénible

• À cause de la structure où Ollama copie les fichiers de modèle dans un stockage blob haché, il est impossible de les partager avec d’autres outils
  C’est sans doute pensé pour la déduplication, mais au final cela complique l’essai d’autres outils
  Comme les fichiers de modèles sont énormes, l’espace de stockage et les téléchargements deviennent une lourde contrainte

• Sur Arch Linux, pacman -Ss ollama renvoie 16 résultats, mais llama.cpp ou lmstudio n’en renvoient aucun
  Espérons que cela change un jour

  • llama.cpp évolue trop vite pour un paquet stable, mais il peut être installé via l’AUR
    Les versions Vulkan, ROCm et CUDA sont toutes prises en charge
  • À l’inverse, sur openSUSE, on peut trouver llamacpp avec zypper
    Les versions et le support diffèrent selon les distributions, et cela explique au fond pourquoi il existe tant de distributions Linux
  • Sur CachyOS, je l’ai installé avec yay -S llama.cpp, et c’était bien plus rapide et meilleur qu’Ollama

• Le nom « llama.cpp » paraît désormais peu accueillant
  Autrefois, il renvoyait au modèle Llama de Meta, mais aujourd’hui il existe beaucoup de modèles open source plus puissants

  • Mais Ollama a en réalité le même problème
    Aujourd’hui, « Local LLaMA » sert presque de nom générique pour l’exécution locale de modèles
  • Si l’on regarde la liste Wikipédia des marques généricisées, on voit que ce phénomène est courant

• Ollama donnait dès le départ l’impression de vouloir contrôler l’ensemble du workflow, ce qui a poussé certains à l’éviter
  Avec le recul, ils estiment que c’était la bonne décision

• La structure de stockage en blobs hachés d’Ollama est le principal piège
  Si on télécharge des modèles depuis des mois, il faut tout retélécharger pour passer à un autre outil
  La plupart des utilisateurs ne s’en rendent compte qu’après avoir déjà beaucoup investi, et ressentent alors fortement le coût de sortie