Pourquoi le choix du runtime d'inférence change tout

Quand on parle d'auto-hébergement de LLM, on confond souvent deux décisions distinctes : le format du modèle et le runtime qui l'exécute. Un modèle Mistral 7B quantisé en GGUF ne se comporte pas de la même façon selon qu'il tourne dans Ollama, dans llama.cpp en direct ou dans vLLM avec un backend CUDA. Les performances, la compatibilité API et la charge mémoire varient radicalement. Avant de brancher votre workflow n8n ou votre agent sur un endpoint local, il faut donc poser la bonne question : quel est le profil de charge réel ?

Ollama : la solution raisonnable pour le développement et les usages mono-utilisateur

Ollama s'installe en une commande, expose une API REST compatible OpenAI sur le port 11434 et gère seul le téléchargement des modèles au format GGUF depuis son registre. C'est le choix évident pour un développeur qui veut itérer vite sur un Mac avec Apple Silicon ou une machine Windows avec un GPU milieu de gamme. llama.cpp tourne sous le capot, ce qui permet d'exploiter le Metal sur macOS ou CUDA sur NVIDIA sans configuration manuelle.

Ses limites deviennent visibles dès qu'on monte en charge. Ollama traite les requêtes de façon séquentielle par défaut. Sur un seul utilisateur ou dans un pipeline automatisé à faible fréquence, c'est suffisant. Dès qu'on multiplie les appels parallèles depuis un orchestrateur comme n8n avec plusieurs workers, les requêtes se mettent en file et la latence grimpe. Pour ce type d'usage, le paramètre OLLAMA_NUM_PARALLEL peut aider, mais il ne résout pas le problème de fond : Ollama n'est pas conçu pour le batching de requêtes.

  • Formats supportés : GGUF uniquement via llama.cpp
  • API : compatible OpenAI Chat Completions et Generate
  • Matériel : CPU, Apple Silicon (Metal), NVIDIA (CUDA), AMD (ROCm expérimental)
  • Cas d'usage idéal : prototypage, usage local, intégration dans un workflow à faible concurrence
  • Modèles disponibles en un pull : Mistral, Llama 3, Phi-3, Gemma 2, Qwen 2.5

vLLM : le runtime de production pour les charges concurrentes

vLLM est un projet Berkeley conçu spécifiquement pour maximiser le débit d'inférence sur GPU NVIDIA. Son innovation centrale s'appelle PagedAttention : elle gère la mémoire KV-cache comme un OS gère la mémoire virtuelle, ce qui permet de traiter plusieurs requêtes simultanées sans exploser la VRAM. Le résultat concret : sur un A100, vLLM peut atteindre 10 à 20 fois le débit d'une inférence naïve avec HuggingFace Transformers.

vLLM expose également une API compatible OpenAI, ce qui rend la migration depuis Ollama triviale côté client. Il supporte les modèles au format Safetensors et GGUF depuis la version 0.4, et prend en charge le function calling, les embeddings et le streaming. Pour un déploiement multi-agents où plusieurs nœuds d'un workflow interrogent le même LLM en parallèle, vLLM est le bon choix. L'inconvénient : il nécessite Python, un GPU NVIDIA avec au moins 16 Go de VRAM pour des modèles 7B en précision complète, et une configuration plus explicite.

  • Formats supportés : Safetensors (natif), GGUF (depuis 0.4), AWQ, GPTQ
  • Concurrence : batching continu, plusieurs requêtes traitées simultanément
  • Cas d'usage idéal : API partagée entre plusieurs agents, production, benchmarking de débit
  • Prérequis matériels : GPU NVIDIA, CUDA 11.8 minimum, 16 Go VRAM conseillés
  • Alternative légère sur CPU ou GPU modeste : llama.cpp server en mode standalone

Méthode de décision : trois questions avant de choisir

Première question : avez-vous un GPU NVIDIA avec suffisamment de VRAM ? Si la réponse est non, vLLM ne vous apportera rien et Ollama reste le chemin le plus direct. Deuxième question : combien de requêtes parallèles votre système va-t-il générer ? En dessous de cinq requêtes simultanées, Ollama avec OLLAMA_NUM_PARALLEL suffit largement. Au-delà, le batching de vLLM devient un avantage mesurable. Troisième question : avez-vous besoin de modèles en précision BF16 ou FP16 pour maintenir la qualité des sorties ? Les quantisations GGUF Q4 d'Ollama dégradent parfois les capacités de raisonnement sur des tâches complexes ; vLLM avec un modèle Safetensors en 8 bits AWQ offre un meilleur compromis qualité-mémoire sur ces cas précis. Dans un workflow d'automatisation mature, rien n'empêche de faire coexister les deux : Ollama pour les tests rapides en local et un endpoint vLLM pour l'environnement de production partagé entre vos agents.