अंतिम समीक्षा: जून 2026
NCA-AIIO परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
तय करें कि कोई कार्यभार GPUs पर है या CPUs पर।
बड़े पैमाने पर समानांतर गणित (डीप-लर्निंग प्रशिक्षण/अनुमान, मैट्रिक्स ऑप्स, सिमुलेशन) → GPU। सीरियल, ब्रांच-हैवी कंट्रोल लॉजिक, ओएस कार्य, हल्का आई/ओ → CPU।
क्यों: GPUs में समानांतर SIMT कार्य पर थ्रूपुट के लिए हजारों कोर अनुकूलित होते हैं; CPUs लेटेंसी-संवेदनशील सीरियल लॉजिक पर जीतते हैं। अधिकांश एआई सिस्टम दोनों को जोड़ते हैं।
NVIDIA बिल्डिंग ब्लॉक चुनें: एक पूर्ण उपकरण बनाम OEM सिस्टम के लिए एक बोर्ड।
टर्नकी इंटीग्रेटेड एआई सर्वर (GPUs + CPUs + NVLink + नेटवर्किंग + सॉफ्टवेयर) → DGX। GPU बेसबोर्ड जिस पर OEMs/क्लाउड प्रोवाइडर सर्वर बनाते हैं → HGX।
क्यों: DGX NVIDIA का तैयार-से-चलाने वाला संदर्भ सिस्टम है; HGX मल्टी-GPU बोर्ड है जिसे हाइपरस्केलर्स स्वयं एकीकृत करते हैं।
एक सर्वर में GPUs को बस द्वारा प्रदान की जाने वाली तुलना में तेज़ GPU-से-GPU बैंडविड्थ की आवश्यकता होती है।
उच्च-बैंडविड्थ इंट्रा-नोड GPU इंटरकनेक्ट के लिए NVLink (और सभी-के-लिए-सभी के लिए NVSwitch) का उपयोग करें; जब NVLink अनुपलब्ध हो तो PCIe बैकअप है।
क्यों: NVLink PCIe की तुलना में कहीं अधिक GPU-से-GPU बैंडविड्थ और कम लेटेंसी प्रदान करता है - नोड के भीतर मॉडल-समानांतर और बड़े-बैच प्रशिक्षण के लिए महत्वपूर्ण है।
एक नोड में सभी 8 GPUs को एक साथ पूर्ण NVLink बैंडविड्थ पर एक-दूसरे से बात करनी चाहिए।
NVSwitch — एक नॉन-ब्लॉकिंग स्विच फैब्रिक जो हर GPU को पूर्ण NVLink गति पर हर दूसरे GPU से जोड़ता है।
क्यों: केवल पॉइंट-टू-पॉइंट NVLink सभी-के-लिए-सभी बैंडविड्थ नहीं देता है; NVSwitch पूर्ण-मेश GPU संचार के लिए क्रॉसबार प्रदान करता है।
स्केल-अप (एक सर्वर के भीतर) को स्केल-आउट (सर्वरों के पार) इंटरकनेक्ट से अलग करें।
एक नोड के भीतर स्केल-अप GPU इंटरकनेक्ट → NVLink/NVSwitch। एक क्लस्टर में नोड्स के पार स्केल-आउट → InfiniBand (या RoCE Ethernet)।
क्यों: NVLink इंट्रा-नोड है; InfiniBand मल्टी-नोड वितरित प्रशिक्षण के लिए नोड्स को एक क्लस्टर में जोड़ता है।
बड़े पैमाने पर वितरित प्रशिक्षण के लिए क्लस्टर फैब्रिक चुनें जहाँ कलेक्टिव-ऑप लेटेंसी सबसे महत्वपूर्ण है।
सबसे कम लेटेंसी, इन-नेटवर्क कंप्यूट (SHARP), RDMA-नेटिव → InfiniBand। परिचित, कम लागत वाला, व्यापक इकोसिस्टम → Spectrum-X Ethernet पर RoCE।
क्यों: SHARP के साथ InfiniBand सभी-कम को स्विच में ऑफलोड करता है, कलेक्टिव लेटेंसी को कम करता है; Spectrum-X एआई फैब्रिक के लिए NVIDIA का Ethernet समाधान है।
नेटवर्किंग, स्टोरेज और सुरक्षा प्रोसेसिंग को CPU से ऑफलोड करें ताकि कोर एआई कंप्यूट के लिए मुक्त हो सकें।
NVIDIA BlueField DPU — प्रोग्रामेबल डेटा प्रोसेसिंग यूनिट जो होस्ट CPU/GPU से इंफ्रास्ट्रक्चर सेवाओं को ऑफलोड और आइसोलेट करती है।
क्यों: DPU पूर्व-पश्चिम नेटवर्किंग, NVMe-oF स्टोरेज और जीरो-ट्रस्ट सुरक्षा को गति देते हैं, जिससे प्रभावी GPU/CPU उपयोग और टेनेंट आइसोलेशन बढ़ता है।
पूर्ण DPU ऑफलोड के बिना GPU नोड्स के लिए उच्च गति RDMA NIC की आवश्यकता है।
NVIDIA ConnectX SmartNIC — RDMA और GPUDirect समर्थन के साथ उच्च-थ्रूपुट InfiniBand/Ethernet अडैप्टर।
क्यों: ConnectX लाइन-रेट RDMA देता है; BlueField पूर्ण इंफ्रास्ट्रक्चर ऑफलोड के लिए ऊपर एक प्रोग्रामेबल Arm सबसिस्टम जोड़ता है।
CPU/होस्ट मेमोरी के माध्यम से स्टेजिंग किए बिना डेटा को GPU मेमोरी में ले जाकर लेटेंसी कम करें।
GPUDirect RDMA — NICs सीधे GPU मेमोरी को पढ़ते/लिखते हैं; GPUDirect Storage NVMe स्टोरेज के लिए भी यही करता है।
क्यों: CPU बाउंस बफर को बायपास करने से डेटा पाथ पर प्रतियां और लेटेंसी हट जाती है, जो मल्टी-नोड प्रशिक्षण थ्रूपुट के लिए महत्वपूर्ण है।
बड़े-मॉडल प्रशिक्षण के लिए वर्तमान-जेन डेटा-सेंटर GPU आर्किटेक्चर चुनें।
Hopper (H100/H200) Transformer Engine + FP8 के साथ स्थापित पीढ़ी है; Blackwell (B200/GB200) सबसे बड़े मॉडलों के लिए उच्च थ्रूपुट और FP4 के साथ नई पीढ़ी है।
क्यों: दोनों ट्रांसफॉर्मर वर्कलोड को लक्षित करते हैं; Blackwell स्केल और निम्न-सटीक (FP4) अनुमान को और आगे बढ़ाता है। बजट और मॉडल आकार से मेल खाएं।
उस हार्डवेयर की पहचान करें जो डीप-लर्निंग मैट्रिक्स गणित को गति देता है।
Tensor Cores — विशेषीकृत इकाइयाँ जो मिश्रित परिशुद्धता (FP16/BF16/FP8/FP4) पर फ्यूज्ड मैट्रिक्स-मल्टीप्लाई-एक्यूमुलेट करती हैं।
क्यों: वे मानक CUDA कोर की तुलना में GEMM/कनवोल्यूशन पर परिमाण के क्रम में उच्च थ्रूपुट प्रदान करते हैं, जो DL प्रदर्शन को बढ़ाता है।
एक बड़ा मॉडल फिट होने में विफल रहता है; मेमोरी बैंडविड्थ, न कि कंप्यूट, बाधा है।
अधिक और तेज़ HBM (जैसे HBM3e के साथ H200/B200) वाले GPUs चुनें; जब एक GPU's मेमोरी अपर्याप्त हो तो मल्टी-GPU मॉडल समानांतरता का उपयोग करें।
क्यों: बड़े मॉडलों का प्रशिक्षण/अनुमान अक्सर मेमोरी-क्षमता और बैंडविड्थ बाध्य होता है; HBM उच्च बैंडविड्थ प्रदान करता है जिसकी GPUs को आवश्यकता होती है।
एंटरप्राइज प्रशिक्षण के लिए एक टर्नकी, मान्य मल्टी-रैक एआई सुपरकंप्यूटर स्थापित करें।
NVIDIA DGX SuperPOD — DGX नोड्स, InfiniBand फैब्रिक, स्टोरेज और Base Command सॉफ्टवेयर का संदर्भ आर्किटेक्चर।
क्यों: SuperPOD पूर्व-मान्य पूर्ण-स्टैक डिज़ाइन है; यह स्केल पर वायरिंग फैब्रिक, स्टोरेज और ऑर्केस्ट्रेशन की अटकलबाजी को हटाता है।
हार्डवेयर के मालिक हुए बिना DGX-क्लास प्रशिक्षण क्षमता प्राप्त करें।
NVIDIA DGX Cloud — प्रमुख क्लाउड प्रोवाइडर पर होस्ट किया गया प्रबंधित एआई प्रशिक्षण इंफ्रास्ट्रक्चर, एक सेवा के रूप में एक्सेस किया जाता है।
क्यों: OpEx बनाम CapEx: DGX Cloud बर्स्टी या अल्पकालिक प्रशिक्षण के लिए उपयुक्त है; ऑन-प्रेम DGX/SuperPOD निरंतर उच्च उपयोग और डेटा-ग्रेविटी बाधाओं के लिए उपयुक्त है।
एआई वर्कलोड के लिए ऑन-प्रेम GPU क्लस्टर बनाम क्लाउड GPUs चुनें।
निरंतर उच्च उपयोग, डेटा संप्रभुता, अनुमानित खर्च → ऑन-प्रेम DGX/SuperPOD। परिवर्तनीय/बर्स्टी मांग, तेज़ शुरुआत, कोई डेटा-सेंटर फुटप्रिंट नहीं → क्लाउड या DGX Cloud।
क्यों: स्वामित्व वाले GPUs केवल उच्च स्थिर उपयोग पर ही अच्छी तरह से अमॉर्टाइज होते हैं; निष्क्रिय स्वामित्व वाला हार्डवेयर शुद्ध लागत है।
एक नया GPU क्लस्टर मौजूदा डेटा सेंटर के रैक पावर और कूलिंग बजट से अधिक है।
नवीनतम GPUs के लिए उच्च-घनत्व शक्ति (दसियों kW/रैक) और लिक्विड कूलिंग की योजना बनाएं; इंस्टॉलेशन से पहले PDUs, बसवे और थर्मल क्षमता का आकार निर्धारित करें।
क्यों: आधुनिक GPU नोड्स (और GB200 रैक) लीगेसी सर्वर की तुलना में कहीं अधिक शक्ति और गर्मी खींचते हैं; एयर कूलिंग और मानक PDUs अक्सर साथ नहीं चल पाते।
प्रशिक्षण रुक जाता है क्योंकि डेटा पाइपलाइन GPUs को पर्याप्त तेज़ी से फीड नहीं कर सकती है।
GPUDirect Storage के साथ उच्च-थ्रूपुट समानांतर/NVMe स्टोरेज का उपयोग करें; GPUs को संतृप्त रखने के लिए निरंतर रीड बैंडविड्थ के लिए आकार निर्धारित करें।
क्यों: कम प्रावधानित स्टोरेज I/O महंगे GPUs को डेटा का इंतजार करते हुए निष्क्रिय छोड़ देता है; स्टोरेज टियर को कुल GPU रीड मांग से मेल खाना चाहिए।
एक मॉडल इतना बड़ा है कि उसे स्वीकार्य समय के भीतर एक ही नोड पर प्रशिक्षित नहीं किया जा सकता।
डेटा/टेंसर/पाइपलाइन समानांतरता का उपयोग करके InfiniBand पर कई नोड्स तक स्केल आउट करें; NCCL GPU कलेक्टिव कम्युनिकेशन को संभालता है।
क्यों: मल्टी-नोड स्केलिंग को एक कम-लेटेंसी फैब्रिक और एक अनुकूलित कलेक्टिव्स लाइब्रेरी (NCCL) की आवश्यकता होती है; एक धीमा फैब्रिक स्केलिंग दक्षता को मार देता है।
एकल A100/H100 छोटे अनुमान कार्यों के लिए अत्यधिक है; आप हार्डवेयर-अलग किए गए स्लाइस चाहते हैं।
Multi-Instance GPU (MIG) — एक GPU को 7 अलग-अलग इंस्टेंसेस में विभाजित करें, प्रत्येक समर्पित कंप्यूट और मेमोरी के साथ।
क्यों: MIG मल्टी-टेनेंट अनुमान के लिए वास्तविक हार्डवेयर आइसोलेशन और अनुमानित QoS देता है, सॉफ्ट टाइम-स्लाइसिंग के विपरीत।
एआई बनाम मशीन लर्निंग बनाम डीप लर्निंग में अंतर करें।
एआई व्यापक लक्ष्य है; ML एक सबसेट है जो डेटा से सीखता है; DL मल्टी-लेयर न्यूरल नेटवर्क का उपयोग करने वाला ML का एक सबसेट है।
क्यों: वे नेस्ट करते हैं: DL ⊂ ML ⊂ AI। DL आधुनिक GPU मांग को बढ़ाता है क्योंकि न्यूरल नेटवर्क बड़े पैमाने पर समानांतर होते हैं।
प्रशिक्षण बनाम अनुमान के कंप्यूट प्रोफाइल में अंतर करें।
प्रशिक्षण = कंप्यूट- और मेमोरी-हैवी, लंबे समय तक चलने वाला, बैच, कई GPUs। अनुमान = लेटेंसी-संवेदनशील, हल्का, अक्सर एकल/आंशिक GPU, उत्पादन में लगातार चलता है।
क्यों: उनकी अलग-अलग हार्डवेयर और स्केलिंग आवश्यकताएँ होती हैं; एक क्लस्टर का आकार निर्धारित करने के लिए दोनों वर्कलोड को अलग करना आवश्यक है।
एक लर्निंग प्रतिमान चुनें: लेबल किया गया डेटा, अनलेबल किया गया डेटा, या इनाम-संचालित परीक्षण और त्रुटि।
लेबल किया गया → सुपरवाइज्ड। अनलेबल किया गया क्लस्टरिंग/स्ट्रक्चर → अनसुपरवाइज्ड। Agent इनाम से सीखता है → रीइन्फोर्समेंट लर्निंग।
क्यों: आपके पास मौजूद डेटा (और लक्ष्य) प्रतिमान को निर्धारित करता है; RLHF LLMs को संरेखित करने के लिए मानव प्रतिक्रिया द्वारा निर्देशित रीइन्फोर्समेंट लर्निंग है।
बताएं कि न्यूरल नेटवर्क GPUs पर अच्छी तरह से क्यों मैप होते हैं।
वे भारित मैट्रिक्स गुणन और नॉनलीनियर सक्रियण की परतें हैं — सघन समानांतर रैखिक बीजगणित जिसे GPUs कुशलता से निष्पादित करते हैं।
क्यों: फॉरवर्ड/बैकवर्ड पास GEMM-हैवी होते हैं; Tensor Cores ठीक इसी को गति देते हैं, यही कारण है कि DL GPUs पर चलता है।
आधुनिक LLMs और जनरेटिव एआई के पीछे के आर्किटेक्चर की पहचान करें।
ट्रांसफॉर्मर — ध्यान-आधारित आर्किटेक्चर जो डेटा और पैरामीटर के साथ स्केल करता है; फाउंडेशन मॉडल और LLMs इसी पर बने हैं।
क्यों: ट्रांसफॉर्मर अत्यधिक समानांतर करने योग्य होते हैं, यही कारण है कि वे बड़े GPU क्लस्टर और Transformer Engine हार्डवेयर की मांग को बढ़ाते हैं।
प्रशिक्षण को गति दें और सटीकता को भौतिक रूप से नुकसान पहुँचाए बिना मेमोरी उपयोग को कम करें।
मिश्रित परिशुद्धता का उपयोग करें — गणित के लिए FP16/BF16 (और Hopper/Blackwell पर FP8), संचय के लिए FP32; Tensor Cores निम्न-परिशुद्धता ऑप्स को गति देते हैं।
क्यों: निम्न परिशुद्धता मेमोरी को आधा करती है और थ्रूपुट को कई गुना बढ़ाती है; लॉस स्केलिंग / BF16 संख्यात्मक स्थिरता को बनाए रखता है।
उस नींव का नाम बताएं जो सॉफ्टवेयर को NVIDIA GPUs पर चलने देती है।
CUDA — NVIDIA का समानांतर-कंप्यूटिंग प्लेटफॉर्म और प्रोग्रामिंग मॉडल; CUDA-X लाइब्रेरी लेयर है (cuDNN, cuBLAS, NCCL, RAPIDS, आदि)।
क्यों: PyTorch/TensorFlow जैसे फ्रेमवर्क आंतरिक रूप से CUDA-X लाइब्रेरीज़ को कॉल करते हैं; CUDA वह खाई है जो एआई सॉफ्टवेयर को NVIDIA GPUs से जोड़ती है।
एक फ्रेमवर्क के भीतर डीप-लर्निंग प्रिमिटिव्स (कनवोल्यूशन, अटेंशन) को गति दें।
cuDNN GPU-अनुकूलित DL प्रिमिटिव प्रदान करता है; cuBLAS सघन रैखिक बीजगणित को संभालता है; दोनों PyTorch/TensorFlow के तहत बैठते हैं।
क्यों: ये लाइब्रेरीज़ ही कारण हैं कि फ्रेमवर्क आपको CUDA कर्नेल लिखे बिना GPU गति प्राप्त करते हैं।
NVIDIA-अनुकूलित, GPU-तैयार कंटेनर, मॉडल और Helm चार्ट प्राप्त करें।
NGC (NVIDIA GPU Cloud) कैटलॉग — अनुकूलित कंटेनर (फ्रेमवर्क, NIM, Triton), प्रीट्रेन्ड मॉडल और SDKs का क्यूरेटेड रजिस्ट्री।
क्यों: NGC कंटेनर NVIDIA GPUs के लिए ट्यून और टेस्ट किए गए आते हैं, जिससे निर्भरता और ड्राइवर-संगतता की अटकलबाजी दूर होती है।
एक मानकीकृत, GPU-कुशल एंडपॉइंट के पीछे कई फ्रेमवर्क से कई मॉडल परोसें।
NVIDIA Triton Inference Server — डायनेमिक बैचिंग, समवर्ती मॉडल निष्पादन और GPU शेयरिंग के साथ मल्टी-फ्रेमवर्क मॉडल सर्विसिंग।
क्यों: Triton प्रति मॉडल एक प्रक्रिया के बजाय बैचिंग और मॉडल समवर्तीता के माध्यम से अनुमान के लिए GPU उपयोग को अधिकतम करता है।
एक फाउंडेशन मॉडल को उत्पादन-तैयार, अनुकूलित अनुमान माइक्रोसर्विस के रूप में तेज़ी से तैनात करें।
NVIDIA NIM — लोकप्रिय मॉडलों के लिए अनुकूलित इंजन और मानक API के साथ पूर्व-निर्मित, कंटेनरयुक्त अनुमान माइक्रोसर्विस।
क्यों: NIM मॉडल + अनुकूलित रनटाइम (TensorRT-LLM/Triton) + API को एक परिनियोजन योग्य इकाई में पैकेज करता है, जिससे उत्पादन का समय कम होता है।
एक प्रशिक्षित मॉडल के लिए अनुमान लेटेंसी कम करें और थ्रूपुट बढ़ाएं।
TensorRT (या LLMs के लिए TensorRT-LLM) के साथ मॉडल को संकलित करें — लेयर फ्यूजन, परिशुद्धता कैलिब्रेशन (INT8/FP8), और कर्नेल ऑटो-ट्यूनिंग।
क्यों: TensorRT लक्ष्य GPU के लिए एक अनुकूलित अनुमान इंजन का उत्पादन करता है, अक्सर कच्चे फ्रेमवर्क की तुलना में थ्रूपुट को कई गुना बढ़ा देता है।
GPUs पर pandas/scikit-learn-शैली डेटा तैयारी और क्लासिकल ML को गति दें।
NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (graphs) GPUs पर डेटा-साइंस वर्कफ़्लो चलाते हैं।
क्यों: RAPIDS सारणीबद्ध ETL और क्लासिकल ML को GPU पर रखता है, पाइपलाइन में CPU बाधाओं से बचता है।
DGX/SuperPOD क्लस्टर में एआई वर्कलोड, जॉब्स और उपयोगकर्ताओं को प्रबंधित करें।
NVIDIA Base Command — DGX इंफ्रास्ट्रक्चर के लिए जॉब शेड्यूलिंग, क्लस्टर प्रबंधन और वर्कलोड ऑर्केस्ट्रेशन।
क्यों: Base Command DGX सिस्टम के लिए ऑपरेशंस कंट्रोल प्लेन है; यह मल्टी-यूज़र जॉब सबमिशन और रिसोर्स ट्रैकिंग को संभालता है।
एंटरप्राइज SLA के साथ समर्थित, सुरक्षित, उत्पादन-ग्रेड एआई सॉफ्टवेयर की आवश्यकता है।
NVIDIA AI Enterprise — समर्थित सॉफ्टवेयर सुइट (फ्रेमवर्क, NIM, Triton, RAPIDS, GPU Operator) सुरक्षा पैच और एंटरप्राइज समर्थन के साथ।
क्यों: यह मान्य स्टैक को समर्थन और जीवनचक्र गारंटी के साथ बंडल करता है, जिसकी विनियमित/उत्पादन वातावरण को आवश्यकता होती है।
एक फाउंडेशन मॉडल को परिभाषित करें और टीमें इसे कैसे अनुकूलित करती हैं।
व्यापक डेटा पर प्रीट्रेन्ड किया गया बड़ा मॉडल, प्रॉम्प्टिंग, RAG, या फाइन-ट्यूनिंग के माध्यम से कई कार्यों के लिए अनुकूलनीय, बजाय खरोंच से प्रशिक्षण के।
क्यों: अनुकूलन (प्रॉम्प्ट/RAG/फाइन-ट्यून) प्रीट्रेनिंग से कहीं अधिक सस्ता है; अधिकांश एंटरप्राइज फाउंडेशन मॉडल का उपभोग करते हैं, उन्हें बनाते नहीं हैं।
एक LLM-समर्थित ऐप में निजी/वर्तमान ज्ञान जोड़ें।
बार-बार बदलने वाले तथ्य → RAG (अनुमान पर एक वेक्टर स्टोर से पुनर्प्राप्त करें)। नया व्यवहार/शैली/डोमेन कौशल सिखाएं → फाइन-ट्यूनिंग।
क्यों: RAG डेटा को बाहरी और पुनःप्रशिक्षित किए बिना अपडेट करने योग्य रखता है; फाइन-ट्यूनिंग व्यवहार को भार में बेक करता है और ताज़ा करने में अधिक महंगा होता है।
न्याय करें कि क्या महंगे GPUs का कुशलतापूर्वक उपयोग किया जा रहा है।
GPU उपयोग, मेमोरी उपयोग और SM/Tensor-Core गतिविधि को ट्रैक करें; कम उपयोग डेटा-पाइपलाइन, बैच-साइज या शेड्यूलिंग बाधाओं का संकेत देता है।
क्यों: उच्च वॉल-क्लॉक GPU "व्यस्त" अभी भी कम प्रभावी कंप्यूट को मास्क कर सकता है; केवल उपयोग गेज पर नहीं, बल्कि Tensor-Core/SM ऑक्यूपेंसी पर देखें।
एक क्लस्टर में GPU स्वास्थ्य, उपयोग, तापमान, शक्ति और त्रुटियों की निगरानी करें।
NVIDIA DCGM (Data Center GPU Manager) — टेलीमेट्री, स्वास्थ्य जांच और डायग्नोस्टिक्स; Prometheus/Grafana को मेट्रिक्स निर्यात करें।
क्यों: DCGM मानक GPU टेलीमेट्री स्रोत है; DCGM Exporter क्लस्टर-व्यापी डैशबोर्ड और अलर्ट के लिए Prometheus को फीड करता है।
प्रति-नोड मैन्युअल सेटअप के बिना एक Kubernetes क्लस्टर पर GPU ड्राइवर, कंटेनर टूलकिट और निगरानी का प्रावधान करें।
NVIDIA GPU Operator — Kubernetes पर ड्राइवर, कंटेनर रनटाइम, डिवाइस प्लगइन, DCGM और MIG कॉन्फ़िगरेशन को स्वचालित करता है।
क्यों: यह पूर्ण GPU सॉफ्टवेयर जीवनचक्र को घोषणात्मक रूप से प्रबंधित करता है, जिससे कमजोर नोड-दर-नोड ड्राइवर इंस्टाल हट जाते हैं।
GPU वर्कलोड के लिए एक ऑर्केस्ट्रेटर चुनें।
माइक्रोसर्विस/अनुमान, क्लाउड-नेटिव, मिश्रित वर्कलोड → Kubernetes। बैच HPC-शैली प्रशिक्षण जॉब, गैंग शेड्यूलिंग, पारंपरिक क्लस्टर → Slurm।
क्यों: Kubernetes लंबे समय तक चलने वाली सेवाओं और इलास्टिसिटी में उत्कृष्ट है; Slurm MPI-शैली शेड्यूलिंग के साथ कतारबद्ध बैच जॉब में उत्कृष्ट है।
Kubernetes पॉड्स को GPUs पर अनुरोध और शेड्यूल करने की आवश्यकता होती है।
NVIDIA डिवाइस प्लगइन GPUs को शेड्यूलेबल रिसोर्स के रूप में विज्ञापित करता है; पॉड्स `nvidia.com/gpu` का अनुरोध करते हैं और शेड्यूलर उन्हें रखता है।
क्यों: डिवाइस प्लगइन के बिना, Kubernetes GPUs को देख या आवंटित नहीं कर सकता; यह वही है जो GPUs को प्रथम श्रेणी का संसाधन बनाता है।
कई छोटे जॉब/उपयोगकर्ताओं को उपयोग बढ़ाने के लिए GPUs साझा करने होंगे।
हार्डवेयर आइसोलेशन → MIG। एक GPU का सॉफ्ट शेयरिंग → टाइम-स्लाइसिंग या MPS। निष्पक्षता के लिए नेमस्पेस कोटा के साथ मिलाएं।
क्यों: MIG QoS गारंटी देता है; टाइम-स्लाइसिंग/MPS आइसोलेशन के बिना एक GPU को ओवरसब्सक्राइब करते हैं। आइसोलेशन आवश्यकता के अनुसार चुनें।
एक साझा क्लस्टर पर उच्च-प्राथमिकता वाले प्रशिक्षण को निम्न-प्राथमिकता वाले प्रयोगों को प्रीएम्प्ट करना चाहिए।
शेड्यूलर में प्राथमिकता/अधिकार और कतारों का उपयोग करें (स्लर्म पार्टिशन या कोटा के साथ Kubernetes PriorityClasses); मल्टी-GPU जॉब्स को गैंग-शेड्यूल करें।
क्यों: गैंग शेड्यूलिंग आंशिक आवंटन डेडलॉक को रोकता है; प्राथमिकता वर्ग विवादित GPUs पर व्यापारिक क्रम लागू करते हैं।
GPU ड्राइवर, CUDA और कंटेनर टूलकिट संस्करणों को नोड्स में सुसंगत और संगत रखें।
GPU Operator (Kubernetes) या NGC कंटेनर के माध्यम से मानकीकृत करें; ड्राइवर को उन CUDA संस्करणों से मिलाएं जिनकी आपके फ्रेमवर्क को आवश्यकता है और रखरखाव विंडो में अपडेट रोल करें।
क्यों: ड्राइवर/CUDA/फ्रेमवर्क बेमेल क्लस्टर विफलताओं का एक प्रमुख कारण हैं; कंटेनर-पिन किया गया CUDA समर्थित सीमाओं के भीतर ऐप को होस्ट ड्राइवर से अलग करता है।
अनुमानित प्रशिक्षण और अनुमान मांग के लिए एक GPU क्लस्टर का आकार निर्धारित करें।
प्रशिक्षण (पीक, बैच) को अनुमान (निरंतर, लेटेंसी-बाउंड) से अलग करें; शक्ति/कूलिंग/फैब्रिक हेडरूम की योजना बनाएं और उच्च स्थिर उपयोग को लक्षित करें।
क्यों: ओवरसाइज़िंग निष्क्रिय GPUs पर CapEx बर्बाद करता है; अंडरसाइज़िंग डिलीवरी को धीमा कर देता है। वर्कलोड मिश्रण के अनुसार योजना बनाएं, न कि एक ही पीक के अनुसार।
GPU निरंतर भारी लोड के तहत थ्रॉटल या विफल हो जाते हैं।
DCGM के माध्यम से तापमान और शक्ति की निगरानी करें; पर्याप्त कूलिंग (घने रैक के लिए लिक्विड) सुनिश्चित करें, उचित शक्ति सीमाएं निर्धारित करें, और थर्मल थ्रेशोल्ड पर अलर्ट करें।
क्यों: थर्मल थ्रॉटलिंग चुपचाप थ्रूपुट को कम करता है; सक्रिय टेलीमेट्री और कूलिंग डिज़ाइन प्रदर्शन और हार्डवेयर जीवनकाल दोनों की रक्षा करते हैं।
साझा हार्डवेयर से कई VMs या VDI उपयोगकर्ताओं को GPU त्वरण प्रदान करें।
NVIDIA vGPU सॉफ्टवेयर शेड्यूलिंग और आइसोलेशन के साथ VMs में एक भौतिक GPU को विभाजित करता है; MIG हार्ड पार्टिशनिंग के लिए vGPU प्रोफाइल को सपोर्ट कर सकता है।
क्यों: vGPU वर्चुअलाइज्ड/मल्टी-टेनेंट GPU एक्सेस (VDI, क्लाउड) को सक्षम बनाता है जिसे बेयर-मेटल पासथ्रू साझा नहीं कर सकता।
एक नोड Xid त्रुटियाँ या विफल जॉब्स लौटाता है; आपको खराब GPUs को अलग करना होगा इससे पहले कि वे अधिक रनों को दूषित करें।
DCGM डायग्नोस्टिक्स और सक्रिय स्वास्थ्य जांच चलाएं; नोड को कॉर्डन/ड्रेन करें, GPU को बदलें या रीसेट करें, और तभी इसे पूल में वापस करें।
क्यों: Xid त्रुटियाँ और ECC दोष विफल GPUs को चिह्नित करते हैं; स्वचालित स्वास्थ्य गेटिंग एक खराब GPU को शेड्यूलिंग पूल को दूषित करने से रोकती है।