Optimasi TensorRT-LLM: Menguasai Stack Inferensi NVIDIA

Diperbarui 11 Desember 2025

Update Desember 2025: TensorRT-LLM mencapai 10.000+ token output/detik pada H100 dengan FP8, TTFT di bawah 100ms. Deployment produksi melaporkan throughput 4x lipat dibanding inferensi PyTorch native. Kernel fusion menggabungkan LayerNorm, matmuls, aktivasi ke dalam kernel CUDA tunggal. Inflight batching memaksimalkan utilisasi GPU. FP8 attention pada Hopper/Blackwell memberikan percepatan tambahan.

TensorRT-LLM dari NVIDIA memberikan performa inferensi mentah yang sulit ditandingi alternatif lain. Pada GPU H100 dengan presisi FP8, framework ini mencapai lebih dari 10.000 token output per detik pada throughput puncak dengan latensi time-to-first-token di bawah 100 milidetik.¹ Deployment produksi melaporkan peningkatan throughput hingga 4x lipat dibanding inferensi PyTorch native. Performa ini memiliki biaya: TensorRT-LLM membutuhkan keahlian konfigurasi lebih tinggi dan siklus optimasi lebih panjang dibanding alternatif yang lebih user-friendly seperti vLLM.

Bagi organisasi yang berkomitmen pada hardware NVIDIA dan bersedia menginvestasikan waktu engineering dalam optimasi, TensorRT-LLM mengekstrak performa maksimal dari infrastruktur GPU yang mahal. Memahami arsitektur framework, opsi kuantisasi, dan parameter tuning memungkinkan tim membangun sistem inferensi yang menjustifikasi investasi hardware premium melalui ekonomi token yang superior.

Arsitektur dan optimasi inti

TensorRT-LLM dibangun di atas optimizer inferensi TensorRT milik NVIDIA, memperluas framework kompilasi dengan optimasi khusus transformer. Library ini menyediakan API Python untuk definisi model bersama komponen runtime C++ untuk deployment produksi.

Kernel fusion: TensorRT-LLM menggabungkan beberapa operasi transformer ke dalam kernel CUDA tunggal yang teroptimasi. LayerNorm, perkalian matriks, penambahan bias, dan fungsi aktivasi dieksekusi bersama alih-alih membutuhkan peluncuran kernel terpisah dan transfer memori. Fusion mengurangi overhead peluncuran kernel dan mengeliminasi materialisasi tensor perantara.²

Kernel attention kustom: Implementasi yang dioptimasi secara manual dari multi-head dan grouped-query attention memanfaatkan instruksi Tensor Core untuk throughput maksimal. Varian Flash Attention mengurangi kebutuhan bandwidth memori sambil mempertahankan presisi numerik. Kernel FP8 attention pada GPU Hopper dan Blackwell memberikan percepatan tambahan.

Inflight batching: Batching statis tradisional memaksa semua request dalam batch menunggu sampai sequence terpanjang selesai. Inflight batching menambahkan request baru ke batch yang sedang berjalan pada setiap langkah generasi, memproses fase konteks dan generasi bersama.³ Pendekatan ini memaksimalkan utilisasi GPU dengan menjaga unit komputasi tetap sibuk bahkan saat request individual selesai.

Paged KV caching: Terinspirasi dari virtual memory sistem operasi, paged attention mengalokasikan KV cache dalam blok non-contiguous alih-alih membutuhkan region memori yang kontinu.⁴ Alokasi level blok memungkinkan berbagi KV cache antar request dengan prefix yang sama dan mencapai hampir nol waste memori dari fragmentasi internal.

Perbandingan performa: TensorRT-LLM vs vLLM

Kedua framework menargetkan inferensi LLM produksi, tetapi perbedaan arsitektur menciptakan profil performa yang berbeda:

TensorRT-LLM secara konsisten mengungguli vLLM dengan konfigurasi default, memberikan throughput 1,34x lebih tinggi pada sequence pendek dan time-per-output-token 2,72x lebih baik pada sequence panjang.⁵ Pada GPU B200, optimasi yang lebih dalam dari TensorRT-LLM untuk arsitektur Blackwell memperlebar gap performa lebih jauh.

