تمكين نماذج بمليارات المعلمات على AWS EFA

في Perplexity، نستخدم أفضل النماذج لمنتجنا واجهات برمجة التطبيقات الخاصة بنا وفرق الأبحاث لدينا. تطرح نماذج مزيج الخبراء (Mixture-of-Experts) الكبيرة المفتوحة المصدر، مثل Kimi-K2، تحديات خاصة، نظراً لأن أكبر عقد الاستدلال المزودة بـ 8 وحدات معالجة رسومية (GPUs) من نوع NVIDIA H200 لا يمكنها استيعابها بكفاءة، مما يستوجب نشرها عبر عقد متعددة. نحن نعرض مجموعة من النوى لتوازي الخبراء والتي تحقق زمن استجابة رائد في هذا المجال على ConnectX-7، متجاوزة أداء DeepEP. كما أن النوى نفسها هي الأولى التي تحقق زمن استجابة عملياً على محول النسيج المرن من أمازون (AWS Elastic Fabric Adapter - EFA)، مما يتيح نشر نماذج بمليارات المعلمات (trillion-parameter).

جرب النوى الخاصة بنا على GitHub واقرأ ورقة البحث الكاملة على arXiv.

المقدمة

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

على عكس الأشكال الأخرى من التوازي، مثل توازي الموتر (Tensor Parallelism - TP) وتوازي البيانات (Data Parallelism - DP) والتي يمكن تنفيذها بسهولة باستخدام مكتبات الاتصال الجماعي مثل torch.distributed و NCCL، يتضمن توجيه MoE اتصالاً جماعياً من نظير إلى نظير (peer-to-peer) متفرقاً. يجب أن تقسم نواة الإرسال (dispatch kernel) مجموعة الرموز الواردة وترسلها إلى الرتب التي تستضيف الخبراء، بينما يجب على مشكلتها المزدوجة، وهي نواة الدمج (combine kernel), استقبال نظيراتها المعالجة وحساب متوسطها المرجح. لا تعتمد عمليات النقل هذه على العمليات الجماعية وتتطلب نوى مخصصة لتحقيق زمن استجابة منخفض.

في Perplexity، طوّرنا نوى محمولة بين العقد ونوى مخصصة داخل العقد، وقدمنا عملنا بعمق أكبر في مقال سابق حول اتصال MoE. كما أوضحنا في منشور مدونة آخر أن النشر عبر عقد متعددة يمكن أن يجلب زمن استجابة أقل وإنتاجية أعلى لنماذج MoE الكبيرة.

في هذا المقال، نتعمق في تنفيذ نوانا الجديدة بين العقد والتي تحسن بشكل كبير أداء عملنا السابق القائم على NVSHMEM. إلى جانب عرض النتائج الرائدة على ConnectX-7، نثبت أيضاً أنه ضمن بيئة وقت تشغيل الاستدلال الخاصة بنا، يمكن استخدام النوى لخدمة أكبر نماذج المصدر المفتوح بفعالية.

الاستدلال عبر InfiniBand

يمكن للتماثل الموازي للموترات والتماثل الموازي للخبراء أن يوسّعا النطاق بفعالية داخل عقدة واحدة، إذ يوفّر NVLink إنتاجية عالية (900GB/s) مع زمن انتقال بمستوى الميكروثانية. وبينما تأتي أنظمة NVIDIA GB200 وGB300 مزوّدة بذاكرة كافية لاحتواء الأوزان وذاكرات التخزين المؤقت KV لنماذج ذات تريليونات المعلمات، فإن عمليات النشر على مثيل AWS p5en المزود بما يصل إلى 8 وحدات معالجة رسومية H200 تكون محدودة بـ 1120GB من HBM، والتي يجب توزيعها بين أوزان النموذج وذاكرات التخزين المؤقت KV. وبالتالي، تتطلب بعض النماذج عمليات نشر بين العقد عبر InfiniBand. 

