كمون أقل وإنتاجية أعلى مع نشر DeepSeek المتعدد العقد

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

أثبتت نماذج مزيج الخبراء (MoE) مثل DeepSeek-V3/R1 مؤخرًا قدرات نموذجية ممتازة وكفاءة تشغيلية عالية. على سبيل المثال، يحتوي نموذج DeepSeek-V3/R1 على 671 مليار معلمة إجمالاً، ولكن كل رمز يستخدم 37 مليار معلمة فقط أثناء الاستدلال. تمثل هذه البنية للنموذج تحديات وفرصًا لأنظمة الاستدلال.

توضح هذه المقالة أنه، على عكس الأنظمة التقليدية، يمكن لنماذج مزيج الخبراء (MoE) مثل DeepSeek-V3/R1 تحقيق إنتاجية أعلى وكمون أقل في نفس الوقت عند استخدام المزيد من وحدات معالجة الرسومات في عمليات النشر عبر عقد متعددة في معظم السيناريوهات.

النشر بعقدة واحدة عبر NVLink، مع توزيع الانتباه وحساب الخبراء عبر وحدات معالجة الرسوميات.

النشر متعدد العقد عبر InfiniBand، مع ربط مجموعات وحدات معالجة الرسوميات داخل العقد وعبرها.

نظرًا للعدد الكبير من الخبراء الصغار الذين يحتوي عليهم النموذج، يجب توزيع عمليات النشر عبر أجهزة متعددة. لقد نظرنا في كل من عمليات النشر على عقدة واحدة باستخدام عقدة واحدة تحتوي على 8 وحدات معالجة رسومات H200 وعمليات النشر على عقد متعددة باستخدام 8 وحدات معالجة رسومات H100.

تستفيد كل من بنيتي النشر من التوازي المبياني، ويتم تنسيق ذلك من خلال جدول الطلبات الداخلي الخاص بنا. يتضمن تنفيذ التوازي المبياني إطلاق عدة مثيلات لمحرك الاستدلال، يعمل كل منها بشكل مستقل لخدمة الطلبات والحفاظ عليها. يتولى جدول الطلبات، الذي يتفاعل مع المحرك من خلال GRPC، مسؤولية توزيع الطلبات بالتساوي قدر الإمكان، مع تسهيل إعادة استخدام التخزين المؤقت للقيم المفتاحية (KV)، وإرسال الطلبات ذات البادئة المتطابقة جزئيًا إلى الخوادم التي تحتوي على ذاكرة التخزين المؤقت. لا تمتد مثيلات المحرك عبر عقد متعددة. ويمكنها اختياريًا استخدام التوازي الموتري لتوزيع الانتباه عبر أجهزة متعددة. وترتبط المثيلات ببعضها البعض عبر NVLink في حالة العقدة الواحدة أو InfiniBand في حالة العقد المتعددة، لتوزيع وجمع الخبراء.

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

لنشر محرك الخدمة، نقوم بإطلاق حاوية واحدة (pod) لكل عقدة تستضيف مثيلات محرك متعددة. تقع على عاتق PyTorch مسؤولية إعداد الاتصال الموزع والتفاوض بشأن تهيئة NVSHMEM. للاتصال، نعتمد على حواض (kernels) CUDA مخصصة موصوفة في مقال سابق على المدونة. يُعد تنفيذ النشر المتطابق متطابقًا تقريبًا، حيث يختار النموذج الحواض الصحيحة للاستخدام بناءً على البنية التي تطبق توازي الخبراء.

قبل الغوص في مقارنات الأداء لدينا، من الضروري فهم استراتيجيات التوازي الرئيسية التي تجعل نشر نماذج مزيج الخبراء الهائلة مثل DeepSeek-V3/R1 أمرًا ممكنًا.

في استدلال النماذج اللغوية الكبيرة، يُستخدم التوازي الموتري عادةً لتقليل استخدام الذاكرة والحساب لكل وحدة معالجة رسومات، مما يقلل بالتالي من الكمون. عادةً، يمكننا توزيع إسقاطات Linear في طبقات الانتباه وطبقات شبكة البارزين (MLP) على طول أبعاد الصفوف أو الأعمدة، وتوزيع عمليات الانتباه على طول بعد رأس الانتباه.

مع التوازي الموتري، لا تحتوي بنية Llama-3 على أي حسابات مكررة لعمليات إسقاط Linear والانتباه عبر وحدات معالجة الرسومات، وهي طريقة توزيع مثالية. ومع ذلك، في نماذج DeepSeek-V3/R1، لا يمكن للتوازي الموتري تحقيق ذلك.

تستخدم نماذج DeepSeek-V3/R1 الانتباه متعدد الكامنة (MLA). تستخدم طبقة الانتباه متعدد الكامنة (MLA) أولاً إسقاط Linear kv_a_proj لحساب المتجه الكامن، ثم تستخدم إسقاط Linear آخر kv_b_proj لتحويله إلى مساحة كل رأس انتباه. وبما أن جميع رؤوس الانتباه تشترك في نفس المتجه الكامن، فلا يمكن للتوازي الموتري توزيع المتجه الكامن، لذا تحتاج جميع رتب التوازي الموتري إلى تكرار معاملات وحسابات kv_a_proj و kv_b_proj. وبالمثل، نظرًا لأن الانتباه متعدد الكامنة يخزن المتجه الكامن في ذاكرة التخزين المؤقت للقيم المفتاحية (KV Cache)، فإن كل رتبة من رتب التوازي الموتري تخزن نسخة مطابقة من ذاكرة التخزين المؤقت للقيم المفتاحية (KV Cache).

