« Quel moteur pour faire tourner mes LLM en local ? » est devenue la question la plus posée par les équipes qui sortent du POC. La réponse courte tient en une phrase : cela dépend entièrement de votre profil de charge. À un seul utilisateur, les cinq runtimes que nous comparons ici tapent les mêmes noyaux matmul et finissent à quelques pourcents les uns des autres. Dès que vous poussez de la concurrence, l'écart explose et seuls deux ou trois moteurs tiennent la route. Cet article tranche, chiffres 2026 à l'appui, sans le marketing habituel.
Le grand bouleversement 2026 : TGI est mort
Commençons par la nouvelle qui simplifie le débat. Le 21 mars 2026, Hugging Face a basculé Text Generation Inference (TGI) en mode maintenance. Le projet redirige désormais explicitement les nouveaux utilisateurs vers vLLM, SGLang, llama.cpp et MLX. Vos déploiements TGI existants continuent de fonctionner, mais pour tout nouveau projet, TGI n'est plus dans le chemin de recommandation. On le garde dans le comparatif parce qu'il reste massivement déployé, et parce qu'il avait un atout que vLLM peine encore à égaler (voir plus bas), mais le verdict est clair : ne démarrez plus dessus.
À un utilisateur, tout le monde se vaut (ou presque)
C'est le point que les benchmarks marketing oublient toujours de souligner. À batch size 1, sur un prompt court, vLLM et Ollama sont à 2-10 % l'un de l'autre pour le même modèle et la même quantization. Sur une RTX 4090 avec un modèle 24B, les cinq runtimes tournent autour de 30 tok/s. C'est logique : à batch 1, tout le monde finit sur les mêmes kernels GPU.
Un benchmark indépendant sur Llama 3.1 8B (RTX 4090, un seul utilisateur) donne Ollama à ~62 tok/s en Q4_K_M, vLLM à 71 tok/s en FP16 et 68 en AWQ. L'écart de 13 % vient autant de la quantization que de l'architecture. Moralité : si vous servez une poignée de requêtes séquentielles, le moteur le plus simple gagne, parce qu'il n'apporte aucun gain de débit réel. C'est exactement le cas du dev local, du prototypage, des outils internes mono-utilisateur.
En charge concurrente, vLLM écrase tout
Le tableau change radicalement dès qu'on empile les requêtes simultanées. C'est là que le continuous batching et la PagedAttention de vLLM font la différence.
- 10 utilisateurs concurrents (Llama 3.1 8B FP16) : vLLM agrège les requêtes et soutient ~485 tok/s cumulés, là où Ollama reste à ~148 tok/s (file FIFO quasi séquentielle). Soit un facteur 3,3 dû à un seul choix d'architecture.
- 50 utilisateurs : vLLM tient ~920 tok/s, Ollama plafonne à ~155 tok/s.
- Le benchmark Red Hat le plus cité : vLLM à 793 tok/s contre 41 tok/s pour Ollama sur le même matériel, soit un écart proche de 19×.
Côté étude évaluée par les pairs (arXiv, 2511.17593), sur LLaMA-2-7B à 100 requêtes concurrentes, vLLM atteint 15 243 tok/s contre 4 156 pour TGI (3,67×), et l'écart grimpe jusqu'à 24× sous charge extrême (200 requêtes). Sur du 70B en parallélisme tensoriel 4 GPU, l'avantage retombe à 2,1× — l'overhead de communication réduit le gap.
Pourquoi Ollama s'effondre ? Il n'implémente ni PagedAttention ni continuous batching. Au-delà de 5-8 requêtes simultanées, la latence P95 explose et la file s'allonge. Ollama alloue le cache KV statiquement par requête ; vLLM le découpe en pages non-contiguës allouées à la demande, réduisant le gaspillage mémoire de 19-27 % et gardant le GPU à 85-92 % d'utilisation.
L'angle mort de vLLM : les très longs prompts
Un détail honnête trop souvent passé sous silence : avant sa mise en maintenance, TGI v3 traitait ~3× plus de tokens et jusqu'à 13× plus vite que vLLM sur les prompts très longs (>200 000 tokens) grâce au prefix caching. Une réponse servie en 27,5 s par vLLM tombait à ~2 s sous TGI v3. Si votre workload, c'est des conversations à historique géant, vérifiez le prefix caching de votre moteur avant de conclure.
CPU et Apple Silicon : le terrain de llama.cpp et LM Studio
Sur CPU pur, llama.cpp est le plus rapide : implémentation C/C++ sans dépendances, quantization GGUF, support matériel le plus large du marché (CUDA, ROCm/HIP, Vulkan, Metal, et même Moore Threads via MUSA). C'est le moteur des machines sans GPU dédié, de l'edge, du CPU+GPU hybride où une partie du modèle vit en VRAM et le reste en RAM système. Pour le détail des arbitrages mémoire, voir notre calcul VRAM/RAM pour faire tourner un LLM local.
Sur Apple Silicon, le backend MLX d'Apple est typiquement 30 à 50 % plus rapide que llama.cpp sur Metal, car il parle directement au GPU et au Neural Engine. LM Studio en a fait son argument phare : moteur MLX unifié, navigateur de modèles Hugging Face qui affiche la VRAM estimée et le niveau de quant avant téléchargement, RAG hors-ligne, support MCP, et un serveur API compatible OpenAI sur localhost:1234. Pour mémoire, LM Studio et Ollama encapsulent tous deux llama.cpp sous le capot — l'écart de débit entre eux est généralement sous les 5 %. Ce comparatif est pertinent quel que soit votre matériel : Mac Studio M4 Max vs M3 Ultra pour la mémoire unifiée, AMD Strix Halo Ryzen AI Max 395 côté iGPU, ou NVIDIA DGX Spark pour le desktop.
Quantization : le bon format pour le bon moteur
Règle d'or 2026 souvent ignorée : le GGUF se lance dans llama.cpp, pas dans vLLM. En vLLM, le GGUF préserve bien la qualité (perplexité 6,74) mais plafonne à ~93 tok/s. Sur GPU, les meilleurs formats pour vLLM sont :
- FP8 (W8A8) sur Hopper/Ada (H100, RTX 40xx) : -2× de mémoire, jusqu'à +1,6× de débit, perte de précision minime. Le défaut par défaut sur matériel récent.
- AWQ INT4 avec noyaux Marlin : le meilleur compromis qualité/vitesse. Marlin apporte jusqu'à 10,9× d'accélération sur AWQ et 2,6× sur GPTQ. La combo Marlin-AWQ atteint 741 tok/s avec la meilleure qualité (51,8 % Pass@1) dans les tests.
- GPTQ INT4 : légèrement en dessous d'AWQ en qualité, mais énorme écosystème de modèles pré-quantifiés.
Côté llama.cpp/GGUF, le sweet spot reste Q4_K_M pour le décode CPU. Pour caser un ~50B sur 16 Go de VRAM, passez en IQ3_S ou Q3_K_M avec offload CPU ; pour du quasi-lossless, Q8_0. Et rappelez-vous : les bits ne font pas tout — un Q4_K_M bien conçu bat un format 5-bit legacy naïf.
API compatible OpenAI : la portabilité comme assurance
Bonne nouvelle : les cinq exposent un endpoint compatible OpenAI (/v1/chat/completions, /v1/completions). Migrer d'un moteur à l'autre ne touche souvent qu'une variable d'environnement BASE_URL. Les frictions restantes sont le format de modèle (Ollama utilise des tags comme llama3:8b, vLLM des repo IDs Hugging Face comme meta-llama/Llama-3.1-8B-Instruct ; on ne pointe pas vLLM sur un .gguf) et la complétude : l'implémentation vLLM est la plus complète (logprobs, structured output via guided decoding). Pour brancher tout ça à vos outils de dev, voir intégrer Ollama à Codex, Claude et OpenClaw en local.
Verdict : le bon outil pour le bon étage
- Ollama — un modèle qui tourne en moins de 5 minutes, DX imbattable, headless containerisable. Parfait en dev/staging et outils internes. Ne passe pas l'échelle au-delà de ~5-8 utilisateurs.
- LM Studio — l'entrée par la GUI : Mac avec MLX sans toucher au terminal, ou Windows/AMD iGPU où son offload Vulkan bat le chemin CUDA-only d'Ollama. Bémol : l'app GUI est closed-source (bloquant pour les déploiements souverains/audités — Jan.ai en alternative).
- llama.cpp — CPU, edge, hybride CPU+GPU, contrôle total des flags, matériel exotique. Le couteau suisse bas niveau.
- vLLM — le défaut de production. En cas de doute, c'est lui : le plus déployé, le plus compatible matériel, 3-20× le débit d'Ollama en concurrence. Le seul angle mort réel = les prompts >200k tokens.
- TGI — à éviter pour tout nouveau projet (maintenance depuis mars 2026).
Le pattern gagnant des équipes matures : Ollama/LM Studio en local et CI, vLLM en prod, tous derrière le même protocole OpenAI. Un seul piège à surveiller : la dérive de quantization. Votre Ollama de dev tourne sans doute en Q4 4-bit, votre vLLM de prod en FP16 ou FP8 — le comportement diffère subtilement. Épinglez le même quant des deux côtés. Et défiez toujours ces chiffres : benchmarkez sur votre matériel, votre modèle, votre concurrence réelle.
Commentaires