فك ترميز MoE المتزامن يجعل وحدات GPU تنتظر المجموعة الأكثر ازدحامًا

إضافة وحدات GPU إلى كتلة حوسبة تخدم LLM ثم الحصول على زيادة في الإنتاجية أقل من المتوقع، مشهد مألوف في عمليات النشر الكبيرة عبر الإنترنت. ويشير Jiqizhixin إلى أن السبب في مخططات نماذج MoE مثل DeepSeek هو الانتظار. فعدة مجموعات من البطاقات تعالج طلباتها بالتوازي، لكنها تُنهي كل خطوة فك ترميز معًا عبر الاتصال بين المجموعات. تسير الخطوة «على إيقاع واحد»: ما دامت المجموعة الأكثر تحميلًا لم تنهِ حسابها، تبقى البقية متوقفة. ولا توجد في الجزء المتاح من المادة أرقام محددة، كما لا يوجد وصف للمنهج نفسه. وفيما يلي شرح لآلية المشكلة استنادًا إلى ما ورد فيها.

لماذا تستغرق الخطوة وقت أبطأ مجموعة بالضبط

في عمليات نشر نماذج MoE يُوزَّع العمل بين مجموعات من البطاقات. لكل مجموعة حصتها من الطلبات، والحمل يختلف من مجموعة إلى أخرى: ففي بعضها محادثات طويلة بسياق ثقيل، وفي بعضها الآخر ردود قصيرة. لكن فك الترميز لا يقتصر على حسابات مستقلة. ففي كل خطوة تحتاج المجموعات إلى تبادل البيانات لاجتياز طبقات النموذج، ومن ذلك توزيع الرموز (tokens) على الخبراء الموجودين على بطاقات مختلفة.

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

أين تضيع الزيادة المتوقعة

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

يُستخلص من الوصف أن للحالة الخصائص التالية:

• الوضع: خدمة عبر الإنترنت مع عدد كبير من الطلبات المتزامنة.
• البنية: نموذج MoE منشور على عدة مجموعات من البطاقات بالتوازي.
• عنق الزجاجة: خطوة فك ترميز متزامنة مع اتصال بين المجموعات.
• العَرَض: الإنتاجية تنمو أبطأ من عدد البطاقات.
• العامل الرئيسي للخسائر: اختلال توازن الحمل بين المجموعات، ما يجعل السريعة تنتظر البطيئة.

النقطة الأخيرة أستنتجها من منطق المخطط، لا من اقتباس. لكن لا يوجد تفسير آخر لعبارة «ما دامت المجموعة الأكثر انشغالًا لم تنهِ حسابها، تنتظر البقية».

ما المعروف عن الحل

يَعِد العنوان بـ«حل جديد» لمشكلة الانتظار في الاستدلال (inference). أما المقطع المتاح فيتناول صياغة المشكلة فقط. وليس معلومًا أي منهج يقترحه المؤلفون، ولا على أي نماذج وعتاد اختُبر، ولا مقدار الزيادة التي تحققت. وأي أرقام للتسريع دون النص الكامل ستكون اختلاقًا، ولذلك لا ترد هنا.

معروفة الفئة العامة من الحلول لمثل هذه المشكلات: موازنة الحمل بين المجموعات، وتوزيع الطلبات عليها بذكاء، وتداخل الحساب مع الاتصال. أما أيٌّ منها استُخدم في هذا العمل، فلا يمكن الجزم به.

الخلاصة العملية

على الفريق الذي يشغّل استدلال MoE بنفسه أن يتحقق مما يعيق التوسع فعليًا. ينبغي أولًا قياس تباين زمن الخطوة بين مجموعات البطاقات، لا الإنتاجية الإجمالية وحدها. فإذا تخلفت أبطأ مجموعة بوضوح عن المتوسط، فالوقت مبكر لشراء مزيد من وحدات GPU: إذ سيبقى جزء منها معطلًا. ثم ينبغي النظر في كيفية توزيع الطلبات على المجموعات، لأن طول السياق وعدد الطلبات النشطة يؤثران بقوة في زمن الخطوة. وبعد ذلك فقط يكون من المجدي احتساب كلفة الرمز (token) عند أعداد مختلفة من البطاقات.

يستحق النص الكامل للدراسة أن يُقرأ قبل نقل المنهج إلى بيئة الإنتاج. أما حتى الآن، فكل ما يُعرف منه هو أين يجب البحث عن الخسائر.