पिछले हफ़्ते एक काम मिला — एक SaaS टिकट सिस्टम बनाने वाली टीम के लिए स्मार्ट कस्टमर सर्विस प्रोटोटाइप बनाना, जिसे एक सप्ताह के भीतर चलाना था, और साथ ही GPT-4o, DeepSeek-V3, Qwen-Max, Doubao चार मॉडलों की प्रतिक्रिया गुणवत्ता की तुलना भी करनी थी। सुनने में मुश्किल नहीं लगता, लेकिन जब असल में काम शुरू किया तो पता चला कि मल्टी-मॉडल एकीकृत एक्सेस में सारे पिटफ़ॉल्स बारीकियों में छिपे हुए हैं। यह लेख इस पूरी प्रक्रिया का रिकॉर्ड है, ताकि मल्टी-मॉडल तुलना करने वाले साथी थोड़ा समय बचा सकें।
Key प्रबंधन: 5 प्लेटफ़ॉर्म, 5 अलग बैकएंड — पहले हिसाब साफ़ करें
शुरुआत में सबसे बड़ी परेशानी कोड लिखना नहीं, बल्कि Key प्रबंधित करना था। चार मॉडल चार प्लेटफ़ॉर्म से आ रहे थे, साथ में एक बैकअप प्लेटफ़ॉर्म — कुल पाँच बैकएंड, पाँच कंसोल, और हर एक का Key फ़ॉर्मेट, कोटा देखने का तरीक़ा, रेट-लिमिट नियम अलग। कुछ प्लेटफ़ॉर्म Key सीधे plaintext में दिखाते हैं, कुछ में पहले सब-अकाउंट बनाकर असाइन करना पड़ता है। प्रोटोटाइप चरण में जल्दी करने के चक्कर में मैंने सारी Keys एक ही .env फ़ाइल में डाल दीं, नतीजा यह हुआ कि अगले दिन टेस्ट वॉल्यूम बढ़ते ही किसी एक प्लेटफ़ॉर्म की Key रेट-लिमिट में फँस गई, और एरर मैसेज से यह पता ही नहीं चल रहा था कि समस्या किस प्लेटफ़ॉर्म की है।
बाद में मैंने एक कॉन्फ़िगरेशन मैपिंग लेयर अपनाई, जिसमें हर Key पर एक उपनाम और उपयोग टैग बाँध दिया, और लॉग में सिर्फ़ उपनाम प्रिंट होता था। इससे भी आसान तरीक़ा है AI API एग्रीगेशन प्लेटफ़ॉर्म का उपयोग करना, जहाँ एक ही Key से सारे मॉडल प्रबंधित हो जाते हैं। तुलना के दौरान हमने token8341 आज़माया — इसके मॉडल गेटवे ने कई घरेलू बड़े मॉडलों की ऑथेंटिकेशन को एक जगह समेट लिया, मॉडल बदलने के लिए सिर्फ़ कॉन्फ़िग में मॉडल का नाम बदलना पड़ता है, Key छूने की ज़रूरत नहीं। प्रोटोटाइप चरण के लिए, चार अलग ऑथेंटिकेशन लॉजिक बनाए रखने से बचना ही एक सप्ताह में काम पूरा करने का आधार बना।
SDK संगतता: हर प्लेटफ़ॉर्म का इंटरफ़ेस अलग दिखता है
SDK इंस्टॉल करने के चरण में ही आधे लोगों का धैर्य टूट जाता है। OpenAI के SDK इकोसिस्टम सबसे परिपक्व हैं, कई विक्रेता "संगत" होने का दावा करते हैं, लेकिन असल में जोड़ने पर पता चलता है कि पैरामीटर नाम मेल नहीं खाते। जैसे किसी प्लेटफ़ॉर्म में temperature को temperature कहा जाता है, किसी में top_p के साथ मिलाकर इस्तेमाल होता है, और किसी ने max_tokens को max_output_tokens बना दिया है। स्ट्रीमिंग स्विच भी एकसमान नहीं है — कहीं stream=True चलता है, कहीं अलग से stream_options पास करना पड़ता है।
मेरा तरीक़ा यह था कि एक एडाप्टर लेयर एब्स्ट्रैक्ट करूँ, बाहर की ओर सिर्फ़ एक समान कॉल फ़ंक्शन दूँ, और अंदर विक्रेता के हिसाब से ब्रांच करूँ। इससे बिज़नेस कोड को अंतर का पता ही नहीं चलता। अगर यह लेयर ख़ुद नहीं लिखनी हो, तो OpenAI SDK-संगत समाधान काफ़ी मेहनत बचाते हैं — base_url की एक लाइन बदलकर मॉडल स्विच हो जाता है, और मल्टी-मॉडल एकीकृत एक्सेस की जटिलता सीधे कोड लेयर से कॉन्फ़िग लेयर में चली जाती है। प्रोटोटाइप वेरिफ़िकेशन चरण में यह समझौता बहुत फ़ायदेमंद रहा।
स्ट्रीमिंग आउटपुट: SSE प्रोटोकॉल का हर कार्यान्वयन अलग
स्मार्ट कस्टमर सर्विस में स्ट्रीमिंग ज़रूरी है, वरना यूज़र तीन सेकंड इंतज़ार करके टेक्स्ट देखता है, अनुभव सीधे बिगड़ जाता है। समस्या यह है कि SSE प्रोटोकॉल के कार्यान्वयन की बारीकियाँ हर प्लेटफ़ॉर्म में अलग हैं। कुछ प्लेटफ़ॉर्म हर chunk में पूरा event स्ट्रक्चर भेजते हैं, कुछ सिर्फ़ data फ़ील्ड पुश करते हैं; समाप्ति संकेत कहीं [DONE] होता है, कहीं finish_reason फ़ील्ड सेट होता है; और कुछ बीच-बीच में heartbeat पैकेट डालते हैं, जिन्हें फ़्रंटएंड पार्स करते समय गलती से कंटेंट समझ लेता है।
शुरू में मैंने OpenAI के फ़ॉर्मेट के अनुसार पार्सर लिखा, दूसरा प्लेटफ़ॉर्म जोड़ते ही गड़बड़ हो गई। समाधान यह निकला कि एक समान SSE पार्सिंग मिडलवेयर लिखूँ, जो हर प्लेटफ़ॉर्म के chunk को एक ही इवेंट स्ट्रक्चर में सामान्यीकृत कर दे, और फ़्रंटएंड सिर्फ़ उसी को पहचाने। जो पिटफ़ॉल भोगा वह यह है: डॉक्युमेंट में लिखे "पूरी तरह संगत" पर भरोसा मत करो, असली रिस्पॉन्स को कैप्चर करके ज़रूर देखो — डॉक्युमेंट और कार्यान्वयन में अक्सर काफ़ी फ़र्क़ होता है।
अपवाद प्रबंधन: किसी एक का टाइमआउट हो तो अपने आप दूसरे पर कैसे स्विच करें
तुलना परीक्षण शुरू होने के बाद सबसे झंझट वाली बात थी किसी एक मॉडल का टाइमआउट। एक बार लोड टेस्ट में Qwen-Max की तरफ़ रिस्पॉन्स अचानक धीमा पड़ गया, पूरी कस्टमर सर्विस चेन अटक गई, फ़्रंटएंड घूमता ही रहा। प्रोटोटाइप चरण में कोई डिग्रेडेशन तंत्र नहीं था, एक गिरा तो सब गिरे।
बाद में मैंने एक मॉडल राउटिंग लेयर जोड़ी — हर रिक्वेस्ट पर टाइमआउट थ्रेशोल्ड सेट किया, टाइमआउट होने पर अपने आप बैकअप मॉडल पर स्विच, और साथ में स्विच लॉग भी रिकॉर्ड किया। यहाँ ध्यान रखने वाली बात है कि स्विच करते समय आँख मूँदकर रीट्राई नहीं करना चाहिए — यह अंतर करना ज़रूरी है कि नेटवर्क टाइमआउट है या कंटेंट मॉडरेशन इंटरसेप्ट, पहले में स्विच किया जा सकता है, दूसरे में स्विच करना भी बेकार है। बड़े मॉडल राउटिंग का मूल्य यही है — उपलब्धता को सिंगल पॉइंट से मल्टी-पॉइंट बना देना। हमारे प्रोजेक्ट में सिलिकॉन-कार्बन फ़ेज़-चेंज शेड्यूलिंग से ऐसा ही वेरिफ़िकेशन किया था — टास्क टाइप के अनुसार अपने आप मॉडल चुनना, और टाइमआउट डिग्रेडेशन की यह चेन काफ़ी स्थिर चली।
लागत निगरानी: Token खपत को कैसे समेटें
एक सप्ताह में सबसे अप्रत्याशित खर्च Token का निकला। चार मॉडल समानांतर में टेस्ट चल रहे थे, रोज़ का कॉल वॉल्यूम बहुत बड़ा नहीं था, लेकिन समेटने की व्यवस्था न होने के कारण महीने के अंत में हिसाब मिलाते समय पता चला कि किसी एक प्लेटफ़ॉर्म की खपत अनुमान से तीन गुना थी। वजह यह थी कि स्ट्रीमिंग आउटपुट में कई प्लेटफ़ॉर्म का usage फ़ील्ड ख़ाली आता है, जिसे ख़ुद अक्षरों के हिसाब से अनुमान लगाना पड़ता है, और वह सटीक नहीं होता।
मेरा तरीक़ा यह रहा कि गेटवे लेयर पर एक समान हिसाब रखूँ — हर कॉल में मॉडल नाम, इनपुट-आउटपुट Token, समय, डिग्रेडेशन हुआ या नहीं, सब एक टेबल में रिकॉर्ड हो। पे-एज़-यूज़ मॉडल में यह हिसाब ख़ुद साफ़ करना ज़रूरी है, पूरी तरह प्लेटफ़ॉर्म के बैकएंड पर निर्भर नहीं रहा जा सकता। API कीमत तुलना में भी ध्यान दें — अगर किसी सस्ते दिखने वाले मॉडल का आउटपुट Token बिलिंग नियम जटिल हो, तो असली लागत उलटकर ज़्यादा हो सकती है।
एक वाक्य में कहें तो: मल्टी-मॉडल तुलना प्रोटोटाइप का मूल किसी एक मॉडल को चलाना नहीं, बल्कि एक्सेस, स्ट्रीमिंग, डिग्रेडेशन और हिसाब — इन चार चीज़ों को एक समान लेयर बनाना है। मॉडल गेटवे के चयन को और गहराई से समझना हो तो API एग्रीगेशन से जुड़ी सामग्री और देख सकते हैं।
लेखक: झोउ मिंगझे
प्रकाशन तिथि: 6 अक्टूबर 2026