Kris Beevers, CEO और सह-संस्थापक, Netbox Labs – साक्षात्कार श्रृंखला

Kris Beevers, CEO और सह-संस्थापक, NetBox Labs एक तकनीकी उद्यमी और इन्फ्रास्ट्रक्चर सॉफ़्टवेयर के अनुभवी हैं, जिनके पास नेटवर्किंग, क्लाउड इन्फ्रास्ट्रक्चर और ऑटोमेशन पर केंद्रित कंपनियों और प्लेटफ़ॉर्मों को बनाने का दो दशकों से अधिक अनुभव है। NetBox Labs का नेतृत्व करने से पहले, Beevers ने 2013 में NS1 की सह-स्थापना की और लगभग एक दशक तक उसके CEO के रूप में कार्य किया, कंपनी को नेटवर्क ऑटोमेशन और एप्लिकेशन ट्रैफ़िक मैनेजमेंट तकनीक के प्रमुख प्रदाता के रूप में विकसित किया, जो 2023 में IBM द्वारा अधिग्रहित की गई। इस लेन‑देन के हिस्से के रूप में, NetBox Labs NS1 से स्वतंत्र कंपनी के रूप में अलग हुआ, जिसमें IBM निवेशक था। अपने करियर की शुरुआती अवधि में, Beevers ने Internap Network Services और Voxel में वरिष्ठ इंजीनियरिंग और आर्किटेक्चर भूमिकाएँ निभाईं, और उन्होंने SolidJoint Research की भी सह-स्थापना की।

NetBox Labs एक इन्फ्रास्ट्रक्चर इंटेलिजेंस प्लेटफ़ॉर्म विकसित करता है, जिसे संगठनों को बढ़ती जटिल नेटवर्क और आईटी इन्फ्रास्ट्रक्चर को मॉडल, संचालित, स्वचालित और शासित करने में मदद करने के लिए डिज़ाइन किया गया है। कंपनी NetBox की व्यावसायिक देखरेख करती है, जो 10,000 से अधिक संगठनों द्वारा उपयोग किया जाने वाला व्यापक रूप से अपनाया गया ओपन‑सोर्स नेटवर्क और इन्फ्रास्ट्रक्चर रिकॉर्ड सिस्टम है। इसका प्लेटफ़ॉर्म इन्फ्रास्ट्रक्चर ग्राफ़ और सच्चाई के स्रोत को ऑपरेशनल इंटेलिजेंस, ऑटोमेशन, AI‑सहायता प्राप्त ऑर्केस्ट्रेशन और गवर्नेंस क्षमताओं के साथ मिलाता है, जिससे इंजीनियर और AI एजेंट दोनों सुरक्षित रूप से इन्फ्रास्ट्रक्चर के साथ इंटरैक्ट कर सकते हैं। NetBox Labs क्लाउड, स्वयं‑प्रबंधित एंटरप्राइज़, हाइब्रिड और एयर‑गैप्ड डिप्लॉयमेंट्स को समर्थन देता है, साथ ही Ansible, Terraform, Nornir और निरंतर इंटीग्रेशन एवं डिप्लॉयमेंट पाइपलाइनों जैसे टूल्स के साथ एकीकृत होता है।

आपने 2013 में NS1 की सह-स्थापना की और लगभग एक दशक तक कंपनी को बनाते रहे, इससे पहले कि IBM द्वारा उसका अधिग्रहण किया गया, जिसके बाद NetBox Labs एक स्वतंत्र कंपनी के रूप में उभरा। NS1 को बनाने से मिली कौन‑सी सीखें आपको NetBox Labs स्थापित करने के लिए प्रेरित करती हैं, और AI युग में आप जिस इन्फ्रास्ट्रक्चर समस्या को हल करने का प्रयास कर रहे हैं, वह कैसे बदल गई है?

NS1 बनाते समय मैंने एक बात सीखी कि इन्फ्रास्ट्रक्चर समस्याएँ शायद ही कभी साफ‑सुथरे ढंग से सीमित रहती हैं। DNS हमारे स्टैक का एक भाग था, लेकिन हमारे ग्राहक अत्यंत जटिल वातावरण संचालित कर रहे थे जहाँ नेटवर्क, डेटा सेंटर, एप्लिकेशन और ऑटोमेशन आपस में निर्भर थे। उन टीमों के साथ जितना अधिक समय बिताया, उतना ही स्पष्ट हुआ कि इन्फ्रास्ट्रक्चर को स्वयं समझना एक बहुत बड़ी समस्या है।