على الرغم من بعض التكرار في الانتباه متعدد الكامنة (MLA)، فإن التوازي الموتري لا يزال يوفر تخفيضًا جزئيًا في المتطلبات الحسابية، مما يجعله قيّمًا للسيناريوهات التي تتطلب سرعات إخراج عالية.

تستبدل نماذج DeepSeek-V3/R1 طبقات شبكة البارزين (MLP) بطبقات مزيج الخبراء (MoE). تحتوي طبقة مزيج الخبراء (MoE) على 256 خبيرًا موجهًا وخبيرًا مشتركًا واحدًا. يتم توجيه كل رمز إلى 8 خبراء موجهين مختلفين للحساب، ويتم جمع النتائج بوزن ترجيحي. يحسب كل رمز أيضًا في الخبير المشترك، ويتم إضافة النتيجة إلى النتيجة الواردة من الخبراء الموجهين.

يعمل توازي الخبراء (EP) النهج النموذجي للتوزيع لطبقات مزيج الخبراء (MoE)، حيث تدير كل وحدة معالجة رسومات 256 / EP من الخبراء الموجهين مع الاحتفاظ بنخة من الخبير المشترك. مقارنة بالتوازي الموتري، تتمثل ميزة توازي الخبراء (EP) في قدرته على توزيع الحوسبة عبر المزيد من وحدات معالجة الرسومات، مما يقلل من استخدام الحوسبة والذاكرة لكل وحدة معالجة رسومات.

قبل إجراء حسابات الخبراء، تحتاج جميع وحدات معالجة الرسومات إلى إجراء اتصال AllToAll لتوجيه الرموز إلى وحدات معالجة الرسومات التي يتواجد فيها الخبراء المقابلون؛ وبعد حسابات الخبراء، يلزم إجراء اتصال AllToAll آخر لجمع نتائج الحوسبة من وحدات معالجة الرسومات المختلفة وإجراء الجمع الموزون. لقد نفذنا نسخة محسنة من هذين الحاضين (kernels) لاتصال AllToAll، وهما Dispatch وCombine، باستخدام NVSHMEM. في منشور المدونة السابق، شرحنا بالتفصيل عملية التنفيذ، وقد تم إتاحة حواضنا كمصدر مفتوح على GitHub.

مع توازي الخبراء (EP)، يمكننا توزيع حوسبة مزيج الخبراء (MoE) عبر 128 وحدة معالجة رسومات أو حتى أكثر. ومع ذلك، لا يمكن تجزئة حوسبة الانتباه متعدد الكامنة (MLA) باستخدام توازي الخبراء (EP). في هذه المرحلة، يمكننا إدخال التوازي المبياني (DP). تمتلك كل مجموعة توازي مبياني (DP Group) نسخة كاملة من طبقة الانتباه متعدد الكامنة (MLA). تقبل كل مجموعة توازي مبياني (DP Group) مدخلات مختلفة وتجري حساب طبقة الانتباه متعدد الكامنة (MLA) بشكل مستقل.

يمكن الجمع بين التوازي المبياني (DP) والتوازي الموتري (TP) لطبقة الانتباه متعدد الكامنة (MLA)، حيث يتم تقسيم مجموعة توازي مبياني (DP Group) واحدة إلى عدة رتب توازي موتري (TP Ranks). ويمكن الجمع بين توازي الخبراء (EP) لطبقة مزيج الخبراء (MoE) والتوازي المبياني/الموتري (DP/TP) لطبقة الانتباه متعدد الكامنة (MLA). EP = DP * TP. على سبيل المثال، على 16 جهازًا، يعني التكوين EP128 DP32 TP4 توزيع الخبراء الموجهين عبر 128 وحدة معالجة رسومات، مع تشكيل كل 4 وحدات معالجة رسومات لمجموعة توازي مبياني (DP Group)، ليصبح إجمالي مجموعات التوازي المبياني المستقلة 32 مجموعة.

تتجاوز معاملات DeepSeek البالغة 671 مليار سعة ذاكرة جهاز واحد بـ 8 وحدات معالجة رسومات H100 (80 جيجابايت * 8)، ولكن جهازًا واحدًا بـ 8 وحدات معالجة رسومات H200 يمكنه استيعاب النموذج بأكمله بالكامل (141 جيجابايت * 8). باستخدام تكوين EP8 DP8 TP1، يستخدم النموذج حوالي 100 جيجابايت من الذاكرة لكل وحدة معالجة رسومات، مما يترك ما يقريبًا 40 جيجابايت لذاكرة التخزين المؤقت للقيم المفتاحية (KV Cache) والنتائج الوسيطة الأخرى. يشغل الرمز الواحد 70,272 بايت من ذاكرة التخزين المؤقت للقيم المفتاحية (KV Cache). بافتراض أن كل طلب يحتوي على 5,000 رمز، يمكن لكل وحدة معالجة رسومات استيعاب ما يقريبًا 100 طلب.

