TensorRT-LLM ऑप्टिमाइज़ेशन: NVIDIA के इन्फरेंस स्टैक में महारत

11 दिसंबर, 2025 को अपडेट किया गया

दिसंबर 2025 अपडेट: TensorRT-LLM H100 पर FP8 के साथ 10,000+ आउटपुट टोकन/सेकंड हासिल कर रहा है, 100ms से कम TTFT के साथ। प्रोडक्शन डिप्लॉयमेंट नेटिव PyTorch की तुलना में 4x थ्रूपुट रिपोर्ट कर रहे हैं। Kernel fusion LayerNorm, matmuls, activations को सिंगल CUDA kernels में मिला रहा है। Inflight batching GPU उपयोग को अधिकतम कर रहा है। Hopper/Blackwell पर FP8 attention अतिरिक्त स्पीडअप दे रहा है।

NVIDIA का TensorRT-LLM रॉ इन्फरेंस परफॉर्मेंस देता है जिसे विकल्प मैच करने में संघर्ष करते हैं। H100 GPUs पर FP8 प्रिसिजन के साथ, यह फ्रेमवर्क पीक थ्रूपुट पर 10,000 से अधिक आउटपुट टोकन प्रति सेकंड हासिल करता है, time-to-first-token लेटेंसी 100 मिलीसेकंड से कम के साथ।¹ प्रोडक्शन डिप्लॉयमेंट नेटिव PyTorch इन्फरेंस की तुलना में 4x तक थ्रूपुट सुधार रिपोर्ट करते हैं। परफॉर्मेंस की एक कीमत है: TensorRT-LLM को vLLM जैसे यूज़र-फ्रेंडली विकल्पों की तुलना में अधिक कॉन्फ़िगरेशन एक्सपर्टीज़ और लंबे ऑप्टिमाइज़ेशन साइकल की आवश्यकता होती है।

NVIDIA हार्डवेयर के प्रति प्रतिबद्ध और ऑप्टिमाइज़ेशन में इंजीनियरिंग समय निवेश करने को तैयार संगठनों के लिए, TensorRT-LLM महंगे GPU इंफ्रास्ट्रक्चर से अधिकतम परफॉर्मेंस निकालता है। फ्रेमवर्क की आर्किटेक्चर, क्वांटाइज़ेशन विकल्पों और ट्यूनिंग पैरामीटर्स को समझना टीमों को ऐसे इन्फरेंस सिस्टम बनाने में सक्षम बनाता है जो बेहतर टोकन इकोनॉमिक्स के माध्यम से प्रीमियम हार्डवेयर निवेश को जस्टिफाई करते हैं।

आर्किटेक्चर और कोर ऑप्टिमाइज़ेशन

TensorRT-LLM NVIDIA के TensorRT इन्फरेंस ऑप्टिमाइज़र पर बनाया गया है, कंपाइलेशन फ्रेमवर्क को transformer-specific ऑप्टिमाइज़ेशन के साथ विस्तारित करता है। लाइब्रेरी प्रोडक्शन डिप्लॉयमेंट के लिए C++ रनटाइम कंपोनेंट्स के साथ मॉडल डेफिनिशन के लिए Python APIs प्रदान करती है।

Kernel fusion: TensorRT-LLM कई transformer ऑपरेशंस को सिंगल ऑप्टिमाइज़्ड CUDA kernels में जोड़ता है। LayerNorm, matrix multiplications, bias additions, और activation functions अलग kernel launches और memory transfers की आवश्यकता के बजाय एक साथ execute होते हैं। Fusion kernel launch overhead को कम करता है और intermediate tensor materialization को समाप्त करता है।²

Custom attention kernels: Multi-head और grouped-query attention के हैंड-ऑप्टिमाइज़्ड implementations अधिकतम थ्रूपुट के लिए Tensor Core instructions का लाभ उठाते हैं। Flash Attention variants न्यूमेरिकल प्रिसिजन बनाए रखते हुए memory bandwidth आवश्यकताओं को कम करते हैं। Hopper और Blackwell GPUs पर FP8 attention kernels अतिरिक्त स्पीडअप प्रदान करते हैं।