على الرغم من أن InfiniBand لا يزال سريعاً للغاية، إلا أنه يوفر إنتاجية تبلغ 400 جيجابت في الثانية (50 جيجابايت/ثانية) فقط، مما يضيف عشرات إلى مئات الميكروثانية من زمن الاستجابة لتوجيه MoE. لحسن الحظ، يمكن إخفاء زمن الاستجابة المضاف من خلال استخدام الخبراء المشتركين، والدفعات الصغيرة (micro-batching)، والتداخل بين الحساب والاتصال لتوفير إنتاجية قابلة للتطبيق بتكلفة تنافسية. قادت DeepSeek هذه التقنيات عبر DeepSeek-R1، المنشورة على عناقيد (clusters) من وحدات معالجة رسومية H800 ومحولات NVIDIA ConnectX-7 InfiniBand.

على عناقيد AWS، يختلف الوضع بسبب استخدام محولات النسيج المرن المخصصة الخاصة بهم (EFA). على الرغم من أنها توفر إنتاجية قصوى تبلغ 400 جيجابت في الثانية على العمليات الجماعية المستخدمة عادةً في أحمال عمل التدريب، إلا أنها تقصر قليلاً عن ConnectX-7 على أحجام الرسائل المتبادلة أثناء إرسال ودمج MoE. بالإضافة إلى ذلك، لا يدعم EFA خاصية GPUDirect Async، مما يتطلب سلسلة (thread) وكيل وحدة المعالجة المركزية (CPU) تربط وحدة المعالجة الرسومية ببطاقة واجهة الشبكة (NIC) من أجل بدء عمليات النقل. وإلى جانب التعقيد المضاف، تضيف معاملات PCIe الإضافية حملاً زائداً يعادل ميكروثانية لجميع عمليات النقل. تتيح الأطر مثل NVSHMEM لكتابة النوى توفير عمليات تنفيذ مستقلة عن الجهاز، ومع ذلك فإن واجهات برمجة التطبيقات العامة تتسبب في حمل زائد يجعل عمليات النشر غير فعالة من حيث التكلفة وزمن الاستجابة.

نوى pplx القائمة على NVSHMEM

جردت نوانا السابقة تطبيق النقل الأساسي من خلال NVSHMEM. لقد اعتمدت على nvshmemx_putmem_signal_nbi_warp لنقل الرموز واحداً تلو الآخر، باستخدام عدادات ذرية لمزامنة الأقران. في حين أن هذا قدم أداءً معقولاً على بطاقات NIC من نوع ConnectX-7 مع IBGDA، فإن تنفيذ ConnectX-7 IBRC القائم على الوكيل كان أبطأ بكثير، بينما فشل تنفيذ EFA في توفير زمن استجابة أقل من جزء من الألف من الثانية (millisecond).

لقد استخدمنا النوى كمنصة اختبار للأجهزة الأساسية، مع تحديد الواجهة الأكثر ملاءمة لعرضها على نماذجنا. افترضنا أن عمليات النقل والتفاعلات المتكررة بين النوى وبطاقات NIC أو سلاسل الوكيل (proxy threads) تعيق الأداء. بالإضافة إلى ذلك، لم يعتمد تنفيذنا على أي ضمانات من الأجهزة بخلاف الموثوقية، مما يشير إلى أنه يمكننا تسريع الأمور عن طريق تقليل العبء الزائد لعمليات البدء والمزامنة (synchronization primitives).

في أعقاب هذه الملاحظات، ابتكرنا نوانا القائمة على EFA والتي تعرض نفس الواجهة، مع تحسين تفاعلات نواة الجهاز مع وكيل المضيف (host proxy) تحت الغطاء لتحقيق أقصى أداء.

توجيه MoE من نوع All-to-All عبر EFA

تكبير

تتبع النوى الجديدة بنية هجينة لوحدة المعالجة المركزية ووحدة المعالجة الرسومية (CPU-GPU)، حيث تتفاعل نوى وحدة المعالجة الرسومية مع النموذج على الجهاز، بينما تتولى سلسلة (thread) وكيل تعمل على وحدة المعالجة المركزية للمضيف التعامل مع التفاعلات مع بطاقة NIC. تعيد النوى الجديدة استخدام محرك النقل TransferEngine نفسه الذي بنيناه لـعمليات نقل ذاكرة التخزين المؤقت KV.

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

تنقسم كل من نوى الإرسال والدمج إلى نصفين: مرسل ومستقبل لتسهيل التداخل والدفعات الصغيرة. يقوم المرسل بخلط الرموز في مخازن الإرسال المؤقتة (buffers) بحيث يمكن كتابتها إلى الأقران من خلال عملية كتابة RDMA واحدة. بعد تنفيذ المرسل، يمكن لوحدة المعالجة الرسومية إجراء عمل آخر (مثل ضرب الخبير المشترك) بينما تكون عمليات النقل عبر الشبكة قيد الانتظار في الخلفية. تتوقف نوى المستقبل (receiver kernels) مؤقتاً حتى يتم استلام جميع عمليات النقل. في الخلفية، تتولى سلسلة عاملة على جانب المضيف (host-side worker thread) عمليات النقل: يتم إرسال إشارة لها من قبل وحدة المعالجة الرسومية عندما يتم ملء مخازن الإرسال المؤقتة، وبعد ذلك تقوم بإرسال كتابات RDMA. بمجرد أن تشير بطاقة NIC إلى الانتهاء، فإنها تلغي حظر المستقبل، والذي بدوره يعيد الرموز إلى النموذج.

النوى مقترنة بشكل وثيق مع المضيف، وتتواصل مع بعضها البعض من خلال كل من الذاكرة الموحدة (unified memory) و GDRCopy. تتيح الذاكرة الموحدة لـ CUDA تعيين ذاكرة الجهاز أو ذاكرة المضيف في مساحات العنوان لكليهما، والتعامل بشفافية مع الاتصال عبر PCIe.

بينما الذاكرة الموحدة مناسبة عمليات النقل الكبيرة، يتم إجراء الاستطلاع منخفض زمن الاستجابة من خلال GDRCopy. يستخدم GDRCopy خاصية GPUDirect RDMA للقراءة والكتابة في ذاكرة وحدة المعالجة الرسومية بزمن استجابة يقدر بالميكروثانية.

بالإضافة إلى RDMA، داخل العقدة الواحدة تستفيد النوى أيضاً من NVLink لتبادل الرموز. يمكن أن يؤدي ذلك إلى تفريغ جزء كبير من حركة المرور، يصل إلى ربع للـ EP32 وثمن للـ EP64، مما يحقق أزمنة استجابة إجمالية أقل.

مخازن الإرسال والاستقبال المؤقتة

يعتبر تصميم مخازن الإرسال المؤقتة لنواة الإرسال أمراً بالغ الأهمية لتحقيق أزمنة استجابة قابلة للتطبيق تتضمن وكيل المضيف. إذا كان هناك N من الرتب ترسل كل منها T من الرموز، وكل منها موجّه إلى R من الخبراء من أصل E، يمكن أن تتلقى الرتبة ما يصل إلى N * T * max(R, E / N) من الرموز في أسوأ حالة ممكنة، إذا تم توجيهها جميعاً إليها. علاوة على ذلك، لا يمكن تحقيق هذا الحد الأدنى إلا عندما يقوم المرسلون بتنظيم كتاباتهم بشكل متتابع، حيث أن مخازن الاستقبال الخاصة ستستهلك مساحة كبيرة جداً من الذاكرة. لكي يتمكن المرسلون من تنظيم كتاباتهم بشكل متتالي دون تعارضات، يجب توزيع المعرفة الكاملة بمعلومات التوجيه على كل رتبة. ونتيجة لذلك، تتبادل نوى الإرسال الخاصة بنا أولاً عدد الرموز لكل خبير، وبعد ذلك يمكن لكل منها تحديد مكان ذهاب كتاباتها والإزاحة التي تستقبل الرموز منها لكل رتبة.

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

تكبير

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

بالنسبة لـ NVLink، يتم تعيين مخازن الإرسال والاستقبال المؤقتة داخل العقدة في الأقران لتمكينهم من دفع أو سحب الرموز مباشرة من الرتب المجاورة.

الإرسال والدمج

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

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

تكبير

تكبير

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

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

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

محرك النقل TransferEngine لتوجيه MoE

لإنشاء نموذج أولي لتنفيذنا، أعدنا في البداية استخدام محرك النقل TransferEngine المبني لعمليات التعبئة المسبقة (prefill) وفك التشفير (decode) المنفصلة من أجل إصدار وتتبع كتابات RDMA. ومع ذلك، على عكس فك التشفير المنفصل حيث تنشر كل عقدة عدداً كبيراً من الكتابات إلى نفس النظير، ينشر إرسال MoE عمليات نقل صغيرة لجميع الأقران في عملية واحدة. خارج الصندوق، لم يكن الأداء مثالياً وكان تنفيذنا متخلفاً عن DeepEP على ConnectX-7 بحوالي 20 ميكروثانية. ونتيجة لذلك، قمنا بتخصيص محرك النقل TransferEngine لدعم عمليتين: التوزيع (scatter) والحاجز (barrier)، لتحسين التفاعلات مع عدد كبير من الأقران.

تعرض كل من عمليتي التوزيع والحاجز مجموعات أقران يمكن تسجيلها مسبقاً لملء هياكل البيانات المستخدمة بواسطة تطبيق النقل الأساسي مسبقاً (قوالب طلبات العمل - Work Request (WR) templating). ينسخ التوزيع شرائح مختلفة من نفس المخزن المؤقت للمصدر إلى إزاحات مختلفة على جميع أعضاء مجموعة الأقران. يشير الحاجز إلى جميع الأقران من خلال رسالة فورية. إن طابور ومعالجة هذه العمليات بشكل مجمع يوفر ميكروثانية قيمة على المسار الحرج. على EFA، حيث تتجمع بطاقتا NIC بسعة 200 جيجابت في الثانية لتوفير نطاق ترددي يبلغ 400 جيجابت في الثانية، نقوم بتقسيم أقران المجموعة عبر بطاقتي NIC بدلاً من تقسيم بايتات كل عملية نقل.

على الرغم من أننا طوّرنا محرك النقل TransferEngine في البداية حصرياً على EFA باستخدام libfabric، إلا أن نوى MoE تعمل على ConnectX-7 دون تغيير سطر واحد من الكود بعد إضافة دعم ConnectX-7 في محرك النقل TransferEngine باستخدام libibverbs. مقارنة بـ EFA المستند إلى مخططات Datagram الموثوقة القابلة للتطوير (SRD)، يتطلب ConnectX-7 عمل إضافي لإعداد الاتصال وإدارة الأقران. نحن نستخدم زوج طابور مخططات غير موثوقة (UD) لبدء الاتصال الموثوق (RC). نحن ننشئ زوجي طابور لكل نظير بعيد، واحد للإرسال/الاستقبال ثنائي الاتجاه (SEND/RECV) وواحد للكتابة أحادية الاتجاه الفورية (WRITE_IMM)، لأن كلا من RECV و WRITE_IMM يستهلكان عملية RECV بالترتيب بينما تتطلب العمليتان حجم مخزن مؤقت مختلف. إلى جانب ذلك، نقوم بإرخاء ترتيب معاملات PCIe بين ConnectX-7 وذاكرة وحدة المعالجة الرسومية. على غرار EFA، ننفذ تحسين قوالب WR. بالإضافة إلى ذلك، عند إرسال رسائل صغيرة متعددة إلى نفس النظير، نستخدم تسلسل WR لتحسين معدل الرسائل.

بظن أن العمل على جانب وحدة المعالجة الرسومية متطابق عبر كلا المحولين، فقد دفعنا تطبيق النقل الأساسي إلى حدوده لتجاوز أداء DeepEP لتسليط الضوء على أن الفجوة بين EFA و ConnectX-7 لتوجيه MoE يتم تحديده بواسطة إمكانيات الأجهزة الأساسية.

التقييم

زمن استجابة الإرسال/الدمج

قمنا بتقييم أزمنة استجابة الإرسال والدمج على أنظمة H200 المزودة ببطاقات ConnectX-7 و EFA على تكوين DeepSeek-V3 و Kimi-K2 القياسي مع بُعد خفي قدره 7168، وإرسال fp8 مُحجّم الكتل ودمج bf16. نأخذ في الاعتبار حجم دفعة قدره 128 للإرسال و 4096 للدمج. على ConnectX-7، نقارن بـ DeepEP ونوى pplx السابقة القائمة على NVSHMEM، باستخدام كل من GPUDirect Async (IBGDA) وكيل المضيف (IBRC). يحقق أزمنة استجابة مجتمعة تبلغ 459 ميكروثانية و 582 ميكروثانية و 692 ميكروثانية على EP16 و EP32 و EP64 على التوالي. نحن نتفوق على النوى الأخرى المستندة إلى EFA والتي تعتمد على وكلاء عموميين، مثل UCCL-EP، والتي تحقق 519 ميكروثانية و 966 ميكروثانية و 1159 ميكروثانية.

تكبير

عند فك الترميز، وعلى الرغم من أن نوىنا أبطأ ببضع ميكروثوانٍ من DeepEP، فإننا نحقق زمن انتقال إجماليًا أقل لأن نوى الدمج لدينا أسرع بكثير. وعلى الرغم من أننا نستخدم وكيلًا مضيفًا، فإننا نتجاوز أداء جميع تطبيقات الوكلاء الخالية من الطرق المعتمدة على IBGDA بفضل عمليات النقل الدُفعية لدينا. كما نُظهر أن تنفيذ الوكيل مهم، إذ إن وكيلنا شديد التخصص أسرع بعشر مرات من تنفيذ NVSHMEM العام. وعلى الرغم من أن EFA أبطأ بمرتين من ConnectX-7 عند نقل حزم بحجم 256KB، وهي قريبة من حجم الحزمة النموذجي المتبادل بواسطة توجيه MoE، فإن الفجوة بين المحولين في المجمل أقل وضوحًا.

تكبير

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

إنتاجية Kimi-K2 / DeepSeek-V3

لإثبات جدوى نوانا، نقوم بإجراء اختبار قياسي (benchmark) للأداء الشامل لمحرك الاستدلال الداخلي الخاص بنا الذي يخدم DeepSeek-V3 (671 مليار معلمة) و Kimi-K2 (1 تريليون معلمة) على مثيلات p5en متعددة المزودة بمحولات النسيج المرن (EFA) وحدات معالجة رسومية H200. نقوم بتشغيل النموذج في وضع التحقق من المسودة ونبلغ عن زمن الاستجابة بافتراض معدل قبول بنسبة 80% باستخدام طبقة MTP واحدة.

على DeepSeek-V3، نقارن مقابل خط أساس داخل العقدة بـ EP=8 يقوم بتشغيل نوى إرسال ودمج فعالة تعتمد على NVLink فقط. تطابق عمليات النشر بين العقد بشكل عام أو تتجاوز أداء نشر العقدة الواحدة، لا سيما في الدفعات متوسطة الحجم، مما يوضح أن القياس عبر العقد يجلب تحسينات للإنتاجية الإجمالية.

على Kimi-K2، تمكن النوى من الخدمة. نظراً لحجمه، لا يمكن للنموذج ملاءمة نفس العقدة باستخدام توازي البيانات (DP) على عقدة H200، وبالتالي فإن نشر العقدة البينية مطلوب لخدمة النموذج. نظراً لأن النموذج يحتوي على رؤوس انتباه (attention heads) أقل، فإننا نحقق أزمنة استجابة أفضل من DeepSeek-V3 ويمكننا خدمة النموذج على EFA بزمن استجابة قابل للتطبيق.

تكبير

تكبير

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

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

نحن نعمل عن كثب مع مهندسي AWS لتحسين الأداء على EFA. من جانبنا، سنتابع التحديثات لـ libfabric والتي تقلل من العبء الزائد لسطح البيانات. بالإضافة إلى ذلك، سنقوم بتجربة efa-direct لمزيد من تقليل الأعباء الزائدة لمساحة المستخدم والتفاعل مباشرة مع الأجهزة.

المراجع

التقرير التقني لـ DeepSeek R1

التقرير التقني لـ Kimi K2

DeepEP

UCCL-EP

تحسين أداء شبكة أنظمة الحوسبة عالية الأداء باستخدام NVIDIA Magnum IO NVSHMEM و GPUDirect Async

اقتباس

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}