LLM auto hébergées · 10 November 2026

Ollama, LM Studio, llama.cpp, vLLM : le grand écart des runtimes locaux en 2026

Tout le monde compare les runtimes locaux au seul thermomètre des tokens par seconde. C’est passer à côté de l’essentiel : sous le capot, quatre architectures de mémoire, de batching et de quantification radicalement différentes. Voici ce que chacune sacrifie vraiment pour tenir sur votre GPU.

Il y a une scène qui se répète sur tous les forums d’IA locale : quelqu’un demande « c’est quoi le runtime le plus rapide ? », et la discussion part en vrille sur des chiffres de tokens par seconde sortis d’un blog isolé, sans protocole, sans modèle identique, sans quantification comparable. Le débat rate systématiquement sa cible. Parce que la vraie question n’est pas « lequel va le plus vite », mais « lequel est architecturé pour ce que je veux faire ». Un dev solo qui discute avec un 8B quantifié et un petit serveur domestique qui sert trois utilisateurs simultanés n’ont pas les mêmes contraintes, et les runtimes qui les servent ont été conçus pour des cibles opposées.

En 2026, quatre familles dominent le terrain : llama.cpp, Ollama, LM Studio et vLLM. Leur généalogie explique presque tout le reste. On va donc commencer par là, avant de plonger dans le KV cache, le batching, la quantification et l’offloading — et de finir par une grille de décision honnête, sans couronner de gagnant.

Quatre runtimes, quatre philosophies : la généalogie qui explique tout le reste

llama.cpp naît en mars 2023 sous la plume de Georgi Gerganov, comme un portage en C/C++ de sa bibliothèque ggml, avec un objectif très concret : faire tourner un LLM sur un laptop, sans CUDA obligatoire, sans serveur. C’est un projet de portabilité avant tout, sous licence MIT. Tout ce qui fera sa force — quantification agressive, support Metal/CUDA/Vulkan/ROCm/SYCL, mmap des poids — découle de cette cible d’origine : le poste unique, le matériel grand public.

Ollama arrive la même année, fondé par Jeffrey Morgan et Michael Chiang. C’est un wrapper en Go autour de llama.cpp, avec une promesse marketing limpide : une commande, et ça tourne. Licence MIT également. LM Studio, édité par Element Labs, prend le chemin inverse : une application desktop (Tauri/Electron) qui embarque llama.cpp et des moteurs propriétaires, avec un runtime MLX spécifique sur Mac. Le confort avant le contrôle.

vLLM, enfin, vient d’ailleurs : c’est un projet académique de UC Berkeley, associé au papier PagedAttention publié à SOSP 2023, sous licence Apache 2.0. Sa cible n’a jamais été le laptop — c’est le datacenter, la concurrence massive, le débit agrégé. Cette origine explique pourquoi il écrase tout en charge serveur et pourquoi il est inadapté au poste unique.

Les jalons 2025-2026 (moteur V1 de vLLM, refonte du moteur Ollama, introduction de MLX dans LM Studio) et les questions de gouvernance — notamment la controverse autour du fork de llama.cpp par Ollama — restent, à ce jour, mal documentés par des sources primaires. On les signalera sans les trancher : c’est le lot de beaucoup d’affirmations qui circulent sur cet écosystème.

Le KV cache, ce poste de dépense invisible

Voici le cœur technique de tout. Quand un modèle génère du texte, il conserve en mémoire, pour chaque token déjà traité, les tenseurs Key et Value de chaque couche d’attention. C’est le KV cache. Sa taille croît linéairement avec la longueur du contexte et le nombre de tokens en vol. Sur un petit modèle avec un contexte court, c’est négligeable. Sur un 8B en contexte 32k, cela devient un poste de dépense mémoire majeur — souvent plus gros que les poids du modèle lui-même une fois quantifiés.

Deux stratégies s’opposent. L’allocation contiguë naïve, celle dont hérite llama.cpp (et donc Ollama) : une séquence = un bloc réservé à l’avance, de la taille maximale possible. Résultat, de la fragmentation et un taux d’occupation mémoire faible — le papier PagedAttention avance 20-40 %. En face, PagedAttention (vLLM) découpe la mémoire en blocs de taille fixe, gérés via une table de blocs, avec une occupation revendiquée à 90 % et plus. C’est la même idée que la pagination mémoire d’un système d’exploitation : on ne réserve que ce qu’on utilise vraiment.

