6.6 AI इन्फ्रास्ट्रक्चर और संचालन

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफ़ारिशें

एक्सेलरेटर कंप्यूट की योजना बनाएँ और नियंत्रित करें

प्रशिक्षण और इन्फ़रेंस के लिए माँग का अलग-अलग पूर्वानुमान लगाएँ, क्योंकि उनके आकार अलग होते हैं। प्रशिक्षण फुहार जैसा (bursty) और शेड्यूल योग्य है; इन्फ़रेंस निरंतर और लेटेंसी-संवेदनशील है। टीमों में दुर्लभ GPU और TPU साझा करने, वर्कलोड को प्राथमिकता देने, और उपयोग बढ़ाने के लिए शेड्यूलर और कोटा का उपयोग करें। उपयोग को मापें और पुरानी निष्क्रियता को एक समस्या मानें जिसे ठीक करना है। लागत नियंत्रित करने के लिए बेसलाइन लोड के लिए आरक्षित क्षमता को फुहार के लिए ऑन-डिमांड या स्पॉट क्षमता के साथ मिलाएँ। विचार करें कि क्या सस्ते या छोटे एक्सेलरेटर, या हल्के मॉडलों के लिए CPU इन्फ़रेंस पर्याप्त होंगे। अपने पैमाने पर लागत, डेटा-संप्रभुता की ज़रूरतों, और फुहार पैटर्न के आधार पर क्लाउड, ऑन-प्रिमाइसेस, और हाइब्रिड के बीच चुनें, और एक निकास मार्ग बनाए रखें।

पुनर्प्राप्ति इन्फ्रास्ट्रक्चर बनाएँ: एम्बेडिंग और वेक्टर डेटाबेस

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

मॉडल सर्विंग को अनुकूलित करें: बैचिंग, कैशिंग, और लेटेंसी

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

LLMOps का अभ्यास करें: प्रॉम्प्ट वर्ज़निंग, मूल्यांकन पाइपलाइन, और ऑब्ज़र्वेबिलिटी

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

लागत को निरंतर और अवलोकनीय रूप से प्रबंधित करें

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

समझौते: फ़ायदे और नुकसान

निर्णय	विकल्प A	विकल्प B	समझौता
कंप्यूट स्थान	क्लाउड	ऑन-प्रिमाइसेस	लोचशीलता और कम अग्रिम लागत बनाम नियंत्रण, संप्रभुता, और स्थिर-अवस्था अर्थशास्त्र
क्षमता	आरक्षित	ऑन-डिमांड/स्पॉट	पूर्वानुमेय लागत बनाम लचीलापन और बाधा जोखिम
बैच आकार	बड़े बैच	छोटे बैच	थ्रूपुट और लागत बनाम लेटेंसी
मॉडल आकार	बड़ा मॉडल	छोटा मॉडल	गुणवत्ता बनाम लागत और गति
वेक्टर स्टोर	समर्पित डेटाबेस	मौजूदा डेटाबेस विस्तार	पैमाने पर प्रदर्शन बनाम सरलता और कम सिस्टम
कैशिंग	आक्रामक	न्यूनतम	कम लागत और लेटेंसी बनाम ताज़गी और जटिलता

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. आज हमारी प्रति-उपयोगी-परिणाम लागत क्या है, और कौन-सा लीवर इसे सबसे अधिक हिलाएगा? कच्ची क्षमता और प्रति-अनुरोध औसत उस संख्या को छुपाते हैं जो मायने रखती है: मूल्य की एक वास्तविक इकाई पहुँचाने में क्या लागत आती है, और उपयोग के साथ यह कैसे स्केल होती है। एक बड़ी टीम के लिए, एक अनुकूलित और एक अनुकूलित न की गई तैनाती के बीच का अंतर अक्सर खर्च में कई गुना होता है, इसलिए यह प्रश्न बिल के बारे में एक अस्पष्ट चिंता को सुधारों की एक क्रमबद्ध सूची में बदल देता है। टीम और उपयोग मामले के अनुसार वर्तमान लागत विशेषण, प्रति-अनुरोध और प्रति-परिणाम रुझान, और सबसे बड़े लागत चालक लाएँ। लाभ के क्रम में लीवर पर चर्चा करें: मॉडल राइट-साइज़िंग, कैशिंग (प्रीफ़िक्स और सिमेंटिक कैशिंग सहित), बैचिंग, और प्रॉम्प्ट या संदर्भ ट्रिमिंग। सरकार में, बहु-वर्षीय खर्च का पूर्वानुमान लगाने और उसे उचित ठहराने के दबाव को जोड़ें। उत्तर को हर शीर्ष लागत चालक को एक स्वामी और एक लीवर सौंपना चाहिए, कंधे उचकाना नहीं।

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

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

