Lambda, Kubernetes सेवा के लिए ओपन-सोर्स Run:ai शेड्यूलर तैयार कर रही है

Lambda ने 13 अक्टूबर, 2026 को बताया कि वह NVIDIA के साथ मिलकर ओपन-सोर्स Run:ai GPU शेड्यूलर को Lambda Kubernetes Service (LKS) में पूरी तरह समर्थित प्रबंधित विकल्प बनाने पर काम कर रही है। यह प्रबंधित घटकों के रूप में उपलब्ध कराए जाने वाले शेड्यूलरों की नियोजित लाइब्रेरी का हिस्सा होगा।

यह योजना Lambda के ब्लॉग पर 13 अक्टूबर, 2026 की एक पोस्ट में सामने आई। कंपनी ने कहा, “हम NVIDIA के Run:ai को ओपन-सोर्स करने के फैसले का स्वागत करते हैं और इसे Lambda Kubernetes Service (LKS) में पूरी तरह समर्थित विकल्प बनाने पर काम कर रहे हैं।” Lambda ने बताया कि वह 2022 से अपने बुनियादी ढाँचे पर Run:ai का समर्थन कर रही है। कंपनी ने कहा कि उसका लक्ष्य LKS के ज़रिए Run:ai की क्षमताओं को अपनाना और संचालित करना आसान बनाना है, ताकि टीमों को GPU क्षमता के आवंटन और साझा करने के तरीके पर अधिक नियंत्रण मिल सके।

NVIDIA ने 2025 में शेड्यूलर को ओपन-सोर्स किया

NVIDIA ने 1 अप्रैल, 2025 को KAI Scheduler को Apache 2.0 लाइसेंस के तहत ओपन-सोर्स जारी करने की घोषणा की। यह Kubernetes के लिए मूल रूप से विकसित GPU शेड्यूलिंग समाधान है, जिसे पहले Run:ai प्लेटफ़ॉर्म के भीतर बनाया गया था, NVIDIA की घोषणा के अनुसार। NVIDIA ने कहा कि शेड्यूलर को NVIDIA Run:ai प्लेटफ़ॉर्म के हिस्से के रूप में पैकेज और वितरित किया जाना जारी है।

NVIDIA के अनुसार, शेड्यूलर लगातार उचित हिस्सेदारी के मानों की फिर से गणना करता है और कोटा तथा सीमाओं को वास्तविक समय में समायोजित करता है। इसमें गैंग शेड्यूलिंग, GPU साझाकरण और पदानुक्रमित कतारबंदी को एक साथ इस्तेमाल किया जाता है। इसका अंतर्निर्मित पॉडग्रूपर Kubeflow, Ray, Argo और Training Operator सहित फ़्रेमवर्क के साथ वर्कलोड को अपने-आप जोड़ता है। NVIDIA ने शेड्यूलिंग चक्र का वर्णन किया है, जिसमें Kubernetes क्लस्टर की स्थिति का एक स्नैपशॉट लिया जाता है, निर्धारित कोटा और कोटे से अधिक के चरणों के ज़रिए हर कतार की उचित हिस्सेदारी की गणना की जाती है, और फिर आवंटन, समेकन, संसाधनों की वापसी तथा पूर्व-निरसन की कार्रवाइयाँ लागू की जाती हैं, ताकि मौजूदा आवंटन गणना की गई स्थिति के अनुरूप हो जाएँ।

Run:ai में GPU साझाकरण और कोटा-आधारित शेड्यूलिंग

Lambda ने बताया कि AI विकास में GPU की ज़रूरतें अलग-अलग होती हैं: डीबगिंग सत्रों में GPU का केवल एक हिस्सा पर्याप्त हो सकता है, मूल्यांकन के लिए कई स्वतंत्र कार्य एक साथ चलाने पड़ सकते हैं, जबकि वितरित प्रशिक्षण में एक ही समय पर बड़ी संख्या में आपस में तेज़ी से जुड़े GPU की ज़रूरत पड़ सकती है। काम शुरुआती विचारों से प्रयोगों और फिर उत्पादन तक पहुँचता है, तो ये ज़रूरतें भी बदलती रहती हैं। जब छोटे कार्यों को पूरा GPU दिया जाता है, तो शोधकर्ताओं को इंतज़ार करना पड़ता है, जबकि आरक्षित क्षमता बेकार पड़ी रहती है। टीमों के प्रयोग भी किसी दूसरी टीम के आरक्षित लेकिन निष्क्रिय GPU के पीछे अटक सकते हैं।

