TensorRT-LLM-Optimierung: NVIDIAs Inferenz-Stack meistern

Aktualisiert am 11. Dezember 2025

Update Dezember 2025: TensorRT-LLM erreicht über 10.000 Output-Tokens/Sek. auf H100 mit FP8, TTFT unter 100ms. Produktiveinsätze berichten von 4-fachem Durchsatz gegenüber nativem PyTorch. Kernel-Fusion kombiniert LayerNorm, Matmuls und Aktivierungen in einzelne CUDA-Kernel. Inflight Batching maximiert die GPU-Auslastung. FP8-Attention auf Hopper/Blackwell liefert zusätzliche Geschwindigkeitssteigerungen.

NVIDIAs TensorRT-LLM liefert rohe Inferenz-Performance, die Alternativen kaum erreichen können. Auf H100-GPUs mit FP8-Präzision erreicht das Framework über 10.000 Output-Tokens pro Sekunde bei Spitzendurchsatz mit Time-to-First-Token-Latenzen unter 100 Millisekunden.¹ Produktiveinsätze berichten von bis zu 4-fachen Durchsatzverbesserungen gegenüber nativer PyTorch-Inferenz. Die Performance hat ihren Preis: TensorRT-LLM erfordert mehr Konfigurations-Expertise und längere Optimierungszyklen als benutzerfreundliche Alternativen wie vLLM.

Für Organisationen, die sich NVIDIA-Hardware verschrieben haben und bereit sind, Engineering-Zeit in die Optimierung zu investieren, extrahiert TensorRT-LLM maximale Performance aus teurer GPU-Infrastruktur. Das Verständnis der Framework-Architektur, Quantisierungsoptionen und Tuning-Parameter ermöglicht es Teams, Inferenz-Systeme zu bauen, die Premium-Hardware-Investitionen durch überlegene Token-Ökonomie rechtfertigen.

Architektur und Kern-Optimierungen

TensorRT-LLM baut auf NVIDIAs TensorRT-Inferenz-Optimierer auf und erweitert das Kompilierungs-Framework um Transformer-spezifische Optimierungen. Die Bibliothek bietet Python-APIs für die Modelldefinition zusammen mit C++-Runtime-Komponenten für den Produktiveinsatz.

Kernel-Fusion: TensorRT-LLM kombiniert mehrere Transformer-Operationen in einzelne optimierte CUDA-Kernel. LayerNorm, Matrix-Multiplikationen, Bias-Additionen und Aktivierungsfunktionen werden zusammen ausgeführt, anstatt separate Kernel-Starts und Speicherübertragungen zu erfordern. Fusion reduziert den Kernel-Start-Overhead und eliminiert die Materialisierung von Zwischen-Tensoren.²

Benutzerdefinierte Attention-Kernel: Handoptimierte Implementierungen von Multi-Head- und Grouped-Query-Attention nutzen Tensor-Core-Instruktionen für maximalen Durchsatz. Flash-Attention-Varianten reduzieren den Speicherbandbreiten-Bedarf bei gleichzeitiger Beibehaltung der numerischen Präzision. FP8-Attention-Kernel auf Hopper- und Blackwell-GPUs bieten zusätzliche Geschwindigkeitssteigerungen.

Inflight Batching: Traditionelles statisches Batching zwingt alle Anfragen in einem Batch, auf die längste Sequenz zu warten. Inflight Batching fügt neue Anfragen bei jedem Generierungsschritt zu laufenden Batches hinzu und verarbeitet Kontext- und Generierungsphasen zusammen.³ Der Ansatz maximiert die GPU-Auslastung, indem Recheneinheiten beschäftigt gehalten werden, auch wenn einzelne Anfragen abgeschlossen werden.

Paged KV-Caching: Inspiriert vom virtuellen Speicher von Betriebssystemen, allokiert Paged Attention den KV-Cache in nicht-zusammenhängenden Blöcken, anstatt kontinuierliche Speicherbereiche zu erfordern.⁴ Block-Level-Allokation ermöglicht das Teilen des KV-Cache zwischen Anfragen mit gemeinsamen Präfixen und erreicht nahezu null Speicherverschwendung durch interne Fragmentierung.

Performance-Vergleich: TensorRT-LLM vs. vLLM

Beide Frameworks zielen auf produktive LLM-Inferenz ab, aber architektonische Unterschiede erzeugen unterschiedliche Performance-Profile:

TensorRT-LLM übertrifft vLLM konstant mit Standardkonfigurationen und liefert 1,34x höheren Durchsatz bei kurzen Sequenzen und 2,72x bessere Zeit-pro-Output-Token bei langen Sequenzen.⁵ Auf B200-GPUs erweitert TensorRT-LLMs tiefere Optimierung für die Blackwell-Architektur den Performance-Abstand weiter.