Côté llama.cpp et Ollama, les leviers concrets existent : quantification du KV cache via --cache-type-k et --cache-type-v en q8_0 ou q4_0, réglage de num_ctx, et côté Ollama la variable OLLAMA_KV_CACHE_TYPE. Côté LM Studio, la quantification du KV est exposée dans l’interface, mais le moteur sous-jacent reste partiellement opaque.

Un ordre de grandeur pour un 8B en contexte 32k ? Il dépend du nombre de couches, du nombre de têtes KV, de la dimension de tête, du GQA et du dtype du cache. Aucune source primaire fournie ne permet de poser un chiffre fiable — et c’est précisément le genre de calcul qu’il faut refaire soi-même sur la documentation officielle plutôt que de recopier un chiffre de forum.

Batching et scheduling : le continuous batching change tout (ou pas)

C’est ici que vLLM creuse l’écart. Il implémente le continuous batching, le chunked prefill, le prefix caching, le speculative decoding, ainsi que le tensor et pipeline parallelism. Concrètement : au lieu de traiter les requêtes par lots figés, il insère et retire des séquences à chaque pas de décodage, ce qui maintient le GPU occupé en permanence. C’est la mécanique qui fait exploser le débit agrégé.

llama.cpp propose llama-server avec des slots parallèles (-np), un batching interne, mais l’état réel du continuous batching au sens vLLM en 2025-2026 reste à vérifier sur la documentation officielle. Ollama expose OLLAMA_NUM_PARALLEL et OLLAMA_MAX_LOADED_MODELS, avec une file d’attente dont le comportement — décrit par certaines sources tierces comme quasi séquentiel — mérite d’être confronté aux variables officielles. LM Studio offre un serveur compatible OpenAI, avec un parallélisme limité et une file d’attente.

Et là, il faut être franc sur les chiffres qui circulent. Un blog tiers (morgannriu.fr) annonce vLLM à ~793 tok/s cumulés contre ~41 tok/s pour Ollama en charge concurrente (facteur ~19) — mais le corps du même article donne ~485 tok/s contre ~148 tok/s à 10 utilisateurs (facteur ~3,3). Les deux jeux de chiffres ne peuvent pas décrire le même scénario. Aucune source primaire, aucun protocole reproductible. Il faut le dire clairement : ces chiffres ne sont pas recoupés, et le facteur réel dépend du nombre d’utilisateurs, du modèle et de la quantification.

Batch size 1 : le match nul que personne ne raconte

Voilà l’idée reçue à démonter : vLLM « écrase » tout. À un seul utilisateur, l’écart entre runtimes tombe sous les 10 % pour un même modèle et une quantification comparable. Sur RTX 4090 avec Llama 3.1 8B, un blog unique (non recoupé) donne Ollama ~62 tok/s en Q4_K_M contre vLLM ~71 tok/s en FP16 et ~68 en AWQ.

Pourquoi ? Parce que sans concurrence, PagedAttention et le continuous batching n’ont presque rien à optimiser : il n’y a qu’une séquence à servir. Et la quantification Q4 de llama.cpp compense une partie du retard face au FP16. La conséquence pratique est nette : pour un dev solo qui discute avec son modèle, le choix du runtime n’est pas un choix de performance, mais d’ergonomie et de compatibilité matérielle.

Quantification et offloading : ce que chacun accepte de sacrifier

Le format de quantification conditionne tout le reste — débit, qualité, facilité d’usage. llama.cpp et ses dérivés (Ollama, LM Studio) misent sur GGUF et ses variantes K-quants (Q2_K à Q6_K), I-quants (IQ1-IQ4), importance matrix, et quantification du KV cache. C’est ce qui permet de faire tenir un modèle sur 8, 12 ou 24 Go de VRAM. vLLM, lui, privilégie les formats serveur haute précision : GPTQ, AWQ, FP8, INT8/INT4 via bitsandbytes, avec un support GGUF expérimental ou limité selon les versions — et pas de K-quants. AWQ et GPTQ supposent CUDA ; MLX suppose Apple Silicon.

