TensorRT (NVIDIA TensorRT)

TensorRT est un écosystème d’outils NVIDIA pour l’optimisation et l’accélération de l’inférence de modèles de deep learning sur GPU NVIDIA. Il inclut un compilateur d’inférence, des runtimes optimisés, et des techniques d’optimisation de modèles (quantification, fusion de couches, tuning de kernels) qui produisent des performances jusqu’à 36× supérieures aux plateformes CPU.

L’écosystème TensorRT se décline en plusieurs composants. Le moteur TensorRT « classique » optimise tout type de modèle de deep learning (vision, NLP, audio). TensorRT-LLM, la brique spécialisée pour les LLM, ajoute les optimisations spécifiques aux modèles de langage auto-régressifs : in-flight batching, paged KV caching, quantification FP8/FP4/INT4, décodage spéculatif, et parallélisme multi-GPU. C’est le moteur d’inférence le plus rapide sur GPU NVIDIA pour les LLM en production.

Éditeur: NVIDIA
Type: Compilateur + runtime d’inférence pour GPU NVIDIA
Composants: TensorRT (général), TensorRT-LLM (LLM), NVIDIA Model Optimizer (quantification), TensorRT Cloud
Version TRT-LLM: v1.2.0 (branche active, mars 2026)
Quantifications: FP8, NVFP4, INT8 (SmoothQuant), INT4 (AWQ)
GPU supportés: Turing (RTX 20xx), Ampere (A100, RTX 30xx), Ada (L40, RTX 40xx), Hopper (H100, H200), Blackwell (B200, RTX 50xx)
Intégrations: NVIDIA Dynamo, Triton Inference Server, ONNX Runtime (comme EP)
Licence: Open source (Apache 2.0) pour TensorRT-LLM
Architectures LLM: Llama, Mistral, Qwen, DeepSeek, Phi, Gemma, Falcon, GPT, etc.

L’écosystème TensorRT

TensorRT n’est pas un outil unique mais un ensemble de composants complémentaires :

TensorRT (le compilateur d’inférence) : prend un modèle (depuis PyTorch, TensorFlow ou ONNX) et le compile en un « engine » binaire ultra-optimisé pour le GPU NVIDIA cible. L’engine intègre la fusion de couches, le tuning automatique des kernels, la calibration de précision, et l’optimisation mémoire. C’est la brique fondatrice, utilisée pour tous les types de modèles (vision, NLP, audio, etc.).

TensorRT-LLM : une bibliothèque Python open source construite au-dessus de TensorRT, spécifiquement conçue pour les LLM. Elle gère tout ce qui est propre à l’inférence auto-régressive : boucle de génération, cache KV paginé, batching dynamique, parallélisme distribué, et décodage spéculatif. C’est le composant le plus important pour les développeurs qui travaillent avec des LLM.

NVIDIA Model Optimizer (anciennement TensorRT Model Optimizer) : une bibliothèque unifiée de techniques d’optimisation de modèles, incluant la quantification post-entraînement (PTQ), le quantization-aware training (QAT), le pruning, et la distillation. Elle produit des checkpoints quantifiés directement déployables dans TensorRT-LLM, vLLM, ou SGLang.

NVIDIA Dynamo : un framework de serving distribué à l’échelle du datacenter qui s’intègre avec TensorRT-LLM pour orchestrer l’inférence sur des clusters GPU.

Triton Inference Server : un serveur d’inférence multi-framework (TensorRT, PyTorch, ONNX, etc.) avec batching dynamique, model ensembles, et support Kubernetes natif.

TensorRT-LLM : l’essentiel

Optimisations clés

TensorRT-LLM combine plusieurs optimisations qui, ensemble, produisent les meilleures performances LLM sur GPU NVIDIA :

