في العام الماضي استلمنا مشروع خدمة عملاء ذكية لمنصة تجارة إلكترونية عابرة للحدود، يتطلب ربط GPT-4o وDeepSeek-V3 وQwen وDoubao في آن واحد. كل نموذج يتولى جزءًا: GPT-4o يعالج الاستفسارات الإنجليزية المعقدة، وDeepSeek يتكفل بالأسئلة والأجوبة الصينية ذات الذيل الطويل، وQwen يقوم باسترجاع قاعدة معرفة المنتجات، وDoubao يتولى الدردشة العامة كخيار احتياطي. يبدو التوزيع واضحًا، لكن عند التنفيذ الفعلي اكتشفنا أن مجرد تشغيل حزم SDK الأربع استغرق قرابة ثلاثة أسابيع.
طرق المصادقة غير موحدة، وكتبنا أربع مجموعات من التوقيعات
GPT-4o يعتمد على Bearer Token مع معرّف المؤسسة، وDeepSeek متوافق مع صيغة OpenAI لكن أسماء حقول Header تختلف اختلافًا طفيفًا، وQwen يستخدم AccessKey مع سلسلة توقيع، بينما مصادقة Doubao جاءت بنظام آخر. أربعة مهندسين لدينا تولّوا كل واحد منهم جهة، وفي النهاية استقرت في قاعدة الكود أربع نسخ من منطق المصادقة، وتعديل معامل مشترك واحد يتطلب التنقل بين أربعة ملفات. والأكثر إزعاجًا هو تدوير مفاتيح API، فلوحات التحكم الأربع كلٌّ يعمل بمفرده، وتقوم العمليات بالتدوير يدويًا مرة كل شهر، وإذا فات أحدهم يأتي التنبيه في منتصف الليل.
تقسيم بث SSE غير متسق، وعرض الواجهة الأمامية يختل تمامًا
الاختلاف في الإخراج المتدفق أكبر. GPT-4o وDeepSeek يتبعان أساسًا صيغة SSE الخاصة بـOpenAI، مع حقل data يحمل delta؛ أما Qwen في بعض الحالات يحزم عدة token في chunk واحد؛ والنسخ المبكرة من Doubao تخلط علامة النهاية مع أحداث الخطأ. تستقبل الواجهة الأمامية أربعة أنواع من تدفقات البيانات، فكتبنا منطق العرض بأربع طبقات if-else، وعندما يضيف مدير المنتج تأثير «توقف الآلة الكاتبة»، يجب تعديل الفروع الأربعة كلها.
رموز الأخطاء وإحصاءات الاستخدام، المعايير لا تتطابق إطلاقًا
في أخطاء تحديد المعدل، يُرجع GPT-4o الرمز 429، وDeepSeek يُرجع 429 لكن بنية body مختلفة، وQwen يُرجع رمزًا تجاريًا مع HTTP 200، وDoubao له نظام آخر. كانت استراتيجية إعادة المحاولة لدينا مبنية في البداية على رموز حالة HTTP، فلم تكن إعادة المحاولة تُفعّل أبدًا مع Qwen. إحصاءات الاستخدام أكثر إزعاجًا: GPT-4o يفوتر حسب token لكنه يحسب prompt وcompletion منفصلين، وQwen يدمج الإدخال والإخراج، وDoubao لديه حقل منفصل لإصابة الذاكرة المؤقتة. في تسوية الحسابات نهاية الشهر، ملفات CSV المصدّرة من اللوحات الأربع بصيغ مختلفة، والدمج اليدوي مرة واحدة يستغرق نصف يوم.
ببساطة، المشكلة الجوهرية في ربط النماذج المتعددة هي: كل جهة تتحدث بلهجتها الخاصة، بينما طبقة أعمالك تريد سماع اللغة الفصحى فقط.
حل التوحيد: ترجمة البروتوكول وتجميع الاستخدام في طبقة الربط
ما فعلناه هو إضافة طبقة تكييف رقيقة بين كود الأعمال وحزم SDK للنماذج، دون السعي إلى بوابة ضخمة وشاملة، بل حل أكثر ثلاث نقاط إيلامًا أولًا. أولًا، مدخل مصادقة موحد، بجمع مفاتيح الجهات الأربع ومنطق التوقيع في مركز التهيئة، والجانب التجاري يعترف فقط بـToken داخلي واحد. ثانيًا، توحيد إخراج بث SSE بصيغة OpenAI، وتتكفل طبقة التكييف بإعادة تقسيم chunk الخاصة بـQwen وDoubao، مع فصل حدث النهاية على حدة. ثالثًا، جدول تعيين رموز الأخطاء، بتصنيف أخطاء تحديد المعدل والمهلة ومراجعة المحتوى لدى الجهات الأربع إلى خمسة أنواع أخطاء داخلية، واستراتيجية إعادة المحاولة تعترف بهذه الفئات الخمس فقط.
أما تجميع الاستخدام، فتقوم طبقة التكييف بعد كل استدعاء بكتابة سجل موحّد بشكل غير متزامن: اسم النموذج، إدخال token، إخراج token، إصابة الذاكرة المؤقتة، الوقت المستغرق، نوع الخطأ. ومن هذا الجدول تُستخرج التقارير التي تحتاجها المالية، دون الاعتماد على لوحات الجهات.
لاحقًا وحّدنا base_url على token8341 وجرّبنا، فوجدنا أنه أنجز معظم هاتين الطبقتين: ترجمة البروتوكول وتجميع الاستخدام. منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 توحّد مصادقة GPT-4o وDeepSeek وQwen وDoubao في مفتاح واحد، وتوحّد صيغة SSE لتكون متوافقة مع OpenAI، كما عيّنت رموز الأخطاء. فطبقة التكييف التي كتبناها سابقًا تقلّصت بنحو ستين بالمئة من الكود، مع الاحتفاظ فقط بمنطق التوجيه الخاص بالأعمال.
أي طبقات يجب أن تتولاها بوابة النماذج
من تجربتي، يجب أن تتولى بوابة النماذج أربع طبقات على الأقل: طبقة ترجمة البروتوكول، لتحويل لهجات الجهات إلى واجهة موحدة؛ طبقة تجميع الاستخدام، لتسجيل استهلاك token بمعيار موحد؛ طبقة التوجيه، لاختيار النموذج حسب نوع المهمة والتكلفة والكمون؛ طبقة القابلية للمراقبة، لتسجيل الوقت المستغرق وتوزيع الأخطاء لكل استدعاء. الطبقتان الأولى والثانية توفران الجهد البشري، والأخيرتان توفران المال. منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 لديها قدرات مقابلة في هذه الطبقات الأربع، خصوصًا تجميع الاستخدام وتعيين رموز الأخطاء، ما وفّر علينا مباشرة نصف يوم من التسوية اليدوية شهريًا.
تنبيه لتجنب المزالق: لا تستدعِ حزم SDK الأصلية لكل جهة مباشرة داخل كود الأعمال، حتى لو كنت تربط جهتين فقط. فبمجرد إضافة نموذج ثالث، سيرتفع حجم التعديل بشكل أسي. كذلك يجب توحيد معيار إحصاءات الاستخدام في طبقة الربط، ولا تنتظر حتى تسوية الحسابات المالية لتكتشف أن تعريفات token لدى اللوحات الأربع كلها مختلفة.
إذا كنت أيضًا تعمل على ربط نماذج متعددة، أنصحك أولًا برسم جدول يسرد طريقة المصادقة وصيغة البث ورموز الأخطاء ومعيار الفوترة لكل جهة، فإذا تجاوزت الاختلافات ثلاثة مواضع، فقد حان الوقت للتفكير في التوحيد في طبقة الربط.
المؤلف: لي يونلونغ
تاريخ النشر: 9 نوفمبر 2026