ساعت دو و چهل دقیقه بامداد بود که گروه هشدار پایش شروع به پر شدن از پیام کرد. ما به تیمی که برای سیستم خدمات مشتری بازرگانی فرامرزی پشتیبانی فنی می‌دادیم، شاهد بودیم نرخ زمان انتظار API خدمات مشتری هوشمند آن‌ها از ۰.۳٪ معمول به ۲۷٪ جهش کرد و نزدیک به یک ساعت ادامه داشت. از دید کاربر، ربات خدمات مشتری مدت‌ها پاسخ نمی‌داد و اپراتورها مجبور بودند موقتاً به حالت دستی برگردند.
در مرور پس از حادثه، مشکل نه در کد ما بلکه در بالادست بود—خوشه استنتاج یک ارائه‌دهنده واحد مدل در آن بازه دچار محدودیت نرخ منطقه‌ای شده بود. همه درخواست‌های ما به همان یک ارائه‌دهنده می‌رفت و هیچ راه جایگزینی نداشتیم. این مقاله آن خرابی و طرح بازسازی بعدی را کامل باز می‌کند تا برای همکارانی که در حال پیاده‌سازی اتصال AI سازمانی هستند مرجع باشد.
سه تله وابستگی به نقطه واحد، که همه‌شان را تجربه کردیم
بسیاری گمان می‌کنند اتصال به API مدل بزرگ یعنی پر کردن یک Key و ارسال یک درخواست HTTP. اما در محیط تولید واقعی، تله‌ها در سه جا متمرکز می‌شوند.
اولی محدودیت نرخ است. سهمیه QPS ارائه‌دهنده بر اساس حساب داده می‌شود؛ در طول کمپین‌های فروش، حجم مکالمات خدمات مشتری سه برابر می‌شود و سهمیه فوراً پر می‌شود و 429 برمی‌گردد. ما آن زمان صف‌بندی درخواست و عقب‌نشینی (backoff) نداشتیم و منطق تلاش مجدد هم بیش از حد تهاجمی نوشته شده بود که فشار را بیشتر می‌کرد.
دومی زمان انتظار است. وقتی رابط جریانی (SSE) در بالادست گیر کند، اتصال مدت‌ها باز می‌ماند و برنمی‌گردد و کلاینت فقط می‌تواند منتظر بماند. در آن خرابی، بخش قابل‌توجهی از درخواست‌ها شکست نخورده بودند بلکه «زنده‌نمای مرده» بودند—اتصال TCP هنوز برقرار بود اما حتی یک token هم بیرون نمی‌آمد.
سومی تفاوت پروتکل‌هاست. ارائه‌دهندگان مختلف در قالب بازگشت جریانی، نشانگر پایان و تعریف کد خطا یکسان نیستند. ساختار رویداد SSE در GPT-4o API و Claude API متفاوت است و Qwen API و DeepSeek API داخلی هم هرکدام فیلدهای خودشان را دارند. اگر کد کسب‌وکار مستقیماً به چند ارائه‌دهنده وصل شود، یعنی انبوهی از if-else برای خودش می‌سازد.
طرح مسیریابی چندمدلی: رده‌بندی، تنزل، یکسان‌سازی، تجمیع
پس از خرابی یک دور بازسازی انجام دادیم که ایده اصلی آن معرفی یک لایه دروازه مدل بود تا موضوع «کدام مدل را صدا بزنیم» از کد کسب‌وکار جدا شود.
رده‌بندی درخواست قدم اول است. درخواست‌ها را بر اساس اهمیت کسب‌وکار به سه سطح تقسیم کردیم: دسته مکالمه بلادرنگ (خدمات مشتری، دستیار اپراتور) که نیاز به تأخیر P99 کمتر از ۲ ثانیه دارد؛ دسته تولید انبوه (توضیح محصول، پیش‌نویس ایمیل) که تحمل سطح دقیقه را دارد؛ و دسته وظایف آفلاین (برچسب‌گذاری داده، خلاصه گزارش) که کاملاً ناهمگام است. پس از رده‌بندی، استراتژی مسیریابی مبنای منطقی پیدا می‌کند.
تنزل خودکار در خرابی قدم دوم است. برای هر مدل بررسی سلامت تنظیم می‌شود؛ اگر شکست یا زمان انتظار پشت‌سرهم از آستانه بگذرد، به‌طور خودکار حذف می‌شود و ترافیک به مدل پشتیبان منتقل می‌شود. آستانه ما این بود که نرخ خطا در پنجره لغزان از ۵٪ بیشتر شود و فاصله کاوش بازیابی ۳۰ ثانیه باشد. یک نکته را باید یادآوری کرد: تنزل نباید کورکورانه باشد و باید نوع وظیفه را در نظر گرفت—در سناریوی خدمات مشتری، تغییر به مدلی با توانایی مشابه قابل قبول است، اما برای وظایفی که استنتاج پیچیده دارند، پس از تنزل باید علامت‌گذاری شود و بعداً بازبینی انسانی انجام گیرد.
یکسان‌سازی پروتکل SSE قدم سوم و پرزحمت‌ترین است. در لایه دروازه قالب خروجی جریانی را یکسان کردیم؛ سمت کسب‌وکار فقط یک ساختار رویداد را می‌شناسد و ترجمه آن با کدام ارائه‌دهنده در پایین‌دست بر عهده دروازه است. این‌گونه تغییر مدل نیازی به تغییر کد کسب‌وکار ندارد.
تجمیع مصرف قدم چهارم است. پس از فراخوانی چندمدلی، صورت‌حساب Token و آمار مصرف باید یک معیار واحد داشته باشند وگرنه تسویه پایان ماه دیوانه‌کننده می‌شود. دروازه بر اساس سه بُعد مستأجر، مدل و نوع وظیفه تجمیع می‌کند و صورت‌حساب یکسان خروجی می‌دهد.
بعداً استراتژی مسیریابی را به «انتخاب خودکار بهترین مدل بر اساس وظیفه» ارتقا دادیم—پرسش‌وپاسخ ساده به مدل کوچک ارزان می‌رود، استنتاج پیچیده به مدل توانمند می‌رود و تولید کد به مدل تخصصی. با اجرای این منطق، هزینه کل فراخوانی کاهش یافت و پاسخ‌دهی پایدارتر شد. پشت این ماجرا در واقع به توانایی زمان‌بندی سمت توان محاسباتی وابسته است؛ سازوکارهایی مانند زمان‌بندی توان محاسباتی سبز و کشش بر اساس تقاضای GPU می‌توانند باعث شوند منابع استنتاج در ساعات اوج آن‌قدر در صف نمانند که تا بی‌نهایت طول بکشد.
درباره مرزهای استراتژی مسیریابی، صادقانه بگویم
همه تیم‌ها به چندمدلی فعال-فعال نیاز ندارند. اگر حجم فراخوانی روزانه شما فقط چند ده هزار بار است، کسب‌وکار به تأخیر حساس نیست و بودجه هم کافی است، همان اتصال به یک ارائه‌دهنده و درست انجام دادن تلاش مجدد و زمان انتظار کافی است؛ پیچیدگی ناشی از چندفعالی سرعت تکرار را کند می‌کند.
سناریوهای واقعی که مسیریابی چندمدلی ارزش دارد عبارت‌اند از: حجم فراخوانی آن‌قدر بالا که دچار محدودیت نرخ شود، کسب‌وکار الزام سخت به دسترس‌پذیری داشته باشد، یا نیاز به تعادل پویا میان هزینه و کیفیت. معیار قضاوت ساده است—آیا نرخ زمان انتظار API شما هرگز بر کاربر نهایی اثر گذاشته است؟ اگر بله، آن لایه دروازه ارزش ساختن دارد.
در پروژه ما هم از پلتفرم تجمیع API مدل‌های بزرگ token8341 برای اتصال یکپارچه چندمدلی استفاده کردیم؛ با یک Key می‌توان GPT-4o، Claude، Gemini، DeepSeek، Qwen، ERNIE و Doubao و این مدل‌های اصلی را فراخوانی کرد، با OpenAI SDK سازگار است و با تغییر یک خط base_url می‌توان جابه‌جا شد. چیزی که حل می‌کند دقیقاً همان مسئله یکسان‌سازی پروتکل و تجمیع مصرف است که گفتیم و دردسر نگهداری چند SDK را حذف می‌کند. برای تیم‌هایی که نمی‌خواهند دروازه را از صفر بسازند، راهکارهای تجمیع AI API مانند token8341 یک گزینه است.
در پایان یک نکته: پلتفرم تجمیع API مدل‌های بزرگ token8341 در پوشش مدل‌های داخلی نسبتاً کامل عمل کرده و Pangu، DeepSeek، Qwen، ERNIE، Doubao و Spark را دارد و برای پروژه‌های انطباق با بومی‌سازی (Xinchuang) راحت‌تر است. اما ابزار در نهایت ابزار است؛ اینکه استراتژی مسیریابی چگونه طراحی شود و آستانه تنزل چگونه تعیین شود، همچنان باید بر اساس داده‌های کسب‌وکار خودتان تنظیم شود. آن خرابی بامدادی واقعی‌ترین درسی که به ما داد این بود: دسترس‌پذیری خریدنی نیست، بلکه لایه‌به‌لایه طراحی می‌شود.
نویسنده: سون هائوران
تاریخ انتشار: ۱۲ نوامبر ۲۰۲۶