यह वही बड़ा कारण था जिसने मुझे NetBox की ओर आकर्षित किया। पहले से ही यह व्यापक रूप से अपनाया गया ओपन‑सोर्स प्रोजेक्ट और इंजीनियरों का एक समुदाय था जो इसे अपने पास मौजूद चीज़ों को मॉडल करने, उनके कनेक्शन और अपेक्षित रूप को दर्शाने के लिए उपयोग कर रहा था। हमने उस नींव पर निर्माण करने का अवसर देखा।

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

इसलिए NS1 से मिली सीख अभी भी लागू होती है। इन्फ्रास्ट्रक्चर को अच्छी तरह स्वचालित करने से पहले, आपको उसे समझना होगा। AI केवल इसे सही तरीके से करने की आवश्यकता को और अधिक तात्कालिक बना देता है।

पिछले दशक के अधिकांश हिस्से में, क्लाउड कंप्यूटिंग ने डेवलपर्स और इन्फ्रास्ट्रक्चर टीमों को उनके एप्लिकेशन के नीचे की भौतिक हार्डवेयर को अमूर्त करने की अनुमति दी। AI इस प्रवृत्ति को उलट क्यों रहा है और DevOps, Site Reliability Engineering (SRE), और नेटवर्क इंजीनियरों को फिर से पावर, कूलिंग, रैक, केबलिंग और भौतिक नेटवर्किंग के बारे में सोचने पर मजबूर क्यों कर रहा है?

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

AI इन्फ्रास्ट्रक्चर वास्तव में आपको यह करने की अनुमति नहीं देता।

जब आप इन वातावरणों का निर्माण कर रहे होते हैं, तो आप कुछ काफी भौतिक प्रश्नों से शुरू करते हैं। मेरे पास कितना जमीन है? मुझे कितना पावर मिल सकता है? मैं किस प्रकार की कूलिंग सपोर्ट कर सकता हूँ? इनसे आगे आप रैक, GPU सर्वर, स्विच, फाइबर ऑप्टिक केबलिंग में प्रवेश करते हैं और अंततः लॉजिकल लेयर, IP पते, कॉन्फ़िगरेशन और सॉफ़्टवेयर तक पहुँचते हैं।

इन सभी चीज़ों का आपस में निर्भर होना है। पावर और कूलिंग डेंसिटी को समझे बिना आप यह तय नहीं कर सकते कि आप कितने रैक तैनात करेंगे। GPUs को उनके आपस में जुड़े नेटवर्क से स्वतंत्र रूप से नहीं सोचा जा सकता।

यह उन अनुशासनों को मजबूर कर रहा है जिन्होंने वर्षों तक भौतिक लेयर से दूर रहने की कोशिश की थी, फिर से उसके साथ जुड़ने के लिए। अमूर्तता समाप्त नहीं हुई है, लेकिन उसके नीचे की भौतिक सीमाएँ अचानक बहुत अधिक महत्वपूर्ण हो गई हैं।

AI डेटा सेंटर अब गीगावॉट स्केल पर चर्चा में हैं। जब इन्फ्रास्ट्रक्चर पारंपरिक एंटरप्राइज़ या क्लाउड वातावरण से बड़े GPU क्लस्टरों के आसपास डिज़ाइन किए गए सुविधाओं में बदलता है, तो संचालनात्मक रूप से मूल रूप से क्या बदलता है?

गीगावॉट स्केल बिल्कुल ही खगोलीय है। लेकिन जबकि स्केल स्पष्ट रूप से अलग है, मेरा मानना है कि अधिक रोचक अंतर आवश्यक समन्वय की मात्रा है।

सोचिए कि 300 मेगावॉट डेटा सेंटर को ऑनलाइन लाने के लिए क्या-क्या करना पड़ता है। आपको जमीन और बिजली चाहिए। फिर आपको सुविधा का डिजाइन बनाना होता है और रैक, GPU सर्वर, स्विच, फाइबर, पावर इन्फ्रास्ट्रक्चर और कूलिंग उपकरण खरीदने होते हैं, अक्सर पूरी तरह अलग-अलग विक्रेताओं से, जिनके उत्पादों को प्रस्तुत करने के तरीके भी पूरी तरह अलग होते हैं। इन सभी उपकरणों को पहुंचना, प्राप्त करना, रैक में लगाना, केबलिंग करना, कॉन्फ़िगर करना, परीक्षण करना और अंततः प्रशिक्षण या इन्फ़रेंस के लिए सौंपना पड़ता है।