أردنا فهم اختلافات الأداء بين عمليات النشر على عقدة واحدة وعقد متعددة في ظل تكوينات مختلفة. استخدمنا جهاز H200 واحدًا لنشر عقدة واحدة وما يصل إلى 16 جهاز H100 لنشر عقد متعددة. لكل بيئة نشر، استخدمنا مجموعات من التوازي الموتري TP 1، 2، 4، 8، وأحجام دفعات لكل وحدة معالجة رسومات تبلغ 1، 2، 4، 8، 16، 32، 64، 128. افترضنا أن كل طلب يحتوي على طول ذاكرة تخزين مؤقت للقيم المفتاحية (KV Cache) يبلغ 5,000 رمز. وافترضنا أيضًا أن التنبؤ متعدد الرموز (MTP) يتنبأ برمز إضافي واحد (أي أن طول الاستعلام لكل طلب هو 2)، وافترضنا بحذر معدل قبول بنسبة 60%. يوضح الشكل أدناه الإنتاجية وسرعة الإخراج للتكوينات المختلفة.

حدود باريتو بين الكمون والإنتاجية لتكوينات الخبراء المتوازية المختلفة.

يمثل المحور الأفقي سرعة الإخراج لكل طلب بالرمز/ثانية. ويستخدم المحور الرأسي مقياسًا لوغاريتميًا لإظهار الإنتاجية لكل جهاز بالرمز/ثانية. لقد حددنا حد باريتو (Pareto Frontier) لكل تكوين توازي خبراء (EP) بخطوط ملونة مختلفة.

في السيناريوهات ذات متطلبات سرعة الإخراج العالية للغاية، يمكن أن يؤدي استخدام نشر عقدة واحدة EP8 DP1 TP8 مع حجم دفعة قدره 1 إلى تحقيق سرعة إخراج تتجاوز 100 رمز/ثانية، ولكن الإنتاجية منخفضة للغاية، وتكافئ سرعة الإخراج. في هذا السيناريو، يحتوي الدفعة بأكملها على رمزين فقط، والتي يمكن توجيهها إلى ما لا يزيد عن 2*8=16 خبيرًا، مما ينشط إجمالي ما لا يزيد عن 57 مليار معلمة.

في نطاق سرعة الإخراج من 80 إلى 40 رمزًا/ثانية، مع زيادة الإنتاجية، تنخفض سرعة الإخراج بشكل كبير. في المقابل، تمتلك EP128 إنتاجية أعلى بحوالي 5 مرات من نشر العقدة الواحدة عند نفس سرعة الإخراج.

يمكن تفسير هذه الظاهرة من خلال فحص كيفية سلوك عمليات النشر على عقدة واحدة: ترتبط زيادة حجم الدفعة ارتباطًا مباشرًا بزيادة الخبراء المنشطين. عندما يكون حجم الدفعة 1، يكون متوسط عدد الخبراء المنشطين لكل وحدة معالجة رسومات هو 2 * 8 / 8 = 2. عندما تكون الدفعة كبيرة بما يكفي، يتم تنشيط جميع الخبراء، مما يعني أن كل وحدة معالجة رسومات تنشط 256 / 8 = 32 خبيرًا. تعني تنشيط المزيد من الخبراء أن وحدة معالجة الرسومات تحتاج إلى قراءة المزيد من المعلمات من الذاكرة، مما يزيد بشكل كبير من ضغط نطاق ترددي الذاكرة. نظرًا لأن مرحلة فك التشفير في النماذج اللغوية الكبيرة تعاني بالفعل من اختناق في نطاق ترددي الذاكرة وليس أداء الحوسبة، فإن زيادة حجم الدفعة في نشر العقدة الواحدة تقلل بشكل كبير من سرعة الإخراج.

تكشف مقارنة تكوينات النشر الأربعة لعقد متعددة (EP16، EP32، EP64، وEP128) أن قيم EP الأعلى تحول حد باريتو (Pareto Frontier) نحو تحسينات متزامنة في الإنتاجية وسرعة الإخراج.

يعني استخدام رقم EP أعلى تخصيص عدد أقل من الخبراء لكل وحدة معالجة رسومات. على سبيل المثال، تعني EP128 أن كل وحدة معالجة رسومات مسؤولة عن 256 / 128 = 2 من الخبراء، وبالتالي يتم تقليل ضغط نطاق ترددي الذاكرة بشكل كبير. وبعبارة أخرى، باستخدام رقم EP أكبر، نحصل بفعالية على نطاق ترددي ذاكرة أكبر. عندما يكون حجم الدفعة لكل وحدة معالجة رسومات أقل من 64، فإن زيادة حجم الدفعة لا تؤثر بشكل كبير على سرعة حوسبة الخبراء لأن زيادة عدد المدخلات لا تزيد بشكل كبير من ضغط نطاق ترددي الذاكرة. لذلك، نلاحظ أنه عند استخدام EP128، لا تؤثر زيادة حجم الدفعة على سرعة الإخراج بشكل كبير.

