बिल में अचानक बढ़ोतरी क्यों हुई
जब टीम ने पहली बार जनरेटिव AI जोड़ा, तो उन्होंने हर यूजर रिक्वेस्ट को सबसे नए और सबसे सक्षम मॉडल पर भेज दिया। जैसे-जैसे ट्रैफिक बढ़ा, प्रति-रिक्वेस्ट लागत भी उसी अनुपात में बढ़ती गई, और CFO के स्प्रेडशीट ने दिखाया कि खर्च यूजर ग्रोथ की तुलना में कहीं अधिक तेजी से बढ़ रहा है। सामान्य त्वरित समाधान—"बस एक सस्ता मॉडल इस्तेमाल करें"—प्रोडक्शन में विफल हो जाता है क्योंकि अलग-अलग क्वेरीज़ को अलग-अलग रीजनिंग (तर्क) स्तरों की आवश्यकता होती है। असली समाधान यह है कि रिक्वेस्ट कैसे भेजी जाती है, न कि हमेशा कौन सा मॉडल इस्तेमाल किया जाता है।
पैसे बचाने वाला एक राउटिंग लेयर बनाना
इंजीनियर ने इन्फरेंस सर्विस (inference service) को किसी अन्य प्रोडक्शन कंपोनेंट की तरह माना: टियर्स (tiers) परिभाषित करें, SLAs सेट करें, और लेटेंसी बजट लागू करें। इसके परिणामस्वरूप जो आर्किटेक्चर बना उसमें चार गतिशील हिस्से हैं जो मिलकर 95% की कमी लाते हैं।
टियर आधारित राउटिंग (Tiered routing)
एक हल्का फ्रंट-एंड प्रत्येक आने वाली रिक्वेस्ट को उसकी कठिनाई के आधार पर वर्गीकृत करता है। लगभग 95% क्वेरीज़ एक "सस्ते" टियर में आती हैं जो एक साधारण मॉडल चलाता है; केवल सबसे कठिन 5% को ही प्रीमियम मॉडल पर भेजा जाता है। वर्गीकरण नियम-आधारित (जैसे, लंबाई, डोमेन-विशिष्ट कीवर्ड की उपस्थिति) हो सकता है या ऐतिहासिक एस्केलेशन डेटा से सीखा जा सकता है। डिफ़ॉल्ट रूप से लो-कॉस्ट टियर का उपयोग करने से, चैटबॉट की मासिक लागत $420 से घटकर $28 रह गई।
मॉडल राइट-साइजिंग (Model right-sizing)
कार्य की जटिलता के अनुसार मॉडल की क्षमता का मिलान करना सबसे बड़ी बचत प्रदान करता है:
- Simple chat – फ्लैगशिप मॉडल के बजाय एक लाइटवेट मॉडल का उपयोग करें (97.5% बचत)।
- Classification – मिड-साइज़ मॉडल को सस्ते विकल्प से बदलें (98.3% बचत)।
- Summarization – टॉप-टियर मॉडल को मिड-रेंज मॉडल से बदलें (97.2% बचत)।
सटीक मॉडल के नाम महत्वपूर्ण नहीं हैं; सिद्धांत यह है कि सबसे सक्षम मॉडल को उन कुछ क्वेरीज़ के लिए आरक्षित रखा जाए जिन्हें वास्तव में इसकी आवश्यकता है।
स्मार्ट कैशिंग (Smart caching)
प्रत्येक कैश हिट एक नेटवर्क कॉल और एक API चार्ज को खत्म कर देता है। एक डिस्ट्रिब्यूटेड Redis कैश सफल प्रतिक्रियाओं के साथ-साथ "नकारात्मक" उत्तरों ("मुझे नहीं पता") को भी स्टोर करता है। जब वही अनुत्तरित प्रश्न फिर से आता है, तो सिस्टम मॉडल को दूसरी बार बुलाने के बजाय कैश किया गया "मुझे नहीं पता" वापस कर देता है। हजारों रिक्वेस्ट के दौरान, अकेले यही बिल में एक बड़ी कटौती करता है।
प्रॉम्प्ट कंप्रेशन (Prompt compression)
लंबे प्रॉम्प्ट टोकन के उपयोग को बढ़ाते हैं, जिसका सीधा असर लागत पर पड़ता है। टीम क्लाइंट साइड पर या प्री-प्रोसेसिंग स्टेप में एक सस्ता समराइज़र चलाती है, जिससे महंगे मॉडल तक पहुँचने से पहले 2,000-टोकन के कॉन्टेक्स्ट को घटाकर लगभग 400 टोकन कर दिया जाता है। टोकन में यह कमी सभी रिक्वेस्ट में कई गुना बढ़ जाती है, जिससे एंड-यूज़र अनुभव बदले बिना भारी बचत होती है।
स्ट्रैटेजिक बैचिंग (Strategic batching)
बैचिंग कई स्वतंत्र रिक्वेस्ट को एक ही API कॉल में समूहित करती है। इसका नियम सरल है: यदि कोई यूजर जवाब का इंतज़ार कर रहा है, तो बैच न करें; यदि रिक्वेस्ट बैकग्राउंड में चल रही है (जैसे नाइटली रिपोर्ट्स, शेड्यूल्ड जॉब्स), तो सब कुछ बैच कर दें। केवल रात के समय चलने वाले बैच जॉब्स ही खर्च में 10-20% की और कमी लाते हैं।
ऑप्टिमाइज़ेशन लूप की निगरानी करना
आप उसे बेहतर नहीं बना सकते जिसे आप मापते नहीं हैं। इंजीनियर ने चार साप्ताहिक मेट्रिक्स सेट किए:
- टियर के आधार पर प्रति रिक्वेस्ट लागत।
- प्रत्येक राउटिंग पाथ के लिए कैश-हिट रेट।
- सस्ते से प्रीमियम टियर में एस्केलेशन रेट।
- प्रति कस्टमर सेगमेंट खर्च।
ये आंकड़े विचलन (drift) को सामने लाते हैं—उदाहरण के लिए, बढ़ता हुआ एस्केलेशन रेट यह संकेत दे सकता है कि वर्गीकरण लॉजिक बहुत अधिक आक्रामक है या सस्ते मॉडल की गुणवत्ता गिर गई है। टीम हर हफ्ते थ्रेशोल्ड, मॉडल असाइनमेंट और कैश पॉलिसी पर काम करती है, जिससे लागत नियंत्रण एक संकट प्रतिक्रिया के बजाय एक आदत बन जाता है।
निष्कर्ष (Takeaway)
एक अनुशासित राउटिंग लेयर जो रिक्वेस्ट को वर्गीकृत करती है, मॉडल को राइट-साइज़ करती है, आक्रामक रूप से कैश करती है, प्रॉम्प्ट को कंप्रेस करती है और बैकग्राउंड काम को बैच करती है, विश्वसनीयता को उच्च रखते हुए AI-API खर्च को 95% तक कम कर सकती है। इन्फरेंस स्टैक को एक प्रोडक्शन सर्विस की तरह मानें: टियर्स परिभाषित करें, परिणामों को मापें और साप्ताहिक रूप से सुधार करें।