4. जब एक प्रॉम्प्ट या मॉडल परिवर्तन शिप होता है, तो एक चुपचाप गुणवत्ता या लागत प्रतिगमन को उपयोगकर्ताओं तक पहुँचने से क्या रोकता है? एक सर्विंग स्टैक लेटेंसी और अपटाइम पर स्वस्थ दिख सकता है जबकि यह जो उत्तर लौटाता है वे चुपचाप खराब होते जाते हैं या एक नया प्रॉम्प्ट प्रति अनुरोध टोकन उपयोग को दोगुना कर देता है। एक बड़ी टीम के लिए जहाँ कई समूह स्वतंत्र रूप से प्रॉम्प्ट संपादित करते और मॉडल बदलते हैं, एक बिना-गेट किया गया परिवर्तन एक होने वाली प्रोडक्शन घटना है, और साझा प्लेटफ़ॉर्म पर हर टीम के साथ प्रभाव-क्षेत्र बढ़ता है। अपनी मूल्यांकन कवरेज लाएँ: किन प्रॉम्प्ट और मॉडलों के पास ऑफ़लाइन टेस्ट सूट हैं, क्या वे सूट हर परिवर्तन पर स्वचालित रूप से चलते हैं, कौन-से गुणवत्ता और लागत थ्रेशोल्ड एक रिलीज़ को गेट करते हैं, और आप कितनी तेज़ी से वापस रोल कर सकते हैं। चर्चा करें कि क्या प्रॉम्प्ट समीक्षा के साथ सोर्स कंट्रोल में रहते हैं, या क्या कोई अभी भी हाथ से एक लाइव सिस्टम प्रॉम्प्ट संपादित कर सकता है। उद्यम और सरकारी सेटिंग में, हर परिवर्तन को एक ऑडिट ट्रेल और एक नामित अनुमोदक से जोड़ें, क्योंकि एक नियामक जो पूछता है “इसे किसने बदला और आपने क्या परीक्षण किया” उसे एक ऐसा उत्तर चाहिए जो दर्ज हो, याद न किया गया हो।

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

6. क्या हम वास्तव में अपने AI खर्च के स्वामी हैं, और क्या हर टीम उस लागत को देख और उसके लिए जवाब दे सकती है जो वह चलाती है? AI लागत उपयोग के साथ ऐसे तरीकों से स्केल होती है जो लोगों को आश्चर्यचकित करते हैं, और विशेषण के बिना बिल एक अपारदर्शी संख्या के रूप में पहुँचता है जिसे घटाने के लिए कोई टीम ज़िम्मेदार महसूस नहीं करती। एक बड़े संगठन में, जिस लागत का कोई स्वामी नहीं है वह लागत है जिसे कोई अनुकूलित नहीं करता, इसलिए सवाल यह है कि क्या खर्च को बजट, अलर्ट, और प्रति-परिणाम रुझान के साथ टीमों और उपयोग मामलों में टैग किया जाता है, या इसे केवल तब खोजा जाता है जब वित्त इसे बढ़ाता है। अपना लागत-विशेषण मॉडल, टीम के अनुसार सबसे बड़े चालक, और हर स्वामी जिन लीवर को नियंत्रित करता है, लाएँ: राइट-साइज़िंग, कैशिंग, बैचिंग, और संदर्भ ट्रिमिंग। उद्यम और सरकारी बजट के लिए, बहु-वर्षीय इन्फ्रास्ट्रक्चर खर्च का पूर्वानुमान लगाने और उसे उचित ठहराने का अनुशासन जोड़ें, क्योंकि एक सार्वजनिक निकाय जो अपने कंप्यूट बिल को पंक्ति दर पंक्ति समझा नहीं सकता, वह समीक्षा में इसका बचाव करने में संघर्ष करेगा।

क्षेत्र लेंस

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

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

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

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

उदाहरण

स्टार्टअप। एक AI लेखन सुविधा चला रहे एक छोटे स्टार्टअप ने बिना कोई GPU स्वामित्व में रखे अपना बिल समझदार रखा। इसने एक होस्टेड इन्फ़रेंस API को कॉल किया, आसान अनुरोधों को एक सस्ते छोटे मॉडल पर रूट किया और कठिन मामलों के लिए बड़ा मॉडल बचाया, और दोहराए गए प्रॉम्प्ट के उत्तरों को कैश किया। इसने अपने प्रॉम्प्ट को git में एक छोटी मूल्यांकन स्क्रिप्ट के साथ संग्रहीत किया जो हर परिवर्तन से पहले चलती थी, पुनर्प्राप्ति के लिए एक प्रबंधित वेक्टर डेटाबेस का उपयोग किया ताकि इसे एक चलाना न पड़े, और प्रति-अनुरोध लागत लॉग की ताकि संस्थापक खर्च को आश्चर्य बनने से पहले चढ़ते हुए देख सकें।

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विपरीत प्रतिमान और नुकसान

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

परिपक्वता मॉडल

