Technique
L’écart entre la commodité et la maîtrise.
Ollama est le projet le plus populaire pour faire tourner des LLM en local. Tous les tutos en parlent. Et pourtant, je n’en veux pas chez moi. Voici pourquoi.
Ce qu’Ollama résout bien
L’onboarding. Trois commandes et vous avez un Llama 3 qui tourne. Pour quelqu’un qui découvre les LLM locaux, c’est parfait. Pour quelqu’un qui veut juste essayer, idem.
Ce qu’Ollama abstrait trop
Le runtime exact. Ollama emballe llama.cpp dans une interface unifiée, mais cache les paramètres importants (taille du contexte, layers GPU, quantization choisie, threads CPU, prompt template). Le jour où votre modèle hallucine ou tourne trop lentement, vous ne savez pas par où commencer parce que ces paramètres sont gérés “pour vous”.
La gestion des modèles. Ollama télécharge les modèles dans un format propriétaire (.ollama) qui n’est pas un GGUF standard. Si demain vous voulez migrer vers llama.cpp direct, vLLM, ou un autre runtime, vos modèles téléchargés ne sont pas réutilisables tels quels.
Le serveur HTTP. Ollama expose un serveur sur le port 11434, ce qui crée une dépendance forte sur sa CLI et son API. Tout votre code applicatif appelle Ollama. Si vous voulez changer de runtime, il faut tout réécrire.
Mon choix : llama-cpp-python direct
J’utilise llama-cpp-python dans un environnement Python virtuel, qui charge directement un fichier GGUF récupéré de Hugging Face. C’est plus brut, plus exigeant à configurer au départ, mais :
- Je vois et je contrôle tous les paramètres (n_ctx, n_threads, n_gpu_layers, temperature, repeat_penalty, etc.)
- Mes modèles GGUF sont des fichiers standards, réutilisables avec d’autres runtimes
- Mon code applicatif appelle directement la fonction Python, pas un serveur HTTP intermédiaire
- Quand quelque chose ne fonctionne pas, je peux lire le code source du runtime sans abstraction Ollama-spécifique
Le principe sous-jacent
Cette décision illustre un principe plus large que j’applique partout : quand un outil abstrait quelque chose, il faut savoir ce qu’il abstrait et pouvoir s’en passer le jour où on en aura besoin. Ollama abstrait trop, et son écosystème vous lock-in à mesure que vous bâtissez du code par-dessus. Trois mois de développement basés sur Ollama, c’est trois mois de code à refaire si vous voulez migrer.
Ce n’est pas qu’Ollama est mauvais — c’est qu’il est mauvais pour mon cas d’usage (outil professionnel intégré dans un agent custom). Pour quelqu’un qui veut juste essayer un LLM local depuis une CLI, Ollama est probablement le bon choix.