vLLM menawarkan keunggulan dalam pengalaman developer:⁶ - API kompatibel OpenAI untuk penggantian drop-in - Deployment lebih sederhana tanpa langkah kompilasi - Optimasi model otomatis dengan default yang masuk akal - Dukungan hardware lebih luas di luar GPU NVIDIA

Rekomendasi: Deploy TensorRT-LLM ketika memaksimalkan efisiensi hardware menjustifikasi investasi engineering. Pilih vLLM untuk time-to-production lebih cepat atau ketika beroperasi pada skala lebih kecil di mana performa absolut kurang penting dibanding kecepatan pengembangan.

Strategi kuantisasi

TensorRT-LLM mendukung opsi kuantisasi yang ekstensif untuk menukar presisi dengan performa dan efisiensi memori. Memilih metode kuantisasi yang tepat bergantung pada batch size, kebutuhan akurasi, dan target hardware.

Kuantisasi FP8 (direkomendasikan pertama)

FP8 memberikan keseimbangan terbaik antara peningkatan performa dengan degradasi akurasi minimal:⁷

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

Kuantisasi FP8 membutuhkan kalibrasi untuk menentukan faktor scaling yang sesuai. Proses kalibrasi menjalankan inferensi pada sampel representatif untuk mengukur rentang aktivasi:

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 memberikan peningkatan performa menengah dengan dampak akurasi sangat rendah dan hanya membutuhkan menit untuk kalibrasi. GPU Hopper dan Blackwell menyediakan dukungan hardware FP8; GPU Ada mendukung FP8 dengan efisiensi yang berkurang.

INT4 AWQ untuk deployment dengan keterbatasan memori

Ketika keterbatasan memori membatasi ukuran model, Activation-aware Weight Quantization INT4 mengkompresi weight menjadi 4 bit sambil mempertahankan akurasi yang dapat diterima:⁸

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

INT4 AWQ unggul dalam skenario batch kecil (batch size ≤ 4) di mana inferensi menjadi memory-bound. Waktu loading weight mendominasi komputasi, sehingga kompresi weight yang agresif memberikan percepatan substansial. Untuk batch besar, keunggulan performa INT4 AWQ berkurang seiring peningkatan densitas komputasi.

INT8 SmoothQuant untuk optimasi seimbang

SmoothQuant memigrasikan kesulitan kuantisasi dari aktivasi ke weight, memungkinkan kuantisasi INT8 yang efektif tanpa kehilangan akurasi yang signifikan:

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

INT8 SmoothQuant memberikan peningkatan performa menengah dengan dampak akurasi menengah. Organisasi harus mencoba FP8 terlebih dahulu, beralih ke INT8 SQ jika hasil FP8 tidak memenuhi kebutuhan.

Framework pemilihan kuantisasi

NVIDIA merekomendasikan urutan prioritas berikut:⁹

1. FP8 - Tradeoff performa/akurasi terbaik, membutuhkan Hopper/Blackwell
2. INT8 SmoothQuant - Alternatif bagus untuk GPU Ada atau ketika akurasi FP8 tidak mencukupi
3. INT4 AWQ/GPTQ - Kompresi maksimal untuk skenario dengan keterbatasan memori

Untuk KV cache secara spesifik, kuantisasi FP8 direkomendasikan dibanding INT8 pada GPU Hopper dan Ada karena dampak akurasi yang lebih rendah dalam kebanyakan kasus.

Konfigurasi deployment produksi

Deployment TensorRT-LLM yang optimal membutuhkan tuning beberapa parameter berdasarkan karakteristik workload:

Konfigurasi engine build

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: Default 256 di versi terbaru. Deployment produksi yang mencapai throughput maksimal sering meningkatkan ke 2048, memanfaatkan sepenuhnya kemampuan inflight batching.¹⁰

max_num_tokens: Mengontrol total token yang diproses per iterasi batch. Default 8192 menyeimbangkan throughput dengan konsumsi memori. Kurangi untuk deployment dengan keterbatasan memori; tingkatkan dengan hati-hati sambil memantau.

