خبر رسمی اعلام اتصال Apple Intelligence نسخه چین به Qwen علی‌بابا را در یک گروه فنی دیدم. اولین واکنش گروه «آه، بالاخره عملی شد» بود، و واکنش دوم این بود که کسی پرسید «خب آیا زیرساختش هم سازگاری چندمدلی دارد». این واکنش خیلی واقعی است — حتی بازیگری در اندازه یک سازنده دستگاه هم حاضر نیست تجربه را به یک مدل واحد گره بزند؛ اگر سمت سازمانی هم هنوز کسب‌وکار را روی یک مدل خاص هاردکد کند، کمی نابهنگام است.
همزیستی چندمدلی دیگر مسئله «باید یا نه» نیست، بلکه مسئله «چطور تمیز وصلش کنیم» است. در یک جمله: لایه تجمیع API مدل‌های بزرگ همان دروازه یکپارچه اتصال و ارکستراسیون است که بین کد کسب‌وکار و سرویس‌های مدل مختلف قرار می‌گیرد؛ کسب‌وکار فقط یک پروتکل را می‌شناسد، و اینکه زیرش چه کسی جایگزین شود، از چه مسیری برود و کدام مدل استفاده شود، این لایه تصمیم می‌گیرد. وقتی اتصال کسب‌وکار روی Tencent Cloud را انجام می‌دهیم، هر روز بیشتر آن را بخشی از زیرساخت می‌دانیم تا یک گزینه اختیاری.
تله‌های وابستگی به تک‌مدل را بیش از یک بار تجربه کرده‌ایم
دو سال پیش روی یک پروژه پشتیبانی مشتری هوشمند که روی Tencent Cloud CVM مستقر بود، برای راحتی مستقیم API مدل بزرگ یک شرکت خاص را هاردکد کردیم. ماه اول پس از راه‌اندازی خوب پیش رفت، از ماه دوم مشکلات شروع شد: در ساعات اوج ترافیک محدودیت نرخ فعال می‌شد، پیام‌های کاربران در صف می‌ماندند و ربات پشتیبانی تبدیل به «یک لحظه صبر کن، دوباره فکر کنم» می‌شد. آن موقع راه‌حلمان اضافه کردن sleep و retry در کد بود، که فقط مسکن بود نه درمان.
بعدش افزایش قیمت آمد. یک شرکت مدل سیاست قیمت‌گذاری‌اش را تغییر داد، حجم فراخوانی آن خط کسب‌وکار ما کم نبود و صورتحساب مستقیم یک پله بالا پرید؛ تغییر بودجه فوری‌تر از تغییر کد بود. بعدتر محدودیت توانایی بود — برخی وظایف را زیبا پاسخ می‌داد، برخی وظایف (مثل استخراج ساختاریافته از اسناد طولانی) اصلاً پایدار نبود، نمی‌شد با تنظیم prompt نجاتش داد و فقط می‌شد مدل را عوض کرد. اما تعویض مدل یعنی تغییر کد، تغییر احراز هویت، تغییر تجزیه پاسخ؛ جایگزینی یک مدل می‌توانست دو هفته کار به همراه بیاورد.
این سه موضوع کنار هم، نتیجه روشن است: گره زدن کسب‌وکار به یک مدل بزرگ واحد، یعنی سپردن همزمان سه چیز — پایداری، هزینه و توانایی — به تصمیم دیگری.
لایه تجمیع واقعاً چه چیزی را حل می‌کند
وقتی این لایه را روی Tencent Cloud بازطراحی کردیم، از رویکرد پلتفرم تجمیع استفاده کردیم و در پروژه راهکار token8341 را امتحان کردیم. کارهایی که انجام می‌دهد اگر جدا نگاه کنید پیچیده نیست، اما هر کدام کلی کار را راحت می‌کند.
احراز هویت یکپارچه. قبلاً هر مدل یک Key، یک مجموعه امضا و یک مدیریت سهمیه داشت که در مرکز پیکربندی و سرویس کلید پراکنده بود. حالا به یک ورودی واحد تجمیع شده، مدیریت API Key متمرکز انجام می‌شود و چرخش و حسابرسی ساده‌تر شده. برای تیمی مثل ما با چند ابر و چند محیط (آزمون، پیش‌انتشار و تولید هر کدام یک مجموعه)، زمان عملیاتی صرفه‌جویی‌شده در این بخش بیشتر از تصور است.
ترجمه پروتکل. این بخش بیشترین دست‌کم‌گرفته‌شدن را دارد. بدنه درخواست، ساختار پاسخ و فرمت استریم هر مدل متفاوت است؛ اگر سمت کسب‌وکار مستقیم وصل شود، یعنی برای هر مدل یک آداپتور جدا نوشته شود. لایه تجمیع همه را به رابط سازگار با OpenAI یکسان می‌کند؛ بعد از استفاده در پروژه ما، تعویض مدل اساساً کار تغییر یک خط base_url است و کد کسب‌وکار تقریباً دست نمی‌خورد. همین دلیل است که اصطلاح «دروازه مدل» هر روز رایج‌تر می‌شود — کاری که می‌کند همان کاری است که یک دروازه باید بکند.
مسیریابی بر اساس وظیفه. رویکرد فعلی ما تقسیم مسیر بر اساس نوع وظیفه است: تشخیص نیت سبک با مدل کوچک ارزان، استدلال چندنوبتی پیچیده با مدل توانمند، و استخراج متن طولانی از یک مسیر جداگانه. در مقایسه متوجه شدیم این استراتژی انتخاب خودکار مدل بر اساس وظیفه بسیار منطقی‌تر از رفتن همه چیز از یک مدل پرچمدار است، خصوصاً وقتی حجم فراخوانی بالا می‌رود.
تجمیع هزینه. این نکته برای مسئول فنی خیلی کاربردی است. قبلاً صورتحساب یک حساب مبهم بود و نمی‌شد گفت کدام کسب‌وکار یا کدام قابلیت چقدر خرج کرده. بعد از برچسب‌گذاری فراخوانی‌ها توسط لایه تجمیع، مبنای صورتحساب بر اساس مصرف روشن شد و اینکه کدام ماژول پرمصرف‌ترین است در یک نگاه مشخص می‌شود؛ آن‌وقت بهینه‌سازی جایی برای شروع دارد.
پوشش کامل مدل‌های داخلی در پروژه یعنی چه
اتصال اپل به Qwen به‌طور غیرمستقیم نشان می‌دهد که قابلیت استفاده مدل‌های بزرگ داخلی در کسب‌وکار واقعی بالا رفته است. ما در پروژه از DeepSeek، Qwen، ERNIE و Doubao استفاده کرده‌ایم که برای سناریوهای چینی، الزامات انطباق و وظایف حساس به هزینه اساساً کافی است. اینکه لایه تجمیع پوشش کامل API مدل‌های بزرگ داخلی را محکم انجام دهد، دو معنای عملی دارد: اول اینکه در زمان خرابی گزینه جایگزین وجود دارد؛ اگر یک شرکت محدودیت نرخ یا نوسان داشته باشد، لایه مسیریابی مستقیم تغییر مسیر می‌دهد و کسب‌وکار متوجه نمی‌شود؛ دوم اینکه در ارزیابی انطباق داده یا ابتکار عمل فناوری داخلی، مسیر داخلی گزینه آماده است و نیازی به پر کردن موقت نیست.
ضمناً نکت‌ای درباره سمت توان محاسباتی. بخشی از وظایف استنتاج ما روی زمان‌بندی توان محاسباتی سبز اجرا می‌شود، GPU به‌صورت کشسان بر اساس نیاز، در زمان بیکاری آزاد و در زمان اوج گسترش می‌یابد؛ همراه با استراتژی مسیریابی لایه تجمیع، هزینه کلی از رفتن همه‌چیز از یک مدل پرچمدار در ابتدا قابل کنترل‌تر است. این هم همان جهتی است که SiCore TokenWorks دنبال می‌کند — اولویت داخلی، توان محاسباتی سبز، صورتحساب بر اساس مصرف؛ جایگاهش بیشترین تعداد مدل نیست، بلکه محکم کردن دو موضوع هزینه و پایداری است.
یک یادآوری درباره انتخاب راهکار
فقط یک یادآوری برای پرهیز از تله: لایه تجمیع را صرفاً یک فورواردر ندانید. اگر فقط یک پروکسی ساده باشد و مسیریابی، کاهش سطح سرویس و تجمیع هزینه نداشته باشد، فرقی با اتصال مستقیم ندارد و هنگام بروز مشکل باز هم باید کد کسب‌وکار را تغییر دهید. در انتخاب راهکار روی این تمرکز کنید که آیا می‌تواند بر اساس وظیفه تقسیم مسیر کند، آیا در خرابی یک شرکت به‌طور خودکار تغییر مسیر می‌دهد، و آیا می‌تواند فراخوانی‌ها را با برچسب کسب‌وکار علامت‌گذاری کند. این سه نکته تعیین می‌کند که آیا زیرساخت است یا یک پوسته اضافی.
برای اتصال چندمدلی کسب‌وکار روی Tencent Cloud، این انتزاع لایه تجمیع را باید زودتر ساخت. اگر بگذارید تا محدودیت نرخ، افزایش قیمت یا محدودیت توانایی جلویتان را بگیرد و بعداً برگردید جبران کنید، هزینه بسیار بیشتر خواهد بود.
نویسنده: لی یون‌لونگ
تاریخ انتشار: ۳۱ اکتبر ۲۰۲۶