ومن المثير للاهتمام، أنه في أحجام الدفعات الأكبر (64 طلبًا لكل وحدة معالجة رسومات)، لاحظنا ظاهرة جديدة: إنتاجية نشر العقدة الواحدة أعلى قليلاً من نشر العقد المتعددة. يعود جزء من السبب إلى أن NVLink داخل العقدة له نطاق ترددي أعلى من InfiniBand بين العقد. ويعود جزء آخر إلى قيود في تنفيذنا. سنقوم بتحليل هذه الظاهرة بمزيد من التفصيل لاحقًا.

نظرًا لقيود سعة الذاكرة، لا يمكن لتكوين EP8 DP8 TP1 الوصول إلى حجم دفعة يبلغ 128 لكل وحدة معالجة رسومات، لذا يظل نشر العقد المتعددة خيارًا أفضل في السيناريوهات التي تسعى إلى إنتاجية أعلى.

كما تم تقديمه باختصار أعلاه فيما يتعلق بتوازي الخبراء، تظل وحدات معالجة الرسومات خاملة أثناء الاتصال في طبقة مزيج الخبراء (MoE). لتقليل الهدر وتقليل الكمون، نحتاج إلى العثور على مهام حوسبة مستقلة عن البيانات لملء هذا الوقت الخامل.

جداول الحساب والاتصال من دون تداخل، وتداخل الإرسال، وخط أنابيب من خمس مراحل.

يوضح الجزء العلوي من الشكل أعلاه تدفق الحوسبة لطبقة واحدة. تعتمد حوسبة مزيج الخبراء (MoE) على Dispatch، وتعتمد حوسبة الطبقة التالية على نتيجة Combine.

نحن نضع الخبير المشترك على كل وحدة معالجة رسومات. وبهذه الطريقة، لا تتطلب حوسبة الخبير المشترك اتصال AllToAll. لذلك، يمكننا إجراء حوسبة الخبير المشترك مباشرة بعد Dispatch Send، ثم انتظار اكتمال Dispatch Recv. نطلق على مخطط التداخل هذا اسم "تداخل الإرسال" (Dispatch Overlap).

يوفر تداخل الإرسال (Dispatch Overlap) تنفيذًا مباشرًا وقابلية تطبيق واسعة النطاق. تخفي هذه التقنية وقت حوسبة الخبير المشترك عبر جميع أحجام EP وأحجام الدفعات.

لزيادة تداخل الحوسبة والاتصالات بشكل أكبر، استخدمنا الدفعات المصغرة (micro batching) المذكورة في تقرير DeepSeek التقني لكسر تبعية البيانات. كما هو موضح في الجزء السفلي من الشكل، قمنا بتقسيم حوسبة طبقة Transformer واحدة إلى 5 مراحل:

المرحلة 1: InputNorm، QKVProj، AppendKV، BMM

المرحلة 2: BMM، Attn، OProj، PostNorm، Gate

المرحلة 3: الإرسال والاستلام، خبير مشترك

المرحلة 4: Dispatch Recv، MoE، Combine Send

المرحلة 5: Combine Recv

في طبقات Transformer الكثيفة الثلاث الأولى، نستخدم الدفعة بأكملها. في طبقات Transformer مزيج الخبراء (MoE) الـ 58 التالية، نقوم بتقسيم الدفعة بالتساوي إلى دفعتين مصغرتين. تنفذ الدفعتان المصغرتان بالتناوب، بإزاحة قدرها 3 مراحل. نظرًا لعدم وجود تبعية بيانات بين هاتين الدفعتين المصغرتين، يمكننا التبديل إلى حوسبة دفعة مصغرة أخرى بعد Dispatch Send وبعد Combine Send.

بعد ذلك، نقارن تأثيرات التداخل من خلال تجربة، فضلاً عن مقارنة اختلافات الأداء بين نشر العقدة الواحدة EP8 ونشر العقد المتعددة EP128. لسهولة المقارنة، استخدمنا وحدات معالجة الرسومات H100 للتجربة التالية. استخدمنا TP1، وحجم دفعة قدره 128 لكل وحدة معالجة رسومات، وطول استعلام قدره 2 لكل طلب، وطول ذاكرة تخزين مؤقت للقيم المفتاحية (KV Cache) يبلغ 5000.

كمون الطبقة حسب النواة للتكوينات المتوازية للخبراء المتقارنة وتلك ذات التداخل.

يوضح الشكل أعلاه إجمالي الوقت المستغرق في طبقة Transformer مزيج الخبراء (MoE) واحدة ونسبة الكمون بأنواع مختلفة من الحواض (kernels). باستثناء Dispatch وCombine وGroupGEMM، يجب أن يكون وقت تنفيذ الحواض الأخرى متساويًا في سلسلتي EP8 وEP128 NoOverlap وEP128 DispatchOverlap لأن حجم الدفعة هو نفسه.

دعنا نقارن أولاً تأثيرات طرق التداخل الثلاث. استغرقت NoOverlap إجمالي 2667 ميكروثانية، واستغرقت DispatchOverlap 2651 ميكروثانية، مما يوفر 16 ميكروثانية أو 0.6% فقط. أظهرت الدفعات المصغرة (MicroBatch) تحسنًا كبيرًا للغاية، حيث استغرقت 1896 ميكروثانية، وهو تسريع بنسبة 29%. تم تقليل وقت Dispatch وCombine بشكل كبير. انخفض Dispatch من 593 ميكروثانية إلى 367 ميكروثانية، وCombine من 1012 ميكروثانية إلى 237 ميكروثانية.