use_paged_context_fmha: Mengaktifkan paged attention untuk manajemen KV cache yang efisien. Diperlukan saat menggunakan inflight batching. Implementasi ini melakukan pre-alokasi memori KV cache, membutuhkan sekitar 60% lebih banyak VRAM dibanding weight model saja.¹¹

Integrasi Triton Inference Server

Deployment produksi biasanya menggunakan NVIDIA Triton Inference Server dengan backend TensorRT-LLM:

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

Triton menyediakan orkestrasi multi-model, request queuing, pengumpulan metrik, dan scaling native Kubernetes. Container NGC yang sudah di-build menyertakan backend TensorRT-LLM dengan dukungan inflight batching dan paged KV cache yang diaktifkan.

Perencanaan memori

Estimasi kebutuhan memori sebelum deployment:

Total VRAM = Model Weights + KV Cache + Activation Memory + Runtime Overhead

Model Weights (FP8): Parameters × 1 byte
Model Weights (INT4): Parameters × 0.5 bytes
KV Cache: batch_size × seq_len × num_layers × 2 × hidden_dim × precision_bytes

Model dengan 70B parameter dalam FP8 membutuhkan sekitar: - Weights: 70GB - KV Cache (batch 256, seq 8192): ~120GB - Aktivasi + overhead: ~30GB - Total: ~220GB (3x H100 80GB atau 2x H200 141GB)

Workflow tuning performa

Optimasi sistematis mengekstrak performa maksimal dari deployment TensorRT-LLM:

Fase 1: Pengukuran baseline

Gunakan trtllm-bench untuk penilaian performa cepat:

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

Utilitas benchmarking mengatur parameter engine optimal secara otomatis, memberikan performa baseline tanpa kompleksitas deployment Triton penuh.¹²

Fase 2: Pemilihan kuantisasi

Uji FP8 terlebih dahulu terhadap kebutuhan akurasi. Jika akurasi menurun melampaui threshold yang dapat diterima, evaluasi INT8 SQ atau INT4 AWQ. Jalankan benchmark evaluasi pada task representatif, bukan hanya pengukuran perplexity.

Fase 3: Optimasi batch size

Profil throughput di seluruh batch size dari 1 hingga max_batch_size. Identifikasi titik knee dari kurva throughput di mana batching tambahan memberikan return yang berkurang. Set max_batch_size 20-30% di atas titik ini untuk mengakomodasi lonjakan traffic.

Fase 4: Tuning KV cache

Pantau utilisasi KV cache selama workload produksi. Jika utilisasi konsisten melebihi 80%, tingkatkan max_num_tokens atau kurangi max_batch_size. Jika utilisasi tetap di bawah 50%, kurangi alokasi untuk membebaskan memori bagi batch yang lebih besar.

Fase 5: Monitoring berkelanjutan

Lacak metrik kunci di produksi: - Token per detik (throughput) - Time-to-first-token (latensi) - Queue depth (kapasitas) - Utilisasi KV cache (memori) - Utilisasi GPU (efisiensi)

Optimasi lanjutan

Speculative decoding

TensorRT-LLM mendukung speculative decoding menggunakan model draft yang lebih kecil untuk memprediksi beberapa token yang diverifikasi oleh model utama. Teknik ini memberikan percepatan 1,5-2x untuk workload yang kompatibel:

# Aktifkan speculative decoding dalam engine build
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

Speculative decoding menguntungkan aplikasi yang sensitif terhadap latensi di mana time-to-completion lebih penting daripada throughput. Optimasi ini membutuhkan pemeliharaan baik model draft maupun target di memori.

Konfigurasi multi-GPU

TensorRT-LLM mendukung tensor parallelism (TP), pipeline parallelism (PP), dan expert parallelism (EP) untuk inferensi terdistribusi:

# 4-way tensor parallelism
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

TP membagi setiap layer di seluruh GPU, membutuhkan operasi all-reduce pada setiap batas layer. PP membagi layer di seluruh GPU dalam tahap pipeline. Untuk inferensi, TP biasanya memberikan latensi lebih baik sementara PP memungkinkan

[Konten dipotong untuk terjemahan]