बादल की छिपी हुई लागत
मशीनी अनुवादित · मूल लेख पढ़ें
अध्याय 5 — बादल की छिपी हुई लागत
पिछले पांच वर्षों की प्रमुख धारणा यह है कि बादल किफायती, स्केलेबल और सरल है। कई वर्कलोड के लिए यह पूरी तरह से सच है। लेकिन एंटरप्राइज़ RAG के लिए, यह अक्सर ऐसा नहीं होता है। और वह क्षण जब आपको इसका एहसास होता है, आमतौर पर पहली तिमाही के अंत में होता है, जब बिल आता है।
आइए खाते के सबसे कम आंके गए हिस्से पर गौर करें: विज़न मॉडल के API। जब कोई कंपनी अपने फ़ोटो संग्रह को आधुनिक RAG में डालती है, तो प्रत्येक फ़ोटो को एक मल्टीमॉडल मॉडल द्वारा "वर्णित" किया जाना चाहिए जो सामग्री, वस्तुओं, संदर्भ, किसी भी ओवरले किए गए टेक्स्ट, मूड, रचना को निकालता है। एक बड़ी यूरोपीय मॉडल प्रदाता - अभी भी अज्ञात - 2025 में 32 बिलियन पैरामीटर वाले Qwen परिवार का एक उत्कृष्ट मॉडल प्रदान कर रही थी, जिसकी प्रति छवि कीमत आकर्षक थी। समस्या, जो केवल क्षेत्र में और महीनों के उत्पादन के बाद ही खोजी गई: लोड के तहत, प्रदाता प्रतिक्रियाओं को काट रहा था। हमेशा नहीं, अनुमानित तरीके से नहीं, परीक्षण टीम के सामने होने पर नहीं: यादृच्छिक रूप से। दस में से एक फ़ोटो, कभी-कभी पाँच में से एक, आधी कटी हुई JSON, खराब तरीके से पार्स की गई, आंशिक या शून्य मेटाडेटा के साथ वापस आ गई। समय प्रति छवि दस सेकंड से बढ़कर दो सौ सेकंड हो गया, बिना किसी पैटर्न के। रीट्राय का बिल - क्योंकि रीट्राय का भुगतान किया जाता है, प्रत्येक कॉल, यहां तक कि वह भी जिसे सर्वर काट देता है - अपेक्षा से अधिक था। डेटाबेस विषम था: कुछ फ़ोटो मेटाडेटा से भरपूर, अन्य अधूरी। और टीम परीक्षण वातावरण में समस्या को पुन: उत्पन्न करने में असमर्थ थी, क्योंकि परीक्षण में लोड कम था और सब कुछ ठीक से काम कर रहा था।
समाधान तीन भागों में आया: एक अधिक संक्षिप्त प्रॉम्प्ट (छोटे उत्तर कम कटते हैं), एक बुद्धिमान पुनः प्रयास तर्क (यदि उत्तर में पचास सेकंड से अधिक समय लगता है और खाली लौटाता है, तो तुरंत पुनः प्रयास करें) और - जब मात्रा उचित हो - क्लाउड को पूरी तरह से छोड़ देने और स्थानीय GPU पर विज़न मॉडल चलाने की क्षमता, जो धीमा लेकिन नियतात्मक है। इस अनुभव से, सही आर्किटेक्चर "हमेशा क्लाउड" या "हमेशा स्थानीय" नहीं है। यह "प्रत्येक कॉल के लिए चुनें, इस आधार पर कि उस समय क्या आवश्यक है" है।
फिर प्रश्नों का अध्याय है। एक क्लासिक क्लाउड-नेटिव RAG में प्रत्येक उपयोगकर्ता खोज, सशुल्क API कॉल की एक श्रृंखला को ट्रिगर करती है। एक प्रश्न के एम्बेडिंग के लिए। एक इरादे वर्गीकरण के लिए (प्रश्न किस प्रकार का है?)। दस्तावेज़ों को फिर से रैंक करने के लिए। अंतिम उत्तर उत्पन्न करने के लिए। प्रत्येक की लागत एक अंश है। पचास उपयोगकर्ताओं और प्रतिदिन दस हजार प्रश्नों वाली एक आंतरिक सेवा - जो कम नहीं है, लेकिन एक मध्यम आकार की कंपनी के लिए बहुत बड़ी संख्या भी नहीं है - मासिक बिल उन आंकड़ों तक पहुंच जाता है जो एक उदार CFO को भी परेशान कर देगा। और वृद्धि रैखिक है: आप उपयोगकर्ताओं को दोगुना करते हैं, आप बिल को दोगुना करते हैं। आपके द्वारा उपभोग किए गए टोकन में कोई पैमाना अर्थव्यवस्था नहीं है, आपके लिए नहीं।
एक समस्या 2025 में भी छिपी हुई थी और 2026 में केंद्रीय हो गई: प्रत्येक व्यक्तिगत क्वेरी कंपनी के दस्तावेजों के टुकड़ों को — कभी-कभी गोपनीय, कभी-कभी एनडीए द्वारा कवर किए गए, कभी-कभी उद्योग नियमों के अधीन — एक बाहरी प्रदाता के सर्वर पर भेजती है, उन न्यायालयों में जो हमेशा आपके साथ मेल नहीं खाते हैं, लॉग प्रतिधारण नीतियों के साथ जो हमेशा स्पष्ट नहीं होती हैं। पिछले अठारह महीनों में, एक से अधिक यूरोपीय कंपनियों ने केवल एक ऑडिट के दौरान ही पाया — आमतौर पर एक चिंतित ग्राहक या आईएसओ ऑडिट द्वारा प्रेरित — कि उनके अनुबंध, मूल्य सूची और तकनीकी विनिर्देशों को संसाधित किया गया था (और संभावित रूप से "सेवा सुधार" के उद्देश्यों के लिए लॉग किया गया था) यूरोपीय संघ के बाहर के बुनियादी ढांचे द्वारा। आश्चर्य, आमतौर पर, उस स्थानीय हार्डवेयर पर बचत से अधिक महंगा था जिसे वे टालना चाहते थे।
विकल्प विपरीत हठधर्म नहीं है। "क्लाउड नहीं, स्थानीय हाँ" उतना ही गलत है जितना कि "क्लाउड हमेशा हाँ"। विकल्प एक ऐसी संरचना है जो आपको प्रत्येक व्यक्तिगत टुकड़े के लिए — एम्बेडिंग, वर्गीकरण, रीरैंकिंग, विज़न, अंतिम पीढ़ी — चुनने की अनुमति देती है कि क्लाउड मॉडल या स्थानीय मॉडल का उपयोग करना है, और एक दिन में अपना मन बदलने की अनुमति देती है, तिमाही में नहीं। इसके लिए एक डिज़ाइन की आवश्यकता होती है जिसमें आपूर्तिकर्ता विनिमेय हों, जहाँ कोई भी टुकड़ा किसी विशिष्ट कंपनी के नाम से बंधा न हो, जहाँ रेगुलो से ओलामा (या इसके विपरीत) में परिवर्तन एक कॉन्फ़िगरेशन पंक्ति हो, पुन: लेखन नहीं। और यह, हाल ही तक, दुर्लभ था। लोकप्रिय ढांचे, "प्रदाता-अज्ञेयवादी" मुखौटे के बावजूद, वास्तव में किसी के साथ बहुत विवाहित थे।
कोई टिप्पणी? हमें लिखें
यह संदेश केवल हम तक पहुंचेगा। यदि आपकी टिप्पणी दिलचस्प है तो हम इसे लेख के अंत में प्रकाशित कर सकते हैं, लेकिन केवल मूल्यांकन के बाद।
जैसे ही आप लिखते हैं, आपका ब्राउज़र एक छोटा सा गणितीय समस्या हल कर रहा है—यह स्पैम को रोकने का हमारा तरीका है बिना किसी तीसरे पक्ष की सेवा या आपको ट्रैफिक लाइट पहचानने के लिए कहे। आपसे कुछ नहीं मांगा जा रहा है और कोई भी डेटा इस साइट से बाहर नहीं जाता।