Inflight batching: पारंपरिक static batching एक batch में सभी requests को सबसे लंबे sequence के पूरा होने तक इंतज़ार करने के लिए मजबूर करता है। Inflight batching प्रत्येक generation step पर running batches में नई requests जोड़ता है, context और generation phases को एक साथ प्रोसेस करता है।³ यह दृष्टिकोण GPU उपयोग को अधिकतम करता है individual requests के पूरा होने पर भी compute units को busy रखकर।

Paged KV caching: ऑपरेटिंग सिस्टम वर्चुअल मेमोरी से प्रेरित, paged attention KV cache को continuous memory regions की आवश्यकता के बजाय non-contiguous blocks में allocate करता है।⁴ Block-level allocation common prefixes वाली requests के बीच KV cache sharing को सक्षम बनाता है और internal fragmentation से near-zero memory waste हासिल करता है।

परफॉर्मेंस तुलना: TensorRT-LLM vs vLLM

दोनों फ्रेमवर्क प्रोडक्शन LLM इन्फरेंस को टारगेट करते हैं, लेकिन आर्किटेक्चरल अंतर अलग परफॉर्मेंस प्रोफाइल बनाते हैं:

TensorRT-LLM डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ vLLM को लगातार आउटपरफॉर्म करता है, शॉर्ट सीक्वेंस पर 1.34x अधिक थ्रूपुट और लॉन्ग सीक्वेंस पर 2.72x बेहतर time-per-output-token देता है।⁵ B200 GPUs पर, Blackwell आर्किटेक्चर के लिए TensorRT-LLM का गहरा ऑप्टिमाइज़ेशन परफॉर्मेंस गैप को और बढ़ाता है।

vLLM डेवलपर एक्सपीरियंस में फायदे प्रदान करता है:⁶ - Drop-in replacement के लिए OpenAI-compatible API - कंपाइलेशन स्टेप के बिना सरल डिप्लॉयमेंट - सेंसिबल डिफ़ॉल्ट्स के साथ ऑटोमैटिक मॉडल ऑप्टिमाइज़ेशन - NVIDIA GPUs से परे व्यापक हार्डवेयर सपोर्ट

सिफारिश: TensorRT-LLM तब डिप्लॉय करें जब हार्डवेयर एफिशिएंसी को अधिकतम करना इंजीनियरिंग निवेश को जस्टिफाई करता हो। तेज़ time-to-production के लिए या जब छोटे स्केल पर ऑपरेट कर रहे हों जहाँ absolute परफॉर्मेंस development velocity से कम मायने रखता है, vLLM चुनें।

क्वांटाइज़ेशन स्ट्रैटेजीज़

TensorRT-LLM प्रिसिजन को परफॉर्मेंस और मेमोरी एफिशिएंसी के खिलाफ ट्रेड करने के लिए व्यापक क्वांटाइज़ेशन विकल्पों का समर्थन करता है। सही क्वांटाइज़ेशन मेथड चुनना batch size, accuracy requirements, और target hardware पर निर्भर करता है।

FP8 क्वांटाइज़ेशन (पहले इसकी सिफारिश)

FP8 न्यूनतम accuracy degradation के साथ परफॉर्मेंस सुधार का सबसे अच्छा संतुलन प्रदान करता है:⁷

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

FP8 क्वांटाइज़ेशन को उचित scaling factors निर्धारित करने के लिए calibration की आवश्यकता होती है। Calibration प्रक्रिया activation ranges को मापने के लिए representative samples पर inference चलाती है:

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 बहुत कम accuracy impact के साथ मध्यम परफॉर्मेंस सुधार देता है और calibration के लिए केवल मिनटों की आवश्यकता होती है। Hopper और Blackwell GPUs हार्डवेयर FP8 सपोर्ट प्रदान करते हैं; Ada GPUs कम efficiency के साथ FP8 को सपोर्ट करते हैं।