1. प्रारंभ (Initiate)। जो सबसे ज़ोर से माँगे उस पर प्रतिक्रिया करने वाला तदर्थ GPU आवंटन, कोई बैचिंग या कैशिंग नहीं, बिल पहुँचने तक कोई लागत दृश्यता नहीं, प्रॉम्प्ट लाइव और बिना वर्ज़न के संपादित, न्यूनतम निगरानी।
2. विकास (Develop)। कुछ टीमें साझा शेड्यूलिंग, कैशिंग, और वर्ज़न-नियंत्रित प्रॉम्प्ट अपनाती हैं, लेकिन प्रथा संगठन में असंगत है: एक समूह बैच और मूल्यांकन करता है जबकि दूसरा अभी भी हर अनुरोध को व्यक्तिगत रूप से सर्व करता है और हाथ से प्रॉम्प्ट बदलता है।
3. मानकीकरण (Standardize)। एक दस्तावेज़ीकृत, पक्की-सड़क प्लेटफ़ॉर्म संगठन-व्यापी लागू है: कोटा और प्राथमिकताओं के साथ साझा शेड्यूलिंग, मानक बैचिंग, कैशिंग, और राइट-साइज़िंग, पुनर्प्राप्ति के लिए वेक्टर इन्फ्रास्ट्रक्चर, स्वचालित मूल्यांकन पाइपलाइन जो हर प्रॉम्प्ट या मॉडल परिवर्तन को गेट करती हैं, और टीमों तथा उपयोग मामलों में लागत विशेषण।
4. प्रबंधन (Manage)। प्लेटफ़ॉर्म को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है: एक्सेलरेटर उपयोग, प्रति-उपयोगी-परिणाम लागत, टेल लेटेंसी, पुनर्प्राप्ति रिकॉल, और प्रति-परिवर्तन गुणवत्ता प्रतिगमन को अलर्ट और थ्रेशोल्ड के साथ ट्रैक किया जाता है, लागत हर टीम के स्वामित्व में है, और एक परिवर्तन पर जाओ या न-जाओ का निर्णय अंतर्ज्ञान के बजाय साक्ष्य पर तय होता है।
5. समन्वय (Orchestrate)। इन्फ्रास्ट्रक्चर निरंतर सुधरता और अनुकूलित होता है: रूटिंग, बैचिंग, और स्केलिंग स्वयं को लाइव लागत और गुणवत्ता संकेतों के अनुसार ट्यून करती हैं, माँग और बाधाओं के बदलने पर क्षमता को टीमों में और क्लाउड, ऑन-प्रिमाइसेस, और संप्रभु लक्ष्यों के बीच फिर से संतुलित किया जाता है, पोर्टेबिलिटी का अभ्यास किया जाता है, और इन्फ्रास्ट्रक्चर योजना उत्पाद, सुरक्षा, और खरीद के साथ एकीकृत है।

चर्चा के लिए विचार

• आप प्राथमिकता वाले वर्कलोड को भूखा रखे बिना एक्सेलरेटर उपयोग कैसे बढ़ाते हैं?
• आपकी लेटेंसी आवश्यकताओं के लिए सही बैचिंग और कैशिंग संतुलन कहाँ है?
• ऑन-प्रिमाइसेस या संप्रभु तैनाती क्लाउड पर अपनी लागत कब उचित ठहराती है?
• आप कई टीमों में AI खर्च को कैसे विशेषित और नियंत्रित करते हैं?
• एक प्रॉम्प्ट या मॉडल परिवर्तन को प्रोडक्शन तक पहुँचने से क्या गेट करना चाहिए?
• आप सर्विंग इन्फ्रास्ट्रक्चर को प्रदाता बदलने लायक पर्याप्त पोर्टेबल कैसे रखते हैं?

मुख्य निष्कर्ष

• एक्सेलरेटर दुर्लभ और महँगे हैं; उन्हें जानबूझकर शेड्यूल, साझा, और उपयोग करें।
• बैचिंग, कैशिंग, और मॉडल राइट-साइज़िंग लागत और लेटेंसी के लिए प्राथमिक लीवर हैं।
• पुनर्प्राप्ति एप्लिकेशन को अच्छी तरह संचालित एम्बेडिंग और वेक्टर-खोज इन्फ्रास्ट्रक्चर चाहिए।
• LLMOps (प्रॉम्प्ट वर्ज़निंग, मूल्यांकन पाइपलाइन, और ऑब्ज़र्वेबिलिटी) जनरेटिव AI की परिचालन रीढ़ है।
• लागत को अवलोकनीय रूप से प्रबंधित करें और लॉक-इन से बचने के लिए पोर्टेबिलिटी बनाए रखें।

संदर्भ और आगे पढ़ने के लिए

• Chip Huyen, Designing Machine Learning Systems.
• Google, Site Reliability Engineering (Beyer, Jones, Petoff, Murphy, editors).
• Jared Kaplan et al., Scaling Laws for Neural Language Models.
• Reza Yazdani Aminabadi et al., DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale.
• Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM).
• Andriy Burkov, Machine Learning Engineering.