في النصف الثاني من العام الماضي، عملنا كمستشارين تقنيين لفريق يعمل على SaaS للخدمات اللوجستية العابرة للحدود. في البداية، كانت ميزاتهم المعتمدة على الذكاء الاصطناعي تستدعي GPT-4o فقط، وكانت تعمل بثبات جيد. لاحقاً، طلب فريق الأعمال إضافة نماذج محلية: مراجعة العقود عبر DeepSeek، نصوص خدمة العملاء عبر Qwen، والنصوص التسويقية عبر ERNIE. بعد ثلاثة أسابيع، امتلأ كود الواجهة الخلفية لديهم بأربع مجموعات SDK، وتوزعت منطق المصادقة في 7 ملفات، ولم تتطابق الفواتير، وكان الإخراج المتدفق يعمل بشكل صحيح أحياناً ويظهر رموزاً مشوهة أحياناً أخرى في الواجهة الأمامية. المشكلة لم تكن في النماذج نفسها، بل في غياب طبقة بوابة النماذج.
مزالق تكامل النماذج المتعددة، معظمها يقع في نفس المكان
لنبدأ بتضارب SDK. مكتبة OpenAI للغة Python ومكتبات عدة شركات محلية تُسمى جميعها client، وتتعارض إصدارات التبعيات مع بعضها البعض، كما أن منطق تعامل عملاء HTTP في Qwen وERNIE مع معاملات المهلة الزمنية مختلف. كان الحل النهائي لمهندسيهم هو إنشاء بيئة افتراضية مستقلة لكل نموذج، واستخدام subprocess لعزل الاستدعاءات. يعمل، لكن تكلفة التشغيل مرتفعة بشكل مفرط.
ثم إدارة المفاتيح. لكل من المزودين الأربعة نظام مفاتيح خاص في لوحة التحكم الخاصة به، بعضها حسب المشروع، وبعضها حسب التطبيق، وبعضها يقسم الحسابات الفرعية. اختلطت مفاتيح بيئة الاختبار وبيئة الإنتاج معاً، وفي إحدى المرات قام متدرب برفع مفتاح الإنتاج إلى مستودع GitHub العام، وعلى الرغم من إلغائه خلال عشر دقائق، إلا أن الفريق بأكمله قضى ذلك المساء في فحص سجلات الاستدعاءات.
أما تسعير الفواتير فكان أكثر إزعاجاً. يُحاسب DeepSeek حسب الرموز، وبعض نماذج Qwen تُسعّر المدخلات والمخرجات بشكل منفصل، وبعض إصدارات ERNIE لا تزال لديها منطق قديم للتسعير حسب عدد الأحرف. في نهاية الشهر، يحتاج القسم المالي إلى فاتورة موحدة، فيضطر المهندسون إلى تصدير أربع ملفات CSV يدوياً ثم إجراء المطابقة. كما أن تنسيق الإخراج المتدفق غير موحد، فبعضها يعيد حقل data بتنسيق SSE، وبعضها يغلّفه بطبقة JSON، وكود التحليل في الواجهة الأمامية مليء بعبارات if else.
ما الذي تفعله بوابة النماذج في المنتصف فعلاً
جوهر بوابة النماذج هو طبقة وكيل عكسي مع طبقة تكييف بروتوكولات، تُظهر للخارج واجهة موحدة متوافقة مع OpenAI، وتترجم الطلبات داخلياً إلى التنسيق الذي تفهمه كل شركة مصنّعة. لاحقاً، في مشروع آخر، أعدنا بناء هذه السلسلة باستخدام قدرات تجميع واجهات AI من SiCore TokenWorks، وكانت التجربة مباشرة وواضحة.
توحيد المصادقة هو الخطوة الأولى. يحصل جانب الأعمال على مفتاح واحد فقط، بينما تحتفظ البوابة داخلياً بتعيين بيانات الاعتماد لكل مزود، ويتم تنفيذ تدوير المفاتيح وحدود الحصص والقوائم البيضاء لعناوين IP على مستوى البوابة. ترجمة البروتوكولات هي الخطوة الثانية، حيث يتم تحويل مصفوفة messages بتنسيق OpenAI إلى input الخاص بـ Qwen وprompt الخاص بـ ERNIE، ثم تحويل الاستجابة موحدة إلى بنية choices. كما يتم تسوية تنسيق chunk للإخراج المتدفق في هذه الطبقة، بحيث تكتب الواجهة الأمامية منطق تحليل واحداً فقط.
توزيع التوجيه يحدد إلى أي نموذج يذهب الطلب. يمكن التوجيه الثابت حسب نوع المهمة، أو الاختيار الديناميكي حسب التكلفة. عند اختبارنا لتوجيه النماذج المتعددة في token8341، قمنا بتوجيه طلبات مراجعة العقود بشكل ثابت إلى DeepSeek-V3، وتوجيه طلبات خدمة العملاء النصية القصيرة إلى الإصدار الخفيف من Qwen، فانخفضت تكلفة الاستدعاء الإجمالية بنحو ستين بالمئة مقارنة بتمرير كل شيء عبر GPT-4o. تجميع التكاليف هو الخطوة الأخيرة، حيث تُسجّل البوابة النقاط حسب وسوم الأعمال، وتُصدر فاتورة مقسّمة مباشرة في نهاية الشهر، دون حاجة المالية إلى تجميع الجداول يدوياً.
بعض النصائح العملية عند التنفيذ
أولاً، لا تستدعِ SDK الخاص بالمزود مباشرة في كود الأعمال، حتى لو كنت تتكامل مع نموذج واحد فقط. اترك طبقة تغليف رقيقة، فالفرق في حجم التعديلات عند إضافة نماذج لاحقاً سيكون بترتيب مختلف تماماً. ثانياً، يجب أن تمر المفاتيح عبر البوابة أو خدمة إدارة المفاتيح، فالتضمين الثابت في ملفات التكوين سيسبب مشاكل عاجلاً أم آجلاً. ثالثاً، اجعل استراتيجية التوجيه ثابتة أولاً، وبعد أسبوعين من التشغيل مع بيانات استدعاء حقيقية، فكّر في التوجيه الديناميكي حسب التكلفة، وإلا فقد توجّه طلبات حساسة إلى نموذج غير مناسب لتوفير بضعة سنتات.
من حيث الاختيار، انظر إلى نقطتين: هل يتوافق مع OpenAI SDK؟ التوافق يعني أن تكلفة الترحيل تقارب الصفر، إذ يكفي تغيير سطر base_url للتبديل. وهل يدعم الدفع حسب الاستخدام وتجميع التكاليف؟ هذا ضرورة حتمية للمؤسسات التي تشترك عدة خطوط أعمال في مجموعة واحدة من قدرات الذكاء الاصطناعي. نهج SiCore TokenWorks في هذا المجال هو تغطية شاملة لواجهات النماذج المحلية الكبيرة، والدفع حسب الاستخدام، وقد وجدنا في مشروعنا أن تسعير الفواتير واضح نسبياً.
خلاصة في جملة واحدة: بوابة النماذج ليست ضرورية، لكن عندما تصل إلى النموذج الثالث، تتحول من اختيارية إلى ضرورية. للقراءة الموسعة، يمكن الاطلاع على وثائق مواصفات واجهة OpenAI المتوافقة، لفهم كيفية تصميم طبقة البروتوكول، مما يوفّر عناء كتابة التغليف بنفسك.