Vous voulez héberger un LLM et vous tombez sur six noms qui reviennent dans tous les benchs : Ollama, llama.cpp, vLLM, SGLang, TGI et LMDeploy. Lequel choisir ? La réponse dépend de trois variables : matériel disponible, profil d'usage (dev local, serving production, batch) et modèles ciblés. Ce comparatif vous donne le tableau de décision, les critères objectifs et les recommandations par profil, sans chiffre inventé.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre ce que chaque backend d'inférence fait vraiment et ce qu'il ne fait pas.
- Choisir entre Ollama, llama.cpp, vLLM, SGLang, TGI et LMDeploy selon votre matériel.
- Identifier les critères techniques qui comptent : API OpenAI-compatible, quantification, batching dynamique, structured output.
- Savoir pourquoi FastChat ne fait plus partie de la sélection.
- Repérer les cas limites où aucun backend seul ne suffit (multi-modèles, routing, hybridation).
Recommandation rapide
Section intitulée « Recommandation rapide »Identifiez votre profil d'usage dans le tableau ci-dessous, vous obtenez le backend recommandé sans avoir à lire la suite. Les sections suivantes détaillent les critères techniques et les cas particuliers.
| Profil d'usage | Matériel typique | Backend recommandé | Alternative |
|---|---|---|---|
| Développeur en local, modèles 7B–13B | CPU + RAM 16 Go ou plus | Ollama | llama.cpp (llama-server) |
| Quantification fine, contrôle bas niveau | CPU / iGPU / Vulkan / Metal | llama.cpp | — |
| Serving production GPU, mono-modèle | 1 GPU NVIDIA 24 Go et plus | vLLM | SGLang |
| Multi-turn rapide, structured output natif | 1+ GPU NVIDIA | SGLang | vLLM |
| Multi-modèles avec routing avancé | GPU mono ou multi-nœud | vLLM + LiteLLM Proxy | TGI |
| Modèles fortement quantifiés (W4A16) | GPU NVIDIA | LMDeploy | vLLM |
Critères de comparaison
Section intitulée « Critères de comparaison »Les six backends partagent une promesse : servir un LLM via une API HTTP. Ils diffèrent sur cinq dimensions qui déterminent l'usage réel. Lisez-les dans l'ordre : la première suffit souvent à éliminer la moitié des candidats.
Cible matérielle
Section intitulée « Cible matérielle »Le matériel conditionne le choix avant tout autre critère. llama.cpp et Ollama acceptent CPU, iGPU Intel (Vulkan), Apple Silicon (Metal) et GPU NVIDIA/AMD. vLLM et SGLang exigent un GPU NVIDIA récent (Ampere et au-delà, CUDA ≥ 12.x). TGI suit la même contrainte avec un support partiel AMD ROCm. LMDeploy vise spécifiquement les GPU NVIDIA avec un focus sur les modèles quantifiés.
API OpenAI-compatible
Section intitulée « API OpenAI-compatible »Tous exposent une API REST compatible OpenAI (/v1/chat/completions, /v1/embeddings pour certains). Cela permet de remplacer un backend par un autre sans modifier le code client. Ollama ajoute son endpoint natif (/api/generate), plus simple pour les usages locaux. vLLM, SGLang et TGI offrent l'API OpenAI par défaut. llama.cpp la propose via le binaire llama-server.
Throughput vs latence mono-utilisateur
Section intitulée « Throughput vs latence mono-utilisateur »vLLM et SGLang sont optimisés pour le throughput agrégé grâce au continuous batching et au PagedAttention. Ils excellent quand des dizaines de requêtes arrivent en parallèle. Ollama et llama.cpp sont optimisés pour la latence en mono-utilisateur : excellents pour un agent local ou un copilote IDE, plus limités sous charge concurrente. Ce critère est souvent le point de bascule entre « dev local » et « serving production ».
Quantification supportée
Section intitulée « Quantification supportée »llama.cpp lit les formats GGUF (Q4_K_M, Q5_K_M, Q8_0, etc.), la norme pour le CPU et l'hybride CPU/GPU. Ollama utilise GGUF en sous-couche. vLLM accepte AWQ, GPTQ, FP8 et INT8 en GPU. SGLang supporte AWQ, GPTQ et W8A16. LMDeploy se distingue par son support natif W4A16 (kernels Marlin), qui divise la mémoire GPU par quatre sans perte significative sur la plupart des modèles.
Structured output et grammaires
Section intitulée « Structured output et grammaires »SGLang intègre nativement le structured output (JSON, regex, grammaires) au niveau du moteur, sans librairie additionnelle. vLLM propose la même chose via guided_decoding (intégrations Outlines et XGrammar). Ollama et llama.cpp offrent le mode JSON et les grammaires GBNF. TGI s'appuie sur Outlines. LMDeploy reste plus limité sur ce point — c'est un compromis du choix W4A16-first.
Comparatif détaillé
Section intitulée « Comparatif détaillé »Le tableau ci-dessous synthétise les six backends sur les critères qui structurent un choix. Les chiffres de performance font l'objet de la section suivante : ils dépendent du modèle, du matériel et du workload, et ne valent que pour le contexte précis où ils ont été relevés.
| Backend | Licence | Cible matérielle | API OpenAI | Quantif. | Structured output | Guide |
|---|---|---|---|---|---|---|
| Ollama | MIT | CPU, GPU, Apple Silicon | Oui (+ API native) | GGUF | JSON, GBNF | Lire |
| llama.cpp | MIT | CPU, GPU, iGPU, Vulkan, Metal | Oui (llama-server) | GGUF | JSON, GBNF | Lire |
| vLLM | Apache 2.0 | GPU NVIDIA (Ampere+) | Oui | AWQ, GPTQ, FP8, INT8 | guided_decoding | Lire |
| SGLang | Apache 2.0 | GPU NVIDIA | Oui | AWQ, GPTQ, W8A16 | Natif | Lire |
| TGI | Apache 2.0 | GPU NVIDIA, AMD ROCm | Oui (Messages API) | AWQ, GPTQ, EETQ | Outlines | — |
| LMDeploy | Apache 2.0 | GPU NVIDIA | Oui | W4A16, AWQ, INT4/8 | Limité | — |
Performances mesurées
Section intitulée « Performances mesurées »Un comparatif sans chiffres reste théorique. Voici des mesures réelles, relevées dans les labs des guides dédiés. Précaution essentielle : ces chiffres ne se comparent pas entre eux — le matériel et le modèle diffèrent à chaque fois. Ils donnent des ordres de grandeur par contexte, jamais un classement universel.
Inférence locale sur CPU
Section intitulée « Inférence locale sur CPU »Sur un poste sans GPU — un i7-12650H, 8 threads — llama.cpp sert un modèle Qwen2.5-1.5B quantifié en Q4_K_M. Le débit de génération atteint environ 28 tokens/seconde, l'ingestion de prompt environ 160 tokens/seconde. C'est confortable pour un usage mono-utilisateur — un agent local, un copilote — mais ce plafond se ressent dès qu'on vise plusieurs requêtes simultanées.
Serving GPU : vLLM face à SGLang
Section intitulée « Serving GPU : vLLM face à SGLang »Sur un GPU H100 PCIe 80 Go, avec le même modèle (Qwen2.5-14B-Instruct) et le même protocole (200 requêtes, 1024 tokens d'entrée, 256 de sortie), vLLM et SGLang ont été mesurés côte à côte.
| Mesure | vLLM 0.21 | SGLang 0.5 |
|---|---|---|
| Débit total — charge plafond | 8 354 tok/s | 8 274 tok/s |
| Débit total — charge modérée | 7 916 tok/s | 7 920 tok/s |
| TTFT médian — charge modérée | 230 ms | 139 ms |
Le constat est net : sur un workload standard, les deux moteurs sont équivalents — moins de 1 % d'écart sur le débit. SGLang garde un léger avantage sur le délai de premier token. Ce bench ne sollicite toutefois pas le RadixAttention de SGLang, car les prompts ne partagent aucun préfixe ; sur une charge multi-turn ou RAG, l'écart se creuserait en sa faveur. Le détail des mesures figure dans les guides vLLM et SGLang.
Quel outil pour quel cas
Section intitulée « Quel outil pour quel cas »Cette section déroule quatre profils types rencontrés en équipe DevOps/Plateforme. Trouvez le vôtre — la recommandation associée s'appuie sur les critères de la section précédente, pas sur des préférences subjectives.
Cas 1 — Développeur, modèle local, mono-utilisateur
Section intitulée « Cas 1 — Développeur, modèle local, mono-utilisateur »Vous codez sur un portable ou un poste fixe avec 16 à 32 Go de RAM, sans GPU dédié ou avec un iGPU intégré. Votre objectif : prototyper un agent, tester un RAG local, faire du prompt engineering sans dépendre d'une API SaaS. Ollama reste l'outil le plus simple : installation en une commande, gestion automatique des modèles, service système au démarrage. Si vous voulez contrôler la quantification ou compiler avec Vulkan pour exploiter votre iGPU Intel/AMD, le guide llama.cpp : serveur d'inférence montre comment obtenir ces leviers de réglage.
Cas 2 — Serving production, mono-modèle, GPU dédié
Section intitulée « Cas 2 — Serving production, mono-modèle, GPU dédié »Vous avez une instance GPU NVIDIA (L40S, A100, H100) à exposer derrière une API interne. Votre charge est mixte : requêtes concurrentes, prompts variés, longueurs de contexte hétérogènes. Le guide vLLM détaille ce cas : il reste la référence avec son continuous batching, son PagedAttention et un écosystème mature (vllm bench serve, intégrations LangChain/LlamaIndex/LiteLLM). Le guide SGLang montre qu'il devient un concurrent sérieux quand votre workload est dominé par les prompts longs ou le multi-turn : son RadixAttention réutilise les caches de préfixe entre requêtes, ce qui change la donne sur les agents conversationnels.
Cas 3 — Inférence batch ou pré-calcul d'embeddings
Section intitulée « Cas 3 — Inférence batch ou pré-calcul d'embeddings »Vous générez des résumés, des embeddings ou des classifications sur un large corpus. Le critère devient le throughput cumulé, pas la latence par requête. vLLM en mode batch reste excellent et bien documenté. TGI propose un mode batch natif intégré à l'écosystème Hugging Face. LMDeploy brille si votre modèle existe en W4A16 : la mémoire GPU divisée par quatre permet d'augmenter la taille de batch ou de servir un modèle plus gros sur la même carte.
Cas 4 — Multi-modèles avec routing
Section intitulée « Cas 4 — Multi-modèles avec routing »Vous voulez exposer plusieurs modèles (un pour le code, un pour le résumé, un pour le RAG) derrière une API unique avec authentification et budgets. La solution n'est pas un backend particulier mais un proxy LLM : voir le guide LiteLLM Proxy Server qui route vers les backends individuels. Chaque modèle reste servi par le backend le plus adapté à sa taille — un petit modèle 7B sur Ollama, un gros 70B quantifié sur vLLM ou LMDeploy.
Et FastChat ?
Section intitulée « Et FastChat ? »FastChat était l'option de référence en 2023-2024 pour exposer un LLM local avec une API OpenAI-compatible. Le projet de LMSYS est aujourd'hui en perte de vitesse : les développeurs principaux ont rejoint le projet SGLang, et les dernières releases significatives datent de fin 2024. Pour les nouveaux déploiements, l'écosystème recommande Ollama (usage local), llama.cpp (llama-server, contrôle fin) ou SGLang (production GPU). Un déploiement FastChat existant continue de fonctionner ; pour les nouveaux projets, choisissez parmi les six backends ci-dessus.
À retenir
Section intitulée « À retenir »- Le matériel disponible est le premier critère de choix — il élimine la moitié des candidats avant même de regarder les features.
- Ollama et llama.cpp dominent l'inférence locale (CPU, iGPU, GPU léger).
- vLLM et SGLang sont les références pour le serving GPU production, avec des points forts différents (batching pur vs prompts longs).
- LMDeploy se distingue sur la quantification W4A16 pour faire tenir des gros modèles sur peu de VRAM.
- FastChat n'est plus recommandé pour les nouveaux projets ; bascule vers SGLang ou Ollama selon le profil.
- Aucun bench universel n'existe : mesurez sur votre modèle et votre matériel avant de figer un choix architectural.