Optimisation TensorRT-LLM : Maîtriser la pile d'inférence de NVIDIA

Mis à jour le 11 décembre 2025

Mise à jour de décembre 2025 : TensorRT-LLM atteint plus de 10 000 tokens de sortie/sec sur H100 avec FP8, avec un temps jusqu'au premier token (TTFT) inférieur à 100 ms. Les déploiements en production rapportent jusqu'à 4x d'amélioration du débit par rapport à l'inférence PyTorch native. La fusion de kernels combine LayerNorm, multiplications matricielles et activations en un seul kernel CUDA. Le batching en vol maximise l'utilisation du GPU. L'attention FP8 sur Hopper/Blackwell offre des accélérations supplémentaires.

TensorRT-LLM de NVIDIA offre des performances d'inférence brutes que les alternatives peinent à égaler. Sur les GPU H100 avec précision FP8, le framework atteint plus de 10 000 tokens de sortie par seconde au débit maximal avec des latences de temps jusqu'au premier token inférieures à 100 millisecondes.¹ Les déploiements en production rapportent jusqu'à 4x d'amélioration du débit par rapport à l'inférence PyTorch native. Cette performance a un coût : TensorRT-LLM nécessite plus d'expertise en configuration et des cycles d'optimisation plus longs que des alternatives conviviales comme vLLM.

Pour les organisations engagées dans le matériel NVIDIA et prêtes à investir du temps d'ingénierie dans l'optimisation, TensorRT-LLM extrait les performances maximales d'une infrastructure GPU coûteuse. Comprendre l'architecture du framework, les options de quantification et les paramètres de réglage permet aux équipes de construire des systèmes d'inférence qui justifient les investissements en matériel premium grâce à une économie de tokens supérieure.

Architecture et optimisations fondamentales

TensorRT-LLM s'appuie sur l'optimiseur d'inférence TensorRT de NVIDIA, étendant le framework de compilation avec des optimisations spécifiques aux transformers. La bibliothèque fournit des API Python pour la définition des modèles ainsi que des composants runtime C++ pour le déploiement en production.

Fusion de kernels : TensorRT-LLM combine plusieurs opérations de transformer en un seul kernel CUDA optimisé. LayerNorm, multiplications matricielles, ajouts de biais et fonctions d'activation s'exécutent ensemble plutôt que de nécessiter des lancements de kernels séparés et des transferts mémoire. La fusion réduit la surcharge de lancement des kernels et élimine la matérialisation des tenseurs intermédiaires.²

Kernels d'attention personnalisés : Des implémentations optimisées manuellement de l'attention multi-têtes et à requêtes groupées exploitent les instructions Tensor Core pour un débit maximal. Les variantes de Flash Attention réduisent les besoins en bande passante mémoire tout en maintenant la précision numérique. Les kernels d'attention FP8 sur les GPU Hopper et Blackwell offrent des accélérations supplémentaires.

Batching en vol : Le batching statique traditionnel force toutes les requêtes d'un batch à attendre que la séquence la plus longue soit terminée. Le batching en vol ajoute de nouvelles requêtes aux batchs en cours à chaque étape de génération, traitant ensemble les phases de contexte et de génération.³ Cette approche maximise l'utilisation du GPU en gardant les unités de calcul occupées même lorsque des requêtes individuelles se terminent.

Cache KV paginé : Inspirée de la mémoire virtuelle des systèmes d'exploitation, l'attention paginée alloue le cache KV en blocs non contigus plutôt que de nécessiter des régions mémoire continues.⁴ L'allocation au niveau des blocs permet le partage du cache KV entre les requêtes avec des préfixes communs et atteint un gaspillage mémoire quasi nul dû à la fragmentation interne.

Comparaison des performances : TensorRT-LLM vs vLLM

Les deux frameworks ciblent l'inférence LLM en production, mais des différences architecturales créent des profils de performance distincts :

TensorRT-LLM surpasse systématiquement vLLM avec les configurations par défaut, offrant un débit 1,34x supérieur sur les séquences courtes et un temps par token de sortie 2,72x meilleur sur les séquences longues.⁵ Sur les GPU B200, l'optimisation plus poussée de TensorRT-LLM pour l'architecture Blackwell creuse davantage l'écart de performance.

vLLM offre des avantages en termes d'expérience développeur :⁶ - API compatible OpenAI pour un remplacement direct - Déploiement plus simple sans étape de compilation - Optimisation automatique des modèles avec des paramètres par défaut sensés - Support matériel plus large au-delà des GPU NVIDIA

