पहले निष्कर्ष: मॉडल गेटवे केवल "कई API जोड़ना" नहीं है, यह एक ऐसी इंफ्रास्ट्रक्चर परत है जिसे स्वयं विफलता सहन करनी होती है। दो साल पहले हमने एक ऑनलाइन परामर्श प्लेटफ़ॉर्म के लिए AI एकीकरण किया था, स्मार्ट कस्टमर सर्विस एक ही मॉडल API पर चल रही थी। किसी मंगलवार तड़के दो बजे के बाद, अपस्ट्रीम ने 504 लौटाना शुरू किया, SDK डिफ़ॉल्ट रूप से तीन बार पुनःप्रयास करता है, एक्सपोनेंशियल बैकऑफ़ के साथ, लेकिन व्यवसाय पक्ष में एक साथ हज़ारों सत्र समानांतर में चल रहे थे, पुनःप्रयास की मात्रा तुरंत सामान्य अनुरोधों से कई गुना बढ़ गई। थ्रेड पूल भर गया, यहाँ तक कि हेल्थ चेक भी टाइमआउट हो गया, पूरी कॉल श्रृंखला डोमिनो की तरह गिर पड़ी। बाद में समीक्षा में, समस्या मॉडल में नहीं थी, बल्कि यह थी कि हमने सभी अंडे एक टोकरी में रख दिए थे, और कोई गेटवे परत सुरक्षा कवच नहीं थी।
मॉडल गेटवे वास्तव में क्या हल करता है
अलग करके देखें, गेटवे परत को चार चीज़ें संभालनी होती हैं। मल्टी-मॉडल रूटिंग आधार है, एक ही "कस्टमर सर्विस प्रश्नोत्तर" कार्य को इरादे के अनुसार सस्ते घरेलू मॉडल को सौंपा जा सकता है, जटिल तर्क के समय उच्च-स्तरीय मॉडल पर जाया जा सकता है। रेट लिमिटिंग और सर्किट ब्रेकिंग जीवनरक्षक है, एकल Key के फटने से पहले ही सक्रिय रूप से काट देना चाहिए। प्रोटोकॉल अनुवाद सबसे अधिक कम आँका जाने वाला हिस्सा है, विभिन्न SDK के अनुरोध बॉडी, प्रतिक्रिया बॉडी, त्रुटि संरचनाएँ सभी अलग होती हैं। लागत आवंटन इस बात से जुड़ा है कि हिसाब साफ़ हो सके, किस व्यवसाय लाइन, किस टेनेंट ने कितने token जलाए, यह व्यक्ति स्तर तक तोड़ा जा सके।
हमारे प्रोजेक्ट में token8341 के मॉडल गेटवे का उपयोग करके कार्य के अनुसार स्वचालित रूप से इष्टतम मॉडल चुनने का अभ्यास किया गया, जो OpenAI SDK के साथ संगत है, base_url को एक पंक्ति बदलकर स्विच किया जा सकता है। यह विशेषता मौजूदा सिस्टम के लिए विशेष रूप से अनुकूल है, कोड में दर्जनों कॉल बिंदुओं को पूरी तरह बदलने की ज़रूरत नहीं है। सिलिकॉन-कार्बन फेज़ ट्रांज़िशन इस परत में जो करता है, उसका सार AI API एकत्रीकरण की जटिलता को गेटवे के भीतर समेटना है।
SSE स्ट्रीमिंग आउटपुट के प्रोटोकॉल के गड्ढे
स्ट्रीमिंग आउटपुट गड्ढों का मुख्य क्षेत्र है। सतह पर देखने में सभी SSE हैं, लेकिन वास्तविक अंतर कम नहीं है। चंकिंग रणनीति में, कुछ विक्रेता token के अनुसार काटते हैं, कुछ वाक्य के अनुसार, और कुछ एक खंड में कई डेटा ब्लॉक भर देते हैं। समाप्ति संकेत और भी अव्यवस्थित है, OpenAI शैली में data: [DONE] का उपयोग होता है, अन्य विक्रेता सीधे स्ट्रीम काट देते हैं बिना संकेत के। त्रुटि कोड भी एकसमान नहीं हैं, टाइमआउट 429 हो सकता है, 503 हो सकता है, या 200 प्रतिक्रिया में एक त्रुटि ऑब्जेक्ट के साथ भी हो सकता है।
गेटवे परत को सामान्यीकरण करना होता है: सबको मानक SSE प्रारूप में बदलना, समाप्ति संकेत पूरा करना, विभिन्न विक्रेताओं के त्रुटि कोड को एक आंतरिक त्रुटि एनम में मैप करना। इस तरह ऊपरी व्यवसाय को केवल एक प्रकार की स्ट्रीम संभालनी होती है। सुनने में गंदा काम लगता है, लेकिन यह परत न करें तो हर व्यवसाय टीम को बार-बार वही गड्ढे पार करने पड़ेंगे।
रेट लिमिटिंग कैसे कॉन्फ़िगर करें कि नुकसान न हो
टोकन बकेट स्मूद दर नियंत्रित करने के लिए उपयुक्त है, बकेट क्षमता अचानक वृद्धि की सहनशीलता तय करती है, पुनःपूर्ति दर दीर्घकालिक औसत तय करती है। स्लाइडिंग विंडो सांख्यिकीय रेट लिमिटिंग के लिए उपयुक्त है, जैसे "प्रति मिनट N बार से अधिक नहीं"। वास्तविक उत्पादन में हम दोनों का उपयोग करते हैं: प्रवेश द्वार पर स्लाइडिंग विंडो से मोटे दाने की सुरक्षा, एकल Key आयाम पर टोकन बकेट से सूक्ष्म नियंत्रण।
मल्टी-Key रोटेशन एक और कुंजी है। एक ही विक्रेता के कई Key आवेदन करें, गेटवे वज़न के अनुसार राउंड-रॉबिन करे, कोई Key रेट लिमिट पर ट्रिगर हो तो अस्थायी रूप से हटा दें, कूलिंग अवधि के बाद वापस डालें। इस तरह एकल Key की कोटा सीमा सीधे व्यवसाय की ऊपरी सीमा नहीं बनेगी। ध्यान दें, रोटेशन के साथ सर्किट ब्रेकिंग ज़रूरी है, अन्यथा एक खराब Key बार-बार चुना जाएगा।
डिग्रेडेशन और मल्टी-एक्टिव: RPO और RTO कैसे तय करें
मुख्य मॉडल के टाइमआउट होने पर स्वचालित रूप से बैकअप मॉडल पर स्विच करें, यह क्रिया तेज़ होनी चाहिए। हमने आंतरिक रूप से RTO को "विफलता का पता चलने से ट्रैफ़िक हटने तक" के समय के रूप में परिभाषित किया है, लक्ष्य सेकंड स्तर तक दबाना; RPO सत्र स्थिति के लिए है, आदर्श स्थिति में शून्य नुकसान, लेकिन स्ट्रीमिंग परिदृश्य में पहले से निकाली गई सामग्री वापस नहीं ली जा सकती, केवल यह सुनिश्चित किया जा सकता है कि आगे के अनुरोध बाधित न हों। बैकअप मॉडल के चयन में क्षमता संरेखण पर विचार करें, मुख्य मॉडल लंबे पाठ का तर्क करता हो, बैकअप मॉडल केवल छोटे प्रश्नोत्तर कर सकता हो, तो स्विच करना अपंग डिग्रेडेशन के बराबर है।
गड्ढों से बचने की चेतावनी: पुनःप्रयास तर्क व्यवसाय कोड में न लिखें। SDK का अंतर्निहित पुनःप्रयास गेटवे परत के बाहर है, विफलता के समय गेटवे की सर्किट ब्रेकिंग रणनीति से टकराएगा। पुनःप्रयास को एकीकृत रूप से गेटवे में केंद्रित करना चाहिए, व्यवसाय पक्ष को केवल सफलता या अंतिम विफलता मिले।
एक वाक्य में सारांश, मॉडल गेटवे का मूल्य मल्टी-मॉडल एकीकृत एक्सेस, रेट लिमिटिंग, प्रोटोकॉल सामान्यीकरण, डिग्रेडेशन जैसे गंदे कामों को केंद्रीकृत रूप से संभालना है, ताकि व्यवसाय कोड साफ़ रहे। विस्तार से देखें, यदि आप AI API गेटवे चयन कर रहे हैं, तो मुख्य रूप से देखें कि यह base_url को एक पंक्ति बदलकर एक्सेस कर सकता है या नहीं, और विफलता के समय स्विचिंग रणनीति कॉन्फ़िगर करने योग्य है या नहीं।
लेखक: चेन जिंगशिंग
प्रकाशन तिथि: 4 अक्टूबर 2026