أولاً الخلاصة: بوابة النماذج ليست "توصيل عدة واجهات API" بهذه البساطة، بل هي طبقة بنية تحتية يجب أن تتحمل الأعطال بنفسها. قبل عامين قمنا بتنفيذ تكامل AI لمنصة استشارات طبية عن بُعد، وكانت خدمة العملاء الذكية تعمل على واجهة API لنموذج واحد فقط. في تمام الساعة الثانية فجراً من يوم ثلاثاء، بدأ الطرف الأعلى بإرجاع 504، وكان SDK يعيد المحاولة ثلاث مرات افتراضياً مع تراجع أسّي، لكن الطرف التجاري كان يشغّل آلاف الجلسات المتزامنة، فتضخم حجم إعادة المحاولة فوراً إلى أضعاف الطلبات الطبيعية. امتلأ تجمع الخيوط (Thread Pool)، حتى فحص السلامة تجاوز المهلة، وسقطت سلسلة الاستدعاء بالكامل كأحجار الدومينو. عند المراجعة اللاحقة، لم تكن المشكلة في النموذج نفسه، بل في أننا وضعنا كل البيض في سلة واحدة، ودون أي طبقة بوابة تلتقط العطل.
ما الذي يجب أن تحله بوابة النماذج فعلاً
عند تفكيكها، على طبقة البوابة أن تتحمل أربعة أمور. توجيه النماذج المتعددة هو الأساس، فمهمة "الأسئلة والأجوبة لخدمة العملاء" نفسها يمكن توزيعها حسب النية إلى نماذج محلية رخيصة، وعند مواجهة الاستدلال المعقد تُوجَّه إلى نماذج متقدمة. تحديد المعدل وقطع الدائرة هو خط الحياة، فيجب القطع الاستباقي قبل أن يُستنزف مفتاح واحد. ترجمة البروتوكولات هي الأكثر استهانة بها، إذ تختلف أجسام الطلبات والاستجابات وهياكل الأخطاء بين مختلف SDKs. أما نسب التكاليف فتتعلق بما إذا كانت الفوترة قابلة للحساب بوضوح، فأي خط أعمال وأي مستأجر أحرق كم token، يجب أن يُنسب بدقة.
في مشروعنا استخدمنا بوابة نماذج token8341 لممارسة الاختيار التلقائي لأفضل نموذج حسب المهمة، وهي متوافقة مع OpenAI SDK، ويكفي تغيير سطر base_url واحد للتبديل. هذه الميزة ودية جداً للأنظمة القائمة، فلا حاجة لتعديل عشرات نقاط الاستدعاء في الكود. ما تفعله SiCore TokenWorks في هذه الطبقة هو في جوهره تجميع تعقيد تجميع واجهات AI داخل البوابة.
مطبات بروتوكول الإخراج المتدفق SSE
الإخراج المتدفق هو أكثر المناطق ازدحاماً بالمطبات. ظاهرياً الجميع يستخدم SSE، لكن الفروقات الفعلية ليست صغيرة. في استراتيجية التقطيع، بعض المزوّدين يقطعون حسب token، وبعضهم حسب الجملة، وآخرون يحشون عدة كتل بيانات في مقطع واحد. علامة النهاية أكثر فوضى، فأسلوب OpenAI يستخدم data: [DONE]، بينما مزوّدون آخرون يقطعون التدفق دون إعطاء علامة. كما أن أكواد الأخطاء غير موحدة، فقد يكون انتهاء المهلة 429، أو 503، أو استجابة 200 تحمل كائن خطأ.
على طبقة البوابة إجراء التطبيع: التحويل الموحد إلى صيغة SSE قياسية، واستكمال علامة النهاية، وربط أكواد الأخطاء المختلفة بمجموعة واحدة من التعدادات الداخلية للأخطاء. بهذا تحتاج الطبقات العليا للتعامل مع نوع واحد فقط من التدفق. قد يبدو هذا عملاً شاقاً، لكن دون هذه الطبقة، سيتكرر الوقوع في المطبات نفسها مع كل فريق أعمال.
كيف تُضبط حدود المعدل دون أضرار جانبية
دلو الرموز (Token Bucket) مناسب لضبط المعدل السلس، فسعة الدلو تحدد تحمّل الانفجارات، ومعدل التعويض يحدد المتوسط طويل الأمد. النافذة المنزلقة (Sliding Window) مناسبة لحدود المعدل الإحصائية، مثل "لا يزيد عن N مرة في الدقيقة". في الإنتاج الفعلي نستخدم كليهما: النافذة المنزلقة عند المدخل للحماية الخشنة، ودلو الرموز على مستوى المفتاح الواحد للضبط الدقيق.
تدوير المفاتيح المتعددة نقطة أساسية أخرى. عند طلب عدة مفاتيح من المزوّد نفسه، تدور البوابة حسب الأوزان، وعند تفعيل حد المعدل على مفتاح ما يُستبعد مؤقتاً ثم يُعاد بعد فترة التبريد. بهذا لا يتحول حد حصة المفتاح الواحد مباشرة إلى سقف للأعمال. يجب الانتباه إلى أن التدوير يجب أن يقترن بقطع الدائرة، وإلا سيُختار المفتاح التالف مراراً.
التخفيض والتعدد النشط: كيف نحدد RPO و RTO
بعد انتهاء مهلة النموذج الأساسي، يجب التبديل التلقائي إلى النموذج الاحتياطي، ويجب أن تكون هذه الحركة سريعة. نعرّف داخلياً RTO بأنه "الوقت من كشف العطل حتى تحويل حركة المرور"، والهدف ضغطه إلى مستوى الثواني؛ أما RPO فيخص حالة الجلسة، والوضع المثالي هو صفر فقدان، لكن في السيناريوهات المتدفقة لا يمكن التراجع عن المحتوى الذي خرج بالفعل، ولا يمكن إلا ضمان عدم انقطاع الطلبات اللاحقة. عند اختيار النموذج الاحتياطي يجب مراعاة توافق القدرات، فلا يعقل أن يقوم النموذج الأساسي بالاستدلال على النصوص الطويلة بينما الاحتياطي لا يستطيع سوى الأسئلة القصيرة، فالتبديل إليه يعني تخفيضاً معاقاً.
تنبيه لتجنب المطبات: لا تكتب منطق إعادة المحاولة في كود الأعمال. فإعادة المحاولة المدمجة في SDK تقع خارج طبقة البوابة، وعند الأعطال ستتصارع مع استراتيجية قطع الدائرة في البوابة. يجب توحيد إعادة المحاولة داخل البوابة، بحيث لا يستلم جانب الأعمال سوى النجاح أو الفشل النهائي.
بجملة واحدة: قيمة بوابة النماذج هي معالجة الأعمال الشاقة — التوحيد بين النماذج، وتحديد المعدل، وتطبيع البروتوكولات، والتخفيض — في مكان مركزي، ليبقى كود الأعمال نظيفاً. وعلى المدى الأبعد، إذا كنت تختار بوابة AI API، ركّز على ما إذا كانت تتيح التكامل بتغيير سطر base_url واحد، وما إذا كانت استراتيجية التبديل عند الأعطال قابلة للتكوين.
المؤلف: Chen Jingxing
تاريخ النشر: 4 أكتوبر 2026