और जब आप यह सब कर रहे होते हैं, तो जमीन आपके नीचे ही बदल रही होती है। GPU आर्किटेक्चर बदल रहे हैं। नेटवर्किंग बदल रही है। कूलिंग की आवश्यकताएँ बदल रही हैं। अब से छह महीने बाद उपलब्ध घटक वही नहीं हो सकते जो आप आज डिजाइन कर रहे हैं।

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

इस पैमाने पर, इन्फ्रास्ट्रक्चर संचालन एक विशाल लॉजिस्टिक्स और प्रतिबंध-समाधान समस्या बन जाता है। जो कंपनियाँ इसे अच्छी तरह से करती हैं, वे सटीक डिजाइन डेटा को प्रोक्योरमेंट, डिप्लॉयमेंट और संचालन तक पूरी तरह ले जाने में बहुत कुशल होती हैं।

आपने कहा है कि इस पैमाने पर इन्फ्रास्ट्रक्चर चलाने के लिए कोई स्थापित प्लेबुक या टैलेंट पाइपलाइन प्रभावी रूप से मौजूद नहीं है। वर्तमान में कौन सी कौशल सबसे कठिन से मिलने वाले हैं, और AI इन्फ्रास्ट्रक्चर के विस्तार के साथ सबसे बड़ी टैलेंट कमी कहाँ उत्पन्न होगी?

संभवतः अभी दुनिया में केवल कुछ सौ लोग ही हैं जो वास्तव में इस तरह के इन्फ्रास्ट्रक्चर को इस गति और पैमाने पर बना सकते हैं। और उनमें से अधिकांश वास्तव में इसे कर रहे होते हैं, इसलिए वे काफी व्यस्त हैं।

यही इस क्षण को असामान्य बनाता है। कोई परिपक्व ज्ञानभंडार नहीं है जिसे आप बस पढ़कर सीख सकें। इस काम को करने वाले लोग एक-दूसरे से सीख रहे हैं और वास्तविक समय में चीज़ें समझ रहे हैं। और क्योंकि तकनीक इतनी तेज़ी से बदल रही है, इनमें से कुछ सीखें बहुत जल्दी पुरानी हो जाती हैं।

मुझे लगता है कि कमी इसलिए एक ही नौकरी शीर्षक से बड़ी है। हमें ऐसे लोग चाहिए जो नेटवर्किंग, कंप्यूट और ऑटोमेशन को समझते हों, लेकिन साथ ही उन भौतिक वातावरण को भी समझते हों जहाँ ये सिस्टम रहते हैं। पावर, कूलिंग, सुविधा डिजाइन, सप्लाई चेन और फील्ड ऑपरेशन्स अब उसी बातचीत का हिस्सा बन रहे हैं।

जो लोग इन सीमाओं को पार कर सकते हैं, वे अत्यंत मूल्यवान होंगे। लेकिन मुझे नहीं लगता कि हमने अभी तक यह तय किया है कि इन सभी भूमिकाओं का रूप क्या होगा। टैलेंट मॉडल इन्फ्रास्ट्रक्चर के साथ-साथ बन रहा है।

जैसे-जैसे सॉफ़्टवेयर, नेटवर्किंग, सुविधाएँ, ऊर्जा और डेटा सेंटर इंजीनियरिंग के बीच की सीमाएँ धुंधली होती जा रही हैं, आप कौन सी नई तकनीकी भूमिकाएँ या हाइब्रिड स्किल सेट्स उभरते देख रहे हैं?

मुझे नहीं लगता कि हम अभी जानते हैं कि इन सभी भूमिकाओं का रूप क्या होगा। जो बात हमें पता है वह यह है कि इस इन्फ्रास्ट्रक्चर को बनाने वाले लोगों को पहले से कहीं अधिक विस्तृत समस्याओं के सेट पर विचार करना होगा।

आप केवल कंप्यूट या नेटवर्किंग को अलग‑अलग नहीं देख रहे हैं। पावर, कूलिंग, भौतिक डिजाइन, सप्लाई चेन, नेटवर्किंग और ऑटोमेशन को मिलकर इन वातावरणों को ऑनलाइन लाना और चलाते रहना पड़ता है।

