نیمه دوم سال گذشته، ما بهعنوان مشاور فنی برای تیمی که در حوزه SaaS لجستیک فرامرزی فعالیت میکرد، کار میکردیم. قابلیت AI آنها در ابتدا فقط GPT-4o را فراخوانی میکرد و بسیار پایدار اجرا میشد. بعداً واحد کسبوکار درخواست افزودن مدلهای داخلی را داد: بازبینی قرارداد با DeepSeek، عبارات خدمات مشتری با Qwen، و متنهای بازاریابی با ERNIE. سه هفته بعد، کد بکاند آنها ۴ مجموعه SDK را در خود جای داده بود، منطق احراز هویت در ۷ فایل پراکنده شده بود، صورتحسابها با هم نمیخواند، و خروجی استریم در فرانتاند گاهی درست و گاهی خراب بود. مشکل در خود مدل نبود، بلکه در نبود یک لایه دروازه مدل بود.
تلههای اتصال چندمدلی، تقریباً همه در یک نقطه اتفاق میافتند
ابتدا تداخل SDK را بگوییم. SDK پایتون OpenAI و SDK چند شرکت داخلی همه client نام دارند، نسخههای وابستگی با هم تضاد دارند، و کلاینتهای HTTP Qwen و ERNIE در پردازش پارامترهای timeout منطق متفاوتی دارند. راهحل نهایی مهندسان آنها این بود که برای هر مدل یک محیط مجازی جداگانه بسازند و فراخوانی را با subprocess ایزوله کنند. کار میکرد، اما هزینه نگهداری بهشدت بالا بود.
حالا مدیریت Key. کنسولهای چهار شرکت هرکدام سیستم Key خودشان را دارند، بعضی بر اساس پروژه، بعضی بر اساس اپلیکیشن، و بعضی حتی زیرحساب دارند. Keyهای محیط تست و محیط تولید با هم قاطی شده بودند. یک بار یک کارآموز Key تولید را در مخزن عمومی GitHub قرار داده بود. اگرچه ظرف ده دقیقه لغو شد، اما آن بعدازظهر تمام تیم مشغول بررسی لاگهای فراخوانی بودند.
معیار صورتحساب حتی دردسرسازتر بود. DeepSeek بر اساس token محاسبه میکند، بعضی مدلهای Qwen ورودی و خروجی را جداگانه قیمتگذاری میکنند، و بعضی نسخههای ERNIE هنوز منطق باقیمانده محاسبه بر اساس تعداد کاراکتر دارند. واحد مالی در پایان ماه یک صورتحساب تجمیعی میخواست، و مهندسان فقط میتوانستند چهار فایل CSV را دستی استخراج و نقشهبرداری کنند. فرمت خروجی استریم هم یکسان نبود، بعضی فیلد data مربوط به SSE را برمیگردانند، بعضی یک لایه JSON بستهبندی میکنند، و کد تجزیه فرانتاند پر از if else است.
دروازه مدل واقعاً در وسط چه کاری انجام میدهد
ماهیت دروازه مدل یک لایه پروکسی معکوس بهعلاوه لایه سازگارسازی پروتکل است که به بیرون یک رابط سازگار با OpenAI یکپارچه ارائه میدهد و به داخل درخواست را به فرمتی ترجمه میکند که هر شرکت بتواند بفهمد. ما بعداً در پروژه دیگری این زنجیره را با قابلیت تجمیع AI API شرکت SiCore TokenWorks بازسازی کردیم و تجربهمان نسبتاً مستقیم بود.
احراز هویت یکپارچه اولین قدم است. سمت کسبوکار فقط یک Key میگیرد، دروازه بهصورت داخلی نگاشت اعتبارنامه به هر شرکت را نگهداری میکند، و چرخش Key، محدودیت سهمیه، و لیست سفید IP همه در لایه دروازه انجام میشوند. ترجمه پروتکل قدم دوم است، تبدیل آرایه messages با فرمت OpenAI به input مربوط به Qwen، prompt مربوط به ERNIE، و سپس تبدیل یکپارچه پاسخها به ساختار choices. فرمت chunk خروجی استریم نیز در این لایه صاف میشود و فرانتاند فقط یک مجموعه منطق تجزیه مینویسد.
مسیریابی توزیع تعیین میکند که درخواست به کدام مدل برود. میتوان بر اساس نوع وظیفه بهصورت ایستا مسیریابی کرد، یا بر اساس هزینه بهصورت پویا انتخاب کرد. وقتی ما مسیریابی چندمدلی token8341 را تست کردیم، درخواستهای مربوط به بازبینی قرارداد را بهصورت ثابت به DeepSeek-V3 مسیریابی کردیم و درخواستهای کوتاه خدمات مشتری را به نسخه سبک Qwen مسیریابی کردیم؛ هزینه کل فراخوانی حدود شصت درصد نسبت به اینکه همه از GPT-4o استفاده کنند کاهش یافت. تجمیع هزینه آخرین قدم است، دروازه بر اساس برچسبهای کسبوکار نقطهگذاری میکند و در پایان ماه مستقیماً صورتحساب تفکیکی صادر میکند و واحد مالی دیگر نیازی به ترکیب دستی جداول ندارد.
چند توصیه عملی هنگام پیادهسازی
اول، SDK شرکت را مستقیماً در کد کسبوکار فراخوانی نکنید، حتی اگر فقط یک مدل متصل میکنید. یک لایه پوشش نازک باقی بگذارید، تفاوت حجم تغییرات هنگام افزودن مدل بعدی یک مرتبه بزرگی خواهد بود. دوم، Key باید از طریق دروازه یا سرویس مدیریت کلید عبور کند؛ روش hardcode کردن در فایل پیکربندی دیر یا زود مشکلساز میشود. سوم، استراتژی مسیریابی را ابتدا ایستا انجام دهید، دو هفته اجرا کنید و بعد از داشتن دادههای واقعی فراخوانی، مسیریابی پویا بر اساس هزینه را در نظر بگیرید، در غیر این صورت بهراحتی ممکن است برای صرفهجویی چند صدم، درخواستهای کلیدی به مدل نامناسبی مسیریابی شوند.
از نظر انتخاب، دو نکته را ببینید: آیا با OpenAI SDK سازگار است، سازگاری یعنی هزینه مهاجرت تقریباً صفر است و با تغییر یک خط base_url میتوان جابهجا شد؛ آیا از پرداخت بر اساس مصرف و تجمیع هزینه پشتیبانی میکند، این برای شرکتهایی که چند خط کسبوکار از یک مجموعه قابلیت AI مشترک استفاده میکنند یک نیاز ضروری است. رویکرد SiCore TokenWorks در این زمینه پوشش کامل API مدلهای بزرگ داخلی و پرداخت بر اساس مصرف است؛ در مقایسه در پروژه ما، معیار صورتحساب نسبتاً شفاف بود.
خلاصه در یک جمله: دروازه مدل اجباری نیست، اما وقتی میخواهید سومین مدل را متصل کنید، از اختیاری به ضروری تبدیل میشود. برای مطالعه بیشتر میتوانید مستندات مشخصات رابط سازگار با OpenAI را ببینید تا بفهمید لایه پروتکل چگونه طراحی شده است؛ هنگام نوشتن پوشش خودتان میتوانید از مسیرهای انحرافی کمتری عبور کنید.