نقل ذاكرة وحدة معالجة الرسومات عالي الأداء على AWS Sagemaker Hyperpod

غالبًا ما تتطلب البنية التحتية الحديثة للتعلم العميق نقل كميات كبيرة من البيانات بين وحدات معالجة الرسومات (GPUs) عبر الأجهزة المختلفة. واجهنا في Perplexity تحديًا تقنيًا فريدًا: وهو نقل مناطق ذاكرة وحدة معالجة الرسومات غير المتجاورة بكفاءة بين الأجهزة بأقصى سرعة ممكنة. تقدم منصتنا المستهدفة، مثيلات AWS p5، نطاقًا تردديًا مذهلاً للشبكة يبلغ 3200 جيجابت في الثانية من خلال 32 بطاقة شبكة. تشارك هذه المقالة رحلتنا في بناء حل شبكي مخصص وعالي الأداء يحقق 97.1% من هذا النطاق الترددي النظري.

التحدي التقني

قدمت حالة الاستخدام الخاصة بنا عدة متطلبات تقنية رئيسية:

• نقل عالي النطاق الترددي بين وحدات معالجة الرسومات البعيدة لأجزاء الذاكرة غير المتجاورة
• القدرة على إضافة أو إزالة العقد ديناميكيًا من نشر Kubernetes دون تعطيل العمليات الجارية
• دعم أنماط الاتصال من نظير إلى نظير

على الرغم من أن مكتبة NCCL من NVIDIA هي المعيار الواقعي للتعلم العميق الموزع، إلا أنها لم تكن مثالية لحالة الاستخدام الخاصة بنا:

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

الشبكات الحديثة عالية الأداء

لفهم حلنا، دعنا نستكشف أولاً كيف تختلف الشبكات الحديثة عالية الأداء عن الشبكات التقليدية.

تعتمد معظم الشبكات التي نستخدمها يوميًا على بروتوكولات TCP/IP، حيث تتواصل التطبيقات مع بطاقة الشبكة من خلال نواة نظام التشغيل باستخدام المقابس. ومع ذلك، تستخدم الشبكات عالية الأداء RDMA (الوصول المباشر للذاكرة عن بُعد) - وهي مجموعة برمجيات ومعدات مختلفة تمامًا تمكن من الوصول المباشر للذاكرة بين الأجهزة دون اشراك وحدة المعالجة المركزية (CPU).

توفر AWS محول النسيج المرن Elastic Fabric Adapter (EFA)، وهو واجهة شبكة مخصصة تنفذ بروتوكول Amazon المخصص المسمى Scalable Reliable Datagram (SRD). على عكس شبكات TCP/IP التقليدية حيث يجب نسخ البيانات عدة مرات بين مساحة المستخدم ومساحة النواة ومخازن الشبكة مؤقتة، يتيح EFA مع RDMA نقل البيانات مباشرة بين ذاكرة وحدة معالجة الرسومات وبطاقة الشبكة، متجاوزًا وحدة المعالجة المركزية تمامًا.

فلسفة تصميم الشبكات عالية الأداء

يتطلب بناء أنظمة شبكية عالية الأداء إعادة التفكير في عدة افتراضات أساسية:

1. ملكية الذاكرة المؤقتة: على عكس المقابس التقليدية حيث تدير النواة مخازن الشبكة المؤقتة وتتطلب النسخ بين مساحة المستخدم ومساحة النواة، تتطلب RDMA أن تدير التطبيقات مخازنها المؤقتة بنفسها. عندما يبدأ التطبيق عملية شبكية، فإنه ينقل ملكية الذاكرة المؤقتة إلى بطاقة الشبكة حتى تكتمل العملية، مما يلغي الحاجة إلى نسخ البيانات.
2. تسجيل الذاكرة: يجب على التطبيقات تسجيل مناطق الذاكرة مع نواة نظام التشغيل. تقوم النواة بإعداد تعيينات العناوين الظاهرية التي تسمح لوحدة المعالجة المركزية، ووحدات معالجة الرسومات، وبطاقات الشبكة بفهم نفس العناوين الظاهرية. هذا التسجيل هو عملية لمرة واحدة تتيح عمليات نقل البيانات اللاحقة بدون نسخ.
3. مستوى التحكم مقابل مستوى البيانات: تفصل الشبكات عالية الأداء العمليات إلى فئتين:
   1. تمر عمليات مستوى التحكم (مثل إعداد الاتصال وتسجيل الذاكرة) عبر النواة لضمان الأمان
   2. تتجاوز عمليات مستوى البيانات (نقل البيانات الفعلي) النواة لتحقيق أقصى أداء
4. الاستقبال قبل الإرسال: بدون المخازن المؤقتة التي تديرها النواة، يجب على التطبيقات نشر عمليات الاستقبال مسبقًا، وتحديد المكان الذي يجب وضع البيانات الواردة فيه. هذا تحول أساسي عن نموذج المقبس حيث يمكن للتطبيقات استقبال البيانات في أي وقت.
5. الإكمال القائم على الاستطلاع: بدلاً من انتظار إشعارات النواة من خلال آليات مثل epoll, تستطلع التطبيقات قوائم انتظار إكمال الأجهزة مباشرة. يتيح ذلك القضاء على الحمل الزائد لنداءات النظام والتفاعل الفوري مع العمليات المكتملة.
6. الوعي بطوبولوجيا الأجهزة: يعد فهم وتحسين طوبولوجيا الأجهزة أمرًا بالغ الأهمية لتحقيق أقصى أداء.

فهم طوبولوجيا الأجهزة

تتمتع مثيلات AWS p5 بنية داخلية متطورة. كما هو موضح أدناه، يحتوي كل مثيل على مقبسي وحدة معالجة مركزية يشكلان عقدتي NUMA، حيث تتصل كل عقدة NUMA بأربعة محولات PCIe:

تكبير

تحت كل محول PCIe، نجد:

• أربع بطاقات شبكة EFA بسرعة 100 جيجابت في الثانية
• وحدة معالجة رسومات NVIDIA H100 واحدة
• محرك NVMe SSD واحد

توضح مسارات البيانات لعمليات نقل TCP/IP و RDMA اختلافات أساسية في نهج كل منها:

تكبير

مع TCP/IP (الجانب الأيسر)، يجب نسخ البيانات عدة مرات:

1. من ذاكرة وحدة معالجة الرسومات إلى الذاكرة المؤقتة للتطبيق في مساحة المستخدم
2. من الذاكرة المؤقتة لمساحة المستخدم إلى الذاكرة المؤقتة للنواة
3. من الذاكرة المؤقتة للنواة إلى بطاقة الشبكة
4. تحدث العملية العكسية على جانب الاستقبال

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

في المقابل، توفر RDMA (الجانب الأيمن) نقل بيانات حقيقي بدون نسخ:

1. تقرأ بطاقة الشبكة مباشرة من ذاكرة وحدة معالجة الرسومات
2. تنتقل البيانات مباشرة إلى بطاقة الشبكة البعيدة
3. تكتب بطاقة الشبكة البعيدة مباشرة إلى ذاكرة وحدة معالجة الرسومات المستهدفة
4. يحتاج التطبيق فقط إلى التحقق من قائمة انتظار الإكمال (CQ) في مساحة المستخدم لمعرفة متى انتهى النقل

مع RDMA والاقتران الصحيح للأجهزة، يتطلب نقل البيانات بين وحدتي معالجة رسومات فقط عبور محول PCIe المحلي والشبكة:

تكبير

في المقابل، يجب أن تنسخ عمليات نقل TCP/IP البيانات عدة مرات عبر الذاكرة الرئيسية، مما يتسبب في ازدحام كبير لناقل PCIe:

تكبير

البناء باستخدام libfabric

استخدمنا libfabric - وهو إطار عمل يوفر واجهة عامة لخدمات النسيج. يستخدم تنفيذنا نوعين من عمليات RDMA:

• RDMA ثنائي الاتجاه (SEND/RECV) لرسائل التحكم التي تحمل بيانات وصفية حول مناطق الذاكرة (مثل الإزاحات والأحجام).
• RDMA WRITE أحادي الاتجاه لنقل البيانات الفعلي، حيث تتعامل كل عملية WRITE مع قطعة ذاكرة متجاورة واحدة.

الرحلة إلى ذروة الأداء

تقدم تطويرنا عبر عدة مراحل:

1. تم تنفيذ نقل الرسائل أحادية الاتجاه الأساسية باستخدام SEND/RECV
2. تم التمديد إلى الاتصال ثنائي الاتجاه
3. تمت إضافة GPUDirect RDMA WRITE للنقل المباشر بين وحدات معالجة الرسومات
4. تم التوسيع للتعامل مع عمليات نقل متزامنة متعددة
5. تم إدخال قائمة انتظار العمليات من أجل المتانة
6. تم تحقيق استغلال النطاق الترددي بنسبة 97.4% على بطاقة شبكة واحدة

عند التوسع إلى 32 بطاقة شبكة، قمنا بتنفيذ العديد من التحسينات الحاسمة:

1. قائمة انتظار العمليات: بدلاً من إرسال العمليات مباشرة إلى بطاقات الشبكة، نحافظ على قائمة انتظار على مستوى التطبيق. يوفر هذا متانة ضد ازدحام الشبكة ويبسط نموذج البرمجة.
2. إحماء الشبكة: أدى إنشاء الاتصالات مسبقًا إلى تحسين أداء بدء التشغيل.
3. تعدد السلاسل: سلاسل مخصصة لعمليات الشبكة لكل وحدة معالجة رسومات.
4. تثبيت نواة وحدة المعالجة المركزية: ربط السلاسل بنوى محددة لوحدة المعالجة المركزية لتجنب تأثيرات NUMA وفقدان التخزين المؤقت.
5. تجزئة الحالة: تقليل التنافس بين السلاسل.
6. تجميع العمليات: إرسال عدة عمليات معًا.
7. نشر العملية الكسول: يتم وضع العمليات في قائمة الانتظار في التطبيق أولاً. بعد استطلاع قائمة انتظار الإكمال، نحاول إرسال العمليات المعلقة إلى بطاقة الشبكة، مما يضمن الاستخدام الفعال لموارد الشبكة.
8. تخصيص الموارد الواعي بـ NUMA: تخصيص موارد libfabric مثل قوائم انتظار الإكمال على عقدة NUMA الصحيحة تقليل زمن انتقال الوصول إلى الذاكرة.

من خلال هذه التحسينات، حققنا أداءً نهائيًا قدره 3,108 جيجابت في الثانية - وهو ما يمثل 97.1% من الحد الأقصى النظري للنطاق الترددي.

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

الخاتمة

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

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

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

اقتباس

@online{perplexity2025HighPerformanceGpuMemoryTransferOnAwsSagemakerHyperpod,
  author = {{Perplexity} and Lequn Chen and Phi Hoang},
  title = {{High-performance GPU memory transfer on AWS Sagemaker Hyperpod}},
  date = {2025-02-10},
  url = {https://www.perplexity.ai/hub/blog/high-performance-gpu-memory-transfer-on-aws-sagemaker-hyperpod}
}