Recommandation : Déployez TensorRT-LLM lorsque la maximisation de l'efficacité matérielle justifie l'investissement en ingénierie. Choisissez vLLM pour une mise en production plus rapide ou lorsque vous opérez à plus petite échelle où la performance absolue compte moins que la vélocité de développement.

Stratégies de quantification

TensorRT-LLM prend en charge de nombreuses options de quantification pour échanger la précision contre les performances et l'efficacité mémoire. Le choix de la bonne méthode de quantification dépend de la taille des batchs, des exigences de précision et du matériel cible.

Quantification FP8 (recommandée en premier)

FP8 offre le meilleur équilibre entre amélioration des performances et dégradation minimale de la précision :⁷

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat fp8 \
    --kv_cache_dtype fp8 \
    --output_dir $OUTPUT_PATH

La quantification FP8 nécessite une calibration pour déterminer les facteurs d'échelle appropriés. Le processus de calibration exécute l'inférence sur des échantillons représentatifs pour mesurer les plages d'activation :

from tensorrt_llm.quantization import QuantConfig, CalibConfig

quant_config = QuantConfig(
    quant_algo="fp8",
    kv_cache_quant_algo="fp8"
)

calib_config = CalibConfig(
    calib_dataset="cnn_dailymail",
    calib_batch_size=8,
    calib_num_samples=512
)

FP8 offre une amélioration moyenne des performances avec un impact très faible sur la précision et ne nécessite que quelques minutes de calibration. Les GPU Hopper et Blackwell fournissent un support matériel FP8 ; les GPU Ada supportent FP8 avec une efficacité réduite.

INT4 AWQ pour les déploiements à mémoire limitée

Lorsque la mémoire limite la taille du modèle, la quantification INT4 avec AWQ (Activation-aware Weight Quantization) compresse les poids à 4 bits tout en maintenant une précision acceptable :⁸

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int4_awq \
    --awq_block_size 64 \
    --tp_size 4 \
    --output_dir $OUTPUT_PATH

INT4 AWQ excelle dans les scénarios de petits batchs (taille de batch ≤ 4) où l'inférence devient limitée par la mémoire. Le temps de chargement des poids domine le calcul, donc une compression agressive des poids offre des accélérations substantielles. Pour les grands batchs, l'avantage de performance d'INT4 AWQ diminue à mesure que la densité de calcul augmente.

INT8 SmoothQuant pour une optimisation équilibrée

SmoothQuant transfère la difficulté de quantification des activations vers les poids, permettant une quantification INT8 efficace sans perte significative de précision :

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int8_sq \
    --kv_cache_dtype int8 \
    --output_dir $OUTPUT_PATH

INT8 SmoothQuant offre une amélioration moyenne des performances avec un impact moyen sur la précision. Les organisations devraient essayer FP8 en premier, se rabattant sur INT8 SQ si les résultats FP8 ne répondent pas aux exigences.

Cadre de sélection de la quantification

NVIDIA recommande l'ordre de priorité suivant :⁹

1. FP8 - Meilleur compromis performance/précision, nécessite Hopper/Blackwell
2. INT8 SmoothQuant - Bonne alternative pour les GPU Ada ou lorsque la précision FP8 est insuffisante
3. INT4 AWQ/GPTQ - Compression maximale pour les scénarios à mémoire limitée

Pour le cache KV spécifiquement, la quantification FP8 est recommandée par rapport à INT8 sur les GPU Hopper et Ada en raison d'un impact moindre sur la précision dans la plupart des cas.

Configuration du déploiement en production

Un déploiement TensorRT-LLM optimal nécessite le réglage de plusieurs paramètres en fonction des caractéristiques de la charge de travail :

Configuration de construction du moteur

trtllm-build \
    --checkpoint_dir $CHECKPOINT_PATH \
    --output_dir $ENGINE_PATH \
    --max_batch_size 256 \
    --max_num_tokens 8192 \
    --max_input_len 4096 \
    --max_seq_len 8192 \
    --gemm_plugin auto \
    --use_paged_context_fmha enable \
    --workers 8

max_batch_size : Par défaut 256 dans les versions récentes. Les déploiements en production atteignant un débit maximal augmentent souvent à 2048, exploitant pleinement les capacités de batching en vol.¹⁰

max_num_tokens : Contrôle le nombre total de tokens traités par itération de batch. Par défaut 8192, équilibrant le débit avec la consommation mémoire. Réduisez pour les déploiements à mémoire limitée ; augmentez avec prudence et surveillance.

