Ollama vs LocalAI : quel serveur de modèles LLM auto-hébergé ?

Auto-héberger un serveur de modèles, c'est garder vos prompts et vos données sensibles hors des API commerciales, supprimer la facturation au token et fixer vous-même le modèle, sa version et son quantization. Sur un VPS, vous exposez une API privée à vos applications internes (chatbots, RAG, assistants de code) sans aucune fuite vers l'extérieur. Ollama se distingue par sa simplicité radicale : une commande pour télécharger et lancer un modèle, une API propre, une gestion automatique de la mémoire. LocalAI se positionne comme un remplaçant 'drop-in' de l'API OpenAI : il expose les mêmes endpoints (chat, embeddings, images, audio) et accepte de multiples backends et formats de modèles. Le choix se joue entre expérience minimaliste et compatibilité la plus large possible.

Sans GPU, restez sur des modèles quantifiés légers. Un modèle 3B en GGUF Q4 tourne sur un VPS 4 vCPU et 8 Go de RAM avec une latence acceptable pour du test ; un modèle 7B/8B Q4 demande 8 à 16 Go de RAM et un bon CPU pour rester utilisable. Au-delà, en CPU pur, la latence devient prohibitive : pour du temps réel sur de gros modèles, un VPS avec GPU est indispensable. Prévoyez surtout un disque généreux : les poids de plusieurs modèles pèsent vite des dizaines de Go. Il vous faut Docker et Compose, un volume persistant pour les modèles, un sous-domaine si vous exposez l'API, et un reverse proxy avec authentification.

Avec Ollama, toute la gestion des modèles se fait via la CLI ou l'API REST. ollama pull llama3.2 télécharge la version par défaut ; ollama pull llama3.1:8b-instruct-q4_K_M tire une variante quantifiée précise depuis la bibliothèque officielle sur ollama.com/library. ollama list affiche les modèles locaux avec leur taille sur disque et leur digest. ollama run mistral lance une session interactive dans le terminal. ollama rm llama3.2 supprime un modèle pour libérer de l'espace. Avec LocalAI, la logique est différente : les modèles vivent dans le dossier /models monté dans le conteneur. Vous téléchargez un fichier GGUF (format llama.cpp) ou GPTQ et le placez dans ce répertoire ; LocalAI le charge au démarrage ou à la demande. La galerie LocalAI propose des configurations prêtes à l'emploi pour les modèles populaires. Un point pratique : Ollama gère automatiquement le déchargement des modèles inutilisés pour libérer la RAM, ce que LocalAI laisse à votre configuration.

La quantization réduit la précision des poids pour diminuer la taille du modèle et sa consommation mémoire. Les formats Q4_K_M et Q5_K_S sont les plus courants en pratique. Q4_K_M (4 bits, méthode K, taille M) offre un excellent compromis taille/qualité pour la plupart des usages : un modèle Llama 3.1 8B en Q4_K_M pèse environ 4,7 Go en RAM, contre environ 16 Go pour la version non quantifiée en FP16 (source : ollama.com/library/llama3.1). Q5_K_S monte à environ 5,5 Go mais préserve mieux la cohérence sur les longues générations. Sur un VPS 8 Go, visez les modèles 3B ou 7B en Q4 ; sur 16 Go, un 7B/8B Q5_K_M reste fluide. En CPU pur, comptez 3 à 10 tokens/s selon le modèle et le nombre de cœurs — acceptable pour un usage asynchrone, trop lent pour du streaming interactif. Avec un GPU NVIDIA, Ollama détecte automatiquement CUDA et décharge les couches sur le GPU ; même logique pour AMD (ROCm) et Apple Silicon (Metal). LocalAI offre un contrôle plus fin sur l'affectation des couches GPU via les paramètres de configuration du backend, utile quand GPU et CPU doivent se partager les couches.

Open WebUI est l'interface graphique de référence pour Ollama : elle se déploie en un conteneur Docker et se connecte à Ollama via la variable d'environnement OLLAMA_BASE_URL=http://ollama:11434. Vous obtenez un chat complet avec historique, sélection de modèle, gestion des conversations — similaire à ChatGPT mais hébergé sur votre VPS. Pour les intégrations programmatiques, Ollama expose /api/generate (génération simple) et /v1/chat/completions (compatible OpenAI). Un client Python existant se reconfigure ainsi : client = openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama'). LocalAI expose exactement la même interface OpenAI — POST /v1/chat/completions, POST /v1/embeddings, POST /v1/images/generations — ce qui permet de migrer une application existante en ne changeant que l'URL de base et la clé. Les frameworks comme LangChain, LlamaIndex ou Semantic Kernel ont tous un connecteur Ollama ou OpenAI compatible avec les deux solutions. Pour le RAG, couplez l'un ou l'autre à Weaviate, Qdrant ou Chroma : le LLM génère, le moteur vectoriel filtre les contextes pertinents, tout reste sur votre serveur.

Erreur OOM (Out of Memory) : le modèle est trop grand pour la RAM disponible. Vérifiez avec ollama list la taille réelle du modèle, réduisez la quantization (Q4 au lieu de Q5 ou Q8), ou choisissez un modèle plus petit. Si l'erreur persiste, réduisez le num_ctx (fenêtre de contexte) dans les options de génération. Modèle introuvable : avec Ollama, ollama pull peut échouer si le nom est incorrect — consultez la bibliothèque exacte sur ollama.com/library ; avec LocalAI, vérifiez que le fichier GGUF est bien dans le dossier /models et que son nom correspond à l'identifiant déclaré dans la configuration. GPU non détecté : sur un VPS avec GPU NVIDIA, Ollama nécessite le runtime NVIDIA Container Toolkit installé sur l'hôte et le paramètre runtime: nvidia dans le Compose ; vérifiez avec ollama ps que le modèle est bien déchargé sur GPU. Timeout sur longues générations : augmentez le timeout du reverse proxy (Nginx : proxy_read_timeout 300s) et celui du client. Pour un usage intensif, préférez le streaming ("stream": true) qui renvoie les tokens au fur et à mesure et évite les timeouts sur les longues réponses.

Choisissez Ollama si vous démarrez avec le self-hosted LLM, si vous voulez une expérience de développeur proche de celle d'un gestionnaire de packages, si votre cas d'usage est le prototypage rapide, un chatbot interne ou un assistant de code, ou si vous comptez connecter Open WebUI pour une interface utilisateur immédiate. Ollama gère seul les téléchargements, la quantization et la bascule CPU/GPU — aucune configuration n'est requise au-delà du Compose. Choisissez LocalAI si vous migrez une application existante qui appelle l'API OpenAI et que vous souhaitez éviter tout changement de code côté client, si vous avez besoin de modalités autres que le texte (génération d'images, TTS, STT) dans un seul conteneur, ou si vous gérez des formats de modèles variés (GPTQ, ONNX, exllama2) que le backend llama.cpp ne couvre pas seul. LocalAI demande davantage de configuration initiale mais offre plus de surface de contrôle en production.