अगर आप मल्टी-मॉडल एक्सेस का बैकएंड बना रहे हैं, तो आपने लगभग निश्चित रूप से इस तरह का ब्रेकडाउन अनुभव किया होगा: बिज़नेस कोड में if (vendor === 'openai') ... else if (vendor === 'claude') ... भरा हुआ है, एक स्ट्रीमिंग चैट इंटरफ़ेस के लिए आठ सौ लाइनों का एडाप्टर लॉजिक लिखा गया है, और एक नया विक्रेता जोड़ने पर हर बार कोर लिंक बदलना पड़ता है। समस्या आप में नहीं है, समस्या यह है कि विभिन्न बड़े मॉडल API के प्रोटोकॉल शुरू से ही एकीकृत होने के लिए नहीं बनाए गए थे।
मॉडल गेटवे का सार एक प्रोटोकॉल ट्रांसलेशन लेयर है: N विक्रेताओं के विषम अनुरोध/प्रतिक्रिया को 1 सेट आंतरिक मानक प्रोटोकॉल में समाहित करना। यह लेख सिद्धांत, व्यवहार और तुलना के तीन चरणों में क्रमशः विश्लेषण करता है, और स्पष्ट करता है कि ट्रांसलेशन लेयर वास्तव में कैसे बनाई जानी चाहिए।
एक、चार प्रकार के विषम बिंदु: सीधे कई विक्रेताओं से जुड़ना अनियंत्रित क्यों होना तय है
पहले वास्तविक अंतर देखें, प्रत्येक के साथ संख्याएँ।
प्रमाणीकरण विधि: OpenAI Authorization: Bearer sk-xxx का उपयोग करता है, हेडर फ़ील्ड की लंबाई लगभग 51 अक्षर है; Claude x-api-key का उपयोग करता है; Gemini key को URL के ?key= क्वेरी पैरामीटर में डालता है; Qwen, ERNIE Authorization का उपयोग करते हैं लेकिन हस्ताक्षर एल्गोरिदम अलग हैं, ERNIE के access_token की डिफ़ॉल्ट वैधता 30 दिन है, समाप्त होने पर 110 एरर कोड लौटाता है। चारों के चार अलग तरीके।
SSE स्ट्रीमिंग चंक प्रारूप: OpenAI का chunk data: {"choices":[{"delta":{"content":"x"}}]} है, समाप्ति मार्कर data: [DONE] है; Claude का इवेंट प्रकार event: content_block_delta है जिसके साथ data: {"delta":{"text":"x"}} है, फ़ील्ड नाम content से text हो जाता है; Gemini वृद्धि को candidates[0].content.parts[0].text में रखता है, नेस्टिंग 3 परत गहरी है। बिज़नेस लेयर को एक ही वाक्य को पार्स करने के लिए चार सेट parser लिखने पड़ते हैं।
एरर कोड प्रणाली: यह सबसे कष्टप्रद है। OpenAI HTTP स्टेटस कोड + error.type का उपयोग करता है, रेट लिमिट 429 है; Claude रेट लिमिट पर 429 लौटाता है लेकिन body में type rate_limit_error है; Qwen रेट लिमिट पर संभवतः 200 स्टेटस कोड लौटाए लेकिन body में code: "Throttling" हो; ERNIE error_code: 17 का उपयोग कोटा अधिक होने के लिए करता है। एक ही बात, चार अभिव्यक्तियाँ।
Token गणना मानक: OpenAI का usage.total_tokens = prompt + completion, चीनी और अंग्रेजी दोनों BPE के अनुसार विभाजित; Claude अलग से input_tokens और output_tokens लौटाता है, और चीनी अक्षरों का विभाजन ग्रैन्युलैरिटी अधिक बारीक है, एक ही 500 अक्षरों का चीनी पाठ, दोनों के गणना किए गए token संख्या में 20% से 35% तक का अंतर हो सकता है। उपयोग-आधारित बिलिंग में यह अंतर सीधे बिल त्रुटि में बदल जाता है।
चारों से सीधे जुड़ने पर, बिज़नेस लेयर का कोड 3 से 4 गुना बढ़ जाएगा, और रखरखाव लागत विक्रेताओं की संख्या के साथ रैखिक रूप से बढ़ेगी।
दो、ट्रांसलेशन लेयर डिज़ाइन: एकीकृत प्रारूप, स्ट्रीमिंग सामान्यीकरण, एरर कोड मैपिंग, उपयोग संग्रह
ट्रांसलेशन लेयर को चार काम करने हैं, कोई भी अनुपस्थित नहीं हो सकता।
एकीकृत अनुरोध/प्रतिक्रिया प्रारूप: आंतरिक रूप से एक मानक Schema परिभाषित करें, फ़ील्ड OpenAI शैली के साथ संरेखित (क्योंकि इसका पारिस्थितिकी तंत्र सबसे व्यापक है)। बाहरी अनुरोध पहले आंतरिक प्रारूप में परिवर्तित होता है, फिर एडाप्टर द्वारा प्रत्येक विक्रेता के प्रारूप में परिवर्तित होता है। एडाप्टर पैटर्न, प्रत्येक विक्रेता के लिए एक क्लास, जो buildRequest() और parseResponse() दो मेथड लागू करती है।
स्ट्रीमिंग चंक सामान्यीकरण: मूल बात यह है कि प्रत्येक विक्रेता के SSE chunk को एकीकृत {delta: string, finish_reason: string|null} में परिवर्तित करना। तरीका है एक स्टेट मशीन लिखना, विक्रेता प्रकार के अनुसार विभिन्न parser में वितरित करना, एकीकृत संरचना आउटपुट करना। मुख्य बिंदु सीमा प्रबंधन है: SSE का \n\n विभाजक, data: प्रीफ़िक्स, बहु-पंक्ति data जोड़ना, ये सभी parser में निपटाए जाने चाहिए। मैंने जो समस्या अनुभव की वह Claude के ping इवेंट और message_stop इवेंट थी, अगर स्पष्ट रूप से अनदेखा न किया जाए, तो खाली delta फ्रंटएंड को भेज दिया जाएगा जिससे UI में फ़्लिकर होगा।
एरर कोड मैपिंग तालिका: एक vendorCode -> unifiedCode मैपिंग बनाए रखें, 6 श्रेणियों में एकीकृत करें: AUTH_FAILED, RATE_LIMITED, QUOTA_EXCEEDED, INVALID_REQUEST, UPSTREAM_ERROR, TIMEOUT। अपस्ट्रीम जो भी लौटाए, ट्रांसलेशन लेयर तालिका देखकर एकीकृत कोड में परिवर्तित करती है, बिज़नेस लेयर केवल इन 6 को पहचानती है।
उपयोग संग्रह: प्रत्येक कॉल के बाद प्रत्येक विक्रेता के token मानक को आंतरिक मानक token में एकीकृत रूप से परिवर्तित करें, डेटाबेस में सहेजते समय vendor, model, request_id साथ रखें, जो बाद में मिलान और लागत विश्लेषण के लिए उपयोग होता है। यहाँ मानक अंतर पर ध्यान दें, Claude के output_tokens और OpenAI के completion_tokens को सीधे नहीं जोड़ा जा सकता, रूपांतरण गुणांक के अनुसार एक ही आधार पर सामान्यीकृत करना होगा।
स्तरीय आर्किटेक्चर पर, मैं आमतौर पर चार परतों में विभाजित करता हूँ: एक्सेस लेयर (प्रमाणीकरण+रेट लिमिट), रूटिंग लेयर (मॉडल चयन), ट्रांसलेशन लेयर (प्रोटोकॉल रूपांतरण), एडाप्टर लेयर (विक्रेता SDK कॉल)। ट्रांसलेशन लेयर शुद्ध फ़ंक्शन है, IO को नहीं छूती, यूनिट टेस्ट के लिए सुविधाजनक।
तीन、व्यावहारिक कोड: एक पंक्ति base_url बदलकर एग्रीगेशन गेटवे से जुड़ें
अगर आप शून्य से ट्रांसलेशन लेयर नहीं लिखना चाहते, तो तैयार AI API एग्रीगेशन प्लेटफ़ॉर्म का उपयोग करना अधिक व्यावहारिक विकल्प है। हमारे प्रोजेक्ट में token8341 का उपयोग किया गया है, यह OpenAI SDK के साथ संगत है, एक पंक्ति base_url बदलकर स्विच कर सकते हैं, ट्रांसलेशन लेयर का काम यह आपके लिए कर देता है।
from openai import OpenAI
client = OpenAI(
api_key="your-key",
base_url="https://api.token8341.com/v1" # केवल यह एक पंक्ति बदलें
)
resp = client.chat.completions.create(
model="deepseek-v3", # gpt-4o / qwen-max / claude-4-sonnet भी बदल सकते हैं
messages=[{"role": "user", "content": "SSE समझाएँ"}],
stream=True
)
for chunk in resp:
delta = chunk.choices[0].delta.content
if delta:
print(delta, end="")इस कोड में, SSE चंक सामान्यीकरण, एरर कोड मैपिंग, उपयोग संग्रह सभी गेटवे पक्ष में पूर्ण हो चुके हैं, बिज़नेस लेयर को मानक OpenAI प्रारूप मिलता है। मल्टी-मॉडल रूटिंग भी बच गई, गेटवे कार्य के अनुसार स्वचालित रूप से इष्टतम मॉडल चुन सकता है, जैसे चीनी लंबे पाठ के लिए Qwen, रीज़निंग कार्य के लिए DeepSeek, लागत-संवेदनशील परिदृश्य के लिए Doubao।
समस्या चेतावनी: base_url बदलने के बाद, विक्रेता-विशिष्ट पैरामीटर सीधे पास-थ्रू न करें। जैसे OpenAI का logit_bias, Claude का top_k, गेटवे सभी का समर्थन नहीं कर सकता, पास-थ्रू करने पर संभवतः चुपचाप अनदेखा कर दिया जाए, जिससे आपको लगेगा कि प्रभावी हुआ जबकि वास्तव में नहीं हुआ। लॉन्च से पहले प्रेशर टेस्ट स्क्रिप्ट से पैरामीटर संगतता चलाएँ।
चार、तुलना: मल्टी-मॉडल रूटिंग बनाम सिंगल-मॉडल बाइंडिंग
हमारे वास्तविक मापे गए संख्याओं का एक सेट दें। सिंगल-मॉडल बाइंडिंग (सीधे OpenAI से जुड़ना): एक्सेस में लगभग 2 व्यक्ति-दिन, विफलता स्विचिंग के लिए कोड बदलकर पुनः प्रकाशित करना पड़ता है, औसत रिकवरी समय 15 मिनट, कोई लागत अनुकूलन स्थान नहीं। मल्टी-मॉडल रूटिंग (गेटवे से): एक्सेस में लगभग 0.5 व्यक्ति-दिन, विफलता स्विचिंग स्वचालित, रिकवरी समय 3 सेकंड से कम, लागत कार्य-आधारित विभाजन से लगभग 30% से 40% तक कम।
रखरखाव जटिलता पर, 4 विक्रेताओं से सीधे जुड़ने का एडाप्टर कोड लगभग 2000 पंक्तियाँ, गेटवे से जुड़ने के बाद बिज़नेस लेयर एडाप्टर कोड 200 पंक्तियों से कम हो जाता है, 90% की कमी। लेटेंसी पर, गेटवे एक अतिरिक्त हॉप, P99 में लगभग 20 से 40ms की वृद्धि, इसकी बचाई गई रखरखाव लागत और स्विचिंग लचीलेपन की तुलना में, यह ओवरहेड स्वीकार्य है।
बेशक, गेटवे कोई जादुई समाधान नहीं है। अगर आपका बिज़नेस केवल एक मॉडल का उपयोग करता है, और कभी नहीं बदलेगा, तो सीधे जुड़ना अधिक सरल है। लेकिन जब तक मल्टी-मॉडल, मल्टी-विक्रेता, लागत अनुकूलन शामिल है, ट्रांसलेशन लेयर अनिवार्य बुनियादी ढाँचा है। मॉडल गेटवे, बड़ा मॉडल API, AI API एग्रीगेशन ये तीन बातें, वास्तव में एक ही परत की समस्या के तीन नाम हैं।
अंत में एक चेतावनी: ट्रांसलेशन लेयर की यूनिट टेस्ट कवरेज पूर्ण होनी चाहिए, विशेष रूप से स्ट्रीमिंग चंक के सीमा मामलों में, यह ऑनलाइन दुर्घटनाओं का उच्च-जोखिम क्षेत्र है।
लेखक: लियू झियुआन
प्रकाशन तिथि: 28 अक्टूबर 2026