مقالة
زمن استجابة أقل وإنتاجية أعلى مع نشر DeepSeek متعدد العقد
في معظم الأنظمة، تؤدي محاولة تحقيق التوازن بين الكمون والإنتاجية إلى أهداف متضاربة تتطلّب مقايضات خلال التصميم والنشر. على سبيل المثال، في نماذج اللغة الكثيفة الكبيرة، يمكن أن يؤدي زيادة حجم الدفعة إلى تحسين الإنتاجية ولكن أيضًا يزيد الكمون؛ كما أن زيادة التوازي التنسوري داخل آلة واحدة يمكن أن يقلل الكمون لكنه يقلل من عدد النسخ المتماثلة، مما يؤدي إلى انخفاض الإنتاجية.
لقد أثبتت نماذج خليط الخبراء (MoE) مثل DeepSeek-V3/R1 مؤخراً كفاءات نموذجية وتشغيلية ممتازة. على سبيل المثال، يحتوي نموذج DeepSeek-V3/R1 على 671 مليار متغير في المجموع، لكن كل رمز يستخدم فقط 37 مليار متغير خلال الاستدلال. تقدم بنية النموذج هذه تحديات وفرص لنظم الاستدلال.
تُظهر هذه المقالة أن، بخلاف الأنظمة التقليدية، يمكن لنماذج MoE مثل DeepSeek-V3/R1 أنتحقق في آن واحد إنتاجية أعلى وكمون أقل عند استخدام المزيد من وحدات معالجة الرسومات في النشر عبر العقد في معظم السيناريوهات.
هندسات النشر
نظرًا لشموله على عدد كبير من الخبراء الصغار، يجب أن يتم نشر النموذج عبر عدة أجهزة. لقد أخذنا بعين الاعتبار عمليات النشر على عقدة واحدة باستخدام 8xH200 GPUs وعلى عقد متعددة باستخدام 8xH100 GPUs.
تستفيد كلا العمليتين المعماريتين للنشر من التوازي البياني، المنظم من خلال جدولة الطلبات الداخلية. يتضمن تنفيذ التوازي البياني إطلاق محركات استدلال متعددة تعمل بشكل مستقل لخدمة الطلبات والمحافظة عليها. يكون جدولة الطلبات، الذي يتفاعل مع المحرك عبر GRPC، مسؤولاً عن توزيع الطلبات بشكل متوازن قدر الإمكان، مع تسهيل إعادة استخدام KV، إرسال الطلبات مع البادئة الجزئية إلى الخوادم التي تحتوي على الذاكرة المؤقتة. لا تمتد مثيلات المحرك على عقد متعددة. يمكنها اختيارياً استخدام التوازي التنسوري لتقليل الاهتمام عبر أجهزة متعددة. ترتبط المثيلات عبر NVLink في حالة العقدة الواحدة أو عبر InfiniBand في حالة العقد المتعددة لتوزيع وجمع الخبراء.
يقدم إعداد النشر على العقدة الواحدة كمونًا متفوقاً مع أحجام دفعات صغيرة؛ ومع ذلك، تتراجع الأداء بسرعة تحت ظروف الحمل المتزايد.
لنشر محرك التقديم، نطلق وحدة واحدة لكل عقدة تستضيف مثيلات متعددة للمحرك. تحت مسؤولية PyTorch إعداد الاتصالات الموزعة والتفاوض على إعداد NVSHMEM. للاتصال، نعتمد على النوى CUDA المخصصة الموضحة في منشور المدونة السابق. يكاد يكون تنفيذ النشرين متطابقا، حيث يختار النموذج الموجود النوى المناسبة للاستخدام حسب النسيج الذي ينفذ التوازي الخبير.
تقنيات التوازي
قبل التعمق في مقارنات الأداء، من الضروري فهم الاستراتيجيات الأساسية للتوازي التي تجعل نشر نماذج MoE الضخمة مثل DeepSeek-V3/R1 ممكنًا.
التوازي التنسوري
في استدلال النماذج اللغوية الكبيرة، يُستخدم التوازي التنسوري (TP) عادةً لتقليل استهلاك الذاكرة والحساب لكل وحدة معالجة الرسومات، مما يقلل بالتالي من الكمون. عادةً، يمكننا تقسيم الإسقاطات الخطية في طبقات الانتباه و MLP على أبعاد الصف أو العمود، وتقطيع عمليات الانتباه على البعد رأس الانتباه.
مع TP، لا تحتوي بنية Llama-3 على حساب متكرر لإسقاطات الانتباه والعمليات عبر وحدات معالجة الرسومات، وهي طريقة تقطيع مثالية. ومع ذلك، في نماذج DeepSeek-V3/R1، لا يمكن لـ TP تحقيق ذلك.
تستخدم نماذج DeepSeek-V3/R1 الانتباه متعدد اللاكمون (MLA). تستخدم طبقة MLA أولاً الإسقاط الخطي kv_a_proj لحساب المتجه الكامن، ثم تستخدم إسقاطًا خطيًا آخر kv_b_proj لتحويله إلى مساحة كل رأس من الانتباه. نظرًا لأن جميع رؤوس الانتباه تشترك في نفس المتجه الكامن، لا يمكن لـ TP تقطيع المتجه الكامن، لذا يتعين على جميع مراتب TP تكرار المعلمات والحسابات لـ kv_a_proj و kv_b_proj. وبالمثل، نظرًا لأن MLA تخزن المتجه الكامن في ذاكرة التخزين المؤقت لـ KV، يحتفظ كل مرتبة TP بنسخة متطابقة من ذاكرة التخزين المؤقت لـ KV.
على الرغم من بعض التكرار في MLA، إلا أن التوازي التنسوري لا يزال يقدم تخفيضًا جزئيًا في متطلبات الحساب، مما يجعله ذا قيمة في السيناريوهات التي تتطلب سرعات إخراج عالية.
التوازي الخبير
تستبدل نماذج DeepSeek-V3/R1 طبقات MLP بطبقات MoE. تحتوي طبقة MoE على 256 خبير موجه وواحد مشترك. يتم توزيع كل رمز على 8 خبراء موجهين مختلفين للحساب، ويتم جمع النتائج موزونة. يحسب كل رمز أيضًا في الخبير المشترك، ويتم إضافة النتيجة إلى النتيجة من الخبراء الموجهين.
يعمل التوازي الخبير (EP) كتقنية تقطيع نموذجية لطبقات MoE، حيث يدير كل وحدة معالجة الرسومات 256 / EP خبراء موجهين بينما تحتفظ بنسخة من الخبير المشترك. مقارنةً بـ TP، فإن ميزة EP هي أنه يمكن توزيع الحساب عبر المزيد من وحدات معالجة الرسومات، مما يقلل من استهلاك الحساب والذاكرة لكل وحدة معالجة.
قبل تنفيذ الحساب الخبير، يجب على جميع وحدات المعالجة الرسومية إجراء اتصال AllToAll لإرسال الرموز إلى وحدات المعالجة حيث توجد الخبراء المقابلة؛ بعد الحساب الخبير، هناك حاجة إلى اتصال AllToAll آخر لجمع نتائج الحساب من وحدات المعالجة المختلفة وإجراء جمع موزن. لقد قمنا بتنفيذ نسخة محسّنة من هاتين النوات Kernels للاتصال باستخدام NVSHMEM. في منشور المدونة السابق، شرحنا تفاصيل التطبيق، وتم إتاحة نواتنا على موقع GitHub.
التوازي البياني
مع EP، يمكننا توزيع حساب MoE عبر 128 وحدة معالجة رسومية أو أكثر. ومع ذلك، لا يمكن تقسيم حساب MLA باستخدام EP. عند هذه النقطة، يمكننا إدخال التوازي البياني (DP). يحتوي كل مجموعة DP على نسخة كاملة من طبقة MLA. كل مجموعة DP تقبل مدخلات مختلفة وتقوم بحساب طبقة MLA بشكل مستقل.
يمكن دمج DP TP و MLA طبقة، مع تقسيم مجموعة DP إلى عدة مراتب TP. يمكن دمج EP طبقة MoE مع MLA طبقة DP/TP. EP = DP * TP. على سبيل المثال، على 16 جهازًا، EP128 DP32 TP4 يعني توزيع الخبراء الموجهين عبر 128 وحدة معالجة رسومية، مع تشكيل كل 4 وحدات معالجة مجموعة DP، لما مجموعه 32 مجموعة DP مستقلة.
العقدة الواحدة مقابل متعددة العقد
تتجاوز متغيرات DeepSeek الـ 671 مليار القدرات الذاكرية لقوة معالجة H100 المكونة من 8 وحدات معالجة رسومية (80 غيغابايت * 8)، لكن يمكن لعقدة معالجة H200 المكونة من 8 وحدات معالجة رسومية استيعاب النموذج بالكامل (141 غيغابايت * 8). باستخدام إعداد EP8 DP8 TP1، يستخدم النموذج حوالي 100 غيغابايت من الذاكرة لكل وحدة معالجة، تاركاً حوالي 40 غيغابايت لذاكرة تخزين KV ونتائج وسيطة أخرى. يحتل كل رمز 70,272 بايت من ذاكرة التخزين المؤقت لـ KV. بافتراض أن كل طلب يحتوي على 5,000 رمز، يمكن لكل وحدة معالجة استيعاب حوالي 100 طلب.
أردنا فهم الاختلافات في الأداء بين نشرات العقدة الواحدة والنشرات متعددة العقد في ظل الإعدادات المختلفة. استخدمنا جهاز H200 للنشر على عقدة واحدة وما يصل إلى 16 جهازًا من H100 للنشر متعدد العقد. بالنسبة لكل بيئة نشر، استخدمنا مجموعات من TP 1، 2، 4، 8، وحجم دفعة لكل وحدة معالجة رسومية يبلغ 1، 2، 4، 8، 16، 32، 64، 128. افترضنا أن كل طلب له طول ذاكرة تخزين لـ KV يبلغ 5000 رمز. كما افترضنا أن التنبؤ متعدد الرموز (MTP) يتنبوء برمز إضافي (أي أن طول استعلام كل طلب هو 2)، وافترضنا قبول بنسبة 60٪ بشكل محافظ. تُظهر الشكل أدناه الإنتاجية وسرعة الإخراج للإعدادات المختلفة.
يمثل المحور الأفقي سرعة الإخراج لكل طلب في الرموز/ثانية. يستخدم المحور العمودي مقياساً لوغاريتمياً لعرض الإنتاجية لكل جهاز في الرموز/ثانية. وضعنا الخط الحد الأمثل لكل إعداد EP بخطوط ملونة مختلفة.
في السيناريوهات ذات المتطلبات العالية للغاية لسرعة الإخراج، يمكن استخدام EP8 DP1 TP8 عقدة واحدة مع حجم دفعة صغيرة من 1 لتحقيق سرعة إخراج تتجاوز 100 رمز / ث، أما الإنتاجية فهي منخفضة جدا، مكافئة لسرعة الإخراج. في هذا السيناريو، تحتوي الدفعة بأكملها فقط على رمزين، يمكن إرسالها إلى ما لا يزيد عن 2*8=16 خبراء، مما يؤدي إلى تفعيل ما لا يزيد عن 57 مليار معلمة.
في نطاق السرعة بين 80-40 رمز/ثانية، أثناء زيادة الإنتاجية، تنخفض سرعة الإخراج بشكل كبير. بالمقابل، يعتبر EP128 أعلى بنحو 5 مرات من الإنتاجية مقارنة بنشر العقدة الواحدة بنفس سرعة الإخراج.
يمكن تفسير هذه الظاهرة من خلال دراسة سلوك نشرات العقدة الواحدة: يزيد حجم الدفعة بشكل مباشر معدل الخبراء الذين يتم تفعيلهم. عندما يكون حجم الدفعة 1، يكون متوسط عدد الخبراء المفعيلين لكل GPU هو 2 * 8 / 8 = 2. عندما تكون الدفعة كبيرة بما يكفي، يتم تفعيل جميع الخبراء، أي تفعيل كل GPU 256 / 8 = 32 خبير. تفعيل المزيد من الخبراء يعني أن وحدة المعالجة الرسومية تحتاج إلى قراءة المزيد من المتغيرات من الذاكرة، مما يزيد بشكل كبير الضغط على عرض النطاق الترددي للذاكرة. نظرًا لأن مرحلة فك التشفير في نموذج اللغات الكبيرة بالفعل تعاني من ضيق النطاق الترددي للذاكرة بدلاً من أداء الحساب، فإن زيادة حجم الدفعة في النشر عقدة واحدة تقلل بشكل كبير من سرعة الإخراج.
بالنسبة لمقارنة الأربعة إعدادات للنشر متعدد العقد (EP16، EP32، EP64، وEP128)، فإنزيادة قيم EP تنقل الحد الأمامي الأمثل نحو تحسينات متزامنة في الإنتاجية وسرعة الإخراج.
يعني استخدام رقم EP أعلى أن يتم تخصيص عدد أقل من الخبراء لكل وحدة معالجة رسومية. على سبيل المثال، يعني EP128 أن كل وحدة معالجة رسومية مسؤولة عن 256 / 128 = 2 خبراء، مما يعني أن الضغط على عرض النطاق الترددي للذاكرة قد تم تخفيضه بشكل كبير. بمعنى آخر، باستخدام رقم EP أكبر، نفوز فعليًا بالمزيد من عرض النطاق الترددي للذاكرة. عندما يكون حجم الدفعة لكل وحدة معالجة أقل من 64، فإن زيادة حجم الدفعة لا تؤثر بشكل كبير على سرعة حساب الخبراء لأن زيادة عدد المدخلات لا تزيد بشكل كبير الضغط على عرض النطاق الترددي للذاكرة. لذلك، نلاحظ أنه عند استخدام EP128، لا تؤثر زيادة حجم الدفعة بشكل كبير على سرعة الإخراج.
ومن المثير للاهتمام، أنه مع أحجام دفعة أكبر (64 طلباً لكل وحدة معالجة)، لاحظنا ظاهرة جديدة: إنتاجية النشر عقدة واحدة أعلى قليلاً من إنتاجية النشر متعدد العقد. جزء من السبب هو أن NVLink داخل العقدة لديه عرض نطاق أعلى من InfiniBand بين العقد. جزء آخر هو بسبب القيود في تنفيذنا. سندرس هذه الظاهرة بمزيد من التفصيل لاحقًا.
بسبب قيود سعة الذاكرة، لا يمكن الوصول إلى إعداد EP8 DP8 TP1 حجم الدفعة البالغ 128 لكل وحدة معالجة رسومية، لذا فإن النشر متعدد العقد لا يزال الاختيار الأفضل في السيناريوهات التي تسعى إلى زيادة الإنتاجية.
تداخل الحساب والاتصال
كما هو موضح بإيجاز سابقاً فيما يتعلق بالتوازي الخبير، تكون وحدات المعالجة الرسومية متوقفة أثناء اتصال طبقة MoE. لتقليل الهدر وخفض الكمون، نحتاج إلى العثور على مهام حساب غير متعلقة بالبيانات لملء هذا الوقت الفارغ.
يُظهر الجزء العلوي من الشكل أعلاه تدفق الحساب لطبقة واحدة. يعتمد حساب MoE على الإرسال، وتعتمد حساب الطبقة التالية على نتيجة الدمج.
نضع الخبير المشترك على كل وحدة معالجة رسومية. بهذه الطريقة، لا يتطلب حساب الخبير المشترك اتصال AllToAll. لذلك يمكننا إجراء حساب الخبير المشترك مباشرةً بعد إرسال الإرسال، ثم انتظار اكتمال استقبال الإرسال. نسمي هذا المخطط التداخلي "تداخل الإرسال".
يقدم تداخل الإرسال تنفيذًا مباشرًا وتطبيقًا واسعًا. يخفي هذا الأسلوب زمن حساب الخبير المشترك عبر جميع أحجام EP وأحجام الدفعات.
لزيادة التداخل بين الحساب والاتصال، استخدمنا الدُفع الجزئية التي ذُكرت في تقرير DeepSeek الفني لقطع اعتماد البيانات. كما هو موضح في الجزء السفلي من الشكل، قسمنا حساب طبقة محول واحدة إلى 5 مراحل:
المرحلة 1: إدخال نورم، إسقاط QKV، إلحاق KV، BMM
المرحلة 2: BMM، انتباه، إسقاط O، نورم ما بعد، بوابة
المرحلة 3: إرسال الإرسال، خبير مشترك
المرحلة 4: استقبال الإرسال، MoE، إرسال الدمج
المرحلة 5: استقبال الدمج
في أول 3 طبقات محول كثيفة، نستخدم الدُفعة كلها. في 58 طبقة محول MoE التالية، نقسم الدُفعة بالتساوي إلى دفعتين جزئيتين. تعمل الدفعتان الجزئيتان بالتناوب، مع تعويض بـ3 مراحل. نظرًا لعدم وجود اعتماد على البيانات بين هاتين الدفعتين الجزئيتين، يمكننا التبديل إلى حساب دفعة جزئية أخرى بعد إرسال الإرسال وأيضًا بعد إرسال الدمج.
تفصيل الكمون
بعد ذلك، نقارن تأثيرات التداخل عبر تجربة، ونقارن أيضًا الاختلافات في الأداء بين نشر عقدة واحدة EP8 ونشر متعدد للعقد EP128. لتسهيل المقارنة، استخدمنا وحدات معالجة رسومية H100 للتجربة التالية. استخدمنا TP1، حجم دفعة 128 لكل وحدة معالجة رسومية، طول استعلام 2 لكل طلب، وطول ذاكرة التخزين المؤقت لـ KV 5000.
يُظهر الشكل أعلاه الوقت الكلي المستغرق في طبقة واحدة محول MoE ونسبة الكمون لأنواع مختلفة من النوى. باستثناء الإرسال، الدمج، وGroupGEMM، يجب أن يكون الزمن المستغرق في تنفيذ النوى الأخرى متساويًا بين السلاسل EP8، EP128 NoOverlap، وEP128 DispatchOverlap لأن حجم الدُفعة هو نفسه.
التداخل
لنقارن أولاً تأثيرات أساليب التداخل الثلاثة. استغرق NoOverlap 2667µs في المجموع، بينما استغرق DispatchOverlap 2651µs، مما وفّر 16µs أو فقط 0.6%. أظهر MicroBatch تحسينًا كبيرًا، حيث استغرق 1896µs، مما يمثل تسارعًا بنسبة 29%. تم تقليل وقت الإرسال والدمج بشكل كبير. قلّ ضبط الإرسال من 593µs إلى 367µs، وقلّ ضبط الدمج من 1012µs إلى 237µs.
لاحظ أن تقسيم الدُفعة حجم 128 إلى دفعتين حجم 64 يزيد من الوقت الإجمالي للتنفيذ لنوى الحساب. لذلك، على الرغم من أن الوقت المستغرق في الاتصال قد انخفض بمقدار 1001µs، إلا أن الوقت الإجمالي انخفض فقط بمقدار 771µs. سنشرح السبب باستخدام نموذج Roofline في القسم التالي.
لهذا السبب، لا يحسن تقسيم الدُفعة الجزئية دائمًا الأداء.
يُظهر الشكل أعلاه تحسين الأداء لتقسيم الدُفعة الجزئية مقارنة بوضع تداخل الإرسال لحجم الدُفعة 4-128. عندما يكون حجم الدُفعة أقل من 32، يقلل تقسيم الدُفعة الجزئية من الأداء بنسبة 5%-40%. عندما يكون حجم الدُفعة أكبر أو يساوي 32، يمكن لتقسيم الدُفعة الجزئية تحسين الأداء بنسبة 10%-35%.
EP8 مقابل EP128
نعود إلى الشكل السابق ونقارن EP8 وEP128 Microbatch. استغرق EP8 1802µs في المجموع، أقل قليلاً من EP128 الذي استغرق 1896µs. إلى جانب زيادة زمن التنفيذ للنوى الذي نتج عن تقسيم الدُفعة الجزئية المذكورة أعلاه، الاختلافات الرئيسية تتمثل في GroupGEMM المستخدمة لحساب MoE، والنوى الاتصال الأثنين، الإرسال والدمج.
استغرق GroupGEMM في EP8 555µs، بينما استغرق GroupGEMM في EP128 270µs، مما أدى إلى تقليص النصف. هذه هي الميزة الأساسية للنشر متعدد العقد.
للأسف، الوقت المستغرق في الاتصال زاد بمقدار 213µs، مما أزال إلى حد كبير ميزة GroupGEMM. في اختبارات الأداء المنفصلة للنُوى الاتصال لدينا، وجدنا أنها يمكن أن تحقق فقط نصف عرض النطاق الترددي لـ Infiniband. سنواصل تحسين نوى الاتصال لدينا.
النواة الأخرى التي تتخلف بشكل ملحوظ هي GEMM. زاد تقسيم الدُفعة الجزئية زمن GEMM بمقدار 95µs. سنحلل GEMM بعمق أكبر في قسم Roofline أدناه. نعتقد أن التنفيذ الحالي لـ GEMM لم يصل بعد إلى الأداء الأمثل.
Roofline
يمثل نموذج Roofline أداة جيدة لتحليل أداء النواة. يُمثّل المحور الأفقي شدة الحساب، وهي نسبة FLOP إلى بايتات إدخال/إخراج الذاكرة. يمكن حساب قيمة المحور الأفقي مباشرة من معنى النواة. يمثل المحور الرأسي الأداء المحقق، الذي يتم حسابه عن طريق تقسيم FLOP على زمن القياس.
يتم تحديد الحدود النظرية لأداء النواة مباشرة بواسطة مواصفات وحدة المعالجة الرسومية. يُمثل الحد الأقصى للأداء FP8 لوحدة معالجة H100 بخط أفقي في نموذج Roofline. يُمثل عرض النطاق الترددي للذاكرات لـ H100 بخط مائل يمر من خلال الأصل. يوفر الخطان حدود الأداء للنواة المحددة بالحساب والنواة المحددة بالذاكرة، على التوالي.
أدناه، نناقش أداء نواتي GroupGEMM و GEMM.
GroupGEMM
تنفّذ نواة GroupGEMM في MoE الحساب التالي: هناك g مجموعات في المجموع، تحتوي المجموعة i على m_i رموز، تنفيذ ضرب المصفوفة [m_i، k] x [k، n] -> [m_i، n]. في اختبار الأداء، نفترض أن عدد الرموز في كل مجموعة هو نفسه، ويُرمز إلى m_i = m. ثم عدد FLOP لـ GroupGEMM هو 2 * g * m * k * n، وbytes إدخال/إخراج الذاكرة هو g * (m * k + n * k + m * n).
في نموذج DeepSeek-V3/R1، هناك 256 خبير، ويتم إرسال كل رمز إلى 8 خبراء للحساب. افترض حجم الدُفعة 128، طول الاستعلام 2، باستخدام إعداد EP128 DP128، متوسط عدد الرموز المستقبلة بواسطة كل خبير (أي m) هو 128 * 2 * 8 * 128 / 256 = 1024. بالمثل، يمكننا حساب m للإعدادات وأحجام الدُفعات الأخرى.
لقد استخدمنا DeepGEMM لتنفيذ GroupGEMM في اختبارات الأداء. تغطّى نقاط الاختبار المجموعات من إعدادات EP8، EP16، EP32، EP64، EP128 مع TP1 وأحجام الدُفعات من 1-128.
يُظهر الشكل أعلاه نموذج Roofline لـ GroupGEMM تحت إعدادات EP المختلفة. يمثل EP المختلف عدد مجموعات مختلفة. يُوضح الشكل خطوط أداء متقاربة تقريبًا، مما يشير إلى أن أداء GroupGEMM محدد إلى حد كبير بعدد الرموز الكلي (الموضح كـ g * m).
تم تمييز النجوم كنقاط بيانات لحجم الدُفعة 128 لكل GPU لكل إعداد EP. بمقارنة نقاط البيانات المميزة هذه، يمكننا أن نرى أنه مع زيادة EP (وزيادة DP بشكل متزامن)، يزيد عدد الرموز لكل خبير m أيضًا. في EP8، m=128، بينما في EP128، m=2048.
مع زيادة m، تزيد شدة الحساب. في معظم الإعدادات، يُحدد أداء GroupGEMM بواسطة عرض النطاق الترددي للذاكرة، لذا فإن زيادة m تحسن الأداء.
GEMM
يُطابق نواة GEMM الإسقاطات الخطية في النموذج، مثل Q/K/V/O Projection. بالنسبة لضرب المصفوفة [m، k] x [k، n] -> [m، n]، فإن عدد FLOP هو 2 * m * k * n، وbytes إدخال/إخراج الذاكرة هو m * k + n * k + m * n. يمكننا أيضًا اختبار زمن التنفيذ لأحجام الدُفعات من 1-128.
يُظهر الشكل أعلاه نموذج 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 باستخدام مخطط تكميم لكل كتلة، وكممت الأوزان بشكل ثابت ونشطت أثناء التشغيل. بدلاً من حساب عامل القياس لكل قناة أو لكل مصفوفة بشكل ثابت، يتم حساب عوامل القياس عبر متجهات مكونة من 128 عنصرًا للتنشيط وكتل 128x128 عنصرًا للمصفوفات، مما يقيد تقلص دقة التكميم.
في Perplexity، نعتمد على مزيج من نوى CUDA وTriton لدعم الاستدلال، مع استخدام CUDA لأكثر النوى حساسية للأداء وغير متغيرة بشكل متكرر (مثل الانتباه وGEMM)، مع تنفيذ Triton مجموعة واسعة من التنشيط وطبقات النورماليزيات وطبقات المساعدة. سمحت لنا Triton بتكييف النوى بسرعة مع مخطط التكميم الكتلي.
بالنسبة للطبقات الخطية والموفضلية، نخلط نوى 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)) عامل القياس للتكميم الكتلي. بالنسبة للتكميم الكتلي، يتم حساب عوامل القياس للتنشيط أثناء التشغيل، بدلاً من أن تكون معايرة مسبقًا. نظرًا لأن عوامل القياس للنشطت يتم جمعها فقط على طول K وليس على طول البعد M، تتطلب النوى تغيرات طفيفة لدعم المخطط.
تطلبت وظيفة تنشيط SiLU المستخدمة في DeepSeek-V3/R1 تغييرات كبيرة لدعم رسوميات CUDA، التكميم الكتلي، وعدد الرموز المتناوبة ديناميكياً. يمكن أن يكون التكميم الكتلي مشكلاً لأنه يقدم تقليصات أفقية، لكن النواة قامت بالفعل بتجزئة التنشيطات على طول بعدها الخفي إلى كتل من 1024 عنصر. داخل كتلة واحدة، يتم تقطيع المصفوفة المراد تكميمها بطريقة إضافية إلى كتل من 128 لحساب أكبر قيمة مطلقة، مع توليد Triton تقليصات عرضية ماكس عبر-النوات، مضيفةً حملاً بسيطًا.
لدعم التوجيه تحت رسوميات CUDA، يجب أن تكون النوى على علم بمعلومات التوجيه التي تشير إلى عدد الرموز لكل خبير بدلاً من جدولة العمل بناءً على حجم المخازن التي تم تخصيصها لاستيعاب الحد الأعلى لحساب الرموز. لا يمكننا تقسيم المشكلة بناءً على أبعاد المصفوفة المدخلة، لذلك نقوم بإطلاق عدد ثابت من النوى الدائمة التي تقرأ معلومات التوجيه لتحديد عدد الرموز المأهولة وتقسم عمل معالجة التنشيطات بينها بطريقة ديناميكية.
لقد قمنا بالفعل بوضع بعض النوى الخاصة بنا في مشروع FlashInfer وفي المستقبل سنقوم بفتح المزيد من الكود الخاص بنا.
طبقة MLA
نستخدم FlashInfer لحساب MLA. يدعم FlashInfer إعدادات جدول الصفحات المرنة وأداء مرتفع للغاية.
قمنا بدمج q_a_proj وkv_a_proj في qkv_a_proj واحد. انخفض الكمون من 15.4 µs + 14.8 µs = 30.2 µs إلى 16.7 µs.
قمنا بتفكيك kv_b_proj إلى مصفوفتين، k_b_proj وv_b_proj. قمنا بكتابة نواة كتلة مخروطية FP8 لحسابات المتعلقة بهاتين المصفوفتين.
رسوميات Cuda
يمكن أن تقلل رسوميات CUDA بشكل كبير من زمن إطلاق النواة، وهو حاسم للأداء. نقوم بإنشاء رسوميات CUDA لكل حجم دفعة.
قبل تطوير نواة AllToAll الخاصة بنا، استخدمنا torch.all_to_all_single() للاتصال AllToAll. تتطلب هذه العملية أن تستخدم جميع وحدات المعالجة الرسومية نفس حجم الدُفعة. ومع ذلك، قد تستخدم مجموعات DP المختلفة أحجام دفعة مختلفة.
لضمان نجاح all_to_all_single() مع مجموعات DP المختلفة باستخدام أحجام دفعة مختلفة، استخدمنا أولاً عملية allreduce() قبل تشغيل النموذج للحصول على حجم الدُفعة الأقصى بين جميع مجموعات DP. ثم جعلنا جميع مجموعات DP تستخدم هذا الحجم لتشغيل النموذج.
على الرغم من أن هذه الطريقة تضمن أنه يمكننا استخدام رسوميات CUDA، إلا أن لها ثلاث عيوب. أولاً، تتطلب عملية allreduce() إضافية. ثانيًا، يتم إجبار مجموعات DP ذات أحجام دُفعة أصغر على التوسيع. ثالثًا، يجعل كود التنفيذ الخاص بنا معقدًا.
بعد تنفيذ نواة AllToAll الخاصة بنا، لم نعد نحتاج إلى استخدام جميع وحدات المعالجة الرسومية لنفس حجم الدُفعة. لذلك، لم نعد نحتاج إلى إجراء عمليات allreduce() إضافية أو توسيع أحجام الدُفعة.
موجه MoE
تم تنفيذ موجه MoE في Triton، مستندًا إلى ترتيب معدل مستمد من مكتبة النظام القياسية التي تحتفظ أيضًا بتتبع مؤشرات العناصر المرتبة. يتشارك التطبيق عبر جميع نماذج MoE، حيث يعتبر توجيه Mixtral حالة خاصة من طرق DeepSeek حيث تكون المجموعة Top-K هي نفسها مجموعة جميع الخبراء. تستهلك النوى المتناثرة المؤشرات والنتائج مباشرة، في حين أن أنظمة التجميع/التوزيع الكثيفة التي تعتمد على الكل تتطلب جمع معلومات التوجيه لكل خبير بدلًا من قاعدة لكل رمز.
العمل المستقبلي
في العمل المستقبلي، نخطط لمزيد من تحسين أداء نموذج DeepSeek.
أهم تحسين مستقبلي هو تجزئة التمهيد. تُظهر مرحلة التمهيد ومرحلة فك التشفير لنموذج DeepSeek-V3/R1 خصائص حسابية مختلفة جدًا. كلاهما يمكن استخدام استراتيجيات تحسين مختلفة ومخططات نشر مختلفة.
بالنسبة لطبقة MLA، في مرحلة فك التشفير، نستخدم امتصاص المصفوفة لتقليل عدد FLOP لحساب MLA. في مرحلة التمهيد، فإن الإسقاط الأول للمتجه الكامن إلى مساحة K/V ثم الحساب في شكل الانتباه متعدد الرؤوس (MHA) سيكون أفضل.
إذا كانت عملية التمهيد وفك التشفير تجري على وحدة المعالجة الرسومية نفسها، لتقليل تأثير التمهيد على سرعة إخراج فك التشفير، عادةً ما نستخدم تقسيم التمهيد لتقسيم الاستعلام إلى عدة أجزاء للتمهيد. نظرًا لأن ذاكرة التخزين المؤقت لـ KV تخزن المتجه الكامن، يصبح من الصعب تحويل MLA إلى شكل MHA.
بالنسبة لطبقة MoE، في مرحلة فك التشفير، نستخدم أكبر EP و DP الممكنة لزيادة عدد الرموز المدخلة لكل خبير، مما يحسن أداء GroupGEMM. في مرحلة التمهيد، نظرًا لأن عدد الرموز بالفعل كبير بما فيه الكفاية، يكون GroupGEMM محدّدًا بالفعل بالحساب. لذلك، بالنسبة للتمهيد، يمكننا استخدام EP وDP أصغر.
إذا كانت عملية التمهيد وفك التشفير تجري على وحدة المعالجة الرسومية نفسها، طالما أن أي مجموعة DP تجري التمهيد، سيزيد الكمون لطبقات MoE على جميع وحدات المعالجة الرسومية، مما يؤثر بشكل كبير على سرعة إخراج فك التشفير.
بالإضافة إلى تجزئة التمهيد، نخطط أيضًا لتحسين الجوانب التالية:
أداء AllToAll: يمكن أن تحقق نواة AllToAll الخاصة بنا حاليًا فقط 1/3 من عرض النطاق الترددي لـ Infiniband. سنواصل تحسين هذه النواة.
التنبؤ التخطيطي بأسلوب EAGLE: في البيانات المذكورة أعلاه، افترضنا استخدام التنبؤ التخطيطي للتنبؤ برمز واحد. يمكن لـ EAGLE استخدام بنية شجرية للتنبؤ بطلاب متعدد، مما يحسن طول القبول، مما يمكن أن يزيد بشكل كبير من سرعة الإخراج.
نواة GEMM: في نموذج Roofline الذي تم عرضه سابقًا، يمكننا أن نجد أن كفاءة نواة GEMM لا تزال بعيدة عن الحد النظري. سنواصل تحسين هذه النواة.
GB200 NVL72: في حل GB200 NVL72 الجديد من NVIDIA، يتم ربط 72 GPU من Blackwell عبر NVLink عالي السرعة. بالنسبة لنماذج بنية MoE، يمثل هذا فرصة وتحديًا كبيرًا.
خاتمة
يحقق النشر متعدد العقد لنماذج DeepSeek MoE ما يعتبر مستحيلاً عادةً باستخدام LLMs الكثيفة: تحسين الإنتاجية والكمون في نفس الوقت. من خلال توزيع الخبراء عبر المزيد من وحدات المعالجة، نقلل الضغط على عرض النطاق الترددي للذاكرة لكل جهاز، مما يتيح معالجة أسرع وزيادة في إنتاجية النظام. تُظهر تجاربنا أن إعدادات EP128 تحقق حتى 5 مرات إنتاجية أعلى بسرعات إخراج مكافئة مقارنة بنشرات العقدة الواحدة.
توفر تقنيات تداخل الحساب والاتصال مثل تقسيم الدُفعة الجزئية تقليصاً كبيراً من حمل الاتصال متعدد العقد، وتظهر تنفيذاتنا تسارعاً يصل إلى 40%. لقد مكّنت نوى الاتصال AllToAll المخصصة لدينا وتنفيذات النواة المحسّنة نشرًا فعالًا لنموذج 671B للمعلمات.
مع اكتساب شعبية بنية MoE لقدرتها، تقدم استراتيجيات النشر هذه رؤى قيّمة لتوسيع هذه النماذج بشكل فعال.