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é