لاحظ أنه بالنسبة لحواض الحوسبة، فإن تقسيم دفعة بحجم 128 إلى دفعتين بحجم 64 يزيّد إجمالي وقت التنفيذ. لذلك، على الرغم من انخفاض الوقت المستغرق في الاتصال بمقدار 1001 ميكروثانية، إلا أن الوقت الإجمالي انخفض بمقدار 771 ميكروثانية فقط. سنشرح السبب باستخدام نموذج Roofline في القسم التالي.

لهذا السبب، لا تحسن الدفعات المصغرة الأداء دائمًا.

التغيرات في سرعة الإخراج والإنتاجية لكل عقدة مع التجزئة الدقيقة للدفعات، مرسومة مقابل حجم الدفعة لكل وحدة معالجة رسومية.

يوضح الشكل أعلاه تحسن أداء الدفعات المصغرة (Microbatch) مقارنة بـ DispatchOverlap لأحجام الدفعات 4-128. عندما يكون حجم الدفعة أقل من 32، تقلل الدفعات المصغرة الأداء بنسبة 5%-40%. عندما يكون حجم الدفعة أكبر من أو يساوي 32، يمكن للدفعات المصغرة تحسين الأداء بنسبة 10%-35%.

دعنا نعود إلى الشكل السابق ونقارن بين EP8 وEP128 Microbatch. استغرقت EP8 إجمالي 1802 ميكروثانية، وهي أقل بقليل من 1896 ميكروثانية لـ EP128. بغض النظر عن وقت تنفيذ الحواض المتزايد الناتج عن الدفعات المصغرة (Microbatch) المذكور أعلاه، فإن الاختلافات الرئيسية هي في GroupGEMM المستخدم لحوسبة مزيج الخبراء (MoE)، وحواض الاتصال الاثنين، Dispatch وCombine.

استغرقت GroupGEMM الخاصة بـ EP8 نحو 555 ميكروثانية، بينما استغرقت GroupGEMM الخاصة بـ EP128 نحو 270 ميكروثانية، بانخفاض النصف. هذه هي الميزة الأساسية لنشر العقد المتعددة.

لسوء الحظ، زاد الوقت المستغرق في الاتصال بمقدار 213 ميكروثانية، مما عوّض بشكل كبير ميزة GroupGEMM. في اختبارات الأداء المنفصلة لحواض الاتصال الخاصة بنا، وجدنا أنها لا تستطيع تحقيق سوى نصف نطاق ترددي Infiniband. سنستمر في تحسين حواض الاتصال الخاصة بنا.

حاض آخر يتأخر بشكل كبير وهو GEMM. زادت الدفعات المصغرة وقت GEMM بمقدار 95 ميكروثانية. سنقوم بتحليل GEMM بمزيد من العمق في قسم Roofline أدناه. نعتقد أن تنفيذ GEMM الحالي لم يحقق الأداء الأمثل بعد.

يُعد نموذج Roofline أداة جيدة لتحليل أداء الحواض. محوره الأفقي هو الكثافة الحسابية، وهي نسبة العمليات العائمة (FLOP) إلى بايتات إدخال/إخراج الذاكرة. يمكن حساب قيمة المحور الأفقي مباشرة من دلالات الحاض. يمثل المحور الرأسي الأداء المحقق، والذي يُحسب عن طريق قسمة العمليات العائمة على كمون الاختبار القياسي.

يتم تحديد الحد الأعلى النظري لأداء الحاض مباشرة بواسطة مواصفات وحدة معالجة الرسومات. يبلغ أداء H100 الذروي لـ FP8 نحو 1979 تيرا عملية عائمة في الثانية (TFLOP/s)، والممثّل كخط أفقي في نموذج Roofline. يبلغ نطاق ترددي ذاكرة H100 نحو 3.35 تيرابايت/ثانية، والممثّل كميل خط يمر عبر الأصل. يعطي الخطان حدود الأداء للحواض المقيدة بالحوسبة والمقيدة بالذاكرة، على التوالي.

أدناه، نناقش أداء حواض GroupGEMM وGEMM.

يجري حاضر GroupGEMM في مزيج الخبراء (MoE) الحوسبة التالية: يوجد g مجموعات إجمالاً، وتحتوي المجموعة i-th على m_i من الرموز، وتجري عملية ضرب مصفوفة لـ [m_i, k] x [k, n] -> [m_i, n]. في اختبار الأداء، نفترض أن عدد الرموز في كل مجموعة هو نفسه، والمشار إليه باسم m_i = m. إذن فإن عدد العمليات العائمة (FLOP) لـ GroupGEMM هو 2 * g * m * k * n، وبايتات إدخال/إخراج الذاكرة هي g * (m * k + n * k + m * n).

في نموذج DeepSeek-V3/R1، يوجد 256 خبيرًا، ويتم توجيه كل رمز إلى 8 خبراء للحوسبة. بافتراض حجم دفعة قدره 128، وطول استعلام قدره 2، باستخدام تكوين EP128 DP128، فإن متوسط عدد الرموز التي يستقبلها كل خبير (أي m) هو 128 * 2 * 8 * 128 / 256 = 1024. وبالمثل، يمكننا حساب m للتكوينات الأخرى وأحجام الدفعات.

