Technique<\/p>\n
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.<\/p>\n
L’onboarding. Trois commandes et vous avez un Llama 3 qui tourne. Pour quelqu’un qui d\u00e9couvre les LLM locaux, c’est parfait. Pour quelqu’un qui veut juste essayer, idem.<\/p>\n
Le runtime exact. Ollama emballe La gestion des mod\u00e8les. Ollama t\u00e9l\u00e9charge les mod\u00e8les dans un format propri\u00e9taire ( Le serveur HTTP. Ollama expose un serveur sur le port 11434, ce qui cr\u00e9e une d\u00e9pendance forte sur sa CLI et son API. Tout votre code applicatif appelle Ollama. Si vous voulez changer de runtime, il faut tout r\u00e9\u00e9crire.<\/p>\n J’utilise Cette d\u00e9cision 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\u00f9 on en aura besoin.<\/em> Ollama abstrait trop, et son \u00e9cosyst\u00e8me vous lock-in \u00e0 mesure que vous b\u00e2tissez du code par-dessus. Trois mois de d\u00e9veloppement bas\u00e9s sur Ollama, c’est trois mois de code \u00e0 refaire si vous voulez migrer.<\/p>\n Ce n’est pas qu’Ollama est mauvais \u2014 c’est qu’il est mauvais pour mon cas d’usage (outil professionnel int\u00e9gr\u00e9 dans un agent custom). Pour quelqu’un qui veut juste essayer un LLM local depuis une CLI, Ollama est probablement le bon choix.<\/p>","protected":false},"excerpt":{"rendered":" Technique L’\u00e9cart entre la commodit\u00e9 et la ma\u00eetrise. 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\u00e9sout bien L’onboarding. Trois commandes et vous avez un Llama 3 qui tourne. Pour quelqu’un qui […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-61","post","type-post","status-publish","format-standard","hentry","category-non-classe"],"yoast_head":"\nllama.cpp<\/code> dans une interface unifi\u00e9e, mais cache les param\u00e8tres importants (taille du contexte, layers GPU, quantization choisie, threads CPU, prompt template). Le jour o\u00f9 votre mod\u00e8le hallucine ou tourne trop lentement, vous ne savez pas par o\u00f9 commencer parce que ces param\u00e8tres sont g\u00e9r\u00e9s “pour vous”.<\/p>\n.ollama<\/code>) qui n’est pas un GGUF standard. Si demain vous voulez migrer vers llama.cpp<\/code> direct, vLLM<\/code>, ou un autre runtime, vos mod\u00e8les t\u00e9l\u00e9charg\u00e9s ne sont pas r\u00e9utilisables tels quels.<\/p>\nMon choix : llama-cpp-python direct<\/h3>\n
llama-cpp-python<\/code> dans un environnement Python virtuel, qui charge directement un fichier GGUF r\u00e9cup\u00e9r\u00e9 de Hugging Face. C’est plus brut, plus exigeant \u00e0 configurer au d\u00e9part, mais :<\/p>\n\n
Le principe sous-jacent<\/h3>\n