vLLM bietet Vorteile bei der Entwicklererfahrung:⁶ - OpenAI-kompatible API für Drop-in-Ersatz - Einfacherer Einsatz ohne Kompilierungsschritt - Automatische Modelloptimierung mit vernünftigen Standardwerten - Breitere Hardware-Unterstützung über NVIDIA-GPUs hinaus

Empfehlung: Setzen Sie TensorRT-LLM ein, wenn die Maximierung der Hardware-Effizienz die Engineering-Investition rechtfertigt. Wählen Sie vLLM für schnellere Time-to-Production oder bei kleinerem Maßstab, wo absolute Performance weniger wichtig ist als Entwicklungsgeschwindigkeit.

Quantisierungsstrategien

TensorRT-LLM unterstützt umfangreiche Quantisierungsoptionen für den Kompromiss zwischen Präzision und Performance sowie Speichereffizienz. Die Wahl der richtigen Quantisierungsmethode hängt von Batch-Größe, Genauigkeitsanforderungen und Ziel-Hardware ab.

FP8-Quantisierung (zuerst empfohlen)

FP8 bietet die beste Balance zwischen Performance-Verbesserung bei minimaler Genauigkeitsverschlechterung:⁷

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

FP8-Quantisierung erfordert eine Kalibrierung zur Bestimmung geeigneter Skalierungsfaktoren. Der Kalibrierungsprozess führt Inferenz auf repräsentativen Beispielen durch, um Aktivierungsbereiche zu messen:

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 liefert mittlere Performance-Verbesserung mit sehr geringem Genauigkeitsverlust und erfordert nur Minuten für die Kalibrierung. Hopper- und Blackwell-GPUs bieten Hardware-FP8-Unterstützung; Ada-GPUs unterstützen FP8 mit reduzierter Effizienz.

INT4 AWQ für speicherbeschränkte Einsätze

Wenn Speicherlimits die Modellgröße einschränken, komprimiert INT4 Activation-aware Weight Quantization Gewichte auf 4 Bit bei gleichzeitiger Beibehaltung akzeptabler Genauigkeit:⁸

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

INT4 AWQ glänzt in Small-Batch-Szenarien (Batch-Größe ≤ 4), wo Inferenz speichergebunden wird. Die Gewichts-Ladezeit dominiert die Berechnung, daher bietet aggressive Gewichtskompression erhebliche Beschleunigungen. Bei großen Batches verringert sich der Performance-Vorteil von INT4 AWQ, da die Berechnungsdichte zunimmt.

INT8 SmoothQuant für ausgewogene Optimierung

SmoothQuant verlagert die Quantisierungsschwierigkeit von Aktivierungen zu Gewichten und ermöglicht effektive INT8-Quantisierung ohne signifikanten Genauigkeitsverlust:

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

INT8 SmoothQuant bietet mittlere Performance-Verbesserung mit mittlerem Genauigkeitsverlust. Organisationen sollten zuerst FP8 versuchen und auf INT8 SQ zurückgreifen, wenn FP8-Ergebnisse die Anforderungen nicht erfüllen.

Framework zur Quantisierungsauswahl

NVIDIA empfiehlt die folgende Prioritätsreihenfolge:⁹

1. FP8 - Bester Performance/Genauigkeits-Kompromiss, erfordert Hopper/Blackwell
2. INT8 SmoothQuant - Gute Alternative für Ada-GPUs oder wenn FP8-Genauigkeit unzureichend
3. INT4 AWQ/GPTQ - Maximale Kompression für speicherbeschränkte Szenarien

Für den KV-Cache speziell wird FP8-Quantisierung gegenüber INT8 auf Hopper- und Ada-GPUs empfohlen, da in den meisten Fällen ein geringerer Genauigkeitsverlust auftritt.

Produktiveinsatz-Konfiguration

Optimaler TensorRT-LLM-Einsatz erfordert das Tuning mehrerer Parameter basierend auf Workload-Charakteristiken:

Engine-Build-Konfiguration

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: Standard 256 in neueren Versionen. Produktiveinsätze, die maximalen Durchsatz erreichen, erhöhen oft auf 2048 und nutzen die Inflight-Batching-Fähigkeiten voll aus.¹⁰

max_num_tokens: Steuert die Gesamtzahl der pro Batch-Iteration verarbeiteten Tokens. Standard 8192 balanciert Durchsatz mit Speicherverbrauch. Reduzieren für speicherbeschränkte Einsätze; vorsichtig mit Monitoring erhöhen.