استخدمنا تنفيذ GroupGEMM الخاص بـ DeepGEMM لاختبار الأداء. غطت نقاط الاختبار مجموعات من تكوينات EP8، EP16، EP32، EP64، EP128 مع TP1 وأحجام دفعات 1-128.

أداء GroupGEMM بالنسبة إلى حدود سقف الأداء للحوسبة وعرض نطاق الذاكرة.

يوضح الشكل أعلاه نموذج Roofline لـ GroupGEMM تحت تكوينات EP المختلفة. تتوافق EP المختلفة مع عدد مختلف من المجموعات. يوضح الشكل خطوط أداء متداخلة تقريبًا، مما يشير إلى أن أداء GroupGEMM يتم تحديده في الغالب بواسطة إجمالي عدد الرموز (الممثّل كـ g * m).

تميز النجوم نقاط البيانات المقابلة لحجم دفعة يبلغ 128 لكل وحدة معالجة رسومات لكل تكوين EP. بمقارنة نقاط البيانات المميزة بنجوم، يمكننا أن نرى أنه كلما زادت EP (وزاد DP بشكل متزامن)، زاد أيضًا عدد الرموز لكل خبير m. عند EP8، تكون m=128، بينما عند EP128، تكون m=2048.

مع زيادة m، تزيد الكثافة الحسابية أيضًا. في معظم التكوينات، يكون GroupGEMM مقيدًا بنطاق ترددي الذاكرة، لذا فإن زيادة m تحسن الأداء.

يتوافق حاضر GEMM مع إسقاطات Linear في النموذج، مثل Q/K/V/O Projection. لضرب مصفوفة بقيمة [m, k] x [k, n] -> [m, n]، يكون عدد العمليات العائمة (FLOP) هو 2 * m * k * n، وبايتات إدخال/إخراج الذاكرة هي m * k + n * k + m * n. يمكننا أيضًا اختبار الكمون لأحجام الدفعات 1-128.

أداء GEMM بالنسبة إلى حدود سقف الأداء للحوسبة وعرض نطاق الذاكرة.

يوضح الشكل أعلاه نموذج Roofline لـ GEMM تحت تكوينات EP المختلفة. يمكننا أن نرى أن أداء GEMM مقيد بنطاق ترددي الذاكرة. مع زيادة حجم الدفعة، تزيد الكثافة الحسابية أيضًا، مما يؤدي إلى تحسين الأداء.

عند استخدام الدفعات المصغرة، نقوم بتقسيم الدفعة بالتساوي إلى جزأين. من الشكلين أعلاه، يمكننا أن نرى أنه عندما تصبح m قيمة m/2، تنخفض كفاءة ضرب المصفوفات. لذلك، فإن تنفيذ عمليتي ضرب مصفوفة بحجم m/2 يستغرق وقتاً أطول من تنفيذ عملية ضرب مصفوفة واحدة بحجم m.

طوال هذه المقالة، افترضنا استخدام التنبؤ متعدد الرموز (MTP) لفك التشفير الاستدلالي. يغير MTP طول الاستعلام لكل طلب من 1 إلى 2. بالنسبة لضرب المصفوفات، يعادل هذا تغيير m إلى m * 2، مما يزيد بالتالي من كفاءة ضرب المصفوفات. من ناحية أخرى، إذا رسمنا نموذج Roofline لـ MLA، سنجد أن زيادة طول الاستعلام تزيد بشكل كبير من كفاءة حاضر MLA.

لذلك، يلعب استخدام MTP دورًا مهمًا في كفاءة النموذج.

في هذا القسم، سنقدم بعض تفاصيل التنفيذ والتحسين لنموذج DeepSeek-V3/R1 الخاص بنا.

تم تدريب DeepSeek-V3/R1 أصليًا على FP8 باستخدام مخطط كمية لكل كتلة (per-block quantization)، مع كمية الأوزان بشكل ثابت وكمية التنشيطات أثناء التنفيذ (on-the-fly). بدلاً من حساب عامل تحجيم لكل قناة أو لكل مصفوفة بشكل ثابت، يتم حساب عوامل التحجيم عبر متجهات مكونة من 128 عنصرًا للتنشيطات وبلاطات مكونة من 128x128 عنصرًا للمصفوفات، مما يحد من تدهور الدقة بسبب الكمية.

في Perplexity، نعتمد على مزيج من حواض CUDA وTriton لدعم الاستدلال، حيث يُستخدم CUDA للحواض الأكثر حساسية للأداء والتي ندر تعديلها (مثل الانتباه وGEMM)، بينما ينفذ Triton مجموعة واسعة من حواض التنشيط والتطبيع والأدوات المساعدة. سمح لنا Triton بتكيف الحواض بسرعة مع مخطط كمية الكتل.

لطبقات الخطية (linear) ومزيج الخبراء (MoE)، ندمج حواض Deep GEMM مع حواض Triton GEMM الخاصة بنا، حيث لاحظنا أنه بالنسبة لأبعاد معينة للمصفوفات وأحجام الدفعات المنخفضة، يوفر Split-K كمونًا أقل. إذا كانت الطبقة غير الكمية تجري عملية ضرب (M, K) x (K, N)، فإنها تحتاج إلى عامل تحجيم (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) لكمية الكتل. بالنسبة لكمية الكتل، يتم حساب عوامل التحجيم للتنشيطات أثناء التنفيذ (on-the-fly)، بدلاً من معايرتها مسبقًا. وبما أن عوامل تحجيم التنشيط يتم تجميعها فقط على طول البعد K وليس على طول البعد M، فإن الحواض تتطلب تعديلات طفيفة فقط لدعم المخطط.