Quantification avancée. FP8 sur Hopper (H100/H200) double les performances et divise la mémoire par deux par rapport à FP16, avec un impact minimal sur la qualité. NVFP4 sur Blackwell (B200, RTX 50xx) pousse la compression encore plus loin. INT4 AWQ et INT8 SmoothQuant sont aussi supportés. Les checkpoints quantifiés de modèles populaires (dont DeepSeek en FP4) sont disponibles sur Hugging Face et NGC.

In-flight batching. Au lieu d’attendre qu’un batch complet de requêtes soit terminé avant d’en traiter un nouveau, l’in-flight batching gère dynamiquement les requêtes : les phases de prefill (traitement du contexte) et de génération (production de tokens) sont entrelacées pour maximiser l’utilisation du GPU. Résultat : moins de latence pour l’utilisateur, plus de throughput pour l’opérateur.

Paged KV caching. Inspiré du mécanisme de mémoire paginée des systèmes d’exploitation, le paged KV caching alloue le cache d’attention par blocs plutôt que par requête entière. Cela élimine la fragmentation mémoire et permet de servir plus de requêtes concurrentes avec la même VRAM.

Décodage spéculatif. TensorRT-LLM intègre plusieurs techniques de décodage spéculatif, dont EAGLE-3, la prédiction multi-token (MTP), et le décodage N-gram. Un petit modèle « draft » prédit plusieurs tokens que le modèle principal valide en une seule passe, accélérant le throughput effectif de 1,5× à 3×.

Sparse Attention. Pour les contextes longs, TensorRT-LLM supporte l’attention clairsemée (Sparse Attention) qui ne calcule l’attention que sur un sous-ensemble de tokens, réduisant la complexité quadratique de l’attention standard.

Parallélisme distribué. Tensor parallelism, pipeline parallelism, et expert parallelism (pour les modèles MoE comme Mixture of Experts) permettent de distribuer l’inférence sur plusieurs GPU et plusieurs nœuds.

AutoDeploy (nouveau)

Annoncé en février 2026, AutoDeploy est une fonctionnalité bêta qui compile automatiquement un modèle PyTorch standard en un graphe d’inférence TensorRT-LLM optimisé, sans réécriture manuelle du modèle. Traditionnellement, déployer une nouvelle architecture dans TensorRT-LLM nécessitait de réimplémenter manuellement le modèle en utilisant l’API TensorRT-LLM. AutoDeploy élimine cette étape en extrayant automatiquement le graphe de calcul et en appliquant les transformations d’optimisation (caching, sharding, sélection de kernels).

C’est un changement de paradigme : on passe d’un workflow « réimplémenter pour chaque modèle » à un workflow « compiler automatiquement ». AutoDeploy est particulièrement utile pour les architectures nouvelles ou peu courantes, les variantes internes, et les modèles de recherche qui évoluent rapidement.

Utilisation pratique

L’API Python LLM

TensorRT-LLM v1.0+ fournit une API Python haut niveau qui simplifie considérablement le déploiement :

from tensorrt_llm import LLM, SamplingParams

# Charger un modèle (depuis Hugging Face ou un checkpoint local)
llm = LLM(model="meta-llama/Llama-3.1-8B-Instruct")

# Générer
prompts = ["Explain quantum computing in one paragraph."]
sampling_params = SamplingParams(temperature=0.7, max_tokens=256)

outputs = llm.generate(prompts, sampling_params)
for output in outputs:
    print(output.text)

L’API gère automatiquement le chargement du modèle, la compilation des engines TensorRT, le cache KV paginé, et le batching. Pour les modèles pré-quantifiés (FP8, FP4), le chargement est transparent :

# Charger un modèle FP8 pré-quantifié
llm = LLM(model="nvidia/Llama-3.1-8B-Instruct-FP8")

# Ou quantifier à la volée
llm = LLM(model="meta-llama/Llama-3.1-8B-Instruct", quantization="fp8")

Serving via la CLI