use_paged_context_fmha: Aktiviert Paged Attention für effizientes KV-Cache-Management. Erforderlich bei Verwendung von Inflight Batching. Die Implementierung allokiert KV-Cache-Speicher vorab und benötigt etwa 60% mehr VRAM als die Modellgewichte allein.¹¹

Triton Inference Server-Integration

Produktiveinsätze verwenden typischerweise NVIDIA Triton Inference Server mit dem TensorRT-LLM-Backend:

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

Triton bietet Multi-Modell-Orchestrierung, Request-Queuing, Metrik-Erfassung und Kubernetes-native Skalierung. Der vorgefertigte NGC-Container enthält das TensorRT-LLM-Backend mit aktiviertem Inflight Batching und Paged KV-Cache-Unterstützung.

Speicherplanung

Schätzen Sie den Speicherbedarf vor dem Einsatz:

Gesamt-VRAM = Modellgewichte + KV-Cache + Aktivierungsspeicher + Runtime-Overhead

Modellgewichte (FP8): Parameter × 1 Byte
Modellgewichte (INT4): Parameter × 0,5 Bytes
KV-Cache: batch_size × seq_len × num_layers × 2 × hidden_dim × präzisions_bytes

Ein 70B-Parameter-Modell in FP8 benötigt ungefähr: - Gewichte: 70GB - KV-Cache (Batch 256, Seq 8192): ~120GB - Aktivierungen + Overhead: ~30GB - Gesamt: ~220GB (3x H100 80GB oder 2x H200 141GB)

Performance-Tuning-Workflow

Systematische Optimierung extrahiert maximale Performance aus TensorRT-LLM-Einsätzen:

Phase 1: Baseline-Messung

Verwenden Sie trtllm-bench für schnelle Performance-Bewertung:

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

Das Benchmarking-Utility setzt optimale Engine-Parameter automatisch und bietet Baseline-Performance ohne die volle Triton-Deployment-Komplexität.¹²

Phase 2: Quantisierungsauswahl

Testen Sie zuerst FP8 gegen die Genauigkeitsanforderungen. Wenn die Genauigkeit über akzeptable Schwellenwerte hinaus abnimmt, evaluieren Sie INT8 SQ oder INT4 AWQ. Führen Sie Evaluierungs-Benchmarks auf repräsentativen Aufgaben durch, nicht nur Perplexitätsmessungen.

Phase 3: Batch-Größen-Optimierung

Profilieren Sie den Durchsatz über Batch-Größen von 1 bis max_batch_size. Identifizieren Sie den Knickpunkt der Durchsatzkurve, wo zusätzliches Batching abnehmende Erträge liefert. Setzen Sie max_batch_size 20-30% über diesem Punkt, um Traffic-Spitzen aufzufangen.

Phase 4: KV-Cache-Tuning

Überwachen Sie die KV-Cache-Auslastung während produktiver Workloads. Wenn die Auslastung konstant 80% übersteigt, erhöhen Sie max_num_tokens oder reduzieren Sie max_batch_size. Wenn die Auslastung unter 50% bleibt, reduzieren Sie die Allokation, um Speicher für größere Batches freizugeben.

Phase 5: Kontinuierliches Monitoring

Verfolgen Sie Schlüsselmetriken in der Produktion: - Tokens pro Sekunde (Durchsatz) - Time-to-First-Token (Latenz) - Queue-Tiefe (Kapazität) - KV-Cache-Auslastung (Speicher) - GPU-Auslastung (Effizienz)

Erweiterte Optimierungen

Speculative Decoding

TensorRT-LLM unterstützt Speculative Decoding unter Verwendung kleinerer Draft-Modelle zur Vorhersage mehrerer Tokens, die vom Hauptmodell verifiziert werden. Die Technik bietet 1,5-2x Beschleunigung für kompatible Workloads:

# Speculative Decoding im Engine-Build aktivieren
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

Speculative Decoding profitiert latenz-sensitive Anwendungen, wo die Time-to-Completion wichtiger ist als der Durchsatz. Die Optimierung erfordert das Vorhalten sowohl des Draft- als auch des Target-Modells im Speicher.

Multi-GPU-Konfigurationen

TensorRT-LLM unterstützt Tensor Parallelism (TP), Pipeline Parallelism (PP) und Expert Parallelism (EP) für verteilte Inferenz:

# 4-Wege Tensor Parallelism
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

TP teilt jede Schicht über GPUs auf und erfordert All-Reduce-Operationen an jeder Schichtgrenze. PP teilt Schichten über GPUs in Pipeline-Stufen auf. Für Inferenz bietet TP typischerweise bessere Latenz, während PP ermöglicht

[Inhalt für Übersetzung gekürzt]