पिछले महीने एक बुद्धिमान ग्राहक सेवा परियोजना संभाली, व्यवसाय पक्ष ने एक साथ DeepSeek, Tongyi Qianwen, Doubao तीन बड़े मॉडल को एकीकृत करने की मांग की, कारण था "जो सस्ता हो उसका उपयोग करें, जो सीमित हो उसे दूसरे से बदल दें"। सुनने में उचित लगता है, लेकिन करते समय पता चला: तीनों SDK के प्रमाणीकरण तरीके, बिलिंग मानक, टाइमआउट पुनःप्रयास रणनीतियाँ पूरी तरह से तीन अलग तर्क हैं। DeepSeek Bearer Token का उपयोग करता है, Tongyi DashScope के API-KEY और हस्ताक्षर से चलता है, Doubao के प्रमाणीकरण फ़ील्ड फिर अलग हैं। बिलिंग में, कुछ इनपुट और आउटपुट token को अलग-अलग गणना करते हैं, कुछ मिलाकर मूल्य निर्धारण करते हैं, और कुछ कैश हिट पर छूट देते हैं। टाइमआउट तो और भी परेशानी है, एक का डिफ़ॉल्ट 30 सेकंड, एक का 60 सेकंड, पुनःप्रयास संख्या और बैकऑफ रणनीति अलग-अलग लिखनी पड़ती है।
कोड लिखते-लिखते अंत में, मैंने गिना, केवल तीनों क्लाइंट को एनकैप्सुलेट करने वाली अडैप्टर परत 800 से अधिक लाइनें थीं, जिसमें त्रुटि कोड मैपिंग शामिल नहीं है। यही कारण है कि मॉडल गेटवे की अवधारणा, पिछले वर्ष से घरेलू AI इंजीनियरिंग सर्कल में बार-बार उठाई जा रही है। एक वाक्य में सारांश: मॉडल गेटवे कई बड़े मॉडल API के अंतर को छिपाकर, ऊपरी व्यवसाय के लिए एकीकृत इंटरफ़ेस प्रदान करने वाली मध्यवर्ती परत है।
सीधा कनेक्शन, स्व-निर्मित, एग्रीगेटर प्लेटफ़ॉर्म, तीन समाधानों की इंजीनियरिंग लागत
पहले सीधे आधिकारिक SDK की बात करें। तीन मॉडलों के लिए तीन प्रमाणीकरण, तीन त्रुटि प्रबंधन, तीन पुनःप्रयास तर्क चाहिए। व्यवसाय कोड में सब if-else से भरा होता है कि कौन सा उपयोग करना है। एक नया मॉडल जोड़ें, तो अडैप्टर परत फिर से बदलनी पड़ती है। हमने अनुमान लगाया, तीन सीधे कनेक्शनों की अडैप्टर कोड बनाए रखने में, लगभग पूरे प्रोजेक्ट के बैकएंड कार्यभार का 15% खर्च होता है। यदि मॉडल की संख्या पाँच से अधिक हो जाए, तो यह अनुपात बेकाबू हो जाएगा।
स्व-निर्मित गेटवे दूसरा विकल्प है। मुख्य विचार स्वयं एक प्रॉक्सी परत लिखना है, जो अनुरोधों को विभिन्न API को अग्रेषित करे। लाभ नियंत्रणीयता है, हानि यह कि प्रोटोकॉल रूपांतरण, कुंजी रोटेशन, रेट लिमिट कतार, उपयोग सांख्यिकी स्वयं संभालनी पड़ती है। हमने आंतरिक रूप से मूल्यांकन किया, एक उत्पादन-योग्य स्व-निर्मित गेटवे के लिए कम से कम दो इंजीनियरों को छह से आठ सप्ताह निवेश करना पड़ता है, और बाद में विभिन्न API के संस्करण परिवर्तनों का निरंतर रखरखाव भी। मध्यम और छोटी टीमों के लिए, यह गणना लाभदायक नहीं है।
तीसरा है AI API एग्रीगेटर प्लेटफ़ॉर्म। इस प्रकार के प्लेटफ़ॉर्म कई बड़े मॉडल API को एकीकृत रूप से एनकैप्सुलेट करते हैं, बाहर एक सेट इंटरफ़ेस प्रदान करते हैं। इंजीनियरिंग लागत सबसे कम, एकीकरण चक्र सामान्यतः दिनों में गिना जाता है। हमारी परियोजना में SiCore TokenWorks का उपयोग किया, जो OpenAI SDK के साथ संगत है, base_url की एक पंक्ति बदलकर स्विच कर सकते हैं। यहाँ एक जाल पर ध्यान दें: विभिन्न एग्रीगेटर प्लेटफ़ॉर्म की टाइमआउट और पुनःप्रयास की डिफ़ॉल्ट रणनीतियाँ अलग होती हैं, एकीकरण से पहले अवश्य पुष्टि करें कि प्लेटफ़ॉर्म कस्टम टाइमआउट समय का समर्थन करता है या नहीं, अन्यथा ऑनलाइन कभी-कभार आने वाले लंबे प्रतिक्रिया अनुरोध प्लेटफ़ॉर्म परत द्वारा समय से पहले काट दिए जाएंगे, और त्रुटि संदेश से यह भी पता नहीं चलेगा कि यह गेटवे टाइमआउट है या मॉडल टाइमआउट।
मॉडल गेटवे की चार मुख्य क्षमताएँ
प्रोटोकॉल सामान्यीकरण आधार है। विभिन्न के अनुरोध प्रारूप, प्रतिक्रिया प्रारूप, त्रुटि कोड को एक मानक में एकीकृत करना। आदर्श स्थिति में, ऊपरी व्यवसाय केवल एक इंटरफ़ेस प्रारूप मानता है, मॉडल स्विच करने पर केवल कॉन्फ़िगरेशन बदलें, कोड नहीं। यही कारण है कि OpenAI संगत इंटरफ़ेस घरेलू स्तर पर लोकप्रिय है, पारिस्थितिकी टूलचेन मूल रूप से इस प्रारूप का समर्थन करते हैं।
रूटिंग रणनीति गेटवे का मूल्य है। कार्य प्रकार के अनुसार रूटिंग कर सकते हैं, जैसे सरल प्रश्नोत्तर Doubao पर, जटिल तर्क DeepSeek पर; लागत के अनुसार रूटिंग भी कर सकते हैं, जो वर्तमान में सस्ता हो उस पर; उपलब्धता के अनुसार रूटिंग भी कर सकते हैं, किसी का रेट लिमिट हो तो स्वचालित रूप से बैकअप पर स्विच। जब हमने SiCore TokenWorks के बहु-मॉडल रूटिंग का परीक्षण किया, तो पाया कि कार्य जटिलता के अनुसार विभाजन की रणनीति, ग्राहक सेवा परिदृश्य में समग्र कॉल लागत को काफी कम कर सकती है, क्योंकि बड़ी संख्या में सरल प्रश्नों के लिए सबसे मजबूत तर्क क्षमता वाले मॉडल को कॉल करने की आवश्यकता नहीं होती।
रेट लिमिट डिग्रेडेशन और उपयोग संग्रह उत्पादन वातावरण की अनिवार्यता है। रेट लिमिट को 429 त्रुटि पहचानकर स्वचालित रूप से कतार में पुनःप्रयास करना चाहिए, डिग्रेडेशन को किसी सेवा के अनुपलब्ध होने पर बैकअप मॉडल पर स्विच करना चाहिए। उपयोग संग्रह विभिन्न में बिखरे कॉल वॉल्यूम, token खपत, शुल्क को एकीकृत रूप से सारांशित करना है, जिससे लागत गणना और बजट नियंत्रण सुविधाजनक हो। ये दोनों स्वयं बनाने पर कार्यभार कम नहीं है, विशेषकर उपयोग संग्रह, विभिन्न की बिलिंग मानक असंगत हैं, मिलान तर्क अलग से लिखना पड़ता है।
व्यवसाय परिपक्वता के अनुसार चरणबद्ध कार्यान्वयन
यदि परियोजना अभी शुरू हुई है, केवल एक मॉडल जोड़ा है, तो सीधे आधिकारिक SDK पर्याप्त है, गेटवे की आवश्यकता नहीं, एक परत जोड़ने से एक अतिरिक्त विफलता बिंदु बढ़ता है। जब व्यवसाय स्थिर हो जाए, दूसरा मॉडल जोड़ना हो, तब गेटवे परत पर विचार करें, उस समय स्विचिंग लागत अभी कम है।
यदि व्यवसाय पहले से तीन से अधिक जोड़ चुका है, और उपलब्धता की आवश्यकता है, तो सीधे AI API एग्रीगेटर प्लेटफ़ॉर्म पर जाने की सलाह दी जाती है, एकीकरण और संचालन लागत को आउटसोर्स कर दें। चयन करते समय तीन बिंदुओं पर ध्यान दें: OpenAI SDK के साथ संगतता, कस्टम टाइमआउट और पुनःप्रयास का समर्थन, उपयोग सांख्यिकी की स्पष्टता। जहाँ तक स्व-निर्मित गेटवे की बात है, जब तक विशेष अनुपालन आवश्यकताएँ न हों या टीम में पर्याप्त संचालन जनशक्ति न हो, व्यवसाय के प्रारंभिक चरण में निवेश की सलाह नहीं दी जाती।
मॉडल गेटवे बहु-मॉडल एकीकरण की इंजीनियरिंग जटिलता का समाधान करता है, मॉडल क्षमता की समस्या नहीं। सही समाधान चुनने से, टीम अपना ध्यान वापस व्यवसाय तर्क पर केंद्रित कर सकती है।