TensorRT-LLM peut être déployé comme serveur compatible OpenAI via Triton Inference Server ou via sa propre CLI :

# Lancer un serveur TensorRT-LLM
trtllm-serve meta-llama/Llama-3.1-8B-Instruct 
    --tp_size 1 
    --max_batch_size 64 
    --port 8000

Quantification dans TensorRT-LLM

TensorRT-LLM supporte un large éventail de formats de quantification, chacun ciblant des architectures GPU spécifiques :

Format	GPU minimum	Gain mémoire vs FP16	Gain performance vs FP16	Impact qualité
FP8	Hopper (H100)	~50 %	~2× throughput	Quasi nul
NVFP4	Blackwell (B200, RTX 50xx)	~75 %	>2× vs FP8	Faible (avec calibration)
INT8 (SmoothQuant)	Turing (RTX 20xx)	~50 %	Variable	< 0,5 %
INT4 (AWQ)	Ampere (RTX 30xx)	~75 %	~2-3× throughput	1-3 %

NVIDIA Model Optimizer est l’outil recommandé pour quantifier un modèle avant le déploiement dans TensorRT-LLM. Il supporte la PTQ (post-training quantization) et le QAT (quantization-aware training), et exporte les checkpoints dans un format directement compatible avec TensorRT-LLM, vLLM et SGLang.

DeepSeek optimisé pour Blackwell TensorRT-LLM inclut des optimisations spécifiques pour les modèles DeepSeek (V3/R1) sur GPU Blackwell : attention clairsemée DeepSeek (DSA), routage parfait des experts MoE, kernels FP4 CuteDSL, et stratégies de parallélisme adaptées à l’architecture MoE massive de DeepSeek. Ces optimisations ont permis d’atteindre des performances record sur les benchmarks d’inférence Blackwell.

TensorRT-LLM vs vLLM

TensorRT-LLM et vLLM sont les deux moteurs d’inférence LLM dominants. Voici comment ils se comparent :

Critère	TensorRT-LLM	vLLM
Performance max (NVIDIA)	La plus élevée (kernels NVIDIA natifs)	Très élevée (avec Marlin)
Matériel supporté	GPU NVIDIA uniquement	NVIDIA, AMD (ROCm), TPU (expérimental)
Complexité de déploiement	Plus élevée (compilation d’engines, AutoDeploy aide)	Plus simple (chargement direct des modèles HF)
Formats de quantification	FP8, NVFP4, INT8 SmoothQuant, INT4 AWQ	GPTQ, AWQ, FP8, INT8 W8A8, GGUF, bitsandbytes
Support Blackwell (FP4)	Natif (NVFP4 optimisé)	En cours d’intégration
Décodage spéculatif	EAGLE-3, MTP, N-gram	Supporté (moins de variantes)
Écosystème	NVIDIA (Dynamo, Triton, NeMo)	Communautaire + HF + LLM Compressor
Nouveaux modèles	Support via AutoDeploy (bêta) ou implémentation manuelle	Support rapide via HF Transformers

Verdict TensorRT-LLM si vous êtes sur GPU NVIDIA en production et que chaque milliseconde/token compte, surtout sur Hopper ou Blackwell. vLLM si vous avez besoin de flexibilité (multi-GPU vendor, plus de formats de quantification, support de nouveaux modèles plus rapide), ou si la simplicité de déploiement est prioritaire. Les deux sont d’excellents choix. TensorRT-LLM extrait le maximum du matériel NVIDIA, vLLM offre le meilleur rapport simplicité/performance.

Performances en pratique

Les gains de TensorRT-LLM dépendent du GPU, du modèle, et de la configuration. Voici des ordres de grandeur basés sur les benchmarks publiés :

Sur Hopper (H100/H200) : un modèle Llama 3.1 405B en FP8 atteint jusqu’à 44 % de throughput supplémentaire avec NVIDIA Model Optimizer par rapport à FP16 standard. Les modèles 70B en FP8 sur un seul H100 80 Go offrent un throughput suffisant pour le serving production haute concurrence.