use_paged_context_fmha : Active l'attention paginée pour une gestion efficace du cache KV. Requis lors de l'utilisation du batching en vol. L'implémentation pré-alloue la mémoire du cache KV, nécessitant environ 60% de VRAM de plus que les poids du modèle seuls.¹¹

Intégration avec Triton Inference Server

Les déploiements en production utilisent généralement NVIDIA Triton Inference Server avec le backend TensorRT-LLM :

model_repository/
└── llama-70b/
    ├── 1/
    │   └── model.py
    ├── config.pbtxt
    └── tensorrt_llm/
        └── 1/
            ├── config.json
            └── engine/

Triton fournit l'orchestration multi-modèles, la mise en file d'attente des requêtes, la collecte de métriques et la mise à l'échelle native Kubernetes. Le conteneur NGC pré-construit inclut le backend TensorRT-LLM avec le batching en vol et le support du cache KV paginé activés.

Planification de la mémoire

Estimez les besoins en mémoire avant le déploiement :

VRAM totale = Poids du modèle + Cache KV + Mémoire d'activation + Surcharge runtime

Poids du modèle (FP8) : Paramètres × 1 octet
Poids du modèle (INT4) : Paramètres × 0,5 octets
Cache KV : batch_size × seq_len × num_layers × 2 × hidden_dim × octets_précision

Un modèle de 70B paramètres en FP8 nécessite approximativement : - Poids : 70 Go - Cache KV (batch 256, seq 8192) : ~120 Go - Activations + surcharge : ~30 Go - Total : ~220 Go (3x H100 80 Go ou 2x H200 141 Go)

Workflow de réglage des performances

Une optimisation systématique extrait les performances maximales des déploiements TensorRT-LLM :

Phase 1 : Mesure de référence

Utilisez trtllm-bench pour une évaluation rapide des performances :

python -m tensorrt_llm.bench \
    --model_dir $ENGINE_PATH \
    --input_len 512 \
    --output_len 256 \
    --batch_size 32 \
    --num_requests 1000

L'utilitaire de benchmarking définit automatiquement les paramètres optimaux du moteur, fournissant des performances de référence sans la complexité d'un déploiement Triton complet.¹²

Phase 2 : Sélection de la quantification

Testez d'abord FP8 par rapport aux exigences de précision. Si la précision se dégrade au-delà des seuils acceptables, évaluez INT8 SQ ou INT4 AWQ. Exécutez des benchmarks d'évaluation sur des tâches représentatives, pas seulement des mesures de perplexité.

Phase 3 : Optimisation de la taille des batchs

Profilez le débit sur des tailles de batch de 1 à max_batch_size. Identifiez le coude de la courbe de débit où un batching supplémentaire offre des rendements décroissants. Définissez max_batch_size 20-30% au-dessus de ce point pour accommoder les pics de trafic.

Phase 4 : Réglage du cache KV

Surveillez l'utilisation du cache KV pendant les charges de travail en production. Si l'utilisation dépasse systématiquement 80%, augmentez max_num_tokens ou réduisez max_batch_size. Si l'utilisation reste inférieure à 50%, réduisez l'allocation pour libérer de la mémoire pour des batchs plus grands.

Phase 5 : Surveillance continue

Suivez les métriques clés en production : - Tokens par seconde (débit) - Temps jusqu'au premier token (latence) - Profondeur de file d'attente (capacité) - Utilisation du cache KV (mémoire) - Utilisation du GPU (efficacité)

Optimisations avancées

Décodage spéculatif

TensorRT-LLM prend en charge le décodage spéculatif utilisant des modèles brouillons plus petits pour prédire plusieurs tokens vérifiés par le modèle principal. Cette technique offre une accélération de 1,5-2x pour les charges de travail compatibles :

# Activer le décodage spéculatif dans la construction du moteur
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

Le décodage spéculatif bénéficie aux applications sensibles à la latence où le temps de complétion compte plus que le débit. L'optimisation nécessite de maintenir à la fois les modèles brouillon et cible en mémoire.

Configurations multi-GPU

TensorRT-LLM prend en charge le parallélisme tensoriel (TP), le parallélisme de pipeline (PP) et le parallélisme d'experts (EP) pour l'inférence distribuée :

# Parallélisme tensoriel 4 voies
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

Le TP divise chaque couche entre les GPU, nécessitant des opérations all-reduce à chaque frontière de couche. Le PP divise les couches entre les GPU en étapes de pipeline. Pour l'inférence, le TP offre généralement une meilleure latence tandis que le PP permet

[Contenu tronqué pour la traduction]