اگر در حال ساخت بک‌اند برای اتصال چندمدلی هستید، به احتمال زیاد این فروپاشی را تجربه کرده‌اید: کد کسب‌وکار پر شده از if (vendor === 'openai') ... else if (vendor === 'claude') ...، یک رابط گفتگوی جریانی با هشتصد خط منطق سازگاری نوشته شده، و با افزودن هر ارائه‌دهنده جدید باید یک بار دیگر زنجیره اصلی را دستکاری کنید. مشکل از شما نیست؛ مشکل این است که پروتکل‌های API مدل‌های زبانی بزرگ اصلاً قصد نداشته‌اند یکسان باشند.
ماهیت دروازه مدل، یک لایه ترجمه پروتکل است: تبدیل درخواست/پاسخ ناهمگون N ارائه‌دهنده به ۱ مجموعه پروتکل استاندارد داخلی. این مقاله به صورت تدریجی در سه بخش اصل، عمل و مقایسه تحلیل می‌کند و روشن می‌سازد لایه ترجمه دقیقاً چگونه باید ساخته شود.
۱. چهار نوع نقطه ناهمگونی: چرا اتصال مستقیم به چند ارائه‌دهنده ناگزیر از کنترل خارج می‌شود
ابتدا تفاوت‌های واقعی را ببینید، هر کدام با اعداد.
روش احراز هویت: OpenAI از Authorization: Bearer sk-xxx استفاده می‌کند، طول فیلد سرصفحه حدود ۵۱ کاراکتر؛ Claude از x-api-key؛ Gemini کلید را در پارامتر پرس‌وجوی ?key= در URL قرار می‌دهد؛ Qwen و ERNIE از Authorization استفاده می‌کنند اما الگوریتم امضا متفاوت است، access_token در ERNIE به طور پیش‌فرض ۳۰ روز اعتبار دارد و پس از انقضا کد خطای 110 برمی‌گرداند. چهار ارائه‌دهنده، چهار روش نوشتاری.
قالب تکه‌بندی جریانی SSE: chunk در OpenAI به صورت 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 قرار می‌دهد که ۳ لایه تودرتوتر است. لایه کسب‌وکار برای تجزیه همان یک جمله باید چهار مجموعه parser بنویسد.
سیستم کد خطا: این آزاردهنده‌ترین بخش است. OpenAI از کد وضعیت HTTP به همراه error.type استفاده می‌کند، محدودیت نرخ 429 است؛ Claude محدودیت نرخ را با 429 برمی‌گرداند اما type در body برابر rate_limit_error است؛ Qwen ممکن است محدودیت نرخ را با کد وضعیت 200 اما با code: "Throttling" در body برگرداند؛ ERNIE از error_code: 17 برای نمایش تجاوز از سهمیه استفاده می‌کند. یک چیز واحد، چهار بیان.
معیار شمارش توکن: در OpenAI، usage.total_tokens = prompt + completion و چینی و انگلیسی هر دو بر اساس BPE تقسیم می‌شوند؛ Claude به طور جداگانه input_tokens و output_tokens را برمی‌گرداند و دانه‌بندی تقسیم کاراکترهای چینی ریزتر است؛ برای همان متن چینی ۵۰۰ کلمه‌ای، تعداد توکن‌های شمارش‌شده توسط دو ارائه‌دهنده می‌تواند ۲۰٪ تا ۳۵٪ تفاوت داشته باشد. در صورت پرداخت بر اساس مصرف، این تفاوت مستقیماً به خطای صورت‌حساب تبدیل می‌شود.
با اتصال مستقیم به چهار ارائه‌دهنده، حجم کد لایه کسب‌وکار به ۳ تا ۴ برابر حالت تک‌ارائه‌دهنده متورم می‌شود و هزینه نگهداری به صورت خطی با تعداد ارائه‌دهندگان افزایش می‌یابد.
۲. طراحی لایه ترجمه: قالب یکسان، یکسان‌سازی جریان، نگاشت کد خطا، جمع‌آوری مصرف
لایه ترجمه باید چهار کار انجام دهد و هیچ‌کدام قابل حذف نیست.
قالب یکسان درخواست/پاسخ: یک مجموعه Schema استاندارد داخلی تعریف کنید، فیلدها هم‌راستا با سبک OpenAI (چون اکوسیستمش گسترده‌ترین است). درخواست خارجی ابتدا به قالب داخلی تبدیل می‌شود و سپس آداپتور آن را به قالب هر ارائه‌دهنده تبدیل می‌کند. الگوی آداپتور، یک کلاس برای هر ارائه‌دهنده که دو متد buildRequest() و parseResponse() را پیاده‌سازی می‌کند.
یکسان‌سازی تکه‌بندی جریان: هسته کار تبدیل chunkهای SSE هر ارائه‌دهنده به {delta: string, finish_reason: string|null} یکسان است. روش کار نوشتن یک ماشین حالت است که بر اساس نوع ارائه‌دهنده به parserهای مختلف توزیع می‌شود و ساختار یکسان خروجی می‌دهد. نکته کلیدی مدیریت مرزها است: جداکننده \n\n در SSE، پیشوند data:، اتصال چندخطی data، همه اینها باید در parser بلعیده شوند. چاله‌ای که من در آن افتادم رویدادهای ping و message_stop در Claude بود که اگر صریحاً نادیده گرفته نشوند، delta خالی به فرانت‌اند هل داده می‌شود و باعث چشمک زدن UI می‌شود.
جدول نگاشت کد خطا: یک نگاشت vendorCode -> unifiedCode نگهداری کنید و آن را به ۶ دسته یکسان تبدیل کنید: AUTH_FAILED، RATE_LIMITED، QUOTA_EXCEEDED، INVALID_REQUEST، UPSTREAM_ERROR، TIMEOUT. هر چه بالادست برگرداند، لایه ترجمه از جدول جستجو می‌کند و به کد یکسان تبدیل می‌کند، و لایه کسب‌وکار فقط این ۶ مورد را می‌شناسد.
جمع‌آوری مصرف: پس از هر فراخوانی، معیار توکن هر ارائه‌دهنده را به توکن استاندارد داخلی یکسان تبدیل کنید و هنگام ذخیره در پایگاه داده vendor، model، request_id را همراه داشته باشید تا برای تطبیق و تحلیل هزینه استفاده شود. اینجا باید به تفاوت معیارها توجه کرد؛ output_tokens در Claude و completion_tokens در OpenAI را نمی‌توان مستقیماً جمع زد و باید با ضریب تبدیل به یک مبنای واحد یکسان‌سازی شوند.
از نظر معماری لایه‌بندی، من معمولاً چهار لایه تقسیم می‌کنم: لایه دسترسی (احراز هویت + محدودیت نرخ)، لایه مسیریابی (انتخاب مدل)، لایه ترجمه (تبدیل پروتکل)، لایه سازگاری (فراخوانی 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، پارامترهای مخصوص هر ارائه‌دهنده را مستقیماً عبور ندهید. مثلاً logit_bias در OpenAI، top_k در Claude؛ دروازه لزوماً همه را پشتیبانی نمی‌کند و عبور دادن آن‌ها ممکن است بی‌صدا نادیده گرفته شود و شما فکر کنید اعمال شده‌اند در حالی که نشده‌اند. قبل از انتشار یک بار با اسکریپت تست فشار سازگاری پارامترها را اجرا کنید.
۴. مقایسه: مسیریابی چندمدلی در برابر اتصال تک‌مدلی
یک مجموعه اعداد از آزمایش واقعی ما ارائه می‌دهیم. اتصال تک‌مدلی (اتصال مستقیم به OpenAI): زمان اتصال حدود ۲ نفر-روز، تغییر در صورت خرابی نیازمند تغییر کد و انتشار مجدد، میانگین زمان بازیابی ۱۵ دقیقه، بدون فضای بهینه‌سازی هزینه. مسیریابی چندمدلی (از طریق دروازه): زمان اتصال حدود ۰.۵ نفر-روز، تغییر در صورت خرابی به طور خودکار انجام می‌شود، زمان بازیابی کمتر از ۳ ثانیه، هزینه می‌تواند با توزیع بر اساس وظیفه حدود ۳۰٪ تا ۴۰٪ کاهش یابد.
از نظر پیچیدگی نگهداری، کد سازگاری اتصال مستقیم به ۴ ارائه‌دهنده حدود ۲۰۰۰ خط است؛ پس از استفاده از دروازه، کد سازگاری لایه کسب‌وکار به کمتر از ۲۰۰ خط کاهش می‌یابد، یعنی ۹۰٪ کاهش. از نظر تأخیر، دروازه یک پرش اضافه دارد و P99 حدود ۲۰ تا ۴۰ میلی‌ثانیه افزایش می‌یابد؛ در مقایسه با هزینه نگهداری صرفه‌جویی‌شده و انعطاف‌پذیری جابه‌جایی، این هزینه قابل قبول است.
البته دروازه گلوله نقره‌ای نیست. اگر کسب‌وکار شما فقط از یک مدل استفاده می‌کند و هرگز آن را تغییر نمی‌دهد، اتصال مستقیم ساده‌تر است. اما به محض اینکه چندمدلی، چندارائه‌دهنده و بهینه‌سازی هزینه مطرح شود، لایه ترجمه زیرساخت ضروری است. دروازه مدل، API مدل زبانی بزرگ و تجمیع AI API، در ماهیت سه بیان از یک لایه مشکل هستند.
یک نکته پایانی: پوشش تست واحد لایه ترجمه باید کامل باشد، به‌ویژه موارد مرزی تکه‌بندی جریان، که منطقه پرخطر حوادث آنلاین است.
نویسنده: لیو ژی‌یوان
تاریخ انتشار: ۲۸ اکتبر ۲۰۲۶