मेमोरी-कंस्ट्रेंड डिप्लॉयमेंट के लिए INT4 AWQ

जब मेमोरी लिमिट मॉडल साइज़ को सीमित करती है, INT4 Activation-aware Weight Quantization acceptable accuracy बनाए रखते हुए weights को 4 bits में compress करता है:⁸

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

INT4 AWQ small-batch scenarios (batch size ≤ 4) में उत्कृष्ट है जहाँ inference memory-bound हो जाता है। Weight loading time computation पर हावी हो जाता है, इसलिए aggressive weight compression पर्याप्त स्पीडअप प्रदान करता है। Large batches के लिए, INT4 AWQ का परफॉर्मेंस एडवांटेज कम हो जाता है क्योंकि computation density बढ़ती है।

संतुलित ऑप्टिमाइज़ेशन के लिए INT8 SmoothQuant

SmoothQuant क्वांटाइज़ेशन कठिनाई को activations से weights में माइग्रेट करता है, महत्वपूर्ण accuracy loss के बिना प्रभावी INT8 क्वांटाइज़ेशन को सक्षम बनाता है:

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

INT8 SmoothQuant मध्यम accuracy impact के साथ मध्यम परफॉर्मेंस सुधार प्रदान करता है। संगठनों को पहले FP8 आज़माना चाहिए, अगर FP8 परिणाम आवश्यकताओं को पूरा नहीं करते तो INT8 SQ पर वापस आना चाहिए।

क्वांटाइज़ेशन सेलेक्शन फ्रेमवर्क

NVIDIA निम्नलिखित प्राथमिकता क्रम की सिफारिश करता है:⁹

1. FP8 - सबसे अच्छा परफॉर्मेंस/accuracy ट्रेडऑफ, Hopper/Blackwell की आवश्यकता
2. INT8 SmoothQuant - Ada GPUs के लिए या जब FP8 accuracy अपर्याप्त हो तो अच्छा विकल्प
3. INT4 AWQ/GPTQ - मेमोरी-कंस्ट्रेंड scenarios के लिए अधिकतम compression

KV cache के लिए विशेष रूप से, Hopper और Ada GPUs पर INT8 की तुलना में FP8 क्वांटाइज़ेशन की सिफारिश की जाती है क्योंकि ज्यादातर मामलों में accuracy impact कम होता है।

प्रोडक्शन डिप्लॉयमेंट कॉन्फ़िगरेशन

इष्टतम TensorRT-LLM डिप्लॉयमेंट के लिए workload characteristics के आधार पर कई parameters को ट्यून करने की आवश्यकता होती है:

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: हाल के versions में डिफ़ॉल्ट 256। अधिकतम थ्रूपुट हासिल करने वाले प्रोडक्शन डिप्लॉयमेंट अक्सर 2048 तक बढ़ाते हैं, inflight batching capabilities का पूरा लाभ उठाते हुए।¹⁰

max_num_tokens: प्रति batch iteration प्रोसेस किए गए कुल tokens को नियंत्रित करता है। डिफ़ॉल्ट 8192 थ्रूपुट को memory consumption के साथ संतुलित करता है। मेमोरी-कंस्ट्रेंड डिप्लॉयमेंट के लिए कम करें; मॉनिटरिंग के साथ सावधानी से बढ़ाएं।

use_paged_context_fmha: कुशल KV cache management के लिए paged attention को सक्षम बनाता है। Inflight batching का उपयोग करते समय आवश्यक। Implementation KV cache memory को pre-allocate करता है, जिसके लिए model weights की तुलना में लगभग 60% अधिक VRAM की आवश्यकता होती है।¹¹

Triton Inference Server इंटीग्रेशन

प्रोडक्शन डिप्लॉयमेंट आमतौर पर TensorRT-LLM backend के साथ NVIDIA Triton Inference Server का उपयोग करते हैं:

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

