पहले निष्कर्ष: कस्टमर सर्विस रोबोट का खर्चा बढ़ने की मुख्य वजह अस्सी प्रतिशत मामलों में मॉडल की यूनिट प्राइस महंगी होना नहीं, बल्कि कॉलिंग तरीके में गड़बड़ी है। हमारे अंदरूनी एक डेली एक्टिव यूज़र कुछ हज़ार वाले आफ्टर-सेल्स प्रश्नोत्तर रोबोट का पहले महीने का बिल सीधे बजट से तीन गुना हो गया। जाँच करने पर पता चला कि मॉडल की यूनिट प्राइस में एक पैसा भी बदलाव नहीं हुआ, सारा खर्चा कॉलिंग स्ट्रक्चर की छिपी लागतों का था। यह लेख उस समीक्षा प्रक्रिया को लिखता है, जो लोग लार्ज मॉडल API लागत अनुकूलन कर रहे हैं, वे अपने बिल से मिलान कर सकते हैं।
बिल की असामान्यता कैसी दिखती है
असामान्यता की विशेषता "कुल राशि अधिक" नहीं, बल्कि "संरचना विचित्र" है। हमने दिन-वार कॉलिंग विवरण निकाला, तो तीन गड़बड़ियाँ मिलीं: जिन दिनों कॉलिंग सबसे अधिक थी, उन दिनों प्रति रिक्वेस्ट औसत token संख्या बढ़ रही थी; रीट्राई संख्या का अनुपात लगभग बीस प्रतिशत के करीब था; एक ही यूज़र प्रश्न, कभी कुछ सौ token, कभी दस हज़ार token, भिन्नता बहुत अधिक थी। ये तीनों एक साथ मिलकर यह सिद्ध करते हैं कि समस्या मॉडल की ओर नहीं, बल्कि हमारी अपनी कॉलिंग चेन में है।
चार छिपी लागतें, एक-एक करके अधिक गुप्त
पहली, फ्लैगशिप मॉडल से मोटा काम। हमने शुरू में सुविधा के लिए सभी रिक्वेस्ट एक समान रूप से फ्लैगशिप मॉडल से भेजीं। लेकिन कस्टमर सर्विस परिदृश्य में सत्तर प्रतिशत से अधिक "ऑर्डर कहाँ पहुँचा""वापसी कैसे करें" जैसी इंटेंट पहचान और निश्चित उत्तर टेम्पलेट वाले कार्य हैं, ऐसे कार्यों के लिए छोटा मॉडल पूरी तरह पर्याप्त है, लागत में एक परिमाण का अंतर है। फ्लैगशिप मॉडल से "खुलने का समय क्या है" का उत्तर देना, ट्रक से खाना डिलीवर करने जैसा है।
दूसरी, संदर्भ का अनियंत्रित विस्तार। मल्टी-टर्न संवाद में हम पूरा इतिहास संदेश वापस भेज देते थे, यूज़र जब दसवें राउंड तक पहुँचता, तो अकेले इतिहास ही अधिकांश token घेर लेता। अधिक परेशानी यह है कि बहुत सारा इतिहास वर्तमान प्रश्न से बिल्कुल असंबंधित है, केवल साथ चल रहा है। संदर्भ जितना लंबा उतना बुद्धिमान नहीं होता, एक निश्चित लंबाई के बाद सटीकता में सुधार सीमित है, लेकिन लागत रैखिक रूप से बढ़ती है।
तीसरी, रीट्राई तूफ़ान। हमने एक साधारण विफलता रीट्राई सेट किया, लेकिन बैकऑफ और सर्किट ब्रेकर नहीं लगाया। अपस्ट्रीम में कभी-कभार टाइमआउट होने पर, वही बैच की रिक्वेस्ट बार-बार भेजी जाती थीं, एक बार विफल होने पर एक बार रीट्राई, रीट्राई फिर विफल फिर रीट्राई। बिल में यह हिस्सा पूरी तरह व्यर्थ खर्च हुआ, यूज़र को अब भी त्रुटि ही दिखती थी।
चौथी, स्ट्रीमिंग और नॉन-स्ट्रीमिंग में दोहरा शुल्क। यह सबसे अधिक अनदेखी की जाती है। हमारी कुछ चेन में पूर्ण परिणाम पाने के लिए पोस्ट-प्रोसेसिंग हेतु नॉन-स्ट्रीमिंग कॉल होती थी; फ्रंटएंड को टाइपराइटर इफ़ेक्ट चाहिए था, तो स्ट्रीमिंग से फिर कॉल होती थी। एक ही प्रश्न, दो बार शुल्क। बाद में सबको स्ट्रीमिंग रिसेप्शन और स्थानीय असेंबली में एकीकृत किया, तब यह दोहरी लागत समाप्त हुई।
लेयर्ड रूटिंग कैसे लागू करें
विचार जटिल नहीं है: कार्य की कठिनाई के अनुसार विभाजन। इंटेंट पहचान, स्लॉट निष्कर्षण, निश्चित उत्तर टेम्पलेट जैसे कार्यों के लिए हल्का मॉडल; वास्तव में तर्क, बहु-चरणीय निर्णय, भावना शांति की आवश्यकता वाले जटिल संवाद ही फ्लैगशिप मॉडल को सौंपे जाएँ। बीच में एक मॉडल गेटवे लेयर जोड़ें जो निर्णय ले, रिक्वेस्ट आने पर पहले क्लासिफायर से गुज़रे, कार्य टैग लगे फिर तय हो कि किस मॉडल पर रूट करना है।
हमने कार्य के अनुसार स्वचालित रूप से इष्टतम मॉडल चुनने वाले इस लॉजिक का उपयोग किया, SiCore TokenWorks के मल्टी-मॉडल रूटिंग पर एक दौर की तुलना चलाई, सरल कार्यों को हल्के मॉडल पर स्विच करने के बाद, समग्र लागत स्पष्ट रूप से नीचे आई, प्रतिक्रिया भी तेज़ हुई। यहाँ कुंजी "कौन सा मॉडल उपयोग करें" नहीं, बल्कि "किस कार्य के लिए कौन सा मॉडल" यह मैपिंग टेबल निरंतर ट्यून करना है। लॉन्च की शुरुआत में हमने अनुभव के आधार पर सेट किया, दो सप्ताह चलाने के बाद वास्तविक हिट रेट के अनुसार पुनः कैलिब्रेट किया, परिणाम अनुमान लगाकर सेट करने से बहुत बेहतर रहा। मल्टी-मॉडल एकीकृत एक्सेस का लाभ भी इसी समय प्रकट हुआ, रूटिंग रणनीति बदलने के लिए बिज़नेस कोड बदलने की आवश्यकता नहीं, गेटवे लेयर पर एक बदलाव पर्याप्त है।
अनुकूलन से पहले और बाद के बिल की तुलना
विशिष्ट संख्याएँ नहीं बताऊँगा, अनुपात बताऊँगा। कुल कॉलिंग संख्या नहीं बदली, क्योंकि यूज़र संख्या नहीं बदली। कुल लागत लगभग साठ प्रतिशत घटी, जिसमें फ्लैगशिप मॉडल कॉलिंग का अनुपात लगभग सौ प्रतिशत से घटकर तीस प्रतिशत रह गया, शेष हल्के मॉडल पर बँट गया। रीट्राई संबंधित कॉलिंग लगभग बीस प्रतिशत से घटकर एकल अंक प्रतिशत पर आ गई। प्रति रिक्वेस्ट औसत token संख्या लगभग चालीस प्रतिशत घटी, मुख्यतः संदर्भ ट्रिमिंग से। स्ट्रीमिंग दोहरे शुल्क वाला हिस्सा सीधे शून्य हो गया। कुल मिलाकर, बजट से तीन गुना अधिक से बजट के भीतर वापस आया और कुछ अधिशेष भी बचा।
मॉनिटरिंग और अलर्ट कैसे सेट करें
बचाया हुआ पैसा बनाए रखने के लिए मॉनिटरिंग पर निर्भर रहना है, आत्म-अनुशासन पर नहीं। हमने चार अलर्ट सेट किए: प्रति रिक्वेस्ट token संख्या सीमा से अधिक होने पर ट्रिगर, संदर्भ अनियंत्रण रोकने हेतु; रीट्राई दर निर्धारित अनुपात से अधिक होने पर ट्रिगर, रीट्राई तूफ़ान रोकने हेतु; फ्लैगशिप मॉडल कॉलिंग अनुपात असामान्य रूप से बढ़ने पर ट्रिगर, जिससे संकेत मिले कि रूटिंग विफल हो सकती है; दैनिक लागत की पिछले दिन की तुलना में वृद्धि सीमा से अधिक होने पर ट्रिगर। इन चारों को बहुत जटिल बनाने की आवश्यकता नहीं, दैनिक एग्रीगेशन और सीमा पार होने पर अलर्ट पर्याप्त है। Token बिलिंग मोड में, लागत वास्तविक समय में जमा होती है, महीने के अंत में बिल देखकर अनुकूलन करने तक पैसा खर्च हो चुका होता है।
एक वाक्य में सारांश: कस्टमर सर्विस रोबोट की लागत का बड़ा हिस्सा कॉलिंग स्ट्रक्चर में है, मॉडल की यूनिट प्राइस में नहीं। लेयर्ड रूटिंग, संदर्भ ट्रिमिंग, रीट्राई नियंत्रण, स्ट्रीमिंग एकीकरण ये चार काम ठोस तरीके से करें, बिल स्वयं नीचे आ जाएगा। एक कदम आगे, यदि आपके परिदृश्य में RAG रिट्रीवल भी है, तो वेक्टर स्टोर की रिकॉल संख्या भी इसी सोच से एक बार जाँचने योग्य है।