मैं अभी भी मानता हूँ कि हमें प्रत्येक क्षेत्र में गहरी विशेषज्ञता वाले लोगों की आवश्यकता होगी। लेकिन बढ़ती हुई आवश्यकता यह होगी कि वे समझें कि उनके क्षेत्र में किए गए निर्णय बाकी इन्फ्रास्ट्रक्चर को कैसे प्रभावित करते हैं। और क्योंकि यह काम तेज़ी से होना पड़ता है, ऑटोमेट करने की क्षमता अधिक से अधिक क्षेत्रों में महत्वपूर्ण होगी।

AI एजेंट समस्याओं का निदान करने, कॉन्फ़िगरेशन उत्पन्न करने और इन्फ्रास्ट्रक्चर संचालन के कुछ हिस्सों को स्वचालित करने लगते हैं। आप किन जिम्मेदारियों को AI वास्तविक रूप से इन्फ्रास्ट्रक्चर इंजीनियरों से लेगा, और किन क्षेत्रों में गहरी मानव विशेषज्ञता की आवश्यकता और बढ़ेगी, ऐसा मानते हैं?

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

जहाँ उत्तर स्पष्ट नहीं होता, वहाँ मनुष्यों की भूमिका अधिक महत्वपूर्ण हो जाती है।

इन्फ्रास्ट्रक्चर अजीब तरीकों से फेल हो सकता है। एक फाइबर कट जाता है। कोई डिवाइस उस तरह व्यवहार करने लगता है जैसा डिजाइन में नहीं लिखा है। कोई परिवर्तन कहीं और अप्रत्याशित प्रभाव डालता है। AI एक इंजीनियर को इन स्थितियों को बहुत तेज़ी से समझने में मदद कर सकता है, लेकिन फिर भी ऐसे लोग चाहिए जो सिस्टम को इतनी गहराई से समझते हों कि अगला कदम क्या होना चाहिए, यह तय कर सकें।

मुझे लगता है यही रोचक बदलाव है। इंजीनियर संभवतः कम समय दोहराव वाले कॉन्फ़िगरेशन और ट्रबलशूटिंग में बिताएंगे और अधिक समय इरादा परिभाषित करने, सिस्टम डिजाइन करने, ऑटोमेशन की सीमाएँ तय करने और वास्तव में नई समस्याओं को संभालने में लगाएंगे। इन सभी कार्यों को AI बढ़ाएगा, लेकिन उनका नेतृत्व लोग करेंगे।

यह विशेषज्ञता को कम नहीं, बल्कि अधिक मूल्यवान बनाता है। वह इंजीनियर जो वास्तव में समझता है कि इन्फ्रास्ट्रक्चर इस तरह काम करता है, वह तब अत्यंत महत्वपूर्ण होगा जब ऑटोमेशन के पास स्पष्ट उत्तर न हो।

NetBox Labs ने तर्क दिया है कि इन्फ्रास्ट्रक्चर का प्रबंधन करने वाली AI प्रणालियों को उपकरणों, कनेक्शनों, निर्भरताओं और अन्य भौतिक तथा तार्किक संबंधों का अधिकारिक मॉडल चाहिए। जब AI सहायक जो सिफ़ारिशें देते हैं से उन एजेंटों की ओर बढ़ते हैं जो वास्तव में कार्रवाई कर सकते हैं, तो इस प्रकार के इन्फ्रास्ट्रक्चर संदर्भ का इतना महत्वपूर्ण होना क्यों है?

मुख्य अंतर यह है कि एक बार एजेंट कार्रवाई कर सके, तो गलत होना वास्तविक परिणाम लाता है।

एक इन्फ्रास्ट्रक्चर एजेंट को केवल वर्तमान में उपकरण क्या कर रहा है, इसका स्नैपशॉट पर्याप्त नहीं है। उसे अपने आसपास के पर्यावरण को समझना चाहिए: क्या मौजूद है, चीज़ें कैसे जुड़ी हैं, हाल ही में क्या बदल गया और, सबसे महत्वपूर्ण, इन्फ्रास्ट्रक्चर को कैसे दिखना चाहिए।

उदाहरण के तौर पर कनेक्टिविटी समस्या का निवारण लें। यह जानना कि कोई उपकरण पहुंच से बाहर है, पर्याप्त नहीं है। आप चाहते हैं कि एजेंट के पास केबल पथ को ट्रेस करने, उस उपकरण के आसपास की निर्भरताओं को समझने, हालिया बदलावों को देखे और यह निर्धारित करे कि आगे क्या प्रभावित हो सकता है, इससे पहले कि वह अगला कदम सुझाए।

