الشهر الماضي توليت مهمة، وهي مساعدة فريق يعمل على نظام تذاكر SaaS في بناء نموذج أولي لخدمة العملاء الذكية، كان المطلوب تشغيله خلال أسبوع واحد، مع مقارنة أفقية لجودة إجابات DeepSeek وQwen وDoubao وGPT-4o. كانت أعمالهم كلها تعمل على Tencent Cloud CVM، والحاويات تستخدم TKE، لذلك كان لا بد أن تنطلق جميع الاستدعاءات من داخل السحابة. كنت أظن في البداية أن ربط API لن يكون بهذه الصعوبة، لكن خلال أسبوع واحد، كانت المآزق أكثر مما توقعت.

أبدأ بالخلاصة: إذا كانت أعمالك على Tencent Cloud بحاجة إلى ربط أكثر من نموذج كبير واحد، فلا تكتب مباشرة مقابل SDK الرسمي لكل جهة، بل ابنِ أولاً طبقة تجميع AI API. هذا ليس كسلاً، بل هو إنقاذ للحياة. سأشرح الآن حسب ترتيب وقوعي في المآزق.

إدارة المفاتيح: لا تضع 6 مفاتيح مباشرة في متغيرات البيئة

في اليوم الأول فعلت شيئاً غبياً جداً، حيث وضعت مفاتيح المنصات الأربع كلها داخل متغيرات بيئة CVM، والكود يقرأ مباشرة من os.environ. عمل هذا دون مشاكل، لكن بعد ظهر اليوم نفسه حدثت مشكلة: أراد أحد أفراد الاختبار تبديل مفتاح Qwen لإجراء اختبار ضغط، فقمت بتعديل الإعدادات وإعادة تشغيل الحاوية، لكنني أعدت تشغيل نسخة الإنتاج أيضاً معها.

المشكلة كانت أن المفاتيح وإعدادات الأعمال مختلطة معاً، بلا إدارة مركزية. لاحقاً جمعت كل المفاتيح في خدمة إعدادات مستقلة، مع وسمها ببعدين: «المنصة + الاستخدام»، مثل deepseek-prod وqwen-test. الجهة المستدعية تحصل فقط على الاسم المنطقي، ولا تلمس المفتاح الحقيقي. بعد إنجاز هذه الخطوة، لم يكن تبديل المفتاح يتطلب لمس كود الأعمال، ولا إعادة تشغيل حاوية الأعمال.

إذا كنت لا تريد صيانة هذا النظام بنفسك، فإن استخدام منصة تجميع سيكون أسهل. مشروعنا لاحقاً استخدم token8341، حيث يمكن لمفتاح واحد استدعاء GPT-4o وClaude وGemini وDeepSeek وQwen وERNIE وDoubao وغيرها من النماذج السائدة، وتدوير المفاتيح والتحكم في الحصص يتمان على جانب المنصة، بينما تحتاج الخدمات على Tencent Cloud فقط إلى الاحتفاظ ببيان اعتماد واحد. هذا مناسب جداً لسيناريوهات اختبار المقارنة متعددة النماذج، ويوفر أربع مجموعات من منطق المصادقة.

توافق SDK: أربع جهات بأربع طرق كتابة، وتكلفة الصيانة تنفجر

في اليوم الثاني بدأت كتابة كود الاستدعاء، وهنا كان الجزء المزعج حقاً. DeepSeek وGPT-4o متوافقان مع OpenAI SDK، ويمكن التبديل بتغيير base_url، وهذا الجزء كان سلساً. لكن تسمية معلمات SDK الخاصة بـQwen كانت نظاماً آخر، ومصادقة Doubao تمر عبر توقيع AK/SK وليس Bearer Token، وواجهة ERNIE لها أيضاً تدفق مصادقة خاص بها.

الظاهرة كانت محددة جداً: كتبت دالة chat موحدة، لكنها امتلأت بشروط if، فإذا كانت platform == 'doubao' يسلك هذا الفرع، وإذا كانت elif platform == 'qwen' يسلك فرعاً آخر. وصلت الدالة إلى 200 سطر، ومع ذلك لم يرتفع معدل تغطية الاختبار.

كان الحل هو إدخال بوابة AI API لتحويل البروتوكولات. البوابة تكشف داخلياً واجهة متوافقة مع OpenAI، وتتولى خارجياً ترجمة الطلب إلى التنسيق الذي تفهمه كل جهة. بهذه الطريقة يصبح لدى كود الأعمال SDK واحد فقط، وإضافة نموذج جديد تتطلب فقط إضافة محول على جانب البوابة، دون أي تغيير على جانب الأعمال. بنينا نسخة بأنفسنا، ثم اكتشفنا أن استخدام خدمة تجميع جاهزة أسرع، فمنصات مثل token8341 تقوم بهذا أصلاً، وهي متوافقة مع OpenAI SDK، ويكفي تغيير سطر base_url للتبديل بين النماذج.

البث: صيغ SSE مختلفة فعلاً بين الجهات

في اليوم الثالث عملنا على البث، وكانت الواجهة الأمامية تحتاج إلى إظهار النص حرفاً بحرف. بروتوكول SSE نفسه قياسي، لكن بنية حقل data تختلف بين الجهات. في delta التي تعيدها عائلة OpenAI يوجد حقل content، أما Qwen فتعيد اسماً مختلفاً للحقل، وDoubao قد تدرج أحياناً حزمة نبض في منتصف البث، فتتلقى الواجهة الأمامية delta فارغاً وتُخطئ مباشرة.

