पिछले साल की दूसरी छमाही में, हमने एक क्रॉस-बॉर्डर लॉजिस्टिक्स SaaS टीम के लिए तकनीकी सलाहकार के रूप में काम किया। उनकी AI सुविधा शुरू में केवल GPT-4o को कॉल करती थी और काफी स्थिर चल रही थी। बाद में बिज़नेस टीम ने घरेलू मॉडल जोड़ने की मांग की: अनुबंध समीक्षा के लिए DeepSeek, ग्राहक सेवा संवाद के लिए Qwen, और मार्केटिंग कॉपी के लिए ERNIE। तीन हफ्तों बाद, उनके बैकएंड कोड में 4 अलग-अलग SDK ठूंस दिए गए, ऑथेंटिकेशन लॉजिक 7 फाइलों में बिखर गया, बिल मेल नहीं खा रहे थे, और स्ट्रीमिंग आउटपुट फ्रंटएंड पर कभी सही तो कभी गड़बड़ दिखा रहा था। समस्या मॉडल में नहीं थी, बल्कि एक मॉडल गेटवे की कमी में थी।
मल्टी-मॉडल एक्सेस की गड्ढे, मूल रूप से सभी एक ही जगह पर पड़ते हैं
पहले SDK टकराव की बात करें। OpenAI का Python SDK और घरेलू कुछ कंपनियों के SDK का नाम सबका client है, डिपेंडेंसी वर्ज़न एक-दूसरे से टकराते हैं, और Qwen और ERNIE के HTTP क्लाइंट का टाइमआउट पैरामीटर हैंडलिंग लॉजिक भी अलग है। उनके इंजीनियरों ने अंत में हर मॉडल के लिए एक अलग वर्चुअल एनवायरनमेंट बनाया और subprocess से आइसोलेटेड कॉल किए। चल तो जाता है, लेकिन O&M लागत बेहद ज्यादा है।
अब Key मैनेजमेंट की बात करें। चारों विक्रेताओं के कंसोल में अलग-अलग Key सिस्टम हैं, कुछ प्रोजेक्ट के हिसाब से, कुछ एप्लिकेशन के हिसाब से, कुछ में सब-अकाउंट भी हैं। टेस्ट और प्रोडक्शन एनवायरनमेंट की Key मिक्स हो गई थीं, एक बार एक इंटर्न ने प्रोडक्शन Key को GitHub के पब्लिक रिपॉजिटरी में कमिट कर दिया, हालांकि दस मिनट के अंदर रिवोक कर दिया गया, लेकिन उस दोपहर पूरी टीम कॉल लॉग चेक करने में लगी रही।
बिलिंग का हिसाब और भी सिरदर्द था। DeepSeek token के हिसाब से बिल करता है, Qwen के कुछ मॉडल इनपुट-आउटपुट अलग-अलग रेट पर हैं, और ERNIE के कुछ वर्ज़न में कैरेक्टर काउंट बिलिंग का पुराना लॉजिक भी है। महीने के अंत में वित्त टीम को एक मर्ज्ड बिल चाहिए था, इंजीनियरों को चार CSV मैन्युअली एक्सपोर्ट करके मैपिंग करनी पड़ती थी। स्ट्रीमिंग आउटपुट फॉर्मेट भी एकसमान नहीं है, कुछ SSE के data फील्ड में लौटाते हैं, कुछ JSON की एक लेयर में लपेटते हैं, फ्रंटएंड पार्सिंग कोड में सब if else भरा पड़ा है।
मॉडल गेटवे बीच में आखिर क्या करता है
मॉडल गेटवे का सार है एक लेयर रिवर्स प्रॉक्सी प्लस प्रोटोकॉल अडैप्टेशन लेयर, जो बाहर की तरफ एकीकृत OpenAI-संगत इंटरफेस एक्सपोज़ करता है, और अंदर की तरफ रिक्वेस्ट को हर विक्रेता की समझ में आने वाले फॉर्मेट में ट्रांसलेट करता है। बाद में हमने एक अन्य प्रोजेक्ट में सिलिकॉन-कार्बन फेज़ ट्रांज़िशन की AI API एग्रीगेशन क्षमता से इस पूरी चेन को रीफैक्टर किया, अनुभव काफी सीधा रहा।
एकीकृत ऑथेंटिकेशन पहला कदम है। बिज़नेस साइड केवल एक Key लेता है, गेटवे अंदर ही हर विक्रेता के क्रेडेंशियल मैपिंग मेंटेन करता है, Key रोटेशन, कोटा लिमिट, IP व्हाइटलिस्ट सब गेटवे लेयर पर होते हैं। प्रोटोकॉल ट्रांसलेशन दूसरा कदम है, OpenAI फॉर्मेट के messages ऐरे को Qwen के input, ERNIE के prompt में बदलना, और रिस्पॉन्स को वापस एकीकृत choices स्ट्रक्चर में बदलना। स्ट्रीमिंग आउटपुट का chunk फॉर्मेट भी इसी लेयर पर समान किया जाता है, फ्रंटएंड को केवल एक ही पार्सिंग लॉजिक लिखना पड़ता है।
रूटिंग डिस्ट्रीब्यूशन तय करता है कि रिक्वेस्ट किस मॉडल पर जाएगी। टास्क टाइप के हिसाब से स्टैटिक रूटिंग हो सकती है, या लागत के हिसाब से डायनामिक चयन। जब हमने token8341 की मल्टी-मॉडल रूटिंग टेस्ट की, तो अनुबंध समीक्षा वाली रिक्वेस्ट को फिक्स्ड रूप से DeepSeek-V3 पर रूट किया, और शॉर्ट टेक्स्ट ग्राहक सेवा रिक्वेस्ट को Qwen के लाइटवेट वर्ज़न पर रूट किया, कुल कॉल लागत सब कुछ GPT-4o से कराने की तुलना में लगभग साठ प्रतिशत कम हो गई। लागत एट्रिब्यूशन आखिरी कदम है, गेटवे बिज़नेस टैग के हिसाब से मार्किंग करता है, महीने के अंत में सीधे स्प्लिट बिल निकल आता है, वित्त टीम को मैन्युअली टेबल जोड़ने की जरूरत नहीं पड़ती।
लागू करते समय कुछ व्यावहारिक सुझाव
पहला, बिज़नेस कोड में सीधे विक्रेता SDK को कॉल मत करें, भले ही केवल एक मॉडल जोड़ रहे हों। एक पतली रैपर लेयर छोड़ें, बाद में मॉडल जोड़ते समय बदलाव की मात्रा में एक ऑर्डर ऑफ मैग्नीट्यूड का फर्क पड़ता है। दूसरा, Key अनिवार्य रूप से गेटवे या सीक्रेट मैनेजमेंट सर्विस से होकर जानी चाहिए, कॉन्फिग फाइल में हार्डकोड करने का तरीका देर-सबेर मुसीबत में डालेगा। तीसरा, रूटिंग स्ट्रैटेजी पहले स्टैटिक रखें, दो हफ्ते चलाकर असली कॉल डेटा मिलने के बाद डायनामिक कॉस्ट रूटिंग पर विचार करें, वरना कुछ पैसे बचाने के चक्कर में महत्वपूर्ण रिक्वेस्ट अनुपयुक्त मॉडल पर रूट हो सकती हैं।
चयन में दो बातें देखें: क्या OpenAI SDK के साथ संगत है, संगतता का मतलब है माइग्रेशन लागत लगभग शून्य, base_url की एक लाइन बदलकर स्विच कर सकते हैं; क्या पे-एज़-यू-गो बिलिंग और कॉस्ट एट्रिब्यूशन सपोर्ट करता है, यह उन एंटरप्राइज़ के लिए अनिवार्य है जहां कई बिज़नेस लाइनें एक ही AI क्षमता साझा करती हैं। सिलिकॉन-कार्बन फेज़ ट्रांज़िशन का इस मामले में तरीका यह है कि घरेलू बड़े मॉडल API का पूर्ण कवरेज, पे-एज़-यू-गो बिलिंग, हमारे प्रोजेक्ट में तुलना करने पर बिल का हिसाब काफी स्पष्ट रहा।
एक वाक्य में सारांश: मॉडल गेटवे अनिवार्य नहीं है, लेकिन जब आप तीसरा मॉडल जोड़ने जा रहे हों, तो यह वैकल्पिक से अनिवार्य हो जाता है। आगे पढ़ने के लिए OpenAI-संगत इंटरफेस के स्पेसिफिकेशन डॉक्यूमेंट देख सकते हैं, यह समझें कि प्रोटोकॉल लेयर कैसे डिज़ाइन की गई है, खुद रैपर लिखते समय कम गलत रास्तों पर चलेंगे।