Lambda के विवरण के अनुसार, Run:ai Kubernetes के लिए GPU शेड्यूलर है, जो Kubernetes के डिफ़ॉल्ट शेड्यूलर से दो तरह से आगे जाता है: GPU साझाकरण, जिससे एक ही GPU पर एक से अधिक वर्कलोड चल सकते हैं; और कोटा-आधारित शेड्यूलिंग, जिसमें हर टीम को क्षमता का गारंटीकृत हिस्सा मिलता है और टीमें एक-दूसरे की निष्क्रिय क्षमता उधार ले सकती हैं।

NVIDIA के GPU के हिस्सों से जुड़े दस्तावेज़ के अनुसार, GPU मेमोरी को छोटे हिस्सों में बाँटा जाता है, जिन्हें कई वर्कलोड साझा कर सकते हैं। हर वर्कलोड के लिए माँगी गई मेमोरी की मात्रा लागू की जाती है, ताकि वह अपनी माँगी हुई मात्रा से अधिक न ले सके और न ही किसी दूसरे वर्कलोड की मेमोरी में दखल दे सके। हर पॉड को अपना अलग वर्चुअल मेमोरी पता-क्षेत्र मिलता है। दस्तावेज़ इस व्यवस्था को “लॉजिकल GPU” कहता है।

दस्तावेज़ के अनुसार, हिस्सों के ज़रिए GPU की गणना क्षमता साझा करने के लिए डिफ़ॉल्ट रूप से NVIDIA की टाइम-स्लाइसिंग का इस्तेमाल होता है। कई GPU वाले हिस्सों में एक ही नोड के कई GPU पर समान आकार का हिस्सा आवंटित किया जाता है। उदाहरण के लिए, 8 GPU इस्तेमाल करने वाले और हर GPU पर 40GB मेमोरी की ज़रूरत वाले मॉडल को हर GPU की पूरी मेमोरी देने के बजाय 8×40GB आवंटित किया जा सकता है। इससे उस नोड के हर GPU पर 40GB मेमोरी दूसरे वर्कलोड के लिए उपलब्ध रहती है। दस्तावेज़ बताता है कि एक ही नोड पर GPU के हिस्सों और Multi-Instance GPU (MIG) मोड का एक साथ इस्तेमाल नहीं किया जा सकता।

NVIDIA के शेड्यूलर की अवधारणाओं से जुड़े दस्तावेज़ के अनुसार, हर नए बनाए गए पॉड को एक पॉड समूह सौंपा जाता है। गैंग शेड्यूलिंग का अर्थ है कि कई पॉड से बने वर्कलोड को या तो पूरी तरह शेड्यूल किया जाता है या पूरी तरह लंबित रखा जाता है। हर नोड पूल में प्रत्येक प्रोजेक्ट और विभाग के लिए एक शेड्यूलिंग कतार बनाई जाती है। निर्धारित कोटा यह सीमा तय करता है कि कौन-से ऐसे वर्कलोड चल सकते हैं जिन्हें पहले से रोककर संसाधन वापस नहीं लिए जा सकते; वहीं, कोटे से अधिक उपलब्ध संसाधन केवल उन वर्कलोड को दिए जा सकते हैं जिन्हें रोककर संसाधन वापस लिए जा सकते हैं। शेड्यूलर हर नोड पूल में प्रत्येक प्रोजेक्ट और विभाग के लिए उचित हिस्सेदारी का मान निकालता है। जब एक कतार अपनी उचित हिस्सेदारी से नीचे और दूसरी उससे ऊपर होती है, तो संतुलन बहाल करने के लिए शेड्यूलर कतारों के बीच संसाधन स्थानांतरित करता है। इस प्रक्रिया में कोटे से अधिक संसाधन इस्तेमाल कर रहे ऐसे वर्कलोड को पहले रोका जा सकता है जिनसे संसाधन वापस लिए जा सकते हैं। शेड्यूलर प्रोजेक्टों और विभागों के बीच संसाधन वापस भी ले सकता है। प्रशासक हर नोड पूल के लिए संसाधनों को ठूँसकर भरने या फैलाकर रखने की प्लेसमेंट रणनीति तय कर सकते हैं।

