ماه گذشته یک پروژه پشتیبانی هوشمند مشتری را بر عهده گرفتم. تیم کسب‌وکار خواستار اتصال همزمان به سه مدل بزرگ DeepSeek، Qwen و Doubao بود، با این استدلال که "از هر کدام که ارزان‌تر بود استفاده کن، هر کدام که محدود شد به دیگری سوئیچ کن." این حرف منطقی به نظر می‌رسد، اما وقتی شروع به پیاده‌سازی کردیم متوجه شدیم: روش‌های احراز هویت، معیارهای صورتحساب و استراتژی‌های timeout و retry این سه SDK کاملاً سه منطق متفاوت دارند. DeepSeek از Bearer Token استفاده می‌کند، Qwen از API-KEY و امضای DashScope عبور می‌کند، و فیلدهای احراز هویت Doubao هم متفاوت است. در صورتحساب، برخی ورودی و خروجی توکن را جداگانه محاسبه می‌کنند، برخی ترکیبی قیمت‌گذاری می‌کنند و برخی برای hit شدن cache تخفیف می‌دهند. timeout هم دردسر بیشتری دارد — یکی به طور پیش‌فرض ۳۰ ثانیه، دیگری ۶۰ ثانیه، و تعداد retry و استراتژی backoff هرکدام باید جداگانه نوشته شود.
وقتی کد را تا انتها نوشتم، شمردم: فقط لایه سازگاری برای wrap کردن کلاینت‌های سه شرکت بیش از ۸۰۰ خط شده بود، بدون احتساب mapping کدهای خطا. به همین دلیل است که مفهوم model gateway از سال گذشته در محافل مهندسی AI داخلی بارها مطرح شده. در یک جمله: model gateway یک لایه میانی است که تفاوت‌های APIهای چندین مدل بزرگ را پنهان می‌کند و یک interface یکپارچه به لایه بالای کسب‌وکار ارائه می‌دهد.
اتصال مستقیم، ساخت داخلی، پلتفرم تجمیعی — هزینه مهندسی سه رویکرد
ابتدا اتصال مستقیم به SDK رسمی را بگوییم. سه مدل یعنی سه مجموعه احراز هویت، سه مجموعه مدیریت خطا و سه مجموعه منطق retry. کد کسب‌وکار پر از if-else برای تشخیص اینکه به کدام شرکت برود. با اضافه شدن یک مدل جدید، لایه سازگاری باید دوباره تغییر کند. ما محاسبه کردیم که نگهداری کد سازگاری برای اتصال مستقیم به سه شرکت، حدود ۱۵٪ از کل کار بک‌اند پروژه را تشکیل می‌دهد. اگر تعداد مدل‌ها به بیش از پنج برسد، این نسبت از کنترل خارج می‌شود.
ساخت gateway داخلی گزینه دوم است. ایده اصلی این است که خودتان یک لایه proxy بنویسید و درخواست‌ها را به APIهای مختلف forward کنید. مزیت آن کنترل‌پذیری است، عیب آن این است که باید تبدیل پروتکل، چرخش کلید، صف rate limiting و آمار مصرف را خودتان مدیریت کنید. ما به صورت داخلی ارزیابی کردیم که یک gateway داخلی آماده production حداقل نیاز به دو مهندس با شش تا هشت هفته زمان دارد و بعد از آن هم باید به طور مداوم تغییرات نسخه APIهای مختلف را نگهداری کرد. برای تیم‌های کوچک و متوسط، این محاسبه چندان به صرفه نیست.
گزینه سوم پلتفرم‌های تجمیعی AI API هستند. این پلتفرم‌ها APIهای چندین مدل بزرگ را به صورت یکپارچه wrap می‌کنند و یک مجموعه interface واحد ارائه می‌دهند. هزینه مهندسی کمترین است و دوره اتصال معمولاً بر حسب روز محاسبه می‌شود. در پروژه ما از SiCore TokenWorks استفاده شد که با OpenAI SDK سازگار است و با تغییر یک خط base_url می‌توان سوئیچ کرد. اینجا یک نکته مهم وجود دارد: پلتفرم‌های تجمیعی مختلف استراتژی‌های پیش‌فرض متفاوتی برای timeout و retry دارند. قبل از اتصال حتماً تأیید کنید که آیا پلتفرم از timeout سفارشی پشتیبانی می‌کند یا نه، وگرنه درخواست‌های طولانی که به ندرت در production پیش می‌آید توسط لایه پلتفرم پیش از موعد قطع می‌شوند و از پیام خطا هم نمی‌توان فهمید که timeout از سمت gateway بوده یا از سمت مدل.
چهار قابلیت اصلی model gateway
نرمال‌سازی پروتکل پایه است. فرمت درخواست، فرمت پاسخ و کدهای خطای شرکت‌های مختلف را به یک استاندارد واحد تبدیل می‌کند. در حالت ایده‌آل، لایه بالای کسب‌وکار فقط یک فرمت interface را می‌شناسد و سوئیچ مدل فقط با تغییر config انجام می‌شود نه تغییر کد. به همین دلیل interface سازگار با OpenAI در داخل کشور محبوب است — تقریباً تمام ابزارهای زنجیره‌ای از این فرمت پشتیبانی می‌کنند.
استراتژی routing ارزش اصلی gateway است. می‌توان بر اساس نوع task مسیریابی کرد، مثلاً پرسش و پاسخ ساده از Doubao و استدلال پیچیده از DeepSeek؛ می‌توان بر اساس هزینه مسیریابی کرد، یعنی از هر کدام که قیمت فعلی‌اش پایین‌تر است؛ و می‌توان بر اساس availability مسیریابی کرد، یعنی وقتی یک شرکت محدود شد به طور خودکار به backup سوئیچ کند. وقتی ما routing چندمدلی SiCore TokenWorks را تست کردیم، متوجه شدیم استراتژی تقسیم بر اساس پیچیدگی task در سناریوی پشتیبانی مشتری می‌تواند هزینه کل فراخوانی را به مقدار قابل توجهی کاهش دهد، چون حجم زیادی از سؤالات ساده نیازی به فراخوانی قوی‌ترین مدل استدلالی ندارند.
Rate limiting، degradation و تجمیع مصرف نیازهای ضروری محیط production هستند. Rate limiting باید خطای 429 را تشخیص دهد و به طور خودکار در صف retry کند، و degradation باید وقتی سرویس یک شرکت در دسترس نیست به مدل backup سوئیچ کند. تجمیع مصرف هم یعنی جمع‌آوری یکپارچه حجم فراخوانی، مصرف token و هزینه‌های پراکنده در چندین شرکت، برای سهولت محاسبه هزینه و کنترل بودجه. اگر این دو بخش را خودتان بسازید کار کمی نیست، به خصوص تجمیع مصرف، چون معیارهای صورتحساب شرکت‌های مختلف یکسان نیست و منطق تطبیق حساب باید جداگانه نوشته شود.
پیاده‌سازی مرحله‌ای بر اساس بلوغ کسب‌وکار
اگر پروژه تازه شروع شده و فقط به یک مدل متصل است، اتصال مستقیم به SDK رسمی کافی است و نیازی به gateway نیست، چون اضافه کردن یک لایه خودش یک نقطه خرابی اضافه می‌کند. وقتی کسب‌وکار تثبیت شد و می‌خواهید به مدل دوم متصل شوید، آن‌وقت معرفی لایه gateway را در نظر بگیرید — در این مرحله هزینه سوئیچ هنوز پایین است.
اگر کسب‌وکار قبلاً به بیش از سه شرکت متصل شده و نیازمندی availability دارد، توصیه می‌شود مستقیماً از پلتفرم تجمیعی AI API استفاده کنید و هزینه سازگاری و نگهداری را برون‌سپاری کنید. در انتخاب، سه نکته را جدی بگیرید: آیا با OpenAI SDK سازگار است، آیا از timeout و retry سفارشی پشتیبانی می‌کند، و آیا آمار مصرف شفاف است. در مورد ساخت gateway داخلی، مگر اینکه نیازهای انطباق خاصی وجود داشته باشد یا تیم نیروی عملیاتی کافی داشته باشد، سرمایه‌گذاری در مراحل اولیه کسب‌وکار توصیه نمی‌شود.
model gateway مسئله پیچیدگی مهندسی اتصال چندمدلی را حل می‌کند، نه مسئله توانایی مدل را. انتخاب راهکار درست به تیم اجازه می‌دهد تمرکز خود را به منطق کسب‌وکار برگرداند.