L’offloading raconte le même compromis. llama.cpp expose -ngl (nombre de couches sur GPU), --n-cpu-moe pour les modèles MoE, et s’appuie sur mmap des poids. Ollama expose num_gpu, détecte le matériel automatiquement et gère le chargement/déchargement via keep_alive. LM Studio propose des sliders d’offload GPU avec estimation VRAM avant chargement. vLLM est GPU-first, avec un CPU offloading via --cpu-offload-gb pensé comme du swap, pas comme un partage couche par couche.

Le compromis d’ingénierie est limpide : vLLM suppose de la VRAM confortable et des formats serveur ; llama.cpp et ses dérivés privilégient la portabilité et la quantification agressive pour tenir sur du matériel modeste. Les débits réels en offloading partiel (un 70B Q4 sur 24 Go de VRAM + DDR5) ne sont étayés par aucune mesure indépendante dans nos sources — à manier avec prudence.

Le confort a un prix : ce qu’Ollama et LM Studio cachent sous le capot

Ollama simplifie llama.cpp au prix d’un contrôle moindre sur le KV cache et le batching. Les options de tuning sont enfouies dans des variables d’environnement (OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS, OLLAMA_KV_CACHE_TYPE), et le comportement en concurrence ressemble à une file quasi séquentielle selon des sources tierces — à confronter aux variables officielles. LM Studio soigne l’interface : quantification KV réglable à la souris, serveur OpenAI-compatible, mais moteurs partiellement propriétaires et boîte noire sur le scheduling. Le point commun : les deux simplifient llama.cpp au prix d’un contrôle moindre. À l’inverse, llama.cpp brut offre tous les leviers mais exige de comprendre les flags.

Le contexte 2026 : TGI rangé au placard, vLLM en référence serveur

L’écosystème s’est consolidé. Hugging Face aurait basculé Text Generation Inference en mode maintenance le 21 mars 2026, redirigeant vers vLLM, SGLang, llama.cpp et MLX — information d’un blog tiers, à confirmer par source primaire. Cela renforce vLLM comme référence côté serveur et laisse llama.cpp et MLX comme voies portables. Pour le particulier, la pression de l’écosystème pousse les formats serveur (AWQ, FP8) et les optimisations de batching, tandis que la portabilité reste le terrain de llama.cpp et de ses dérivés. Signalons aussi que llama.cpp v0.5.0 a fait l’objet d’un guide début 2026, et que Windows ML a ajouté un support expérimental de llama.cpp pour les modèles GGUF avec API locale compatible OpenAI (octobre 2026) — signe que la portabilité reste un front actif.

Grille de décision par profil

Verdict nuancé : il n’y a pas de meilleur runtime, seulement un meilleur ajustement

vLLM gagne le débit serveur mais suppose de la VRAM et un format serveur. llama.cpp gagne la portabilité mais plafonne en concurrence. Ollama simplifie mais masque les réglages. LM Studio confortabilise mais reste partiellement opaque. Le choix se joue moins sur « lequel est le plus rapide » que sur le profil d’usage, le matériel et la tolérance au tuning. Restent des questions ouvertes à surveiller : l’évolution du continuous batching dans llama.cpp, la consolidation de MLX, la gouvernance d’Ollama — et surtout la nécessité de benchmarks reproductibles plutôt que de chiffres de blogs isolés.

Sources

• llama.cpp vs. vLLM: Choosing the right local LLM inference engine — Red Hat Developers
• Ollama vs LM Studio vs vLLM: 4 Runtimes, $0-$500 [2026] — shattered.io
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API — gyanaangan.in
• Windows ML: 2026 Updates for GGUF Models and Local AI — Techgenyz
• AI Development on Windows: from PyTorch and llama.cpp to Windows ML — Microsoft Foundry on Windows Blog
• Best Local LLMs (November 2026): Benchmarks, Memory & Workload — benchlm.ai
• Best Hardware for Running Open-Source AI Models Locally in 2026 — memeburn.com
• Héberger son propre LLM pour réduire la facture IA : faire le calcul — journaldunet.com
• Open-Source llm-d 1.0 Hits Production: IBM Research Confirms 11.5× AI Inference Cost Drop — techtimes.com

Article recherché et rédigé automatiquement · Magazine Electrosens