Sur Blackwell (B200) : les optimisations DeepSeek-R1 sur GPU B200 ont établi des records de performance d’inférence. Le format NVFP4 sur Blackwell permet de charger des modèles 2× plus gros qu’en FP8 dans la même VRAM, avec des performances par token encore supérieures grâce aux Tensor Cores de 5ème génération.

Sur RTX (desktop) : TensorRT for RTX accélère les LLM jusqu’à 4× par rapport à l’inférence FP16 standard sur les cartes RTX. Un modèle 7B-8B en INT4 AWQ sur RTX 4090 dépasse couramment les 100 tokens/seconde en génération, avec une première réponse (time to first token) de l’ordre de la seconde pour des contextes courts.

En comparaison directe avec des frameworks non optimisés, TensorRT peut accélérer l’inférence de 36× par rapport à des plateformes CPU seules, et de 1,5× à 3× par rapport à PyTorch standard sur le même GPU. L’essentiel des gains provient de la fusion de kernels (élimination des accès mémoire intermédiaires), la quantification (réduction de la bande passante mémoire), et le batching intelligent (meilleure utilisation du GPU).

Workflow de déploiement typique

Un déploiement TensorRT-LLM suit généralement ce parcours :

1. Choix du modèle et quantification. Sélectionnez un modèle (depuis Hugging Face Hub ou NGC) et quantifiez-le via NVIDIA Model Optimizer si un checkpoint pré-quantifié n’est pas disponible. Pour Hopper, ciblez FP8. Pour Blackwell, ciblez NVFP4. Pour les GPU grand public plus anciens, INT4 AWQ.

2. Compilation de l’engine (optionnel avec l’API LLM). L’API Python LLM haut niveau gère la compilation automatiquement au premier chargement. Pour un contrôle plus fin, vous pouvez compiler manuellement via trtllm-build. L’engine compilé est mis en cache pour les chargements suivants.

3. Serving. Déployez via Triton Inference Server (production datacenter), via la CLI trtllm-serve (déploiement simple), ou via l’API Python (intégration dans votre application). Pour le serving à l’échelle du datacenter, NVIDIA Dynamo orchestre la distribution des requêtes sur le cluster.

4. Monitoring et tuning. Ajustez le max_batch_size, la taille du cache KV, et les stratégies de parallélisme en fonction de vos métriques (latence P95, throughput, utilisation GPU). TensorRT-LLM expose des métriques compatibles Prometheus pour le monitoring.

Premier chargement lent La première exécution d’un modèle avec TensorRT-LLM implique la compilation de l’engine TensorRT, qui peut prendre plusieurs minutes (5 à 30 minutes selon la taille du modèle). Les exécutions suivantes chargent l’engine depuis le cache et démarrent en quelques secondes. Planifiez ce temps de warm-up dans vos déploiements automatisés.

TensorRT et ONNX

ONNX et TensorRT sont complémentaires. ONNX est un format d’échange : vous exportez votre modèle en .onnx depuis n’importe quel framework. TensorRT est un compilateur/runtime : il prend un modèle ONNX en entrée et produit un engine binaire optimisé pour le GPU cible. ONNX Runtime peut utiliser TensorRT comme Execution Provider, combinant la portabilité d’ONNX avec les performances de TensorRT.

Pour les LLM spécifiquement, TensorRT-LLM a son propre chemin d’import (directement depuis les checkpoints PyTorch/Hugging Face) qui évite le passage par ONNX. Le chemin ONNX reste utile pour les modèles non-LLM (vision, audio, tabular) et pour les cas où la portabilité cross-platform est requise.

Limites

GPU NVIDIA uniquement. TensorRT et TensorRT-LLM ne fonctionnent que sur GPU NVIDIA. Si vous ciblez du matériel AMD, Intel, ou Apple Silicon, utilisez vLLM (AMD/NVIDIA) ou llama.cpp/GGUF (multi-plateforme).

