अंतिम समीक्षा: जून 2026
NCP-GENL परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
इंटेंस INT quantization के सटीकता पर नकारात्मक प्रभाव के बिना H100/Blackwell पर कम latency की आवश्यकता है।
TensorRT-LLM के माध्यम से FP8 (E4M3) quantization का उपयोग करें; Hopper और Blackwell में native FP8 Tensor Cores हैं।
क्यों: FP8, INT8 की तुलना में dynamic range को बेहतर ढंग से संरक्षित करता है और Hopper+ पर पूर्ण हार्डवेयर गति से चलता है, जिससे INT8-क्लास throughput पर लगभग FP16 गुणवत्ता मिलती है।
मॉडल मुश्किल से GPU memory में फिट होता है और throughput memory-bandwidth-bound है।
INT4 weight-only quantization (AWQ या GPTQ) लागू करें; activations को FP16/FP8 में रखें।
क्यों: Weight-only INT4 लगभग INT8 की तुलना में memory को आधा कर देता है और bandwidth के दबाव को कम करता है; activation precision उच्च रहता है इसलिए सटीकता का नुकसान कम होता है।
post-training quantization और quantization-aware training के बीच निर्णय लेना।
PTQ से शुरू करें (एक प्रतिनिधि सैंपल पर कैलिब्रेट करें); QAT पर तभी वापस जाएं जब PTQ सटीकता का नुकसान बजट से अधिक हो।
क्यों: PTQ तेज़ है और उसे किसी retraining की आवश्यकता नहीं है; QAT सटीकता को पुनर्प्राप्त करता है लेकिन एक training run का खर्च आता है, इसलिए इसे precision-critical मॉडलों के लिए आरक्षित रखें।
लंबे-context serving में जहाँ KV cache memory पर हावी होता है और batch size को सीमित करता है।
TensorRT-LLM में FP8 या INT8 KV-cache quantization सक्षम करें।
क्यों: KV cache sequence length × batch के साथ बढ़ता है; इसे quantize करने से बड़ी batches और लंबे contexts के लिए memory खाली होती है, जिसका गुणवत्ता पर न्यूनतम प्रभाव पड़ता है।
मिश्रित रिक्वेस्ट लंबाई static batching के साथ GPU निष्क्रिय समय का कारण बनती है।
TensorRT-LLM में in-flight (continuous) batching का उपयोग करें ताकि समाप्त हुई sequences को बाहर कर दिया जाए और नई sequences बीच में ही जुड़ जाएं।
क्यों: Continuous batching GPU को संतृप्त रखता है और heterogeneous request streams के लिए throughput को static batching से कहीं अधिक बढ़ाता है।
एक बड़ा teacher मॉडल गुणवत्ता को पूरा करता है लेकिन latency और cost लक्ष्य को पूरा नहीं कर पाता।
एक छोटे student मॉडल में Distill करें, फिर inference के लिए student को quantize करें।
क्यों: Distillation क्षमता को एक सस्ती architecture में स्थानांतरित करता है; quantization के साथ मिलकर यह cost/latency बचत को बढ़ाता है।
एक interactive use case के लिए single-stream latency बहुत अधिक है।
एक छोटे draft मॉडल के साथ speculative decoding लागू करें जिसे target मॉडल द्वारा सत्यापित किया गया हो।
क्यों: draft कई tokens का प्रस्ताव करता है जिन्हें बड़ा मॉडल एक पास में सत्यापित करता है, जिससे output distribution बदले बिना wall-clock latency कम हो जाती है।
हर चीज़ को INT4 में quantize करने से कुछ संवेदनशील layers पर सटीकता कम हो जाती है।
mixed-precision का उपयोग करें: संवेदनशील layers (जैसे final projection, attention) को उच्च precision पर रखें और बाकी को quantize करें।
क्यों: प्रति-layer संवेदनशीलता भिन्न होती है; selective precision वहाँ सटीकता की रक्षा करती है जहाँ यह मायने रखती है जबकि weights के बड़े हिस्से को अभी भी कम करती है।
एक उचित quantization scheme के बावजूद PTQ सटीकता खराब है।
production traffic से मेल खाते हुए एक in-distribution सैंपल (सैकड़ों प्रतिनिधि prompts) के साथ recalibrate करें।
क्यों: Calibration activation ranges सेट करता है; एक गैर-प्रतिनिधि सैंपल खराब scales और टाली जा सकने वाली सटीकता का नुकसान पैदा करता है।
मॉडल weights एक सिंगल GPU से अधिक हैं लेकिन एक NVLink-कनेक्टेड node में फिट होते हैं।
node में GPUs के बीच tensor parallelism का उपयोग करें।
क्यों: Tensor parallelism प्रत्येक layer को shards करता है और प्रत्येक चरण पर activations का आदान-प्रदान करता है, इसलिए इसे NVLink/NVSwitch की उच्च intra-node bandwidth की आवश्यकता होती है।
मॉडल एक node के लिए बहुत बड़ा है और इसे InfiniBand पर nodes तक फैलाना चाहिए।
nodes के बीच pipeline parallelism जोड़ें, प्रत्येक node के भीतर tensor parallelism बनाए रखते हुए।
क्यों: Pipeline parallelism केवल stage boundaries पर संचार करता है, धीमे inter-node लिंक्स को सहन करता है; bandwidth-hungry tensor parallel को NVLink के लिए आरक्षित रखें।
अधिक GPUs तक scaling करने से throughput लाभ कम होते जाते हैं।
bottleneck को वर्गीकृत करने के लिए Nsight Systems के साथ profile करें; यदि collectives हावी हैं, तो parallel degree कम करें या topology में सुधार करें।
क्यों: एक बिंदु से आगे, all-reduce/all-gather overhead अतिरिक्त compute से अधिक हो जाता है; communication-bound बनाम compute-bound का निदान समाधान में मार्गदर्शन करता है।
छोटे batch sizes पर प्रति-चरण kernel launch overhead decode latency को बढ़ाता है।
decode लूप को कैप्चर और रीप्ले करने के लिए CUDA Graphs सक्षम करें।
क्यों: CUDA Graphs कई छोटे launches को एक रीप्ले में ढहा देता है, जिससे CPU-side launch overhead हट जाता है जो कम batch sizes पर हावी होता है।
एक धीमे लिंक पर रखे गए Tensor-parallel ranks stalls का कारण बनते हैं।
Tensor-parallel ranks को NVLink/NVSwitch साझा करने वाले GPUs पर पिन करें; pipeline stages को nodes के पार रखें।
क्यों: गलत प्लेसमेंट उच्च-आवृत्ति collectives को PCIe या InfiniBand पर रूट करता है, जिससे पूरी pipeline धीमी हो जाती है।
Attention memory-bound है और प्राप्य context length को सीमित करता है।
FlashAttention (fused, IO-aware attention kernels) का उपयोग करें जैसा कि TensorRT-LLM/NeMo stack द्वारा प्रदान किया गया है।
क्यों: FlashAttention पूर्ण attention matrix को materialize करने से बचता है, memory traffic को कम करता है और उच्च गति पर लंबी sequences को सक्षम बनाता है।
कई छोटे मॉडल पूर्ण H100 GPUs का कम उपयोग करते हैं।
प्रत्येक मॉडल को एक slice पर अलग करने के लिए MIG (Multi-Instance GPU) के साथ GPUs को Partition करें।
क्यों: MIG हार्डवेयर-पृथक partitions प्रदान करता है, उपयोगिता बढ़ाता है और co-located छोटे workloads के लिए अनुमानित QoS प्रदान करता है।
डाउनस्ट्रीम सेवा को हर बार कड़ाई से वैध JSON की आवश्यकता होती है।
केवल prompt wording पर निर्भर रहने के बजाय serving runtime में guided/constrained decoding (grammar या JSON schema) का उपयोग करें।
क्यों: Constrained decoding generation समय पर अमान्य tokens को mask करता है, schema-valid output की गारंटी देता है जहाँ prompting केवल विफलता दर को कम करता है।
कार्य को एक सुसंगत प्रारूप की आवश्यकता है जिसे base मॉडल असंगत रूप से संभालता है।
पहले few-shot exemplars का प्रयास करें; केवल तभी fine-tuning पर जाएं जब prompt-आधारित steering plateaus पर पहुंच जाए या token cost अत्यधिक हो।
क्यों: Few-shot zero-training है और तुरंत संपादन योग्य है; fine-tuning तभी जीतता है जब पैटर्न स्थिर होते हैं और prompt overhead नुकसान पहुंचाता है।
बहु-चरणीय reasoning कार्य गलत अंतिम उत्तर देता है।
chain-of-thought ('चरण-दर-चरण सोचें') उत्पन्न करें या अंतिम उत्तर से पहले एक structured reasoning template का उपयोग करें।
क्यों: मध्यवर्ती चरणों को उजागर करने से multi-hop सटीकता में सुधार होता है और त्रुटियों को auditable बनाता है, अतिरिक्त tokens की लागत पर।
एक prompt tweak ने चुपचाप उत्पादन गुणवत्ता को कम कर दिया।
system prompts को कोड के रूप में version करें, eval के पीछे परिवर्तनों को गेट करें, और मॉडल artifacts के समान CI के माध्यम से roll out करें।
क्यों: Prompts मॉडल contract का हिस्सा हैं; unversioned संपादन untracked regressions और unreproducible व्यवहार का कारण बनते हैं।
मॉडल अपने training data के बाहर के तथ्यों को hallucinate करता है।
प्रासंगिक context को पुनः प्राप्त करें और इसे prompt में एक निर्देश के साथ इंजेक्ट करें कि केवल प्रदान किए गए context से ही उत्तर दें।
क्यों: पुनः प्राप्त passages पर grounding मॉडल को स्रोत सामग्री तक सीमित करता है और knowledge-intensive queries पर hallucination को कम करता है।
Latency और cost अधिक हैं क्योंकि prompts फूले हुए हैं।
prompt को ट्रिम और कंप्रेस करें: निर्देशों को dedupe करें, पुनः प्राप्त context का सारांश करें, और exemplars को न्यूनतम तक सीमित करें जो गुणवत्ता बनाए रखता है।
क्यों: Prefill इनपुट tokens के साथ बढ़ता है; लीन prompts मापने योग्य गुणवत्ता हानि के बिना latency और प्रति-request cost दोनों को कम करते हैं।
उपयोगकर्ता-प्रदत्त पाठ system instruction को ओवरराइड कर सकता है।
विश्वसनीय निर्देशों को स्पष्ट delimiters के साथ अविश्वसनीय इनपुट से अलग करें और पुनः प्राप्त/उपयोगकर्ता सामग्री को डेटा के रूप में मानें, न कि आदेशों के रूप में।
क्यों: अविश्वसनीय पाठ को instruction channel में concatenate करना prompt injection को आमंत्रित करता है; स्पष्ट सीमाएं attack surface को कम करती हैं।
एक सीमित GPU बजट पर एक बड़े base मॉडल को एक domain के अनुकूल बनाना।
LoRA का उपयोग करें: low-rank adapters को प्रशिक्षित करें और base weights को फ्रीज करें।
क्यों: LoRA parameters के एक छोटे से हिस्से को प्रशिक्षित करता है, जिससे memory और compute में भारी कमी आती है जबकि अधिकांश narrow कार्यों पर पूर्ण fine-tuning से मेल खाता है।
एक 70B मॉडल का LoRA training भी उपलब्ध memory में फिट नहीं होगा।
QLoRA का उपयोग करें: frozen base को 4-bit (NF4) में quantize करें और ऊपर LoRA adapters को प्रशिक्षित करें।
क्यों: base को 4-bit में रखते हुए केवल adapters को अपडेट करने से बड़े मॉडलों को न्यूनतम सटीकता हानि के साथ एक सिंगल GPU पर fine-tune किया जा सकता है।
एक नए fine-tuning कार्य के लिए LoRA rank चुनना।
एक मामूली rank (जैसे 8-16) से शुरू करें; इसे तभी बढ़ाएं जब कार्य जटिल हो और validation loss अभी भी सुधर रहा हो।
क्यों: उच्च rank क्षमता और लागत बढ़ाता है; over-ranking छोटे datasets पर overfitting का जोखिम उठाता है जबकि under-ranking प्राप्य गुणवत्ता को सीमित करता है।
मॉडल निर्देशों का पालन करता है लेकिन इसके outputs मानवीय पसंद से मेल नहीं खाते हैं।
पहले supervised fine-tuning करें, फिर RLHF या DPO के साथ preference alignment करें।
क्यों: SFT प्रारूप और कार्य सिखाता है; preference optimization उन वैध उत्तरों को आकार देता है जिन्हें मनुष्य वास्तव में पसंद करते हैं।
PPO के साथ RLHF अस्थिर और operationally भारी है।
reward model + PPO loop के बजाय एक preference dataset पर DPO (Direct Preference Optimization) का उपयोग करें।
क्यों: DPO एक अलग reward model या RL rollout के बिना सीधे preferences को ऑप्टिमाइज़ करता है, जिससे pipeline सरल होती है और स्थिरता में सुधार होता है।
LoRA adapter serving समय पर प्रति-रिक्वेस्ट overhead जोड़ता है।
केवल एक adapter को serve किए जाने पर डिप्लॉयमेंट के लिए adapter weights को base में मर्ज करें।
क्यों: एक merged मॉडल में inference पर कोई adapter branch नहीं होता है; adapters को तभी अलग रखें जब एक base पर कई कार्यों को hot-swap कर रहे हों।
एक संकीर्ण कार्य पर fine-tuning सामान्य क्षमताओं को कम करता है।
general/instruction डेटा का एक slice मिलाएं, learning rate कम करें, और पूर्ण fine-tuning के बजाय PEFT को प्राथमिकता दें।
क्यों: general डेटा को फिर से चलाना और weight movement को सीमित करना व्यापक कौशल को संरक्षित करता है जबकि अभी भी नए कार्य को सीख रहा है।
Pretraining/fine-tuning डेटा में भारी near-duplicates होते हैं।
training से पहले fuzzy deduplication (जैसे MinHash/LSH) चलाएं।
क्यों: Duplicates compute को बर्बाद करते हैं, मॉडल को दोहराई गई सामग्री की ओर bias करते हैं, और memorization का कारण बन सकते हैं; dedup प्रति token generalization में सुधार करता है।
training के बाद संदिग्ध रूप से उच्च benchmark scores।
n-gram overlap filtering के माध्यम से benchmark/eval डेटा के खिलाफ training सेट को Decontaminate करें।
क्यों: टेस्ट आइटम्स का leakage मेट्रिक्स को बढ़ाता है और वास्तविक गुणवत्ता को छुपाता है; decontamination मूल्यांकन को ईमानदार रखता है।
corpus में governance नियमों के अधीन व्यक्तिगत डेटा हो सकता है।
training से पहले डेटा pipeline में एक PII detection-and-redaction stage जोड़ें।
क्यों: raw PII पर training regurgitation और compliance उल्लंघनों का जोखिम उठाता है; शुरुआत में scrubbing एक leaky मॉडल को ठीक करने से कहीं अधिक सस्ता है।
raw web-scraped डेटा शोरगुल वाला है और मॉडल की गुणवत्ता को कम करता है।
कम गुणवत्ता वाले, boilerplate और spam दस्तावेजों को हटाने के लिए गुणवत्ता filters (heuristics प्लस एक classifier) लागू करें।
क्यों: एक threshold से परे डेटा गुणवत्ता raw मात्रा से अधिक महत्वपूर्ण है; filtering एक ही training बजट से बेहतर मॉडल उत्पन्न करता है।
Fine-tuning डेटा को NeMo training pipeline में ठीक से feed होना चाहिए।
अपेक्षित NeMo प्रारूप (जैसे prompt/response fields के साथ JSONL) में कनवर्ट करें और मॉडल के tokenizer के साथ tokenize करें।
क्यों: प्रारूप और tokenizer mismatches silent truncation या label errors का कारण बनते हैं; NeMo के schema के अनुरूप होने से training reproducible रहती है।
OpenAI-compatible API के साथ उत्पादन LLM endpoint को तेजी से स्थापित करना।
एक NVIDIA NIM microservice के साथ Deploy करें; non-standard pre/post-processing आवश्यकताओं के लिए ही एक custom Triton ensemble बनाएं।
क्यों: NIM optimized engines और एक मानक API को out of the box भेजता है; custom Triton का प्रयास तभी सार्थक है जब आपको bespoke pipeline control की आवश्यकता हो।
स्वतंत्र रिक्वेस्ट single-request serving की तुलना में तेजी से आती हैं।
समवर्ती रिक्वेस्ट को GPU batches में coalescing करने के लिए Triton dynamic batching सक्षम करें।
क्यों: Batching रिक्वेस्ट के बीच kernel overhead को amortize करता है, जिससे एक छोटे, सीमित latency cost पर throughput बढ़ता है।
एक सिंगल मॉडल instance GPU compute को कम उपयोग करता है।
execution को ओवरलैप करने के लिए Triton में प्रति GPU कई मॉडल instances कॉन्फ़िगर करें।
क्यों: समवर्ती instances memory stalls द्वारा छोड़े गए compute gaps को भरते हैं, जिससे memory अनुमति देने पर उपयोगिता में सुधार होता है।
ट्रैफ़िक spiky है और निश्चित रेप्लिका या तो GPUs को बर्बाद करते हैं या SLOs को छोड़ देते हैं।
cold starts को अवशोषित करने के लिए warm pool के साथ queue depth / GPU utilization पर replicas को Autoscale करें।
क्यों: LLM cold starts (engine load) धीमे होते हैं; warm capacity के साथ एक अग्रणी संकेत पर scaling spikes के दौरान latency की रक्षा करता है।
मौजूदा क्लाइंट OpenAI chat-completions API की उम्मीद करते हैं।
NIM के OpenAI-compatible endpoint के माध्यम से मॉडल को उजागर करें ताकि क्लाइंट बिना rewrites के integrate हो सकें।
क्यों: एक drop-in compatible API क्लाइंट माइग्रेशन कार्य को कम करता है और आपको backends को पारदर्शी रूप से स्वैप करने की सुविधा देता है।
एक मॉडल या prompt परिवर्तन को चुपचाप गुणवत्ता को कम नहीं करना चाहिए।
CI में एक क्यूरेटेड golden eval सेट चलाएं और उन deploys को ब्लॉक करें जो एक गुणवत्ता threshold से नीचे गिरते हैं।
क्यों: स्वचालित regression gates गुणवत्ता में गिरावट को उपयोगकर्ताओं तक पहुंचने से पहले पकड़ते हैं, ठीक वैसे ही जैसे unit tests कोड को गेट करते हैं।
Open-ended outputs के पास स्कोर करने के लिए कोई एकल संदर्भ उत्तर नहीं है।
एक rubric के साथ LLM-as-judge का उपयोग करें, जिसे एक सैंपल पर मानव रेटिंग के खिलाफ कैलिब्रेट किया गया हो।
क्यों: एक rubric-driven judge व्यक्तिपरक मूल्यांकन को स्केल करता है; मानव calibration judge के अपने bias से बचाता है।
उच्च MMLU score लेकिन उपयोगकर्ता उत्पादन कार्य के बारे में शिकायत करते हैं।
केवल generic benchmarks पर नहीं, बल्कि व्यावसायिक परिणामों से जुड़े कार्य-विशिष्ट metrics पर मूल्यांकन करें।
क्यों: Generic benchmarks संकीर्ण deployed कार्यों के साथ कमजोर रूप से सहसंबंधित होते हैं; सही metric दर्शाता है कि उपयोगकर्ताओं को वास्तव में क्या चाहिए।
Offline evals अच्छे लगते हैं लेकिन वास्तविक दुनिया का प्रभाव अनिश्चित है।
ट्रैफ़िक के एक हिस्से को नए संस्करण पर रूट करते हुए एक online A/B test चलाएं और परिणाम metrics की तुलना करें।
क्यों: Live A/B distribution shift और उपयोगकर्ता व्यवहार को कैप्चर करता है जिसे offline सेट याद करते हैं, वास्तविक सुधार की पुष्टि करते हुए।
एक serving fleet में GPU स्वास्थ्य और उपयोगिता में दृश्यता की आवश्यकता है।
DCGM metrics (utilization, memory, ECC, temperature) को Prometheus में निर्यात करें और उन पर alert करें।
क्यों: DCGM मानक NVIDIA telemetry स्रोत है; इसके बिना, GPU-स्तर पर saturation और faults का पता नहीं चलता है।
उपयोगकर्ता रुक-रुक कर धीमी प्रतिक्रियाएं देखते हैं लेकिन औसत latency ठीक लगती है।
p95/p99 time-to-first-token और inter-token latency को ट्रैक करें, और percentile SLO उल्लंघनों पर alert करें।
क्यों: औसत tail latency को छुपाते हैं; LLM UX p95/p99 द्वारा शासित होता है, इसलिए percentile SLIs सही alerting signal हैं।
एक उच्च-ट्रैफ़िक endpoint पर एक नए मॉडल संस्करण को Deploy करना।
SLO या गुणवत्ता regression पर स्वचालित rollback के साथ canary (छोटे ट्रैफ़िक slice) के माध्यम से roll out करें।
क्यों: Canarying blast radius को सीमित करता है और metrics को पूर्ण rollout से पहले सुरक्षा की पुष्टि करने देता है, एक big-bang deploy के विपरीत।
स्पष्ट GPU compute spike के बिना लोड के तहत throughput गिर जाता है।
KV-cache और batch-slot उपयोगिता की निगरानी करें; जब cache संतृप्त हो जाए तो scale out करें या अधिकतम context को छोटा करें।
क्यों: KV-cache exhaustion compute से पहले concurrency को सीमित करता है; इसे देखने से throughput cliffs की व्याख्या होती है जिसे केवल GPU-util ही नहीं देख पाता।
KV cache लक्ष्य batch और context के लिए बहुत बड़ा है।
Grouped-Query Attention (GQA) या Multi-Query Attention (MQA) का उपयोग करने वाली architecture को प्राथमिकता दें।
क्यों: GQA/MQA key/value heads को साझा करते हैं, KV-cache memory को कम करते हैं और थोड़ी गुणवत्ता हानि के साथ प्राप्य batch size बढ़ाते हैं।
एक मॉडल के प्रयोग योग्य context को उसकी प्रशिक्षित लंबाई से आगे बढ़ाने की आवश्यकता है।
RoPE scaling (जैसे NTK-aware / YaRN) प्लस हल्के long-context fine-tuning का उपयोग करें।
क्यों: RoPE interpolation positional encodings को फैलाता है; एक छोटा fine-tune पूर्ण retraining के बिना मॉडल को लंबी सीमा के अनुकूल बनाता है।
आनुपातिक inference cost के बिना अधिक क्षमता चाहते हैं।
एक Mixture-of-Experts मॉडल पर विचार करें जो प्रति token केवल top-k experts को सक्रिय करता है।
क्यों: MoE parameters को स्केल करता है जबकि प्रति-token FLOPs को कम रखता है, लेकिन routing complexity और uneven expert load को प्रबंधित करने के लिए जोड़ता है।
एक deployed मॉडल को topic, safety और format सीमाओं की आवश्यकता है।
input और output rails (topical, moderation, jailbreak) को लागू करने के लिए मॉडल को NeMo Guardrails से wrap करें।
क्यों: Programmable rails मॉडल को retrain किए बिना उसके चारों ओर एक नियंत्रणीय safety layer जोड़ते हैं।
मॉडल कभी-कभी जहरीली या असुरक्षित सामग्री उत्पन्न करता है।
एक output moderation classifier जोड़ें और उन प्रतिक्रियाओं को ब्लॉक/पुनः उत्पन्न करें जो एक जोखिम threshold से अधिक हैं।
क्यों: एक अलग moderation पास असुरक्षित generations को पकड़ता है जिसे केवल prompt-स्तर के निर्देश ही विश्वसनीय रूप से रोक नहीं पाते हैं।
Stakeholders को इस बात के प्रमाण की आवश्यकता है कि मॉडल responsible-AI मानकों को पूरा करता है।
bias और toxicity benchmarks चलाएं, परिणामों को document करें, और उन्हें एक model card में संस्करणों में ट्रैक करें।
क्यों: Documented, repeatable safety evaluation compliance का समर्थन करती है और regressions को उत्पादन तक पहुंचने से पहले उजागर करती है।