LKS में नोड की स्वचालित मरम्मत

Lambda ने कहा कि संसाधनों का साझाकरण और पूर्व-निरसन, दोनों इस धारणा पर निर्भर करते हैं कि GPU ठीक से काम कर रहा है। बड़े पैमाने पर यह तय नहीं माना जा सकता: एक्सेलरेटर XID त्रुटियाँ देते हैं, NVLink और PCIe कनेक्शन की गुणवत्ता घटती है, मेमोरी की पंक्तियों का फिर से मानचित्रण होता है और InfiniBand पोर्ट की गति अपेक्षित दर से कम हो जाती है। शेड्यूलर ठीक से काम कर रहे GPU और खराब हो रहे GPU में अंतर नहीं कर सकता, इसलिए वह ऐसे नोड पर काम भेजता रहता है जो उन्हें गिरा देता है।

Lambda ने बताया कि LKS में स्वचालित मरम्मत की सुविधा पहले से उपलब्ध कराई जा रही है। कंपनी ने कहा कि यह ऐसी खराबियों के लिए हर नोड की निगरानी करती है और उन्हें Kubernetes नोड की मानक स्थिति के रूप में दिखाती है। ऐसी स्थिति सामने आने पर नोड को नए काम के लिए रोक दिया जाता है, चल रहे काम उससे हटा लिए जाते हैं और खराबी या तो अपने-आप ठीक की जाती है या हार्डवेयर की मरम्मत के लिए आगे भेजी जाती है। दोबारा जाँच में सफल होने के बाद ही नोड को सेवा में लौटाया जाता है।

Lambda के प्रबंधित Kubernetes दस्तावेज़ में इस सेवा को ऐसे Kubernetes परिवेश के रूप में बताया गया है जिसमें GPU और InfiniBand (RDMA) का समर्थन है और 1-Click Cluster के सभी नोड्स पर साझा स्थायी स्टोरेज उपलब्ध है। NVIDIA GPU Operator और NVIDIA Network Operator पहले से इंस्टॉल आते हैं। यह सेवा GPU, नेटवर्किंग और स्टोरेज के सही ढंग से काम करने की पुष्टि के लिए लगातार सत्यापन करती है। साथ ही, हार्डवेयर संबंधी समस्याओं का पता लगाने और उनसे उबरने के लिए नोड की स्वचालित समस्या-बहाली भी करती है।

प्रबंधित शेड्यूलर लाइब्रेरी का रोडमैप

Lambda ने GPU शेड्यूलिंग को उस परत के रूप में बताया जिसे वह जानबूझकर खुला छोड़ती है। कंपनी ने कहा कि LKS का अगला लक्ष्य उस दिशा में बढ़ना है जिसे वह एआई सॉफ़्टवेयर लाइब्रेरी कहती है: Kubernetes और Slurm पर चलने वाले शेड्यूलर, जिनमें Run:ai भी शामिल है। इन्हें प्रबंधित घटकों के रूप में उपलब्ध कराया जाएगा, जिन्हें Lambda अपने हार्डवेयर पर सत्यापित और अद्यतन रखेगी—इसके बजाय कि ग्राहक Helm चार्ट से इन्हें खुद जोड़ें। Run:ai इस लाइब्रेरी का प्रमुख लक्ष्य है और Lambda ने कहा कि वहाँ तक पहुँचने के लिए वह NVIDIA के साथ काम कर रही है।

Lambda के अनुसार, ओपन-सोर्स रिलीज़ ही इस तरीके को संभव बनाती है: कंपनी ग्राहकों को एकीकरण संबंधी निर्देशों का सेट थमाने के बजाय Run:ai को सीधे LKS में पैकेज, परीक्षण और अनुरक्षित कर सकती है। Lambda ने कहा कि उसका लक्ष्य ऐसा इंस्टॉलेशन-तैयार एकीकरण उपलब्ध कराना है जिसमें पैकेजिंग, सत्यापन और निरंतर संचालन की ज़िम्मेदारी उसी की हो।

Lambda ने कहा कि वह अपना खुला शोध करती है और जिन उपकरणों पर निर्भर है, उनकी जाँच करने, उन्हें अनुकूलित करने और बेहतर बनाने की क्षमता को महत्व देती है। कंपनी ने NVIDIA के निर्णय को ऑर्केस्ट्रेशन तक इस स्वतंत्रता का विस्तार बताया।