यह वास्तव में वह नींव है जिस पर हमने NetBox Labs में वर्षों से निर्माण किया है, टीमों को भौतिक और तार्किक दोनों इन्फ्रास्ट्रक्चर का सटीक मॉडल प्रदान करते हुए, साथ ही यह इरादा भी कि इसे कैसे काम करना चाहिए।

लेकिन केवल डेटा पर्याप्त नहीं है। आपको यह भी तय करना होगा कि एजेंट को अकेले क्या करने की अनुमति है, क्या इसके लिए व्यक्ति की स्वीकृति आवश्यक है, और प्रत्येक कार्रवाई को कैसे ट्रैक और मान्य किया जाता है।

इन्फ्रास्ट्रक्चर कोड जैसा नहीं है जहाँ एक खराब परिवर्तन हमेशा साफ़‑सुथरे ढंग से वापस किया जा सकता है। एक खराब परिवर्तन संचालन को बंद कर सकता है। इसलिए जब हम AI से जो इंजीनियर को अपनी राय बताता है, से ऐसे AI की ओर बढ़ते हैं जो वास्तव में काम कर सकता है, तो संदर्भ और नियंत्रण दोनों अधिक महत्वपूर्ण हो जाते हैं।

आपके हालिया CIO लेख, “मैं, CEO, व्यक्तिगत रूप से हमारी AI रणनीति बना रहा हूँ,” आप तर्क देते हैं कि AI कंपनी के नेताओं के लिए बहुत महत्वपूर्ण है कि उसे केवल सौंपा न जाए और आप AI उपकरणों के साथ व्यक्तिगत रूप से प्रोटोटाइप बनाते हुए वर्णन करते हैं। इन प्रणालियों को हाथों‑हाथ उपयोग करने से आपके विचार कैसे बदल गए हैं कि इन्फ्रास्ट्रक्चर संचालन में AI वास्तव में क्या स्वचालित कर सकता है?

हाथों‑हाथ काम करने से आप सैद्धांतिक चर्चा में बहुत कम रुचि रखते हैं।

मैंने इन उपकरणों के साथ वास्तव में निर्माण करने में बहुत समय बिताया है, आजकल सबसे अधिक प्रोटोटाइप बनाना या Claude Code के साथ पूर्ण उत्पाद बनाना। आप जल्दी समझते हैं कि प्रभावशाली डेमो देखने और ऐसा कुछ बनाने में बड़ा अंतर है, जिस पर आप वास्तव में भरोसा करके उपयोगी कार्य करवाते हैं।

आप यह भी महसूस करते हैं कि प्रौद्योगिकी किस दिशा में बहुत तेज़ी से आगे बढ़ रही है, यह पढ़कर समझ से कहीं अधिक है। छह महीने पहले जो चीज़ें मैं कठिन मानता था, वे अचानक काफी सरल हो सकती हैं। साथ ही, आप स्पष्ट रूप से देख सकते हैं कि कहाँ अभी भी संदर्भ, निर्णय और संरचना की कमी है।

यहने मेरे इन्फ्रास्ट्रक्चर संचालन के बारे में सोचने को प्रभावित किया है। मैं इस बात को लेकर बहुत आशावादी हूँ कि हम कितनी संचालन कार्य को स्वचालित कर सकते हैं, लेकिन मेरा मानना है कि अंतिम लक्ष्य के रूप में पूर्ण स्वायत्तता से हम अभी दूर हैं।

मेरे लिए सवाल बहुत बुनियादी है। क्या यह हमें इन्फ्रास्ट्रक्चर को तेज़, अधिक विश्वसनीय या अधिक प्रभावी ढंग से संचालित करने में मदद करता है? अगर हाँ, तो बढ़िया। अगर नहीं, तो इसके पीछे की AI कितनी भी परिष्कृत क्यों न हो, इसका कोई महत्व नहीं है।

जैसे-जैसे AI डेटा सेंटर बिजली की उपलब्धता और ठंडक की आवश्यकताओं द्वारा अधिक सीमित होते जा रहे हैं, क्या इन्फ्रास्ट्रक्चर इंजीनियरिंग केवल कंप्यूटिंग संसाधनों के प्रबंधन से ऊर्जा और भौतिक क्षमता के साथ कार्यभार को सक्रिय रूप से समन्वय करने की ओर विकसित हो सकती है?