Triton multi-model orchestration, request queuing, metrics collection, और Kubernetes-native scaling प्रदान करता है। Pre-built NGC container में inflight batching और paged KV cache support enabled के साथ TensorRT-LLM backend शामिल है।

मेमोरी प्लानिंग

डिप्लॉयमेंट से पहले memory requirements का अनुमान लगाएं:

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

FP8 में 70B parameter model के लिए लगभग आवश्यकता: - Weights: 70GB - KV Cache (batch 256, seq 8192): ~120GB - Activations + overhead: ~30GB - कुल: ~220GB (3x H100 80GB या 2x H200 141GB)

परफॉर्मेंस ट्यूनिंग वर्कफ़्लो

व्यवस्थित ऑप्टिमाइज़ेशन TensorRT-LLM डिप्लॉयमेंट से अधिकतम परफॉर्मेंस निकालता है:

फेज़ 1: बेसलाइन मापन

त्वरित परफॉर्मेंस असेसमेंट के लिए trtllm-bench का उपयोग करें:

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

Benchmarking utility स्वचालित रूप से optimal engine parameters सेट करती है, full Triton deployment complexity के बिना baseline performance प्रदान करती है।¹²

फेज़ 2: क्वांटाइज़ेशन सेलेक्शन

पहले accuracy requirements के खिलाफ FP8 टेस्ट करें। अगर accuracy acceptable thresholds से परे degrade होती है, INT8 SQ या INT4 AWQ का मूल्यांकन करें। Representative tasks पर evaluation benchmarks चलाएं, केवल perplexity measurements पर नहीं।

फेज़ 3: Batch size ऑप्टिमाइज़ेशन

1 से max_batch_size तक batch sizes में थ्रूपुट प्रोफाइल करें। थ्रूपुट curve के knee को पहचानें जहाँ अतिरिक्त batching diminishing returns प्रदान करता है। Traffic spikes को accommodate करने के लिए इस point से 20-30% ऊपर max_batch_size सेट करें।

फेज़ 4: KV cache ट्यूनिंग

प्रोडक्शन workloads के दौरान KV cache utilization को मॉनिटर करें। अगर utilization लगातार 80% से अधिक है, max_num_tokens बढ़ाएं या max_batch_size कम करें। अगर utilization 50% से नीचे रहता है, बड़े batches के लिए memory free करने के लिए allocation कम करें।

फेज़ 5: निरंतर मॉनिटरिंग

प्रोडक्शन में key metrics ट्रैक करें: - Tokens per second (थ्रूपुट) - Time-to-first-token (लेटेंसी) - Queue depth (क्षमता) - KV cache utilization (मेमोरी) - GPU utilization (एफिशिएंसी)

एडवांस्ड ऑप्टिमाइज़ेशन

Speculative decoding

TensorRT-LLM main model द्वारा verify किए गए multiple tokens को predict करने के लिए smaller draft models का उपयोग करके speculative decoding को सपोर्ट करता है। यह तकनीक compatible workloads के लिए 1.5-2x स्पीडअप प्रदान करती है:

# Enable speculative decoding in engine build
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

Speculative decoding latency-sensitive applications को लाभ पहुंचाता है जहाँ time-to-completion थ्रूपुट से अधिक मायने रखता है। ऑप्टिमाइज़ेशन के लिए draft और target दोनों models को memory में maintain करने की आवश्यकता होती है।

Multi-GPU कॉन्फ़िगरेशन

TensorRT-LLM distributed inference के लिए tensor parallelism (TP), pipeline parallelism (PP), और expert parallelism (EP) को सपोर्ट करता है:

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

TP प्रत्येक layer को GPUs में split करता है, प्रत्येक layer boundary पर all-reduce operations की आवश्यकता होती है। PP layers को pipeline stages में GPUs में split करता है। Inference के लिए, TP आमतौर पर बेहतर latency प्रदान करता है जबकि PP सक्षम बनाता है

[अनुवाद के लिए कंटेंट ट्रंकेट किया गया]