حساب SiLU والضرب على دفعات، مع إظهار موترات إدخال الخبراء وموترات الإخراج وعوامل التحجيم.

تطلبت دالة تنشيط SiLU المستخدمة بواسطة DeepSeek-V3/R1 تغييرات جوهرية لدعم رسوم بيانية CUDA، كمية الكتل، وأعداد الرموز الموجهة ديناميكيًا. يمكن أن تكون كمية الكتل إشكالية لأنها تدخل تخفيضات أفقية، ومع ذلك فإن الحاض كان قد قسّم التنشيطات بالفعل على طول أبعادها المخفية إلى كتل مكونة من 1024 عنصرًا. داخل كتلة واحدة، تم تقسيم الموتر المراد كميته بشكل إضافي في كتل مكونة من 128 لحساب أكبر قيمة مطلقة، مع قيام Triton بتوليد تخفيضات فعالة كحسب العرض (cross-warp max reductions)، مما يضيف الحد الأدنى من النفقات العامة.

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

لقد قمنا بالفعل برفع بعض حواضنا إلى مشروع FlashInfer وفي المستقبل سنقوم بإتاحة المزيد من كود المصدر الخاص بنا كمصدر مفتوح.

نحن نستخدم FlashInfer لحوسبة الانتباه متعدد الكامنة (MLA). يدعم FlashInfer إعدادات جدول صفحة مرنة وأداءً عاليًا للغاية.

لقد دمجنا q_a_proj و kv_a_proj في حاض واحد qkv_a_proj. انخفض الكمون من 15.4 ميكروثانية + 14.8 ميكروثانية = 30.2 ميكروثانية إلى 16.7 ميكروثانية.

لقد قمنا بتحليل kv_b_proj إلى مصفوفتين، k_b_proj و v_b_proj. لقد كتبنا حاضر BMM بكمية كتل FP8 للحوسبة المتعلقة هاتين المصفوفتين.

يمكن لرسم بياني Cuda تقليل النفقات العامة لإطلاق الحواض بشكل كبير، وهو أمر بالغ الأهمية للأداء. نحن ننشئ رسمًا بيانيًا لـ Cuda لكل حجم دفعة.

قبل تطوير حاضر AllToAll الخاص بنا، استخدمنا torch.all_to_all_single() لاتصال AllToAll. تتطلب هذه العملية من جميع وحدات معالجة الرسومات استخدام نفس حجم الدفعة. ومع ذلك، قد تشغل مجموعات التوازي المبياني (DP Groups) المختلفة أحجام دفعات مختلفة.

لضمان توافق all_to_all_single() مع مجموعات التوازي المبياني (DP Groups) المختلفة التي تستخدم أحجام دفعات مختلفة، استخدمنا أولاً عملية allreduce() قبل كل تشغيل للنموذج للحصول على الحد الأقصى لحجم الدفعة بين جميع مجموعات التوازي المبياني (DP Groups). ثم جعلنا جميع مجموعات التوازي المبياني (DP Groups) تستخدم حجم الدفعة هذا للتشغيل.

على الرغم من أن هذا النهج يضمن إمكانية استخدام رسم بياني Cuda، إلا أن له ثلاث عيوب. أولاً، يتطلب عملية allreduce() إضافية. ثانيًا، تضطر مجموعات التوازي المبياني (DP Groups) ذات أحجام الدفعات الأصغر إلى الحشو (padding). ثالثًا، يجعل كود التنفيذ الخاص بنا معقدًا.

بعد تنفيذ حاضر AllToAll الخاص بنا، لم نعد نطلب من جميع وحدات معالجة الرسومات استخدام نفس حجم الدفعة. لذلك، لم نعد بحاجة إلى إجراء عمليات allreduce() إضافية أو حشو أحجام الدفعات.

تم تنفيذ موجه مزيج الخبراء (MoE) في Triton، مع الاعتماد على فرز معدل مشتق من المكتبة القياسية والذي يتتبع أيضًا مؤشرات العناصر المفروزة. يتم مشاركة التنفيذ عبر جميع نماذج مزيج الخبراء (MoE)، حيث يُعد توجيه Mixtral حالة خاصة لتوجيهات DeepSeek حيث تكون مجموعة Top-K هي نفسها مجموعة جميع الخبراء. تستهلك الحواض المتفرقة مؤشرات ودرجات Top-K مباشرة، بينما تتطلب مخططات الإرسال/الجمع الكثيفة التي تعتمد على الاتصال الشامل (all-to-all) تجميع معلومات التوجيه لكل خبير بدلاً من أساس كل رمز.

في العمل المستقبلي، نخطط لمزيد من تحسين أداء نموذج DeepSeek.

التحسين التالي الأهم هو فصل مرحلة التعبئة (Prefill Disaggregation). تتمتع مرحلة التعبئة ومرحلة فك التشفير لنموذج DeepSeek-V3/R1 بخصائص حوسبة مختلفة تمامًا. يمكن للاهثنين استخدام استراتيجيات تحسين ومخططات نشر مختلفة.