हाँ, और हम पहले ही इसे देखना शुरू कर चुके हैं। हमारे पास आंतरिक रूप से एक वाक्यांश है, “turbines in the parking lot,” जो हाइपरस्केल AI इन्फ्रास्ट्रक्चर बनाने वाली टीमों में से एक के साथ वास्तविक बातचीत से आया था। वे इन्फ्रास्ट्रक्चर को इतनी तेज़ी से ऑनलाइन ला रहे थे कि ग्रिड उसकी गति नहीं पकड़ पा रहा था, इसलिए वे वास्तव में टर्बाइन खरीद रहे थे और उन्हें पार्किंग लॉट में रख रहे थे ताकि पर्याप्त तेज़ बिजली मिल सके।

ये वही वातावरण है जिसमें ये टीमें काम करती हैं। जब बिजली आपके प्रमुख प्रतिबंधों में से एक बन जाती है, तो आपको उपलब्ध संसाधनों के उपयोग में बहुत अधिक समझदारी अपनानी पड़ती है। डिमांड‑साइड रिस्पॉन्स, जहाँ ऑपरेटर इलेक्ट्रिक ग्रिड में बदलाव के जवाब में AI कार्यभार को सक्रिय रूप से समन्वयित करते हैं, पहले से ही हो रहा है और ऊर्जा‑भारी इन्फ्रास्ट्रक्चर चलाने वाली टीमों के लिए यह एक बढ़ती महत्वपूर्ण क्षमता बन रहा है।

हर कार्यभार की आवश्यकताएँ समान नहीं होतीं। लेटेंसी‑सेंसिटिव इन्फ़रेंस को ऑनलाइन रहना पड़ सकता है, जबकि कुछ प्रशिक्षण या बैच कार्यभार को बिजली की कमी के समय शिफ्ट या रोक दिया जा सकता है। मेरा मानना है कि हम अधिकतर देखेंगे कि इन्फ्रास्ट्रक्चर टीमें कंप्यूट, पावर और भौतिक क्षमता को एक ही संचालन समस्या के हिस्से के रूप में प्रबंधित करेंगी।

आगे देखते हुए, क्या आपको लगता है कि AI को स्केल करने में सबसे बड़ा बाधा अंततः GPUs और मॉडल विकास होगा, या पर्याप्त पावर, भौतिक इन्फ्रास्ट्रक्चर, नेटवर्किंग क्षमता, ऑटोमेशन और कुशल इंजीनियरों की कमी जैसी व्यापक चुनौती होगी जो उनके पीछे सब कुछ संचालित करते हैं?

मुझे नहीं लगता कि केवल एक ही बाधा होगी।

वर्तमान में बाजार द्वारा चाही गई गति और पैमाने पर AI इन्फ्रास्ट्रक्चर बनाना मूलतः एक प्रतिबंध‑संतुष्टि समस्या है। किसी भी क्षण में, कुछ न कुछ प्राथमिक प्रतिबंध बन जाता है।

काफी समय तक, सभी लोग GPUs के बारे में बात कर रहे थे। शक्ति अब स्पष्ट रूप से एक बड़ी बाधा है। लेकिन यह नेटवर्किंग उपकरण, कूलिंग, जमीन, फाइबर, खरीदारी, निर्माण, या बस इतना ही कि पर्याप्त लोग मिलें जो जानते हों कि इन सबको कैसे एक साथ जोड़ा जाए, भी हो सकता है।

और एक बाधा को हल करने के बाद, दूसरी अधिक स्पष्ट हो जाती है। यही तब होता है जब मांग आपूर्ति से बहुत अधिक होती है।

इसलिए मैं किसी एक स्थायी बाधा पर दांव नहीं लगाऊँगा। मेरा मानना है कि अधिक महत्वपूर्ण क्षमता यह है कि बाधा के स्थानांतरित होने पर अनुकूलित हो सकें।

यही कारण है कि मुझे नहीं लगता कि अभी कोई AI इन्फ्रास्ट्रक्चर के लिए निश्चित मार्गदर्शिका रखता है। इसे बनाने वाले लोग इसे स्केल करते हुए समझ रहे हैं, और वे दोनों को अत्यंत तेज़ी से कर रहे हैं।

उत्कृष्ट साक्षात्कार के लिए धन्यवाद, जो पाठक अधिक जानना चाहते हैं उन्हें NetBox Labs पर जाना चाहिए।