الظاهرة كانت أن الواجهة الأمامية تتجمد أحياناً بلا حركة، أو يظهر فجأة فقاعة رسالة فارغة. بعد بحث طويل اكتشفنا أن السبب هو عدم تصفية حزمة النبض.

الطريقة الموحدة هي إجراء تطبيع على طبقة البوابة، بحيث تُحوَّل جميع استجابات البث من كل المنصات إلى صيغة chunk الخاصة بـOpenAI، وتُهمل حزم النبض مباشرة، فلا يتعامل جانب الأعمال إلا مع بنية واحدة. إذا لم تفعل هذا، ستكتب الواجهة الأمامية أربع مجموعات من منطق التحليل، وستبكي في كل مرة تعدّلها.

معالجة الاستثناءات: إذا انتهت مهلة جهة ما، يجب التبديل تلقائياً

في اليوم الرابع أجرينا اختبار ضغط، وحدثت مهلة متقطعة عند DeepSeek، فتجمّدت المحادثة كلها. في سيناريو مثل خدمة العملاء الذكية، إذا انتظر المستخدم ثلاث ثوانٍ دون استجابة فسيغلق الصفحة غالباً، ولا يمكن الانتظار بلا فعل.

أضفت طبقة منطق تخفيض: إذا تجاوز استدعاء النموذج الرئيسي عتبة محددة دون أن يعود، يُبدَّل تلقائياً إلى النموذج البديل، وتُسجَّل هذه الفشلة. المفتاح هنا هو أن التخفيض يجب أن يكون غير محسوس، بحيث لا يشعر المستخدم بالتبديل. في مجال توجيه النماذج الكبيرة، عادةً ما تتضمن منصات التجميع تجاوز الأعطال، وقد اختبرنا token8341 فوجدنا التبديل التلقائي فيه مستقراً نسبياً؛ فعند انتهاء مهلة النموذج الرئيسي ينتقل بصمت إلى البديل، ولا يحتاج كود الأعمال إلى كتابة منطق إعادة المحاولة.

تنبيه: لا تبدّل بشكل أعمى، بل يجب التمييز بين ما إذا كانت المشكلة مهلة شبكة أم خطأً من النموذج نفسه. الأولى يمكن التبديل فيها، أما الثانية فالتبديل فيها بلا فائدة، بل يهدر Token.

مراقبة التكلفة: إذا لم تُجمَّع استهلاكات Token، فلن تتطابق الفواتير في نهاية الشهر

في اليوم الأخير عملنا على إحصاءات التكلفة، فاكتشفنا أن فواتير المنصات الأربع أربع فواتير منفصلة، وحتى صيغها مختلفة؛ بعضها يفوتر حسب Token، وبعضها حسب عدد الاستدعاءات، ولا يمكن المقارنة الأفقية بينها إطلاقاً. سأل المدير: «أي نموذج أفضل من حيث القيمة مقابل السعر؟» فلم أستطع تقديم رقم موحد.

كان الحل هو توحيد المحاسبة على طبقة البوابة، بحيث تُسجَّل في كل استدعاء أسماء النماذج وToken الإدخال وToken الإخراج والزمن المستغرق، وتُحفظ في جدول واحد. بهذه الطريقة يمكن إخراج تقارير يومية وحسب النموذج وحسب خط الأعمال. عادةً ما تتضمن منصات التجميع لوحات استخدام مدمجة، وفي نموذج الفوترة حسب الاستخدام يصبح تجميع التكلفة أبسط بكثير. وبالمقارنة، فإن مسار الشراء بالجملة وخفض التكلفة عبر الطاقة الخضراء يجعل تكلفة Token الواحد أقل فعلاً من الشراء المباشر الرسمي، وهذا مهم جداً لسيناريوهات خدمة العملاء ذات الحجم الكبير.

بعض الخلاصات بعد أسبوع

عند ربط نماذج كبيرة بأعمال على Tencent Cloud، فإن الصعوبة لم تكن يوماً «كيف أجعل نموذجاً واحداً يعمل»، بل «كيف أجعل ستة نماذج تتصرف كشخص واحد». إدارة المفاتيح، وتوافق البروتوكولات، وتوحيد البث، وتخفيض الأعطال، وتجميع التكلفة؛ إذا لم تُنجز أي واحدة من هذه الخمس بشكل جيد، فلن يصمد النموذج الأولي أمام اختبار الضغط.

بناء طبقة تجميع هو الخيار الأفضل من حيث القيمة. سواء كتبتها بنفسك أو استخدمت خدمة تجميع AI API جاهزة، المهم ألا يواجه كود الأعمال مباشرة اختلافات ست شركات. منصات مثل SiliconFlow تركز أساساً على الحوسبة الخضراء وأولوية النماذج المحلية، ويمكن استدعاؤها مباشرة من الحاويات على Tencent Cloud، وزمن تأخير الشبكة أقل بكثير من المرور عبر وسيط خارجي، وكان هذا أحد أسباب اختيارنا لها في النهاية.

في يوم إكمال النموذج الأولي قال أحد أفراد الاختبار جملة أثرت فيّ كثيراً: «اتضح أن ربط النماذج الكبيرة ليس ربط API، بل ربط منظومة حوكمة كاملة.» وهذا صحيح.

المؤلف: Chen Jingxing

تاريخ النشر: 6 أكتوبر 2026