Complexité de mise en route. Malgré les améliorations de l’API Python et d’AutoDeploy, TensorRT-LLM reste plus complexe à configurer que vLLM. La compilation d’engines, la gestion des plugins, et le tuning des paramètres de runtime demandent plus d’expertise.

Portabilité des engines. Un engine TensorRT compilé est spécifique au GPU cible (compute capability, mémoire). Un engine compilé pour un H100 ne fonctionne pas sur un A100. Vous devez recompiler pour chaque type de GPU cible.

Support des nouvelles architectures. Historiquement, chaque nouvelle architecture de modèle devait être réimplémentée manuellement dans TensorRT-LLM. AutoDeploy (février 2026) améliore la situation mais reste en bêta. vLLM, qui charge directement les modèles HF Transformers, supporte les nouvelles architectures plus rapidement.

Overhead de compilation. La compilation d’un engine TensorRT peut prendre plusieurs minutes à plusieurs dizaines de minutes, selon la taille du modèle et les optimisations appliquées. C’est un coût initial qui n’existe pas avec vLLM (chargement direct). En production stable, ce coût est amorti.

Questions fréquentes sur TensorRT

TensorRT est-il gratuit ?

Oui. TensorRT-LLM est open source sous licence Apache 2.0 (code sur GitHub). Le SDK TensorRT « classique » est téléchargeable gratuitement depuis le site NVIDIA Developer. L’utilisation en production est libre de droits. NVIDIA Dynamo et Triton Inference Server sont aussi open source.

Faut-il un GPU datacenter (A100, H100) pour utiliser TensorRT-LLM ?

Non. TensorRT-LLM fonctionne aussi sur les GPU grand public : RTX 30xx (Ampere), RTX 40xx (Ada Lovelace), RTX 50xx (Blackwell). Les fonctionnalités FP8 nécessitent un GPU Hopper (H100) ou plus récent, et NVFP4 nécessite Blackwell. Mais INT4 AWQ et INT8 SmoothQuant fonctionnent dès les GPU Turing (RTX 20xx). TensorRT for RTX est même disponible pour les applications desktop et gaming.

Quelle est la différence entre TensorRT et TensorRT-LLM ?

TensorRT est le compilateur/runtime d’inférence généraliste de NVIDIA, applicable à tout modèle de deep learning (vision, NLP, audio). TensorRT-LLM est une bibliothèque Python construite au-dessus de TensorRT, spécifiquement optimisée pour l’inférence des LLM : elle ajoute le cache KV paginé, l’in-flight batching, le décodage spéculatif, le parallélisme distribué, et d’autres optimisations propres à la génération auto-régressive.

Comment quantifier un modèle pour TensorRT-LLM ?

Utilisez NVIDIA Model Optimizer pour la quantification. Il supporte la PTQ (FP8, NVFP4, INT4 AWQ) et le QAT, et exporte des checkpoints directement compatibles avec TensorRT-LLM. Pour les modèles courants, des checkpoints pré-quantifiés sont disponibles sur le Hugging Face Hub et NVIDIA NGC. Vous pouvez aussi quantifier à la volée via l’API Python : LLM(model="...", quantization="fp8").

TensorRT-LLM est-il meilleur que vLLM ?

En termes de performance brute sur GPU NVIDIA, TensorRT-LLM a un avantage grâce à ses kernels natifs NVIDIA et son support FP4/FP8 optimisé. Sur Blackwell, cet avantage est particulièrement marqué. En termes de simplicité de déploiement, flexibilité multi-matériel, et vitesse de support des nouveaux modèles, vLLM a l’avantage. Les deux s’améliorent rapidement. Pour la performance maximale sur NVIDIA : TensorRT-LLM. Pour la flexibilité : vLLM.