Fiche concept

Moteurs d'inférence LLM — vLLM vs TensorRT-LLM vs llama.cpp vs SGLang

À jour au 2026-07-24T14:00:00Z

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Moteurs d'inférence LLM — vLLM vs TensorRT-LLM vs llama.cpp vs SGLang ?

Le moteur d'inférence, pas le modèle, est le plus gros levier sur le coût de service LLM — le même Llama-3-70B peut coûter 3 à 10 fois plus cher sur une boucle generate naïve que sur un déploiement vLLM ou TensorRT-LLM optimisé.

Un moteur d'inférence LLM est la couche d'exécution qui transforme les poids d'un modèle entraîné en tokens réellement servis : il planifie les requêtes entrantes, gère la mémoire GPU, regroupe les invites entre elles, et décode les sorties token par token. Le choix du moteur est sans doute le levier le plus puissant sur le coût de service dans toute la pile d'IA générative — le même modèle ouvert de soixante-dix milliards de paramètres peut coûter de trois à dix fois plus cher à exécuter sur une boucle de service naïve et non optimisée que sur un moteur de production correctement réglé, avant même de toucher à la taille du modèle ou à la conception des invites.

Les quatre moteurs qui comptent

vLLM, issu des travaux de recherche de l'UC Berkeley, est l'implémentation open source de référence vers laquelle la plupart des équipes se tournent en premier. Sa technique signature, PagedAttention, gère le cache clé-valeur à la manière dont un système d'exploitation gère la mémoire virtuelle, ce qui lui permet de faire tenir bien plus de requêtes concurrentes sur le même GPU que les piles de service antérieures. Combiné au batching continu — qui intègre les nouvelles requêtes dans un lot en cours d'exécution plutôt que d'attendre que tout le lot se termine — vLLM couvre une immense gamme de familles de modèles ouverts et reste réellement facile à exploiter, ce qui en fait le choix par défaut des équipes qui hébergent elles-mêmes Llama, Mistral, Qwen ou des modèles similaires sur du matériel NVIDIA ou AMD.

Pourquoi c'est important

vLLM est la référence open-source pour la large couverture de modèles et l'ergonomie Python ; TensorRT-LLM est 1,5-2× plus rapide sur H100/H200 mais exige une compilation de 30 à 90 minutes par variante de modèle et un lock-in NVIDIA.
llama.cpp est le moteur edge/laptop (10-15 tok/s sur MacBook M-series), pas un choix datacenter ; RadixAttention de SGLang est 2-5× plus rapide que vLLM spécifiquement sur les charges agentiques à forte réutilisation de préfixe.
La décision se mappe directement sur le workload : TensorRT-LLM pour le chat mono-utilisateur sensible à la latence, vLLM pour le RAG batch haut débit, SGLang pour les agents Joule multi-tours partageant de grands prompts système.

Points clés

Quatre moteurs dominants : vLLM (open-source par défaut), TensorRT-LLM (débit max sur NVIDIA), llama.cpp (CPU/edge), SGLang (réutilisation de préfixes pour agents).
vLLM combine PagedAttention (C246) + batching continu (C245) — débit 10-24× vs baseline HuggingFace generate().
TensorRT-LLM compile des moteurs par modèle (kernels fusionnés FP8/INT8) — 1,5-2× plus rapide que vLLM sur H100, build 30-90 min, NVIDIA uniquement.
RadixAttention de SGLang partage le KV-cache entre requêtes à préfixes communs — accélération 2-5× sur charges agentiques.
Le choix du moteur est le plus gros levier de coût — mauvais moteur = facture GPU 3-10× avant tout tuning de modèle.
Quantification Q4 sur un modèle 70B : VRAM 140 Go → 40 Go, perte de précision 2-4 % — souvent imperceptible pour l'extraction SAP.
API OpenAI-compatible (/v1/chat/completions) : vLLM et TensorRT-LLM l'implémentent — swap de modèle/moteur sans changer la couche d'intégration SAP.
Métriques monitoring production : tokens/s par GPU, TTFT P50/P99, taux de hit KV-cache, utilisation mémoire GPU (toutes exposées via Prometheus par vLLM).
llama.cpp : Llama-3-8B à 10-15 tokens/s sur MacBook M, 20-30 tokens/s sur RTX 4090 — moteur laptop/edge, pas datacenter.
Pattern déploiement SAP : conteneur Docker sur SAP AI Core + endpoint OpenAI-compatible = intégration BTP/Datasphere/Joule inchangée lors du swap de modèle.

Termes employés sur cette page

Inference engine: Le runtime qui charge les poids du modèle en mémoire GPU/CPU, ordonnance les requêtes entrantes, gère le KV-cache et décode les tokens de sortie ; distinct du modèle lui-même.
vLLM: Moteur d'inférence LLM open-source d'UC Berkeley (2023) bâti autour de PagedAttention et du batching continu ; la référence de fait pour l'auto-hébergement de modèles open-weight.
TensorRT-LLM: Le moteur d'inférence compilé de NVIDIA qui fusionne les kernels CUDA et applique une quantization FP8/INT8 par modèle ; le débit absolu le plus élevé sur matériel NVIDIA.
RadixAttention: La technique de SGLang consistant à organiser le KV-cache en arbre de préfixes, de sorte que plusieurs requêtes partageant un system prompt / des exemples few-shot réutilisent le calcul mis en cache.
Decision owner: La personne responsable qui accepte l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, les accès, la traçabilité (lineage), la supervision et l'escalade à travers le modèle opérationnel.
Evidence grade: Un label qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →