حقق MoK من Cursor زيادة في الأداء بنسبة 2.37x على NVIDIA GB300 NVL72

يقوم Cursor بفتح مصدر MoK، ودمج جدولة الرموز، والاتصال عبر وحدات GPU، وحساب الخبراء داخل نواة GPU واحدة. حققت هذه الخطة تحسينات في الأداء تصل إلى 2.37 ضعفًا في التقدم الأمامي و1.78 ضعفًا في التراجع الأمامي بتنسيق MXFP8 على GB300 NVL72، مع زيادة في إنتاجية التدريب باستخدام 512 وحدة GB300 GPU إلى 1070.2 رمز/ثانية، بزيادة قدرها 41%. انخفض تأخير الإشارة من 103 ميكروثانية إلى 18 ميكروثانية. تشير التحليلات إلى أنه مع وصول عرض نطاق NVLink إلى 130 تيرابايت/ثانية اليوم، أصبح وقت انتظار البيانات على وحدة GPU عائقًا جديدًا في الأداء. يمثل هذا الإنجاز دخول المنافسة في الذكاء الاصطناعي مرحلة "السيادة الكاملة في الطبقات"، حيث تمتلك الشركات التي تقرب الكود من ذاكرة العرض والمسجلات سلطة تسعير أكبر.

كاتب المقال، المصدر: LeFeng.com

في 21 يوليو، أعلنت NVIDIA عن أحدث نتائج تدريب DeepSeek-V3 باستخدام GB300 NVL72: على 256 وحدة معالجة رسومية، بلغت أداء الوحدة الفردية 1,648 TFLOPS.

قبل أقل من أسبوعين، أصدر Cursor Mixture-of-Kittens مفتوح المصدر، والمعروف اختصارًا بـ MoK. بدلًا من مواصلة تحسين ضرب المصفوفات الأسرع، أعاد كتابة طبقة كاملة لتنفيذ MoE، ودمج جدولة الرموز، والاتصال عبر وحدات GPU، وحساب الخبراء داخل نواة GPU واحدة.

هذا الأمر يبدو معاكسًا للحدس. فبما أن GB300 NVL72 قد وضعت 72 وحدة معالجة رسومية في نفس نطاق NVLink، فقد وصل إجمالي عرض النطاق الترددي لـ NVLink إلى 130 تيرابايت/ثانية. ووفقًا لهذه المواصفات، يجب أن يكون نقل البيانات بين وحدات المعالجة الرسومية سريعًا بما يكفي.

في تدريب MoE على نطاق واسع، لا يزال الاتصال يبطئ حساب الخبراء.

المشكلة تكمن في تدفق بيانات MoE. في كل خطوة، يقرر الموجه مرة أخرى إلى أي خبير سيُرسل الـ token، بينما تكون الخبراء موزعين على وحدات GPU مختلفة. يجب نقل الـ token أولاً عبر البطاقات، ثم إعادته بعد الحساب؛ قبل الإرسال، يجب ترتيب المواقع، وبعد الوصول، يجب الانتظار حتى اكتمال البيانات. مع تقليل حسابات الخبراء بسبب MXFP8 وBlackwell Tensor Core، بدأت فترات الانتظار التي كانت تُخفي سابقًا خلف الحسابات تصبح أكثر وضوحًا.

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

في عصرٍ حيث تم دفع موارد الحوسبة إلى أقصى حدٍّ باستخدام Blackwell وNVLink، اكتشف المطورون: أن السرعة الفائقة للعتاد لا يمكنها إنقاذ ترتيب البرمجيات غير الفعّال.

فتح MoK ليس انتصارًا للنواة فحسب، بل يُمثّل بداية عصر "تعريف المشغلات على طبقة التطبيق": من أجل استغلال آخر 30% من القدرة الحسابية، تشن شركات الذكاء الاصطناعي الناشئة حربًا للاستيلاء على السيادة الأساسية.

لكن لفهم لماذا تعمل هذه التصميمات الخاصة بـ Cursor، يجب أولاً أن نوضح أين تدفع MoE "ضريبة الاتصال".

01

ضريبة الاتصالات في MoE

في FFN الكثيف العادي، تكون الأوزان التي يمر بها الـ token ثابتة إلى حد كبير. بعد إضافة Router في MoE، يختار كل token مؤقتًا عددًا قليلاً من الخبراء. عند استخدام Expert Parallel، يتم تقسيم الخبراء إلى العديد من وحدات GPU، وبالتالي يحدث على الأقل جولتان من الاتصال بين البطاقات أثناء عملية التقدم الأمامي.

الجولة الأولى تُسمى Dispatch، حيث يتم إرسال الـ token إلى GPU الذي يقع عليه الخبير؛ وبعد إكمال الخبير للحسابات، يتم إرجاع النتائج إلى الموقع الأصلي للـ token عبر Combine. يتضمن التدريب أيضًا الانتشار العكسي، والذي يُنفّذ جولتين إضافيتين من الاتصال في الاتجاه المعاكس.

إذا كان الهدف فقط نقل كتلة كبيرة من البيانات المتصلة من A إلى B، فإن NVLink كافٍ بسرعة كافية. المشكلة في MoE تكمن في أن توزيع البيانات الذي يُقدمه الموجه في كل خطوة يكون مختلفًا.

قد يتلقى خبير ما خطوةً واحدة الكثير من الرموز، ثم القليل جدًا في الخطوة التالية. يجب على النظام أولاً حساب عدد الرموز لكل خبير، ثم تحديد أين تُوضع هذه الرموز على وحدة معالجة الرسوميات المستهدفة، بالإضافة إلى محاولة تجميع بيانات الخبير نفسه معًا. فقط بهذه الطريقة يمكن لـ Grouped GEMM الحصول على مدخلات منظمة وتقديمها بكفاءة إلى وحدات Tensor Core.

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

لذلك، في مرحلة "اتصال" واحدة، يتم خلط عدة أمور معًا: نقل البيانات، توليد التخطيط، المزامنة، وعدم توازن الحمل. إن القيمة 130 تيرابايت/ثانية تصف عرض النطاق الترددي القصوى الذي يمكن للخزانة بأكملها توفيره، ولا تعني أن كل اتصال ديناميكي وجزئي في MoE يمكنه تعبئة جميع الروابط في نفس الوقت.

لقد قام DeepEP بتسريع نقل البيانات الخاص به. إنه مكتبة اتصالات عالية الأداء مصممة خصيصًا لـ Expert Parallel، وتقدم نوى Dispatch وCombine مخصصة، وتدعم FP8، وتسمح بالتحكم في عدد SMات المستخدمة للاتصال. حتى الإصدار الأحدث يمكنه الحفاظ على إنتاجية اتصال عالية باستخدام عدد أقل بكثير من SMات.

لا يزال يتعين على طبقة MoE واحدة التبادل المستمر بين التوزيع وGrouped GEMM والدمج.

يُواجه هنا تناقض عملي واضح: إذا انتظرت حتى تصل كمية كافية من الرموز قبل الحساب، فستكون المصفوفة كبيرة ويعمل Tensor Core بسلاسة، لكن الحساب يبدأ متأخرًا؛ وإذا بدأت الحساب فور وصول كل رمز، فسيتم تداخل الاتصال والحساب مبكرًا، لكن المصفوفة ستكون صغيرة جدًا، مما يعني أن العديد من وحدات SM في GPU لن تمتلك كمية كافية من العمل.

يمكن لعدة تيارات CUDA أن تسمح بالتوازي بين الاتصال والحساب، لكن من الصعب ضمان دائمًا حصول كلا الطرفين على موارد GPU المثالية.

التصميم خلف MoK يعالج أساسًا مشكلة "الإيقاع" هذا.

02

أحد أكثر التغييرات إثارةً في MoK هو تغيير التوجيه الأمامي من Push إلى Pull.

ال-push التقليدي بسيط: عندما يمتلك GPU المصدر رموزًا، فإنه يكتبها مباشرة في GPU الهدف. تكمن المشكلة في عنوان الهدف. ستتلقى وحدة GPU واحدة في نفس الوقت رموزًا من العديد من وحدات GPU الأخرى.

يجب على كل مرسل أن يعرف مسبقًا إلى أي قسم يجب أن يكتب، ولا يجب أن يتداخلوا مع بعضهم البعض؛ كما يُفضَّل أن تكون رموز نفس الخبير متتالية، وإلا فسيتعين على GEMM اللاحقة إعادة ترتيبها.

مع زيادة عدد وحدات معالجة الرسومات (GPU) المشاركة، يصبح هذا العملية الجدولة أكثر ثقلاً. قام Pull بتغيير الطريقة: فهو يحفظ الـ GPU المستهدف للخبير ليقوم هو نفسه بقراءة الرموز المطلوبة. ما عليه سوى معرفة أي GPU مصدرية توجد فيها الرموز وأين تقع في بيانات المصدر، بينما يُحدد مكان التخزين المحلي بنفسه.

هذا يوفر جهد التنسيق بين عدة طرف مرسل لعنوان الوجهة. يمكن أيضًا ترتيب البيانات المستلمة مباشرة وفقًا للخبراء المحليين.

من المثير للاهتمام أن Pull لم تنقل بيانات أقل. في اختبارات الأداء الدقيقة للـ Cursor، لنفس كتلة البيانات 256×256 BF16، ينقل Push حوالي 159.6 كيلوبايت عبر NVLink، بينما يصل Pull إلى 172.0 كيلوبايت بسبب الحاجة إلى إرسال طلبات إضافية أثناء القراءة.

يتميز Pull بعامل آخر: اتصال MoE مجزأ وغير متوازن في الحمل. تحتوي قنوات NVLink في الاتجاهين على قنوات مستقلة، مما يسمح لـ Pull باستخدام كلا الاتجاهين — الطلب وإرجاع البيانات — في نفس الوقت. في اختبارات الحمل غير المتوازن للخبراء، لاحظ Cursor زيادة بنسبة تصل إلى 29% في استخدام NVLink.

الفجوة في المزامنة أكثر وضوحًا. بعد إكمال عملية Push، يجب على GPU الهدف الانتظار لإشارة إكمال من GPUs الأخرى؛ عندما يكون حجم Expert Parallel كبيرًا، قد يشمل رانك واحد ما يصل إلى 71 زميلًا آخر. أما Pull، فهو يُبادر به GPU المحلي للقراءة، ويمكن استخدام البيانات فور وصولها.

في معيار الدقيقة متعدد العقد لـ Cursor، انخفضت هذه التأخيرات الإشارية من حوالي 103 ميكروثانية في Push إلى 18 ميكروثانية في Pull.

لا يستخدم MoK الـ Pull في كل مكان. في الاتجاه الأمامي، يتم استخدام Pull Dispatch و Push Combine؛ وفي الاتجاه العكسي، يتم استخدام Pull Reverse-Combine و Push Reverse-Dispatch. في مرحلة Dispatch، يجب إعادة تنظيم العديد من مصادر الـ token لتصبح مدخلات خبراء، والـ Pull أكثر كفاءة في التنسيق؛ أثناء Combine، من الواضح جدًا إلى أي token يجب أن يعود كل نتيجة، لذا فإن الدفع المباشر باستخدام Push أسهل.

بعد تغيير اتجاه الاتصال، ما زال MoK يدمج الاتصال والحسابات الخبيرة في نفس Megakernel.

يقوم بتقسيم SM في GPU إلى جزأين. يُشرف أحد الجزأين على التوزيع والدمج وإدارة الحالة، بينما يُخصص الجزء الآخر لتنفيذ Expert FFN. بعد استلام الجانب الاتصالي مجموعة كاملة من الرموز، يُبلغ الجانب الحسابي عبر عداد محلي على GPU؛ وبعد إكمال الحساب، يُبلغ الجانب الحسابي الجانب الاتصالي لإرسال النتائج مرة أخرى.

هذا يسمح لك بتحديد عدد SMs المستخدمة للاتصال وعدد SMs المستخدمة للحساب مباشرة، دون الاعتماد كليًا على تعدد تيارات CUDA للتنافس. المعامل الأكثر أهمية هنا يُسمى minibatch، أي عدد الرموز المُسلَّمة إلى الخبراء في كل مرة.

لا يمكن أن يكون كبيرًا جدًا. فالحجم الكبير يعني أن الحسابات الأولى ستستغرق وقتًا طويلاً للانتظار. ولا يمكن أن يكون صغيرًا جدًا. ففي النهاية، سيقوم خبير GEMM بتفكيك الحسابات إلى عدد كبير من المهام لتقسيمها على SMs، وإذا كان عدد الرموز قليلًا جدًا، فلن يكون هناك عدد كافٍ من المهام، وسيبقى العديد من SMs عاطلًا.

يستخدم Cursor الموجة لتحديد هذا الحد. يمكن فهم موجة كاملة ببساطة على أنها الحالة التي يتم فيها توزيع جميع حسابات SM على العمل. يرغب MoK في أن يكون لدى minibatch واحد على الأقل موجتين كاملتين، لضمان وجود مهام كافية لاستمرار تنفيذ Tensor Core.

النتائج الفعلية تتحدث عن نفسها. على شكل Kimi 2.5 بحجم مخفي قدره 7168 وابعاد خبراء متوسطة قدرها 2048، يقدر Cursor أن minibatch يحتاج على الأقل إلى حوالي 2368 رمزًا. عند 512 رمزًا، يستغرق التقدم الأمامي لـ MoK 5.981 مللي ثانية؛ وعند زيادة ذلك إلى 2560 رمزًا، ينخفض إلى 3.425 مللي ثانية. مع الاستمرار في الزيادة، لم يعد هناك تحسن واضح في السرعة.

بعبارة أخرى، تقسيم الاتصال إلى أجزاء أصغر لا يعني بالضرورة زيادة السرعة دائمًا. يتطلب التداخل الفعال حقًا تسليم البيانات في أسرع وقت ممكن، مع تجنب تقسيم GEMM إلى أجزاء صغيرة جدًا.

لكن MoE لديه مشكلة أخرى: قبل اكتمال عمل Router، لا يمكن معرفة عدد التوكنات الذي سيستلمه كل GPU في النهاية.

إذا تم إعداد buffer وفقًا لأسوأ سيناريو، فسيتم إهدار الكثير من ذاكرة GPU. إذا تم السماح لـ GPU بحساب الرموز أولاً، ثم إخطار CPU بتعيين المساحة المقابلة، فسيتعين على GPU التوقف والانتظار حتى يكمل CPU.

يستخدم MoK مخزنًا ثابت الحجم لـ Ring Token Buffer. يتم ملء مساحة معينة أولاً بالـ tokens المُرسلة من Dispatch، وبعد اكتمال حسابات الخبراء ونقل النتائج بواسطة Combine، تُعاد استخدام هذه المساحة فورًا للـ tokens التالية. يمكن أن يحدث Combine لمجموعة macrobatch السابقة في نفس الوقت مع Dispatch لمجموعة macrobatch التالية.

يُشبه مخزن الدوراني هنا طبقة تخزين مؤقتة: عندما تسير الاتصالات أسرع، تتراكم البيانات داخله؛ وعندما تُستهلك الحسابات أسرع، يُنتظر وصول الدفعة التالية من الرموز. يُدفع整個 العملية بواسطة الحالة على وحدة معالجة الرسومات، دون الحاجة إلى تدخل وحدة المعالجة المركزية في كل دورة لاتخاذ القرار التالي.

كما أضاف Cursor كمية تنشيط MXFP8 إلى مسارات البيانات الخاصة بـ Dispatch و Grouped GEMM و SwiGLU، مما يقلل من الحاجة إلى نواة كميّة مستقلة ويخفّض عدد مرات قراءة وكتابة النتائج الوسيطة في HBM.

بعد دمج Pull و minibatch و SM Partition و Ring Buffer، يصبح MoK فعليًا خط أنابيب MoE مستمر.

03

يقيس معيار Cursor طبقة MoE الكاملة، بما في ذلك الجدولة، التوجيه، خبير FFN، الدمج، والدمج الموزون النهائي، مقارنةً بـ NCCL + PyTorch و DeepEP و TransformerEngine و HybridEP + Megatron.

على GB300 NVL72، يحقق MoK أقصى تحسين قدره 2.37 مرة في التقدم الأمامي و1.78 مرة في التقدم العكسي مقارنة بأسرع خطوط أساس عامة لكل سيناريو؛ كما يحقق تحسينًا أقصى قدره 1.92 مرة في التقدم الأمامي و1.58 مرة في التقدم العكسي لـ BF16.

الأهم هو التدريب الطرفي إلى الطرفي. كانت خطة الإنتاج الأصلية لـ Cursor تستخدم DeepEP. بعد التحول إلى MoK على 512 وحدة معالجة رسومية GB300، ارتفع إنتاجية الوحدة الواحدة من 760.9 رمز في الثانية إلى 1070.2 رمز في الثانية، بزيادة تقارب 41%.

يجب أيضًا فهم الحدود لهذه النتائج. لم يُنشر تحليل الإزالة التفصيلي الكامل من Cursor، لذا لا يمكن تحديد بدقة كم من الضعف 2.37 يعود إلى Pull وكم منه يعود إلى Megakernel وكم منه يعود إلى Ring Buffer.

يمكن التأكيد بشكل منفصل على تحسين Pull لاستخدام NVLink وتأخير الإشارة، بينما تأتي المكاسب الأخرى بشكل أساسي من مجموعات طرق التنفيذ المتكاملة.

يعتمد MoK أيضًا بشكل كبير على الأجهزة. فهو مصمم لمناطق NVLink عالية السرعة مثل Blackwell و NVL72. إن القراءات البعيدة، والاتصالات، والحسابات الدقيقة المتشابكة تعتمد جميعها على قدرة وحدات معالجة الرسومات على الوصول إلى ذاكرة العرض الخاصة ببعضها البعض بتأخير منخفض. عند تغيير حجم المخفي للنموذج، أو Top-k، أو حجم الخبراء، يتغير حجم الـ minibatch المناسب وعدد وحدات الاتصال SM تلقائيًا.

هذا أيضًا هو أكثر ما يُستحق الملاحظة في MoK. في الماضي، كان من السهل عند مناقشة تحسين MoE أن تركز فقط على رقمين: كم TFLOPS لدى GEMM، وكم GB/s لدى All-to-All. لكن مع جيل GB300، لم يعد دفع هذين الرقمين فقط كافيًا لشرح كامل الأداء.

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

رacks بعرض نطاق 130 تيرابايت/ثانية NVLink، لا يزال يتطلب إعادة كتابة نوى GPU لـ MoE، وهذا هو السبب: الروابط سريعة بالفعل، والآن ما نحتاجه هو تقليل الوقت الذي تقضيه GPU في انتظار البيانات.

سلوك Cursor في إعادة كتابة نوى GPU يُمثّل دخول المنافسة في عصر الذكاء الاصطناعي 2.0 إلى مرحلة جديدة تُعرف بـ"السيادة الكاملة للسلاسل".

في الماضي، كنا نؤمن بـ"كلٌّ يعمل في تخصصه"، فمن يصنع التطبيقات يجب أن يركز على التطبيقات (Cursor)، ومن يصنع الأساسيات يجب أن يركز على الأساسيات (NVIDIA). لكن المنافسة الحالية في مجال الذكاء الاصطناعي وصلت إلى مرحلة جديدة من "إزالة الوسطاء"، فـ Cursor لم يبدأ في تطوير النواة لأنه "أراد"، بل لأنه "اضطر".

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

ستبقى شركات الذكاء الاصطناعي التي لا تستطيع اختراق الصندوق الأسود الأساسي في مستنقع "ضريبة العادية".