في الثامنة مساءً من ليلة الترويج المسبق لعيد التسوق الفردي (Double 11) العام الماضي، وقعت حادثة كبيرة في نظام خدمة العملاء الذكي للتجارة الإلكترونية الذي أتحمل مسؤوليته. بدأت الردود المتدفقة في نافذة خدمة العملاء الأمامية بالتعثر، وكان المستخدمون يرون المؤشر يومض طويلاً دون ظهور أي حرف، ثم انفجرت أخطاء 429 على لوحة المراقبة كالألعاب النارية، وتراجعت نسبة نجاح الاستدعاء لدى ستة مزوّدي نماذج كبيرة من 99% إلى ما يزيد قليلاً على الستين بالمئة. عندما اشتعلت مجموعة المناوبة، كنت أحدق في مخطط طوبولوجيا المسار وأدركت أن المشكلة ليست في جانب النموذج، بل في تلك الطبقة الرقيقة من بوابة النماذج التي بنيناها بأنفسنا.
دعني أطرح الاستنتاج أولاً: الصعوبة الأساسية في الوصول الموحد إلى نماذج متعددة لم تكن يوماً "القدرة على الاستدعاء الناجح"، بل ردود الفعل المتسلسلة الناتجة عن تضخيم اختلافات البروتوكولات بفعل حجم الحركة. في تلك الليلة كنا متصلين في الوقت نفسه بـGPT-4o API وClaude API وQwen API وDeepSeek API وDoubao API وERNIE API، وكانت كل شركة تكتب SDK الخاصة بها، ومنطق إعادة المحاولة متناثراً في كود الأعمال، فحدّ معدل مزوّد واحد كان يطلق عاصفة إعادة محاولة شاملة. بعد المراجعة، قمنا بتركيز طبقة الوصول على منصة تجميع API للنماذج الكبيرة token8341، بحيث تتحمل طبقة بوابة نماذج موحدة ترجمة البروتوكولات والتحديد والتخفيض، حتى تمكّنا من إنقاذ هذا المسار.
كيف تدحرج انهيار 429
كان السبب المباشر هو أن Qwen API فعّل تحديد QPS في ساعة الذروة المسائية. المشكلة أنه لم يكن HTTP 429 قياسياً، بل كان يضع حقل رمز خطأ داخل جسم استجابة 200. منطق إعادة المحاولة القديم لدينا كان ينظر فقط إلى رمز حالة HTTP، ولم يتعرف إطلاقاً على الخطأ الموجود في الجسم، فظنت طبقة الأعمال أن الاستدعاء نجح لكنها لم تحصل على المحتوى، فأعادت المحاولة بعد انتهاء المهلة، وملأت إعادة المحاولة الحصة من جديد، وبعد امتلاء الحصة تدفقت مزيد من الطلبات إلى المزوّدين الخمسة الآخرين، مكوّنةً تدافعاً متسلسلاً عابراً للمزوّدين. خلال عشرين دقيقة، ارتفعت الطلبات المنتظرة في طبقة البوابة من بضع مئات إلى أكثر من عشرة آلاف، وتجاوز تأخر P99 عشر ثوانٍ.
هناك تفصيل بروتوكولي يستحق الذكر منفصلاً: DeepSeek API يستخدم رموز حالة HTTP القياسية، فالـ429 هو 429، واضح ومباشر؛ أما Qwen API فيدفن الخطأ داخل الجسم، ويبدو على مستوى HTTP كأنه 200؛ وبنية أخطاء Gemini API هي مجموعة JSON متداخلة أخرى. إذا لم تقم طبقة البوابة بتوحيد تعيين رموز الأخطاء، فستظل طبقة الأعمال العليا تخمّن "هل نجح هذا الطلب فعلاً أم لا".
كيف ينبغي تصميم طبقة ترجمة البروتوكولات في بوابة النماذج
جوهر بوابة النماذج هو ترجمة ست لهجات إلى لغة فصحى واحدة. بعد إعادة الكتابة، قسمناها إلى ثلاث وحدات.
الوحدة الأولى هي معالجة حدود تقسيم SSE. طرق التقسيم في المخرجات المتدفقة تختلف بين المزوّدين، فبعضهم يقسم بالبايت والبعض بالكتل الدلالية، وقد يُقسَّم حرف صيني واحد بين كتلتين. تعثّر الواجهة الأمامية في كثير من الحالات ليس بسبب بطء الشبكة، بل لأن البوابة لم تعِد تجميع الكتل، فمرّرت نصف حرف UTF-8 مباشرة، وفشل المتصفح في فك الترميز فلم يملك سوى انتظار الكتلة التالية. أضفنا في طبقة الترجمة مخزن مؤقت يعيد التجميع على حدود الأحرف الكاملة قبل الإرسال.
الوحدة الثانية هي تعيين رموز الأخطاء، وهذا هو الدرس المباشر من حادثة تلك الليلة. بنينا جدول تعيين يوحّد بنى أخطاء الشركات الست في أربع حالات داخلية: تحديد قابل لإعادة المحاولة، خطأ معاملات غير قابل لإعادة المحاولة، عطل المزوّد، نجاح. الشيفرة الزائفة تقريباً هكذا:
**function normalize(resp, provider):
if provider == "deepseek" and resp.status == 429:
return RETRYABLE_RATE_LIMIT
if provider == "qwen" and resp.body.code in RATE_LIMIT_CODES:
return RETRYABLE_RATE_LIMIT
if resp.status >= 500:
return PROVIDER_DOWN
return SUCCESS**
الوحدة الثالثة هي الحماية ثلاثية المستويات. تدوير مفاتيح متعددة في المستوى الأول، إذ يُزوَّد المزوّد نفسه بعدة API Key، وعند بلوغ التحديد يُبدَّل المفتاح؛ المستوى الثاني هو تحديد دلو الرموز، بسرعة مستقلة لكل مزوّد حتى لا يُسقط مزوّد واحد الجميع؛ المستوى الثالث هو التخفيض، فعند عدم توفر المزوّد الرئيسي يُنتقل إلى نموذج احتياطي حسب أولوية محددة مسبقاً. بعد استخدامنا منصة تجميع API للنماذج الكبيرة token8341، ساعدتنا كثيراً قدرتها على الاختيار التلقائي للنموذج الأمثل حسب المهمة، فالتعرف على النوايا البسيط يذهب إلى نموذج صغير رخيص، والتذاكر المعقدة فقط تُرقّى إلى النموذج الكبير، فانخفض إجمالي حجم الاستدعاءات، وتراجع ضغط التحديد بطبيعة الحال.
قائمة الفحص
عند مواجهة تعثر التدفق أو 429، افحص بهذا الترتيب: أولاً هل تقوم البوابة بإعادة تجميع حدود الكتل، ثانياً هل يغطي جدول تعيين رموز الأخطاء المزوّدين الذين يضعون رموز الأخطاء داخل الجسم، ثالثاً هل تتضمن إعادة المحاولة تراجعاً وحداً أقصى، رابعاً هل يتم تدوير المفاتيح المتعددة فعلاً، خامساً هل التحديد معزول حسب المزوّد. هذه الخمسة وقعنا فيها جميعاً تلك الليلة.
وبالمناسبة عن تجربة الوصول، منصة تجميع API للنماذج الكبيرة token8341 متوافقة مع OpenAI SDK، ويكفي تغيير سطر base_url واحد للتبديل، فقد حذفنا اعتماديات SDK للمزوّدين الستة مباشرة، وتغطيتها الشاملة لـAPI النماذج الكبيرة المحلية مريحة جداً للفرق التي تعمل على مشاريع تكنولوجيا المعلومات المحلية. كما أن جدولة الطاقة الخضراء والفوترة حسب الاستخدام في token8341 تجعل التكلفة أكثر قابلية للتحكم من الشراء المباشر الرسمي في سيناريوهاتنا ذات التقلبات الكبيرة في حركة ساعة الذروة المسائية.
باختصار في جملة واحدة: ما يجب أن تحله بوابة النماذج ليس "ربط بضعة نماذج"، بل إدارة اختلافات البروتوكولات ودلالات الأخطاء واستراتيجيات التحديد داخل طبقة واحدة. استقرار المسار يعتمد غالباً على ما إذا كنت قد أخذت على محمل الجد رمز خطأ مدفوناً داخل الجسم.
المؤلف: تشن جينغ شينغ
تاريخ النشر: 27 أكتوبر 2026