LLM auto hébergées · 18 October 2026vLLM, SGLang, TensorRT-LLM : le match des moteurs d’inférence serveur en 2026 (et pourquoi llama.cpp n’est plus votre seul ami)
En 2026, faire tourner un LLM chez soi n’est plus un exploit de bricoleur : c’est un problème d’ingénierie. Les agents, le RAG et les assistants de code ont transformé votre station de travail en un petit serveur qui doit encaisser du débit, pas juste répondre à un prompt. Et sur ce terrain-là, llama.cpp n’est plus le seul nom qui compte. Voici le comparatif argumenté de vLLM, SGLang et TensorRT-LLM — avec leurs forces, leurs pièges, et le coût réel pour votre portefeuille et vos week-ends.
Le jour où votre 4090 a cessé d’être un simple jouet
Il y a encore deux ans, « faire tourner un LLM en local » tenait du rituel initiatique : on téléchargeait un fichier GGUF, on lançait llama-server, on regardait les tokens défiler à dix ou quinze par seconde, et on trouvait ça magique. Ce temps est révolu — pas parce que llama.cpp a cessé de fonctionner, mais parce que nos usages ont changé d’échelle. Un chat avec un modèle 7B, c’est une chose. Un agent qui enchaîne les appels d’outils, un pipeline RAG qui réinjecte le même contexte système à chaque requête, un assistant de code qui doit servir trois personnes en parallèle sur la même carte : c’est une autre paire de manches, et c’est là que le moteur d’inférence devient le goulot d’étranglement.
La matière première est là. Les modèles ouverts — Llama, Mistral, Qwen, DeepSeek, les MoE chinois — n’ont jamais été aussi bons ni aussi accessibles, et le comparatif des modèles chinois de 2026 le confirme : le « meilleur » modèle dépend désormais entièrement du cas d’usage, pas d’un classement absolu. Côté matériel, les machines à mémoire unifiée ont débarqué en force : mini-PC à 128 Go de mémoire unifiée annonçant des modèles jusqu’à 200B, stations AMD à 192 Go visant le 200B+, Mac Studio M5 Ultra face au DGX Spark. Bref, le matériel suit. Reste à savoir quel logiciel exploiter tout ça.
C’est précisément le rôle des moteurs d’inférence serveur. Là où llama.cpp et Ollama ont ouvert la voie avec une philosophie « un binaire, un fichier, ça marche », vLLM, SGLang et TensorRT-LLM attaquent le problème par l’autre bout : maximiser le débit sous charge, mutualiser la mémoire, et exposer une API compatible OpenAI que n’importe quel client peut consommer. Le fil rouge de ce comparatif n’est pas « lequel est le plus rapide » — la réponse dépend de votre matériel et de votre charge — mais combien ça coûte vraiment : en matériel, en temps de configuration, en compétences à acquérir, et en nuits blanches de débogage.
Un mot sur la genèse, car elle éclaire les philosophies. vLLM est né au Sky Computing Lab de l’UC Berkeley, avec un papier de référence, arXiv:2309.06180, daté de septembre 2023 et présenté à SOSP 2023. Son idée fondatrice, PagedAttention, a redéfini la façon dont on gère le cache KV. SGLang vient du monde académique de Stanford et Berkeley, avec une intuition différente : et si on réutilisait agressivement les préfixes partagés entre requêtes ? TensorRT-LLM, enfin, est la réponse de NVIDIA : compiler le modèle en graphe optimisé pour ses propres GPU, quitte à sacrifier la souplesse. Trois réponses au même casse-tête. Voyons ce qu’elles impliquent concrètement.
PagedAttention, RadixAttention, graphes TensorRT : trois façons de résoudre le même casse-tête mémoire
Commençons par le nerf de la guerre : la mémoire. Un LLM en inférence doit stocker, pour chaque token déjà généré, les tenseurs clé/valeur de l’attention — le fameux cache KV. Sur un contexte long et plusieurs requêtes simultanées, ce cache explose et devient le principal consommateur de VRAM. La façon dont chaque moteur gère cette mémoire détermine tout le reste.
vLLM et PagedAttention. L’analogie est empruntée aux systèmes d’exploitation : au lieu d’allouer un bloc contigu de mémoire par séquence (avec le gaspillage que cela implique quand la séquence est plus courte que prévu), vLLM découpe le cache KV en blocs de taille fixe et les gère via une table de pages, comme un OS gère la mémoire virtuelle. Résultat : une fragmentation quasi nulle et une bien meilleure utilisation de la VRAM disponible. Sur cette fondation, vLLM empile le continuous batching (le scheduler insère et retire des requêtes à chaque pas de génération plutôt que d’attendre qu’un lot entier se termine), le chunked prefill (découper les longs prompts en morceaux pour lisser la charge) et le prefix caching (réutiliser le cache d’un préfixe déjà calculé). Le projet revendique plus de 2000 contributeurs, un support de 200+ architectures de modèles Hugging Face, et une compatibilité matérielle très large : NVIDIA, AMD, Intel, CPU x86/ARM/PowerPC, plus des plugins pour TPU, Gaudi, Ascend, Apple Silicon. Côté serveur, l’API est compatible OpenAI, avec en prime un support de l’Anthropic Messages API et de gRPC. Techniquement, vLLM s’appuie sur des kernels d’attention optimisés (FlashAttention, FlashInfer, FlashMLA, Triton), des graphes CUDA « piecewise » et « full », et torch.compile pour la génération de kernels.
SGLang et RadixAttention. SGLang part d’un constat simple : dans un workflow RAG ou agentique, la majorité du prompt est répétée d’une requête à l’autre (le contexte système, les documents récupérés, l’historique). RadixAttention organise donc le cache KV sous forme d’arbre de préfixes (un radix tree), où chaque nœud est un préfixe partagé. Quand une nouvelle requête arrive avec un préfixe déjà vu, le moteur saute le recalcul. Sur des charges à prompts répétés, le gain de TTFT peut être spectaculaire. SGLang ajoute un frontend de langage structuré qui permet de contraindre la génération (formats de sortie, appels d’outils) directement au niveau du scheduler. La contrepartie : un écosystème plus jeune, moins de recul communautaire, et une documentation moins pléthorique que celle de vLLM.
TensorRT-LLM et la compilation de graphes. NVIDIA joue une autre carte : plutôt que d’interpréter le modèle à l’exécution, TensorRT-LLM le compile en un graphe optimisé, avec fusion de kernels CUDA, quantification poussée (FP8, INT4 SmoothQuant) et un moteur statique taillé pour le matériel NVIDIA. Le résultat, quand tout s’aligne, est une performance brute difficile à égaler. Le prix à payer : la compilation est fastidieuse, le support des modèles est plus restreint, et chaque changement de topologie matérielle ou de version impose de recompiler. C’est un moteur d’ingénieur, pas de bricoleur.
| Moteur | Mécanisme clé | Philosophie | Souplesse | Performance brute |
|---|---|---|---|---|
| vLLM | PagedAttention + continuous batching | Flexibilité et large compatibilité | Élevée (200+ archis, multi-hardware) | Très bonne |
| SGLang | RadixAttention (cache de préfixes) | Réutilisation agressive du contexte | Moyenne (écosystème jeune) | Excellente sur prompts répétés |
| TensorRT-LLM | Compilation de graphes + kernels fusionnés | Performance maximale sur NVIDIA | Faible (NVIDIA only, modèles limités) | Maximale (configurations homogènes) |
Ce que ces architectures impliquent pour vous, concrètement : si vous servez des requêtes variées et ponctuelles, vLLM est le couteau suisse. Si votre charge est un pipeline RAG qui rabâche le même contexte, SGLang est taillé pour vous. Si vous avez du matériel NVIDIA homogène et une équipe qui sait lire un log de compilation, TensorRT-LLM vous donnera le dernier mot en débit.
Débit, latence, VRAM : ce que disent vraiment les benchmarks (et ce qu’ils cachent)
C’est ici qu’il faut être honnête sur ce que l’on peut affirmer. Les sources officielles de vLLM revendiquent un débit de serving « state-of-the-art » grâce à PagedAttention, au continuous batching, au chunked prefill et au prefix caching — mais ce sont des affirmations qualitatives, auto-déclarées par le projet. Les guides de benchmark 2026, comme celui de NeuralWired ou le comparatif des moteurs d’inférence locaux, existent et sont utiles, mais ils doivent être lus avec la même prudence qu’un communiqué de presse : configurations matérielles parfois idéalisées, batch sizes irréalistes, contextes courts qui flattent le TTFT.
Les métriques qui comptent réellement sont au nombre de trois. Le débit en tokens/seconde (surtout en batch, quand plusieurs requêtes tournent ensemble) mesure la capacité à servir. Le TTFT (time to first token) mesure la réactivité perçue — crucial pour un chat ou un agent. Le TPOT (time per output token) mesure la fluidité de la génération. Un moteur peut exceller sur l’un et décevoir sur l’autre : TensorRT-LLM brillera sur le débit brut en batch, SGLang sur le TTFT quand les préfixes sont partagés, vLLM sur l’équilibre général.
Le speculative decoding — présent nativement dans vLLM sous plusieurs formes (n-gram, suffix, EAGLE, DFlash) — est l’autre levier majeur. Le principe : un petit modèle « brouillon » propose plusieurs tokens, le grand modèle les valide en une passe. Le gain dépend énormément du taux d’acceptation, donc du domaine. Sur du code ou du texte très prévisible, il peut être significatif ; sur de la génération créative, beaucoup moins. Les chiffres précis varient trop selon les configurations pour qu’on les cite ici sans risquer de vous induire en erreur — méfiez-vous de quiconque vous promet un multiplicateur universel.
Quant au prefix caching, son intérêt est directement proportionnel à la redondance de vos prompts. Un chatbot qui réinitialise le contexte à chaque message n’en tirera presque rien ; un agent qui recharge le même manuel de 30 000 tokens à chaque étape en tirera un bénéfice considérable. C’est exactement là que RadixAttention de SGLang creuse l’écart.
Un dernier avertissement : les benchmarks sur GPU consumer (RTX 3090/4090/5090) et datacenter (A100/H100/L40S) ne se transposent pas aux machines à mémoire unifiée. Sur Apple Silicon ou sur les mini-PC à mémoire partagée, la bande passante mémoire devient le facteur limitant, et les hiérarchies de cache changent la donne. Les chiffres publiés pour un H100 ne vous disent presque rien sur votre Mac Studio.
Mono-GPU consumer : le match vLLM vs SGLang sur une seule carte, et pourquoi TensorRT-LLM n’est pas (encore) pour vous
Prenons le cas le plus fréquent : une RTX 4090 ou 5090, 24 à 32 Go de VRAM, un modèle 7B à 14B en quantification 4 ou 8 bits. C’est le terrain de jeu du développeur sérieux qui veut servir un assistant de code ou un agent local.
vLLM est le choix par défaut raisonnable. L’installation est simple (Python 3.10+, 3.12+ recommandé, CUDA 13.x), l’API compatible OpenAI permet de brancher n’importe quel client existant, et le support de 200+ architectures Hugging Face signifie que votre modèle exotique a de bonnes chances de fonctionner. La contrepartie : le cache paginé et le batching sont gourmands en VRAM, et il faut parfois ajuster finement gpu_memory_utilization pour ne pas saturer la carte. Sur une 4090, un modèle 7B en FP8 laisse de la marge ; un 14B en 4 bits demande plus d’attention.
SGLang est le choix malin si votre charge est répétitive. Sur un pipeline RAG ou un agent qui recharge le même contexte, RadixAttention fait des merveilles sur le TTFT. Mais l’écosystème est plus jeune : moins de tutoriels, moins de réponses sur les forums, une documentation parfois en retard sur le code. Pour un bricoleur pressé, c’est un vrai coût.
TensorRT-LLM, en revanche, n’est pas (encore) pour vous. La compilation fastidieuse, le support de modèles plus restreint et la quantification parfois capricieuse en font un outil qui récompense l’investissement en temps — mais sur une seule carte consumer, le gain de performance brute par rapport à vLLM ne justifie presque jamais les heures de configuration et de débogage. Réservez-le aux cas où vous savez exactement quel modèle vous allez servir, pendant des mois, sur du matériel NVIDIA fixe.
Et llama.cpp dans tout ça ? Il reste imbattable pour l’expérimentation rapide, le support GGUF universel, et les machines modestes. La version 0.5.0 de septembre 2026 a d’ailleurs consolidé son backend et son serveur. Mais dès que vous avez besoin de servir plusieurs requêtes en parallèle avec un débit décent, ses limites apparaissent. Le bon réflexe : garder llama.cpp pour prototyper, migrer vers vLLM ou SGLang quand la charge devient réelle.
Multi-GPU et petit cluster : quand le parallélisme tensoriel devient votre meilleur allié (et votre pire cauchemar de configuration)
Passer de une à deux, quatre ou huit cartes change complètement la nature du problème. vLLM et SGLang supportent le tensor parallelism (découper chaque couche sur plusieurs GPU), le pipeline parallelism (découper le modèle en étages) et le data parallelism (répliquer le modèle pour multiplier le débit). vLLM va jusqu’à supporter le parallélisme expert et contexte, utile pour les MoE et les très longs contextes.
TensorRT-LLM excelle sur les configurations NVIDIA homogènes — c’est là qu’il justifie enfin son coût de compilation, avec des gains de scalabilité nets sur NVLink. Mais il impose une compilation par topologie : changez le nombre de cartes, et il faut recompiler. Sur un cluster qui évolue, c’est un fardeau.
Les pièges sont nombreux et rarement documentés. Le déséquilibre de charge entre GPU (une carte plus lente ralentit tout le monde), la communication inter-GPU qui devient le goulot sur PCIe plutôt que NVLink, la gestion du KV cache distribué, et — le plus sous-estimé — le coût humain : compétences DevOps, monitoring (Prometheus, Grafana), tolérance aux pannes. Un petit cluster qui tombe la nuit parce qu’un GPU a surchauffé, c’est une expérience formatrice. Pour une petite équipe, vLLM offre le meilleur compromis flexibilité/effort ; TensorRT-LLM ne se justifie que si la performance brute est le critère unique et que l’équipe a les compétences.
Apple Silicon et mémoire unifiée : le terrain de jeu inattendu où llama.cpp garde une longueur d’avance
Voici le scénario que les benchmarks datacenter ignorent superbement : un Mac Studio M5 Ultra ou un MacBook Pro M-series, avec sa mémoire unifiée accessible à la fois par le CPU et le GPU. Pas de VRAM dédiée, pas de transfert PCIe — mais une bande passante mémoire qui devient le facteur limitant absolu.
vLLM supporte Apple Silicon via Metal, mais avec des performances encore en retrait et une maturité moindre que sur NVIDIA. SGLang suit le mouvement. TensorRT-LLM est absent — c’est NVIDIA only, point final. Sur ce terrain, llama.cpp reste le roi, avec son support Metal natif, sa communauté active et son format GGUF universel. Les guides de 2026 sur l’inférence locale Apple Silicon le confirment : pour un Mac, la simplicité et l’efficacité de llama.cpp ou de MLX restent difficiles à battre.
Cela ne veut pas dire qu’un moteur serveur est inutile sur Mac. Si vous voulez exposer une API compatible OpenAI à votre réseau local depuis un Mac Studio, vLLM le fait — mais vous payez en performance et en maturité ce que vous gagnez en standardisation. Le compromis débit/simplicité penche clairement vers llama.cpp sur cette plateforme. Comparez avec les retours d’expérience sur Mac Studio face au DGX Spark : la mémoire unifiée est un atout pour charger de gros modèles, pas nécessairement pour maximiser le débit sous batching.
Quantification, compatibilité modèles et tooling : les pièges qui ruinent votre week-end (et votre budget)
La quantification est le sujet qui fâche. vLLM supporte un éventail large : FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ/AWQ, et même GGUF. Mais ce support dépend des kernels et des versions CUDA — une combinaison qui marchait hier peut casser après une mise à jour. C’est le prix de la flexibilité.
SGLang propose une quantification intégrée, mais avec moins de recul communautaire : quand ça casse, vous êtes plus seul.
TensorRT-LLM pousse la quantification le plus loin (FP8, INT4 SmoothQuant), au prix d’une conversion de modèles parfois laborieuse. C’est là que le bât blesse pour un particulier : convertir un modèle au format TensorRT-LLM n’est pas une opération anodine, et une erreur de quantification peut dégrader silencieusement la qualité.
Côté tooling, vLLM mène la danse avec son API OpenAI-compatible, son support gRPC et son écosystème de monitoring. SGLang suit mais avec un écosystème plus restreint. TensorRT-LLM bénéficie du support NVIDIA mais reste plus fermé. La question du support communautaire est décisive : avec 2000+ contributeurs, vLLM a une réponse à presque tous les problèmes ; SGLang, plus jeune, demande parfois de fouiller ; TensorRT-LLM dépend du bon vouloir de NVIDIA.
Un dernier piège, spécifique aux MoE : les modèles à experts mélangés changent les stratégies de batching et de cache. Des moteurs comme FreeToken, issu de l’UC Berkeley et UT Austin, exploitent le cache d’experts LRU et le double buffering pour faire tourner des modèles à plusieurs centaines de milliards de paramètres sur un desktop — une piste à surveiller, mais qui sort du cadre de ce comparatif.
Le verdict par profil : qui doit migrer, qui doit rester, et combien ça coûte vraiment
Assez de théorie. Voici les recommandations concrètes, profil par profil.
Le bricoleur mono-GPU (RTX 4090, 24 Go). Restez sur llama.cpp ou Ollama pour l’expérimentation et les usages ponctuels. Migrez vers vLLM si le débit en batch devient critique — par exemple si vous servez un assistant de code à plusieurs personnes. Coût : quelques heures de configuration, un peu de VRAM en plus pour le cache.
L’équipe RAG/agents avec prompts répétés. SGLang et RadixAttention sont taillés pour vous. Le gain de TTFT sur des contextes rechargeés en boucle justifie l’apprentissage d’un écosystème plus jeune. Coût : une courbe d’apprentissage et une documentation à compléter par vous-même.
Le puriste de la performance sur NVIDIA. TensorRT-LLM, à condition d’accepter la complexité et de figer votre configuration. Coût : des heures de compilation, un support de modèles limité, et une recompilation à chaque changement.
Le petit cluster multi-GPU. vLLM pour la flexibilité et le support du tensor/pipeline/data parallelism ; TensorRT-LLM si la performance brute prime et que l’équipe a les compétences DevOps.
| Profil | Moteur recommandé | Coût matériel | Coût humain |
|---|---|---|---|
| Bricoleur mono-GPU | llama.cpp / Ollama, puis vLLM | Faible (carte existante) | Faible à modéré |
| Équipe RAG/agents | SGLang | Modéré (VRAM pour le cache) | Modéré (écosystème jeune) |
| Puriste NVIDIA | TensorRT-LLM | Élevé (GPU homogènes) | Élevé (compilation, debug) |
| Petit cluster | vLLM (ou TensorRT-LLM) | Élevé (multi-GPU, NVLink) | Élevé (DevOps, monitoring) |
| Mac / mémoire unifiée | llama.cpp / MLX | Modéré (machine unifiée) | Faible |
Le coût matériel est une chose, mais le coût humain est trop souvent ignoré. Un moteur qui vous fait gagner 20 % de débit mais vous coûte dix heures de débogage par mois n’est pas rentable pour un particulier. Pour une équipe, la calcul est différent : le temps d’ingénieur a un prix, mais le débit a une valeur directe.
Demain, tous sur le même moteur ? Ce qui va rebattre les cartes d’ici 2027
Le paysage bouge vite, et c’est une bonne nouvelle pour votre portefeuille. Trois tendances se dessinent.
D’abord, la convergence des API : l’API compatible OpenAI devient la norme de facto. Cela signifie que changer de moteur devient une décision réversible — vous pouvez prototyper sur vLLM et basculer sur SGLang sans réécrire vos clients. Le choix d’un moteur n’est plus un engagement définitif.
Ensuite, les nouveaux formats de quantification (MXFP4, NVFP4) et l’intégration native du speculative decoding rebattent les cartes sur le rapport performance/qualité. Les moteurs qui sauront les exploiter sans casser la compatibilité prendront l’avantage.
Enfin, la pression de la communauté open source face aux optimisations propriétaires de NVIDIA. vLLM, avec ses 2000+ contributeurs et son support multi-hardware, incarne cette dynamique. La question de la portabilité (AMD, Intel, Apple) devient centrale à mesure que le matériel se diversifie.
L’essor des modèles MoE complique encore la donne : les stratégies de batching et de cache doivent s’adapter à des architectures où seuls quelques experts sont activés par token. Les moteurs qui sauront gérer cette sparsité efficacement — comme les approches de cache d’experts — pourraient bien devenir les nouveaux favoris.
La conclusion est simple : le choix d’un moteur n’est plus un mariage, c’est une décision à réévaluer à chaque version majeure. Et c’est exactement ce qu’on veut. Parce que dans un marché qui bouge, le vrai luxe n’est pas d’avoir le moteur le plus rapide aujourd’hui — c’est de pouvoir en changer demain sans tout reconstruire.
Sources
- vLLM — dépôt GitHub officiel
- vLLM — site officiel
- vLLM — documentation
- vLLM — guide de démarrage rapide
- vLLM — page Wikipedia
- Local LLM Inference Engines Compared: The Definitive 2026 Guide
- vLLM vs SGLang vs TensorRT-LLM: 2026 Benchmark Guide (NeuralWired, 22 juillet 2026)
- Local LLM Inference 2026 — Ollama, vLLM, SGLang, GGUF (Singularity Moments)
- llama.cpp vs MLX vs Ollama vs vLLM: Local AI Inference for Apple Silicon 2026
- llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API (27 septembre 2026)
- Mac Studio M5 Ultra vs DGX Spark 2026 for Local AI (Memeburn)
- NVIDIA Vera Rubin NVL72 Posts First MLPerf Inference Preview Results (Unite.AI)
- Best Local LLMs (October 2026): Benchmarks, Memory & Workload (BenchLM)
- Modèles d’IA chinois en 2026 : DeepSeek, Qwen, Kimi, GLM… lequel pour quoi ? (Iatrust, 5 septembre 2026)
- Faire tourner une IA en local en 2026 : guide complet (Brief IA, 18 septembre 2026)
Article recherché et rédigé automatiquement · Magazine Electrosens