بالنسبة لطبقة الانتباه متعدد الكامنة (MLA)، في مرحلة فك التشفير، نستخدم امتصاص المصفوفات (Matrix Absorption) لتقليل عدد العمليات العائمة (FLOP) لحوسبة الانتباه متعدد الكامنة (MLA). في مرحلة التعبئة، سيكون إسقاط المتجه الكامن أولاً في مساحة K/V ثم الحوسبة في شكل الانتباه متعدد الرؤوس (MHA) أفضل أداءً.

إذا عملت مرحلة التعبئة وفك التشفير على نفس وحدة معالجة الرسومات، لتقليل تأثير التعبئة على سرعة إخراج فك التشفير، فإننا نستخدم عادةً التعبئة المقسمة (chunked prefill) لتقسيم الاستعلام إلى أجزاء متعددة للتعبئة. ونظرًا لأن ذاكرة التخزين المؤقت للقيم المفتاحية (KV Cache) تخزن المتجه الكامن، يصبح من الصعب تحويل الانتباه متعدد الكامنة (MLA) إلى شكل الانتباه متعدد الرؤوس (MHA).

بالنسبة لطبقة مزيج الخبراء (MoE)، في مرحلة فك التشفير، نستخدم أكبر EP وDP ممكنين لزيادة عدد رموز الإدخال لكل خبير، مما يؤدي وبالتالي إلى تحسين أداء GroupGEMM. في مرحلة التعبئة، ونظرًا لأن عدد الرموز كبير بما يكفي بالفعل، فإن GroupGEMM يكون مقيدًا بالحوسبة بالفعل. لذلك، بالنسبة للتعبئة، يمكننا استخدام EP وDP أصغر.

إذا عملت مرحلة التعبئة وفك التشفير على نفس وحدة معالجة الرسومات، طالما أن أي مجموعة توازي مبياني (DP Group) تقوم بالتعبئة، فإن كمون طبقات مزيج الخبراء (MoE) على جميع وحدات معالجة الرسومات سيزداد، مما يؤثر بشكل كبير على سرعة إخراج فك التشفير.

إلى جانب فصل مرحلة التعبئة (Prefill Disaggregation)، نخطط أيضًا لتحسين الجوانب التالية:

أداء AllToAll: يمكن لحاض AllToAll الخاص بنا حاليًا تحقيق ثلث (1/3) فقط من نطاق ترددي Infiniband. سنستمر في تحسين هذا الحاض.

فك التشفير الاستدلالي على طراز EAGLE: في البيانات أعلاه، افترضنا استخدام فك التشفير الاستدلالي للتنبؤ برمز واحد. يمكن لـ EAGLE استخدام بنية شجرة للتنبؤ برموز متعددة، مما تحسن طول القبول، والذي يمكن أن يزيّد سرعة الإخراج بشكل كبير.

حاض GEMM: في نموذج Roofline المعروض سابقًا، يمكننا أن نجد أن كفاءة حاضر GEMM لا تزال بعيدة عن الحد النظري. سنستمر في تحسين هذا الحاض.

GB200 NVL72: في أحدث حل GB200 NVL72 من NVIDIA، يتم ربط 72 وحدة معالجة رسومات Blackwell عبر NVLink عالي السرعة. بالنسبة لنماذج هندسة مزيج الخبراء (MoE)، تعد هذه فرصة وتحديًا كبيرين للغاية.

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

تعمل تقنيات تداخل الحوسبة والاتصالات مثل الدفعات المصغرة (micro-batching) على تقليل النفقات العامة للاتصالات عبر عقد متعددة بشكل كبير، حيث يُظهر تنفيذنا تسريعًا يصل إلى 40%. لقد مكّنت حواض اتصال AllToAll المخصصة وتطبيقات الحواض المحسنة من نشر نموذج الـ 671 مليار معلمة بكفاءة.

مع اكتساب بنيات مزيج الخبراء (MoE) شعبية لقدراتها، توفر استراتيجيات النشر هذه رؤى قيمة لتوسيع مثل هذه النماذج بكفاءة.

التقرير التقني لـ DeepSeek-V3

نظرة عامة على نظام استدلال DeepSeek-V3/R1

Megatron-LM: تدريب النماذج اللغوية ذات المليارات المتعددة من المعلمات باستخدام التوازي النموذجي

EAGLE: أخذ العينات الاستدلالية يتطلب إعادة التفكير في عدم اليقين في الميزات

BibTeX

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}

هندسة النشر

تقنيات التوازي

التوازي الموتري

توازي الخبراء

التوازي المبياني

عقدة واحدة مقابل عقد متعددة

تداخل الحوسبة والاتصالات

تفصيل الكمون

التداخل

EP8 مقابل EP128

Roofline

GroupGEMM

GEMM

الدفعات المصغرة (Microbatch)

التنبؤ متعدد الرموز

التنفيذ والتحسينات

الكمية (Quantization)

طبقة الانتباه متعدد الكامنة (MLA)

رسم بياني Cuda (Cuda Graph)

موجه مزيج الخبراء (MoE Router)

العمل المستقبلي

الخاتمة

المراجع

اقتباس