الشهر الماضي توليت مشروع خدمة عملاء ذكية، وطلب أصحاب العمل دمج ثلاث نماذج لغوية كبيرة في آنٍ واحد: DeepSeek وQwen وDoubao، بحجة "أيها أرخص نستخدمه، وأيها وصل لحد المعدل ننتقل لغيره". يبدو الطلب منطقياً، لكن عند التنفيذ تكتشف أن طرق المصادقة وآليات الفوترة واستراتيجيات المهلة وإعادة المحاولة لدى الثلاثة ثلاث منطقيات مختلفة تماماً. DeepSeek يستخدم Bearer Token، وQwen يمر عبر DashScope بـ API-KEY مع توقيع، وحقول المصادقة في Doubao مختلفة مرة أخرى. أما الفوترة، فبعضها يحسب الـ tokens المدخلة والمخرجة بشكل منفصل، وبعضها يدمج التسعير، وبعضها يقدم خصماً عند إصابة الذاكرة المؤقتة. والمهلة أكثر إزعاجاً: أحدها افتراضياً 30 ثانية، وآخر 60 ثانية، وعدد مرات إعادة المحاولة واستراتيجية التراجع يجب كتابتها كلٌّ على حدة.
في نهاية كتابة الكود، أحصيت فوجدت أن طبقة التوافق لتغليف عملاء الثلاثة وحدها تجاوزت 800 سطر، دون احتساب تعيين رموز الأخطاء. لهذا السبب بالذات، تكرر ذكر مفهوم بوابة النماذج (Model Gateway) في أوساط هندسة الذكاء الاصطناعي المحلية منذ العام الماضي. باختصار: بوابة النماذج هي طبقة وسيطة تحجب الفروقات بين واجهات API للنماذج اللغوية المتعددة، وتكشف للطبقات الأعلى واجهة موحدة.
الاتصال المباشر، البناء الذاتي، ومنصات التجميع: التكلفة الهندسية للثلاثة خيارات
لنبدأ بالاتصال المباشر بـ SDK الرسمي. ثلاثة نماذج تعني ثلاث مجموعات مصادقة، وثلاث مجموعات معالجة أخطاء، وثلاث مجموعات منطق إعادة محاولة. كود العمل مليء بعبارات if-else لتحديد أي نموذج يُستخدم. وإضافة نموذج جديد تعني تعديل طبقة التوافق من جديد. حسبناها: صيانة كود التوافق للاتصال المباشر بثلاثة نماذج تستهلك نحو 15% من إجمالي جهد العمل الخلفي للمشروع. وإذا وصل عدد النماذج إلى خمسة أو أكثر، تفقد هذه النسبة السيطرة.
بوابة مبنية ذاتياً هي الخيار الثاني. الفكرة الأساسية هي كتابة طبقة وكيل (Proxy) تعيد توجيه الطلبات إلى واجهات API المختلفة. الميزة هي التحكم الكامل، والعيب هو أن عليك التعامل بنفسك مع تحويل البروتوكولات وتدوير المفاتيح وطوابير تحديد المعدل وإحصاءات الاستخدام. قدّرنا داخلياً أن بوابة مبنية ذاتياً جاهزة للإنتاج تحتاج على الأقل مهندسين اثنين لمدة ست إلى ثماني أسابيع، بالإضافة إلى صيانة مستمرة لتغييرات إصدارات واجهات API المختلفة. للفرق الصغيرة والمتوسطة، هذه الحسبة غير مجدية.
الخيار الثالث هو منصات تجميع واجهات AI API. هذه المنصات توحّد واجهات API للنماذج المتعددة وتقدم واجهة واحدة للخارج. التكلفة الهندسية الأدنى، ودورة الدمج عادة تُحسب بالأيام. استخدمنا في مشروعنا SiCore TokenWorks، وهو متوافق مع OpenAI SDK، ويكفي تغيير سطر base_url للتبديل. هنا يجب الانتباه لفخ: المنصات المختلفة تختلف في استراتيجياتها الافتراضية للمهلة وإعادة المحاولة، لذا قبل الدمج تأكد من دعم المنصة لتخصيص المهلة الزمنية، وإلا فسيتم قطع الطلبات ذات الاستجابة الطويلة التي تحدث عرضياً في الإنتاج مسبقاً على مستوى المنصة، ولن تستطيع معرفة ما إذا كان الخطأ مهلة بوابة أم مهلة نموذج.
القدرات الأربع الأساسية لبوابة النماذج
توحيد البروتوكول هو الأساس. توحيد صيغ الطلبات والاستجابات ورموز الأخطاء لدى جميع الأطراف في معيار واحد. في الوضع المثالي، تتعرف طبقة العمل العليا على صيغة واجهة واحدة فقط، وتبديل النموذج يتطلب تغيير الإعدادات لا الكود. وهذا أيضاً سبب انتشار واجهات المتوافقة مع OpenAI في الصين، إذ تدعمها سلسلة الأدوات البيئية أساساً.
استراتيجية التوجيه هي جوهر قيمة البوابة. يمكن التوجيه حسب نوع المهمة، كأن تمر الأسئلة البسيطة عبر Doubao والاستدلال المعقد عبر DeepSeek؛ أو حسب التكلفة، فأي نموذج سعره أقل حالياً يُستخدم؛ أو حسب التوافر، فعند وصول نموذج لحد المعدل يُنتقل تلقائياً إلى البديل. عند اختبارنا للتوجيه متعدد النماذج في SiCore TokenWorks، وجدنا أن استراتيجية التوزيع حسب تعقيد المهمة تخفض التكلفة الإجمالية للاستدعاءات في سيناريوهات خدمة العملاء بشكل ملحوظ، لأن كثيراً من الأسئلة البسيطة لا تحتاج لاستدعاء النموذج الأقوى في الاستدلال.
تحديد المعدل والتخفيض التدريجي وتجميع الاستخدام ضرورات بيئة الإنتاج. تحديد المعدل يجب أن يتعرف على خطأ 429 ويعيد المحاولة في طابور تلقائياً، والتخفيض التدريجي يجب أن ينتقل إلى نموذج بديل عند تعطل خدمة ما. أما تجميع الاستخدام فهو تجميع حجم الاستدعاءات واستهلاك الـ tokens والتكاليف الموزعة على عدة أطراف في مكان واحد، لتسهيل حساب التكاليف وضبط الميزانية. هذان البندان يتطلبان جهداً كبيراً إذا بُنيا ذاتياً، خاصة تجميع الاستخدام، لأن آليات الفوترة لدى الأطراف مختلفة ومنطق التسوية يجب كتابته على حدة.
التنفيذ المرحلي حسب نضج الأعمال
إذا كان المشروع في بدايته ويتصل بنموذج واحد فقط، فالاتصال المباشر بـ SDK الرسمي كافٍ، ولا داعي لبوابة تضيف طبقة ونقطة فشل إضافية. وعندما تستقر الأعمال وتحتاج لنموذج ثانٍ، فكّر في إدخال طبقة البوابة، فتكلفة التبديل آنذاك لا تزال منخفضة.
إذا كانت الأعمال متصلة بثلاثة نماذج أو أكثر وتتطلب توافراً عالياً، فأنصح بالانتقال مباشرة إلى منصة تجميع واجهات AI API، لتستعين بمصادر خارجية للتكيف والتشغيل. عند الاختيار ركّز على ثلاث نقاط: التوافق مع OpenAI SDK، ودعم تخصيص المهلة وإعادة المحاولة، ووضوح إحصاءات الاستخدام. أما البناء الذاتي للبوابة، فلا أنصح به في المراحل المبكرة من الأعمال، إلا إذا كانت هناك متطلبات امتثال خاصة أو كان لدى الفريق قدرة تشغيلية كافية.
بوابة النماذج تحل مشكلة التعقيد الهندسي لدمج نماذج متعددة، وليست مشكلة قدرات النماذج. اختيار الحل الصحيح يتيح للفريق إعادة تركيز جهده على منطق الأعمال نفسه.