TensorRT-LLM et TGI
Mis à jour le 29 juillet 2026
Alternatives à vLLM
Si vLLM est le moteur recommandé par défaut, deux alternatives méritent votre attention : TensorRT-LLM de NVIDIA pour les performances maximales, et TGI (Text Generation Inference) de Hugging Face pour son écosystème intégré. Les deux servent les mêmes modèles Mistral, mais avec des philosophies opposées — l’un compile, l’autre s’exécute — et ce choix engage votre organisation bien au-delà de la première mise en service.
TensorRT-LLM
TensorRT-LLM est le framework d’optimisation d’inférence de NVIDIA. Il ne se contente pas de charger un modèle : il le compile en un « engine » optimisé spécifiquement pour votre GPU, ce qui offre les meilleures performances possibles sur matériel NVIDIA. Le workflow se décompose donc en deux étapes distinctes, un build qui produit l’engine TensorRT, puis un serve qui le déploie via Triton Inference Server. Cette séparation est la clé de tout ce qui suit : la performance se gagne au build, pas au runtime.
# Étape 1 : Cloner le dépôt TensorRT-LLM
git clone https://github.com/NVIDIA/TensorRT-LLM.git
cd TensorRT-LLM
# Étape 2 : Construire l'engine (exemple Mistral 7B)
# Les modèles Mistral utilisent l'exemple LLaMA du dépôt
python examples/llama/convert_checkpoint.py \
--model_dir mistralai/Mistral-7B-Instruct-v0.3 \
--output_dir ./checkpoint \
--dtype float16
python -m tensorrt_llm.commands.build \
--checkpoint_dir ./checkpoint \
--output_dir ./engine \
--gemm_plugin float16
Le gain se mesure : selon les cas, TensorRT-LLM se révèle 30 à 50 % plus rapide que vLLM. Il applique des optimisations kernel propres à chaque architecture GPU — Ampere, Hopper, Blackwell —, propose une quantization avancée en FP8, INT8 et INT4 avec calibration automatique, et gère l’inflight batching pour maximiser le débit.
La contrepartie est réelle. Chaque modèle doit être compilé pour votre GPU spécifique, et cette compilation dure de trente minutes à plusieurs heures selon le modèle. Changer de modèle impose un nouveau build, ce qui rend l’exercice pénible si vous testez encore différentes options. Le tout ne fonctionne que sur matériel NVIDIA : aucune portabilité vers AMD ou une autre plateforme. Traduit en organisation, cela signifie qu’une équipe qui itère chaque semaine sur son modèle passera plus de temps à compiler qu’à servir.
Une fois l’engine construit, Triton prend le relais et expose le service :
# Lancer Triton Inference Server avec l'engine
docker run --rm --gpus all \
-v ./engine:/models/mistral/1 \
-p 8000:8000 \
nvcr.io/nvidia/tritonserver:latest \
tritonserver --model-repository=/models
TGI (Text Generation Inference)
TGI est le toolkit d’inférence de Hugging Face. Il occupe une position intermédiaire : moins optimisé que TensorRT-LLM, plus simple à mettre en route, et parfaitement intégré à l’écosystème Hugging Face dont vous tirez déjà probablement vos poids. Le déploiement tient en une commande Docker :
docker run --gpus all --shm-size 1g \
-p 8080:80 \
-e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
ghcr.io/huggingface/text-generation-inference:2.0.3 \
--model-id mistralai/Mistral-7B-Instruct-v0.3
Le serveur est accessible sur le port 8080 une fois le modèle chargé. Sont fournis d’office la quantization intégrée (GPTQ, AWQ, bitsandbytes), le tensor parallelism pour distribuer le modèle sur plusieurs GPU, le streaming token par token et le batching continu, qui regroupe automatiquement les requêtes concurrentes au lieu de les traiter l’une après l’autre.
En production, quelques réglages supplémentaires permettent de cadrer la consommation mémoire :
docker run --gpus all --shm-size 1g \
-p 8080:80 \
-e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
ghcr.io/huggingface/text-generation-inference:2.0.3 \
--model-id mistralai/Mistral-7B-Instruct-v0.3 \
--max-input-length 4096 \
--max-total-tokens 8192 \
--max-batch-prefill-tokens 4096 \
--quantize awq
--max-input-length fixe la longueur maximale du prompt, --max-total-tokens plafonne le prompt et la génération combinés, et --quantize active la quantization pour réduire l’empreinte GPU. Dimensionner ces valeurs au plus juste vous protège d’une requête inhabituellement longue qui saturerait la mémoire et ferait tomber le service pour tout le monde.
Côté client, TGI expose une API compatible avec le client Mistral et le client OpenAI, ce qui permet là encore de réutiliser du code existant :
# Avec le client OpenAI
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8080/v1",
api_key="not-needed"
)
response = client.chat.completions.create(
model="mistralai/Mistral-7B-Instruct-v0.3",
messages=[{"role": "user", "content": "Explique le batching continu."}],
max_tokens=512
)
print(response.choices[0].message.content)
Une API native reste disponible pour les intégrations qui ne passent pas par un SDK :
# Avec curl (API native TGI)
curl http://localhost:8080/generate \
-H "Content-Type: application/json" \
-d '{
"inputs": "Explique le batching continu.",
"parameters": {"max_new_tokens": 512}
}'
Comparaison des trois moteurs
| Critère | vLLM | TensorRT-LLM | TGI |
|---|---|---|---|
| Performance | Excellente | Maximale | Bonne |
| Facilité | Simple | Complexe | Simple |
| API OpenAI | Native | Via Triton | Native |
| Quantization | FP8, AWQ | FP8, INT8, INT4 | GPTQ, AWQ |
| Multi-GPU | Tensor parallel | Tensor + Pipeline | Tensor parallel |
| Build requis | Non | Oui (long) | Non |
| Matériel | NVIDIA + AMD | NVIDIA uniquement | NVIDIA + AMD |
Arbitrer entre les trois
vLLM reste le choix par défaut, et il l’est pour de bonnes raisons : vous démarrez rapidement, vous disposez d’une API compatible OpenAI, et vous changez de modèle sans reconstruire quoi que ce soit. Une équipe encore en phase d’exploration n’a aucun intérêt à s’imposer autre chose.
TensorRT-LLM se justifie dans un scénario précis : un modèle fixe, servi en production à très haut débit, sur du matériel exclusivement NVIDIA, avec une équipe MLOps capable d’assumer la chaîne de build. Si l’un de ces quatre éléments manque, le gain de 30 à 50 % sera mangé par le temps passé à maintenir la compilation.
TGI, enfin, s’impose naturellement si vous vivez déjà dans l’écosystème Hugging Face, si vous voulez de la quantization sans configuration supplémentaire, et si vous cherchez une solution Docker simple à faire adopter par une équipe qui n’est pas spécialiste de l’inférence.
Points clés à retenir
- TensorRT-LLM offre les meilleures performances mais nécessite un build spécifique par GPU
- TGI est le toolkit Hugging Face avec quantization, tensor parallelism et batching intégrés
- vLLM reste le meilleur compromis entre performance et simplicité pour la majorité des cas
- Les trois moteurs exposent une API compatible OpenAI (directement ou via Triton)
- Le choix dépend de votre volume, de votre matériel et de votre tolérance à la complexité