जैसे-जैसे संगठन AI को प्रोडक्शन में ला रहे हैं, Kubernetes उसके आसपास की सेवाओं के लिए एक जाना-पहचाना ठिकाना बनता जा रहा है। लेकिन कोई एप्लिकेशन चल रहा हो, तब भी उपयोगकर्ता जवाबों का इंतज़ार करते रह सकते हैं। यह अंतर बदल देता है कि प्लेटफ़ॉर्म टीमें प्रदर्शन की जाँच कैसे करती हैं, GPU कैसे आवंटित करती हैं और भरोसेमंद सेवा की योजना कैसे बनाती हैं।
संपादकीय उदाहरण: इस लेख में बताई गई कंपनी और घटना काल्पनिक हैं। तकनीकी व्याख्याएँ और उद्योग के आँकड़े लिंक किए गए स्रोतों पर आधारित हैं।
सब कुछ चल रहा है, लेकिन कर्मचारी इंतज़ार कर रहे हैं
कंपनी का नया AI असिस्टेंट सफल दिख रहा था। कर्मचारी कई वेबसाइटों पर खोजने के बजाय आंतरिक नीतियों और तकनीकी दस्तावेज़ों के बारे में सवाल पूछ सकते थे। पायलट ने कुछ ही सेकंड में उपयोगी जवाब दिए। इसके डेवलपरों ने सॉफ़्टवेयर को कंटेनरों में पैक किया और कंपनी के मौजूदा Kubernetes प्लेटफ़ॉर्म पर डिप्लॉय किया।
फिर असिस्टेंट हज़ारों कर्मचारियों के लिए उपलब्ध हुआ। कुछ जवाब जल्दी आए, जबकि कुछ में इतना समय लगा कि लोगों ने हार मान ली।
ऑपरेशंस इंजीनियरों ने क्लस्टर की जाँच की। nodes उपलब्ध थे, एप्लिकेशन के कंटेनर चल रहे थे, और Kubernetes ने प्रतियों की अपेक्षित संख्या बनाए रखी थी। फिर भी सेवा टूटी हुई लग रही थी।
एक और एप्लिकेशन सर्वर जोड़ना स्वाभाविक जवाब लगा। लेकिन इससे पैसा खर्च होता और एक ज़्यादा अहम सवाल का जवाब नहीं मिलता: हर अनुरोध अपना समय कहाँ बिता रहा था?
यह समस्या एक व्यापक बदलाव को दर्शाती है। जनवरी 2026 में प्रकाशित अपने 2025 वार्षिक क्लाउड नेटिव सर्वे में CNCF ने बताया कि सर्वे में शामिल कंटेनर उपयोगकर्ताओं में से 82% प्रोडक्शन में Kubernetes चला रहे थे।
एक अलग सर्वे प्रश्न का उत्तर AI वर्कलोड होस्ट करने वाले 213 संगठनों ने दिया, और उनमें से 66% ने कुछ या सभी इन्फ़रेंस वर्कलोड के लिए Kubernetes का उपयोग किया। ये आँकड़े अलग-अलग उत्तरदाता समूहों का वर्णन करते हैं, दुनिया भर की सभी कंपनियों का नहीं। CNCF ने KubeCon North America 2026 में एक समर्पित AI Inference + Agentic ट्रैक भी शुरू किया।
AI उस इन्फ्रास्ट्रक्चर में प्रवेश कर रहा है जिसे प्लेटफ़ॉर्म टीमें पहले से जानती हैं। रहस्य यह है कि जाने-पहचाने टूल हमेशा पूरी कहानी क्यों नहीं बताते।
पूरे सिस्टम में एक सवाल का पीछा कीजिए
इंजीनियर देर से पूरा हुआ एक अनुरोध चुनते हैं: एक कर्मचारी ने पूछा है कि यात्रा व्यय की प्रतिपूर्ति नीति में क्या बदला है।
असिस्टेंट पहले जाँचता है कि कर्मचारी को वह नीति देखने की अनुमति है या नहीं। वह कंपनी के दस्तावेज़ खोजता है, प्रासंगिक अंश चुनता है, और सवाल तथा सहायक पाठ एक लैंग्वेज मॉडल को भेजता है। मॉडल एक जवाब जनरेट करता है। जनरेशन से पहले सहायक जानकारी खोजने को आम तौर पर रिट्रीवल-ऑगमेंटेड जनरेशन (retrieval-augmented generation, RAG) कहा जाता है। पहले से प्रशिक्षित मॉडल से जवाब तैयार करवाना इन्फ़रेंस (inference) है।
Kubernetes उन चरणों के पीछे के सॉफ़्टवेयर को चला सकता है। एक कंटेनर (container) किसी एप्लिकेशन और उसकी सॉफ़्टवेयर निर्भरताओं को एक साथ पैक करता है।
Kubernetes कंटेनरों को Pods में शेड्यूल करता है, यानी वे इकाइयाँ जिन्हें वह nodes कहलाने वाली वर्कर मशीनों पर रखता है। उपयुक्त संसाधन उपलब्ध होने पर वह माँगी गई प्रतियाँ बनाए रख सकता है और विफल Pods को बदल सकता है। आधिकारिक Kubernetes अवलोकन ऑर्केस्ट्रेशन मॉडल को समझाता है।
लेकिन असिस्टेंट एक अकेली, अविभाज्य सेवा के रूप में नहीं चलता। उसका अनुरोध कई चरणों से गुज़रता है:
| अनुरोध का चरण | किया जा रहा काम | संभावित देरी |
|---|---|---|
| पहचान | कर्मचारी की पहुँच की जाँच | पहचान सेवा का रिस्पॉन्स |
| रिट्रीवल | इंडेक्स किए गए नीति दस्तावेज़ों में खोज | खोज या स्टोरेज की लेटेंसी |
| इन्फ़रेंस | लैंग्वेज मॉडल से जवाब जनरेट करना | मॉडल क्षमता का इंतज़ार और जनरेशन का समय |
| वापसी | जवाब को एप्लिकेशन तक पहुँचाना | नेटवर्क या एप्लिकेशन की देरी |
हमारी उदाहरण के तौर पर ली गई जाँच में पहचान और रिट्रीवल सेवाएँ जल्दी जवाब देती हैं। अनुरोध इन्फ़रेंस पर जमा होते जाते हैं।
एप्लिकेशन API सवालों को उससे तेज़ी से स्वीकार करता है जितनी तेज़ी से मॉडल उन्हें पूरा कर पाता है, जिससे एक क्यू (queue) बन जाती है। ज़्यादा API Pods बस उसी क्यू को और तेज़ी से भरेंगे। इंजीनियरों ने बाधा का पता लगा लिया है। अब उन्हें उसके पीछे के संसाधन को समझना है।
उपलब्ध CPU का मतलब उपलब्ध GPU नहीं है
सामान्य वेब सेवाएँ अक्सर मुख्य रूप से CPU पर निर्भर करती हैं, यानी वह सामान्य-उद्देश्य प्रोसेसर जो एप्लिकेशन कोड चलाता है, और सक्रिय डेटा के लिए मेमोरी पर। बड़े लैंग्वेज मॉडल अक्सर GPU का उपयोग करते हैं, जो एक साथ होने वाली कई गणितीय गणनाओं के लिए उपयुक्त प्रोसेसर हैं। GPU को मॉडल डेटा रखने और अनुरोध संभालने के लिए पर्याप्त समर्पित मेमोरी भी चाहिए। हर AI सेवा को अपने GPU की ज़रूरत नहीं होती: छोटे मॉडल CPU पर चल सकते हैं, और कई एप्लिकेशन इसके बजाय होस्ट किए गए मॉडल को कॉल करते हैं।
हमारी कंपनी ने GPU पर चलने वाला मॉडल होस्ट करने का फ़ैसला किया। कल्पना कीजिए कि उसके पास चार उपयुक्त GPU हैं और चारों पहले से मॉडल-सर्विंग वर्कलोड को आवंटित हैं। Kubernetes के पास एक और API Pod के लिए अतिरिक्त CPU और मेमोरी हो सकती है, लेकिन मॉडल की एक अतिरिक्त रेप्लिका को उपयुक्त GPU चाहिए। वह रेप्लिका तब भी बिना शेड्यूल हुए रह सकती है, जब क्लस्टर में सामान्य कंप्यूटिंग क्षमता भरपूर दिखाई दे रही हो।
Kubernetes डिवाइस प्लगइन (device plugins) के ज़रिए GPU के बारे में जानता है और डायनेमिक रिसोर्स एलोकेशन (Dynamic Resource Allocation, DRA) का उपयोग कर सकता है, ताकि वर्कलोड रिसोर्स क्लेम (resource claims) के ज़रिए डिवाइस की विशेषताएँ माँग सकें। DRA, Kubernetes 1.35 से स्टेबल है।
सबसे अहम बात यह है कि DRA दस्तावेज़ के अनुसार शेड्यूलर किसी ऊँची प्राथमिकता वाले Pod को डिवाइस देने के लिए, DRA संसाधनों का उपयोग कर रहे किसी मौजूदा Pod को प्रीएम्प्ट (preempt) नहीं कर सकता। ज़रूरी Pod तब तक पेंडिंग (pending) रह सकता है जब तक डिवाइस खाली न हो जाए। समर्थित कॉन्फ़िगरेशन में डिवाइस साझा करना संभव है। चार GPU वाला उदाहरण केवल एक सरलीकृत चित्रण है, हर GPU पर एक वर्कलोड का कोई सार्वभौमिक नियम नहीं।
यही वह बिंदु है जहाँ टीम की स्केलिंग वाली पुरानी आदत काम नहीं आती: सॉफ़्टवेयर की ज़्यादा प्रतियाँ बनाने से कोई दुर्लभ एक्सेलेरेटर पैदा नहीं किया जा सकता।
जाँच ने क्या बदला
| पहले की धारणा | अनुरोध से मिला सबूत |
|---|---|
| कंटेनर स्वस्थ हैं, इसलिए असिस्टेंट स्वस्थ है | उपयोगकर्ता अब भी मॉडल इन्फ़रेंस का इंतज़ार करते हैं |
| ज़्यादा API रेप्लिका देरी ठीक कर देंगी | सीमित घटक API नहीं है |
| सर्वर का खाली बैठा CPU मतलब क्षमता मौजूद है | उपयुक्त GPU मेमोरी या डिवाइस पहले से आवंटित हो सकते हैं |
| प्राथमिकता तुरंत रिकवरी क्षमता की गारंटी देती है | DRA शेड्यूलिंग में प्रीएम्प्शन की एक दस्तावेज़ में दर्ज सीमा है |
इंजीनियरों को अब विफलता की एक और व्याख्या की ज़रूरत नहीं है। उन्हें एक हस्तक्षेप चुनना है और उसके नतीजों को परखना है।
क्षमता, दृश्यता और रिकवरी को ठीक कीजिए
API के CPU उपयोग से नहीं, इन्फ़रेंस की माँग से शुरुआत कीजिए। टीम मॉडल का इंतज़ार कर रहे अनुरोधों, इस समय प्रोसेस हो रहे अनुरोधों, रिस्पॉन्स लेटेंसी और मॉडल-सर्विंग थ्रूपुट को मापती है। KServe, Kubernetes पर मॉडल सर्व करने के लिए एक ओपन-सोर्स प्लेटफ़ॉर्म है। इसका जनरेटिव-इन्फ़रेंस ऑटोस्केलिंग दस्तावेज़ दिखाता है कि ज़रूरी मेट्रिक्स इन्फ्रास्ट्रक्चर कॉन्फ़िगर होने पर KEDA (Kubernetes Event-driven Autoscaling) मॉडल-सर्विंग मेट्रिक्स के आधार पर इन्फ़रेंस रेप्लिका को कैसे स्केल कर सकता है, जिनमें vLLM इन्फ़रेंस इंजन से मिलने वाली अनुरोधों की गिनती भी शामिल है।
वह स्केलिंग ज़्यादा रेप्लिका का अनुरोध कर सकती है, लेकिन GPU की उपलब्धता की गारंटी नहीं दे सकती। टीम को तय करना होगा कि एक्सेलेरेटर आरक्षित करना, बैचिंग (batching) सुधारना (अनुरोधों को समूहों में रखना ताकि मॉडल कई अनुरोध एक साथ संभाले), अनावश्यक मॉडल कॉल घटाना या मॉडल का आकार बदलना, इनमें से कौन सा तरीका सबसे अच्छा नतीजा देता है। कई रेप्लिका हो जाने के बाद, AI इन्फ़रेंस लोड बैलेंसिंग पर हमारा लेख समझाता है कि रूटिंग कैश किए गए काम और व्यस्त कंप्यूट को कैसे ध्यान में रख सकती है।
पूरे अनुरोध का पीछा कीजिए। एक डिस्ट्रिब्यूटेड ट्रेस (trace) दर्ज करता है कि अनुरोध कहाँ से गुज़रा और उसके चरणों में कितना समय लगा। OpenTelemetry, जो 21 मई 2026 को CNCF प्रोजेक्ट के रूप में ग्रेजुएट हुआ, वेंडर-न्यूट्रल ऑब्ज़र्वेबिलिटी (observability) टूल देता है। इसके GenAI सिमैंटिक कन्वेंशन (semantic conventions), यानी इस तरह की टेलीमेट्री (telemetry) के लिए तय किए गए फ़ील्ड नाम, मॉडल इनवोकेशन, टोकन उपयोग और टूल एक्ज़ीक्यूशन के लिए अब भी विकसित हो रहे हैं।
टोकन (token) टेक्स्ट की वह इकाई है जिसे मॉडल ग्रहण या जनरेट करता है। टोकन की गिनती प्रोसेसिंग की माँग और लागत को समझाने में मदद कर सकती है। ट्रेसिंग इंतज़ार में बीते समय को जवाब जनरेट करने में बीते समय से अलग कर सकती है। टेलीमेट्री पाइपलाइन का स्वामित्व लेने पर हमारा लेख बताता है कि OpenTelemetry क्या मानकीकृत करता है और कब कलेक्टर चलाना उस अतिरिक्त परत के लायक होता है।
संवेदनशील सामग्री को अनावश्यक टेलीमेट्री से बाहर रखिए। कर्मचारियों के प्रॉम्प्ट, खोजकर निकाले गए नीति पाठ और जनरेट किए गए जवाबों में निजी जानकारी हो सकती है। OpenTelemetry GenAI एट्रिब्यूट दस्तावेज़ संभावित संवेदनशील सामग्री की पहचान करता है। इंजीनियरों को पूरे प्रॉम्प्ट बिना सोचे-समझे स्टोर किए बिना लेटेंसी और गिनतियाँ दर्ज करनी चाहिए, और जिस सामग्री की उन्हें वाकई ज़रूरत हो, उसके लिए एक्सेस कंट्रोल, फ़िल्टरिंग और रिटेंशन लागू करना चाहिए।
सिर्फ़ रीस्टार्ट नहीं, पूरी सेवा को परखिए। अगर कोई इन्फ़रेंस node विफल होता है, तो Kubernetes उसकी जगह एक नया Pod शेड्यूल कर सकता है। उस Pod को फिर भी एक उपयुक्त एक्सेलेरेटर और मॉडल फ़ाइलें चाहिए। एप्लिकेशन को अपनी खोज और पहचान से जुड़ी निर्भरताएँ भी चाहिए। एक उपयोगी रिकवरी टेस्ट यह मापता है कि कर्मचारी कब फिर से सही और अधिकृत जवाब पा सकते हैं।
और अगर कोई AI एजेंट रिकॉर्ड बदल सकता है, तो डाउनस्ट्रीम एप्लिकेशन को हर कार्रवाई को असली उपयोगकर्ता के लिए अधिकृत करना होगा: किसी मॉडल का किसी टूल को कॉल करने का फ़ैसला उस ऑपरेशन को करने की अनुमति नहीं है। Kubernetes सुरक्षा नियंत्रण वर्कलोड की सुरक्षा में मदद करते हैं, लेकिन व्यावसायिक ऑथराइज़ेशन की जगह नहीं लेते।
ये जवाब अलग-अलग समस्याएँ हल करते हैं। स्केलिंग सीमित क्षमता की समस्या से निपटती है, ट्रेसिंग प्रदर्शन को समझाती है, प्राइवेसी नियंत्रण सबूत की रक्षा करते हैं, और रिकवरी तथा ऑथराइज़ेशन खुद सेवा की रक्षा करते हैं।
मॉडल खुद चलाएँ या इन्फ़रेंस खरीदें
टीम Kubernetes पर इन्फ़रेंस होस्ट करना जारी रख सकती है, या अपना एप्लिकेशन Kubernetes पर चलाते हुए एक मैनेज्ड मॉडल API का उपयोग कर सकती है। इनमें से कोई भी सार्वभौमिक जवाब नहीं है।
| विकल्प | सेल्फ़-होस्टेड इन्फ़रेंस | मैनेज्ड मॉडल API |
|---|---|---|
| हार्डवेयर | टीम एक्सेलेरेटर क्षमता और उसके उपयोग का प्रबंधन करती है | प्रदाता सर्विंग इन्फ्रास्ट्रक्चर का प्रबंधन करता है |
| स्केलिंग | शेड्यूलिंग, मॉडल-सर्विंग मेट्रिक्स और अतिरिक्त क्षमता की ज़रूरत | कोटा, समवर्तिता (concurrency) और प्रदाता की सीमाओं के प्रबंधन की ज़रूरत |
| नियंत्रण | रनटाइम और मॉडल डिप्लॉयमेंट पर ज़्यादा नियंत्रण | प्रदाता द्वारा समर्थित मॉडलों और सुविधाओं तक सीमित |
| अर्थशास्त्र | हार्डवेयर समय, इंजीनियरिंग, ऑपरेशंस और स्टोरेज | उपयोग शुल्क, प्रतिबद्धताएँ और इंटीग्रेशन लागत |
| जोखिम | मॉडल लोडिंग, क्लस्टर और एक्सेलेरेटर की रिकवरी | नेटवर्क, सेवा की उपलब्धता और डेटा प्रोसेसिंग से जुड़ी व्यवस्थाएँ |
लगातार ऊँचे वॉल्यूम पर कई मॉडल सर्व करने वाली कंपनी के लिए इन्फ़रेंस का प्रबंधन खुद करना फ़ायदेमंद हो सकता है। एक असिस्टेंट चलाने वाली छोटी टीम मैनेज्ड सेवा का उपयोग करके GPU से जुड़े काफ़ी काम से बच सकती है। अगर वह इन्फ़रेंस Kubernetes में रखती है, तो जहाँ आइसोलेशन, क्षमता या विश्वसनीयता इसे उचित ठहराएँ, वहाँ समर्पित GPU node pools (GPU वर्कर मशीनों के समूह) या अलग क्लस्टर उपयुक्त हो सकते हैं। जो टीम मॉडल खुद होस्ट करती है, उसे उसे सर्व करने के लिए एक इंजन भी चुनना होगा, और AI इन्फ़रेंस इंजन चुनने पर हमारी गाइड बताती है कि किन बातों की तुलना करनी है।
हमारे उदाहरण वाली कंपनी अब मापी गई अनुरोध माँग, सेवा लक्ष्यों, संचालन के प्रयास और डेटा आवश्यकताओं के आधार पर विकल्पों की तुलना कर सकती है। यह इस फ़ैसले से ज़्यादा उपयोगी है कि हर AI घटक को Kubernetes क्लस्टर में ही रहना चाहिए, सिर्फ़ इसलिए कि एप्लिकेशन का बाकी हिस्सा वहाँ है।
किसी टीम को कितनी गहराई तक जाना है, यह उसकी भूमिका पर निर्भर करता है। ज़्यादातर प्लेटफ़ॉर्म और एप्लिकेशन टीमों को बस इस पैटर्न को पहचानना और यह मापना होता है कि अनुरोध कहाँ इंतज़ार करता है, जो सही सवाल जल्दी पूछने के लिए काफ़ी है। जो टीमें मॉडल खुद होस्ट करती हैं, उन्हें एक्सेलेरेटर शेड्यूलिंग और मॉडल सर्विंग में ज़्यादा गहराई चाहिए, और नीचे लिंक किए गए Kubernetes और KServe दस्तावेज़ उन्हीं के लिए लिखे गए हैं।
Kubernetes एक मज़बूत आधार बना हुआ है: यह सेवाओं को शेड्यूल करता है, उपलब्धता बनाए रखने में मदद करता है और टीमों को जाने-पहचाने ऑपरेशनल नियंत्रण देता है। AI ऐसी संसाधन सीमाएँ और एप्लिकेशन से जुड़ी ज़िम्मेदारियाँ जोड़ता है जिन्हें ये नियंत्रण अपने आप नहीं सुलझा सकते।
प्लेटफ़ॉर्म टीमों के लिए अहम कौशल AI को पूरी तरह नई दुनिया मानना नहीं है। अहम कौशल यह जानना है कि जाने-पहचाने Kubernetes तरीके कहाँ खत्म होते हैं, और मॉडल-सर्विंग इंजीनियरिंग को कहाँ से शुरू होना चाहिए।
और गहराई में जाएँ
- CNCF वार्षिक क्लाउड नेटिव सर्वे 2025: CNCF, जनवरी 2026। अपनाने के आँकड़े, सर्वे में शामिल समूह और सीमाएँ।
- KubeCon North America 2026 का AI Inference + Agentic ट्रैक: CNCF, अगस्त 2026। इस आयोजन की उभरती इन्फ्रास्ट्रक्चर प्राथमिकताएँ।
- Kubernetes GPU शेड्यूलिंग: डिवाइस प्लगइन पर आधिकारिक मार्गदर्शन।
- Kubernetes डायनेमिक रिसोर्स एलोकेशन: स्टेबल स्थिति, डिवाइस क्लेम और प्रीएम्प्शन की सीमाएँ।
- KServe जनरेटिव-इन्फ़रेंस ऑटोस्केलिंग: KServe। मॉडल-सर्विंग स्केलिंग और KEDA मेट्रिक्स।
- OpenTelemetry का ग्रेजुएशन: 21 मई 2026। प्रोजेक्ट का एक अहम पड़ाव।
- OpenTelemetry GenAI सिमैंटिक कन्वेंशन: मॉडल, एजेंट और टूल टेलीमेट्री के लिए विकसित हो रहे कन्वेंशन।
- OpenTelemetry GenAI एट्रिब्यूट: प्राइवेसी के लिहाज़ से संवेदनशील इंस्ट्रूमेंटेशन विवरण।