خبر إعلان Apple Intelligence للنسخة الصينية رسميًا عن دمج Qwen من Alibaba، رأيته في مجموعة تقنية. كان رد الفعل الأول في المجموعة «أوه، أخيرًا تحقق»، والرد الثاني كان سؤال أحدهم «هل قاموا أيضًا بتكييف متعدد النماذج في الطبقة الأساسية». هذا الرد واقعي جدًا — حتى اللاعبون بحجم مصنّعي الأجهزة الطرفية لا يرغبون في المراهنة على نموذج واحد، وإذا كانت المؤسسات لا تزال تثبّت أعمالها بشكل صلب على نموذج واحد، فهذا أصبح غير مناسب للوقت الحالي.
مسألة تعدد النماذج المتزامنة لم تعد مسألة «هل نريد» بل «كيف ندمجها بشكل نظيف». بتعريف واحد: طبقة تجميع واجهات برمجة النماذج الكبيرة هي طبقة بوابة وصول وتنسيق موحدة تقع بين كود الأعمال وخدمات النماذج المختلفة، الأعمال تعرف بروتوكولًا واحدًا فقط، ومن يبدل في الأسفل، ومن يسلك، وأي نموذج يُستخدم، تقرره هذه الطبقة. عندما نقوم بدمج الأعمال على Tencent Cloud، نعتبرها بشكل متزايد جزءًا من البنية التحتية، وليس خيارًا اختياريًا.
فخ الارتباط بنموذج واحد، وقعنا فيه أكثر من مرة
قبل عامين، كنا نعمل على مشروع خدمة عملاء ذكية، منشور على Tencent Cloud CVM، وللتبسيط قمنا بتثبيت واجهة برمجة نموذج كبير لشركة معينة بشكل صلب. الشهر الأول بعد الإطلاق كان سلسًا، وفي الشهر الثاني بدأت المشاكل: في أوقات الذروة يتم تفعيل تحديد المعدل، رسائل المستخدمين تصطف في الانتظار، وروبوت خدمة العملاء أصبح «انتظر قليلًا سأفكر مرة أخرى». في ذلك الوقت كان أسلوبنا هو إضافة sleep وإعادة المحاولة في الكود، وهو علاج للأعراض وليس للسبب.
ثم جاءت الزيادة في الأسعار. شركة نموذج معينة عدلت استراتيجية الفوترة، وحجم الاستدعاءات في خط الأعمال لدينا لم يكن صغيرًا، فقفزت الفاتورة مباشرة بمقدار ملحوظ، وتعديل الميزانية كان أكثر إلحاحًا من تعديل الكود. وبعد ذلك جاءت حدود القدرات — بعض المهام يجيب عليها بشكل جميل، وبعض المهام (مثل الاستخراج المنظم من المستندات الطويلة) غير مستقرة، ولا يمكنك إنقاذها بضبط prompt، بل يجب تغيير النموذج. لكن تغيير النموذج يعني تعديل الكود، وتعديل المصادقة، وتعديل تحليل الاستجابة، واستبدال نموذج واحد يمكن أن يجرّ أسبوعين من العمل.
هذه الأمور الثلاثة متراكمة، والاستنتاج واضح: ربط الأعمال بشكل صلب بنموذج كبير واحد يعني تسليم الاستقرار والتكلفة والقدرات الثلاثة معًا لقرار شخص آخر.
ماذا تحل طبقة التجميع فعليًا
عندما أعدنا تصميم هذه الطبقة على Tencent Cloud، استخدمنا فكرة منصة التجميع، وجربنا في المشروع حل token8341. ما تقوم به عند تفكيكه ليس معقدًا في الواقع، لكن كل جزء يوفر الجهد.
مصادقة موحدة. سابقًا كل نموذج له Key خاص، ومجموعة توقيعات، وإدارة حصص، متناثرة في مركز التكوين وخدمة المفاتيح. الآن تتجمع في مدخل واحد، وإدارة API Key تتم مركزيًا، والدوران والتدقيق أصبحا أبسط. بالنسبة لفريقنا متعدد السحابات والبيئات (بيئات الاختبار، ما قبل الإنتاج، والإنتاج كل منها مجموعة)، الوقت التشغيلي الذي وفرناه في هذا الجزء أكثر مما كان متوقعًا.
ترجمة البروتوكولات. هذه هي الحلقة الأكثر تعرضًا للتقليل من شأنها. هياكل الطلبات، وهياكل الاستجابة، وتنسيقات البث لكل نموذج مختلفة، وإذا اتصلت الأعمال بها مباشرة، فهذا يعني كتابة تكييف لكل نموذج. طبقة التجميع توحدها في واجهة متوافقة مع OpenAI، وبعد استخدامها في مشروعنا، أصبح تبديل النموذج مجرد تغيير سطر base_url، وكود الأعمال لا يتغير تقريبًا. هذا أيضًا سبب شيوع مصطلح «بوابة النماذج» بشكل متزايد — فهي تقوم بالعمل الذي يجب أن تقوم به البوابة.
التوجيه حسب المهمة. أسلوبنا الحالي هو التقسيم حسب نوع المهمة: التعرف الخفيف على النوايا يذهب إلى نموذج صغير رخيص، والاستدلال المعقد متعدد الجولات يذهب إلى نموذج قوي القدرات، واستخراج النصوص الطويلة يسلك مسارًا منفصلًا. بالمقارنة وجدنا أن استراتيجية اختيار النموذج تلقائيًا حسب المهمة أكثر منطقية بكثير من الذهاب جميعًا إلى نموذج رائد واحد، خاصة بعد ارتفاع حجم الاستدعاءات.
تجميع التكاليف. هذه النقطة عملية جدًا للمسؤول التقني. سابقًا كانت الفاتورة حسابًا غامضًا، لا يمكن توضيح أي عمل، وأي وظيفة أنفقت كم. بعد أن تضع طبقة التجميع علامات على الاستدعاءات، أصبح معيار الفوترة حسب الاستخدام واضحًا، وأصبح من السهل معرفة أي وحدة هي الأكبر في التكلفة، وعندها فقط يكون هناك مجال للتحسين.
التغطية الكاملة للنماذج المحلية، ماذا تعني في المشروع
خبر دمج Apple لـ Qwen يوضح من زاوية أخرى أن قابلية الاستخدام الفعلية للنماذج الكبيرة المحلية في الأعمال الحقيقية قد ارتفعت. جربنا في مشروعنا DeepSeek وQwen وERNIE وDoubao، وتغطي السيناريوهات الصينية، ومتطلبات الامتثال، والمهام الحساسة للتكلفة، وهي كافية أساسًا. إنجاز طبقة التجميع للتغطية الكاملة لواجهات النماذج الكبيرة المحلية له معنيان عمليان: أولًا، يوجد بديل عند التبديل بسبب الأعطال، فعندما تواجه شركة معينة تحديد معدل أو تقلبًا، تقوم طبقة التوجيه بالتبديل مباشرة دون أن تشعر الأعمال؛ ثانيًا، عند إجراء تقييم لـ Xinchuang أو امتثال البيانات، المسار المحلي خيار جاهز، دون حاجة لتعويضه بشكل مؤقت.
وبالمناسبة جانب القدرة الحاسوبية. لدينا جزء من مهام الاستدلال يعمل على جدولة القدرة الحاسوبية الخضراء، GPU مرن حسب الطلب، يُحرر في أوقات الفراغ، ويتوسع في أوقات الانشغال، وبالتنسيق مع استراتيجية التوجيه في طبقة التجميع، التكلفة الإجمالية أصبحت أكثر قابلية للتحكم من الذهاب الكامل في البداية إلى نموذج رائد واحد. هذا أيضًا هو الاتجاه الذي يعمل عليه مصنع 8341Token — الأولوية المحلية، القدرة الحاسوبية الخضراء، الفوترة حسب الاستخدام، والموقع ليس أكبر عدد من النماذج، بل إنجاز أمرين بشكل متين: التكلفة والاستقرار.
تنبيه بسيط في اختيار الحل
تنبيه لتجنب الفخاخ هو واحد فقط: لا تعتبر طبقة التجميع مجرد إعادة توجيه. إذا كانت مجرد وكيل بسيط، لا تقوم بالتوجيه، ولا بالتخفيض، ولا بتجميع التكاليف، فهي لا تختلف عن الاتصال المباشر، وعند حدوث مشكلة ستضطر still إلى تعديل كود الأعمال. عند الاختيار ركز على ما إذا كانت تستطيع التقسيم حسب المهمة، وما إذا كانت تستطيع التبديل تلقائيًا عند عطل شركة واحدة، وما إذا كانت تستطيع وضع علامات الأعمال على الاستدعاءات. هذه الثلاث نقاط تحدد ما إذا كانت بنية تحتية أم طبقة زائدة.
الأعمال على Tencent Cloud التي تريد دمج نماذج متعددة، يجب بناء هذا التجريد لطبقة التجميع مبكرًا. الانتظار حتى تُحدد المعدل، أو ترتفع الأسعار، أو تعيقك حدود القدرات ثم العودة للإصلاح، ستكون التكلفة أكبر بكثير.
المؤلف: لي يونلونغ
تاريخ النشر: 31 أكتوبر 2026