سال گذشته ما پروژه‌ای برای خدمات مشتری هوشمند در حوزه تجارت الکترونیک فرامرزی را شروع کردیم که نیاز داشت به‌طور همزمان به GPT-4o، DeepSeek-V3، Qwen و Doubao متصل شود. هر چهار مدل هر کدام بخشی از کار را بر عهده داشتند: GPT-4o پرسش‌های پیچیده انگلیسی را پردازش می‌کرد، DeepSeek پرسش‌وپاسخ‌های طولانی چینی را پوشش می‌داد، Qwen بازیابی پایگاه دانش محصولات را انجام می‌داد و Doubao برای گفتگوهای عمومی به‌عنوان پشتیبان عمل می‌کرد. در ظاهر تقسیم کار مشخص به نظر می‌رسید، اما وقتی شروع به کار کردیم فهمیدیم که تنها راه‌اندازی SDKهای چهار شرکت تقریباً سه هفته وقت گرفت.
روش‌های احراز هویت یکسان نیستند؛ فقط برای امضا چهار نسخه نوشتیم
GPT-4o از Bearer Token با شناسه سازمان استفاده می‌کرد، DeepSeek با فرمت OpenAI سازگار بود اما در نام فیلد Header تفاوت‌های جزئی داشت، Qwen از AccessKey با رشته امضا استفاده می‌کرد و احراز هویت Doubao هم سیستم دیگری بود. چهار مهندس ما هر کدام با یکی از این شرکت‌ها کار می‌کردند و در نهایت در مخزن کد چهار منطق احراز هویت مختلف باقی ماند؛ برای تغییر یک پارامتر عمومی باید چهار فایل را می‌گشتیم. دردسر بزرگ‌تر چرخش API Key بود؛ کنسول‌های چهار شرکت هر کدام جداگانه عمل می‌کردند و تیم عملیات هر ماه به‌صورت دستی کلیدها را عوض می‌کرد. اگر یکی از آن‌ها فراموش می‌شد، نیمه‌شب هشدار دریافت می‌کردیم.
تکه‌بندی ناهمگون خروجی جریانی SSE باعث به‌هم‌ریختن رندر فرانت‌اند شد
تفاوت‌ها در خروجی جریانی بسیار بیشتر بود. GPT-4o و DeepSeek اساساً از فرمت SSE مربوط به OpenAI پیروی می‌کنند و فیلد data شامل delta است؛ Qwen در برخی سناریوها چند token را در یک chunk بسته‌بندی می‌کند؛ نسخه‌های اولیه Doubao نشانگر پایان و رویداد خطا را با هم مخلوط می‌کردند. فرانت‌اند چهار نوع جریان داده دریافت می‌کرد و منطق رندر به چهار لایه if-else تبدیل شده بود. وقتی مدیر محصول می‌خواست جلوه «مکث ماشین تحریر» را اضافه کند، باید هر چهار شاخه تغییر می‌کردند.
کدهای خطا و آمار مصرف، معیارهایشان کاملاً با هم منطبق نیست
برای خطای محدودیت نرخ، GPT-4o کد 429 برمی‌گرداند، DeepSeek هم 429 برمی‌گرداند اما ساختار body متفاوت است، Qwen کد تجاری همراه با HTTP 200 برمی‌گرداند و Doubao هم روش دیگری دارد. استراتژی تلاش مجدد ما ابتدا بر اساس کد وضعیت HTTP نوشته شده بود، اما در مورد Qwen هرگز فعال نمی‌شد. آمار مصرف دردسر بیشتری داشت: GPT-4o بر اساس token محاسبه می‌کند اما prompt و completion جداگانه حساب می‌شوند، Qwen ورودی و خروجی را ادغام می‌کند و Doubao فیلد جداگانه‌ای برای برخورد با کش دارد. در پایان ماه، مالی برای تطبیق حساب‌ها با چهار CSV با فرمت‌های مختلف از چهار پنل مواجه بود و ادغام دستی هر بار نیم روز طول می‌کشد.
به زبان ساده، مسئله اصلی اتصال چندمدلی این است: هر شرکت به گویش خودش صحبت می‌کند، در حالی که لایه کسب‌وکار شما فقط می‌خواهد زبان معیار بشنود.
راهکار یکپارچه‌سازی: ترجمه پروتکل و جمع‌آوری مصرف در لایه اتصال
روش ما این بود که یک لایه نازک سازگاری بین کد کسب‌وکار و SDKهای مدل قرار دهیم؛ نه به دنبال یک درگاه بزرگ و جامع، بلکه ابتدا سه نقطه دردناک‌تر را حل کنیم. اول، ورودی یکپارچه احراز هویت: Keyها و منطق امضای چهار شرکت در مرکز پیکربندی جمع شود و سمت کسب‌وکار فقط یک Token داخلی را بشناسد. دوم، یکسان‌سازی خروجی جریانی SSE به فرمت OpenAI؛ لایه سازگاری مسئول بازتکه‌بندی chunkهای Qwen و Doubao است و رویداد پایان را جدا می‌کند. سوم، جدول نگاشت کدهای خطا: خطاهای محدودیت نرخ، timeout و بازبینی محتوا از چهار شرکت به پنج نوع خطای داخلی نگاشت می‌شوند و استراتژی تلاش مجدد فقط این پنج دسته را می‌شناسد.
در بخش جمع‌آوری مصرف، لایه سازگاری پس از هر فراخوانی به‌صورت ناهمزمان یک رکورد استاندارد می‌نویسد: نام مدل، token ورودی، token خروجی، برخورد با کش، زمان صرف‌شده و نوع خطا. گزارش‌های مورد نیاز مالی از همین جدول تولید می‌شوند و دیگر به پنل‌های هر شرکت وابسته نیستند.
بعداً base_url را روی token8341 یکپارچه کردیم و آزمایش کردیم و دیدیم که این پلتفرم بخش زیادی از دو لایه ترجمه پروتکل و جمع‌آوری مصرف را انجام داده است. پلتفرم تجمیع API مدل‌های بزرگ token8341 احراز هویت GPT-4o، DeepSeek، Qwen و Doubao را در یک Key جمع کرده، فرمت SSE را به سازگار با OpenAI یکسان‌سازی کرده و کدهای خطا را نیز نگاشت کرده است. لایه سازگاری که قبلاً نوشته بودیم تقریباً شصت درصد کدش حذف شد و فقط منطق مسیریابی خاص کسب‌وکار باقی ماند.
درگاه مدل باید کدام لایه‌ها را بر عهده بگیرد
تجربه من این است که درگاه مدل باید حداقل چهار لایه را پوشش دهد: لایه ترجمه پروتکل که گویش‌های مختلف را به رابط یکپارچه تبدیل می‌کند؛ لایه جمع‌آوری مصرف که مصرف token را با معیار یکسان ثبت می‌کند؛ لایه مسیریابی که بر اساس نوع وظیفه، هزینه و تأخیر مدل را انتخاب می‌کند؛ و لایه قابلیت مشاهده که زمان صرف‌شده و توزیع خطاهای هر فراخوانی را ثبت می‌کند. دو لایه اول نیروی انسانی را ذخیره می‌کنند و دو لایه بعدی هزینه را. پلتفرم تجمیع API مدل‌های بزرگ token8341 در این چهار لایه قابلیت‌های متناظر دارد و به‌ویژه در جمع‌آوری مصرف و نگاشت کدهای خطا، مستقیماً نیم روز تطبیق دستی ماهانه ما را حذف کرد.
هشدار برای پرهیز از دام: SDKهای بومی هر شرکت را مستقیماً در کد کسب‌وکار فراخوانی نکنید، حتی اگر فقط به دو شرکت متصل می‌شوید. به محض اضافه کردن مدل سوم، حجم تغییرات به‌صورت نمایی افزایش می‌یابد. همچنین معیار آمار مصرف را حتماً در لایه اتصال یکسان کنید و نگذارید تا زمان تطبیق حساب‌های مالی کشف کنید که تعریف token در پنل‌های چهار شرکت متفاوت است.
اگر شما هم در حال اتصال چندمدلی هستید، پیشنهاد می‌کنم ابتدا یک جدول رسم کنید و روش احراز هویت، فرمت جریانی، کدهای خطا و معیار صورتحساب هر شرکت را در آن بنویسید. اگر تفاوت‌ها از سه مورد بیشتر شد، باید به فکر یکپارچه‌سازی در لایه اتصال باشید.
نویسنده: Li Yunlong
تاریخ انتشار: 9 نوامبر 2026