تدريب موزع مع Amazon EKS و Torch Distributed Elastic

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

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

يتكون تدريب النموذج الموزع بشكل أساسي من نموذجين:

• نموذج مواز - في التدريب الموازي للنموذج ، يكون النموذج نفسه كبيرًا جدًا بحيث لا يمكن وضعه في ذاكرة وحدة معالجة رسومات واحدة ، وهناك حاجة إلى العديد من وحدات معالجة الرسومات لتدريب النموذج. نموذج GPT-3 الخاص بـ Open AI مع 175 مليار معلمة قابلة للتدريب (حوالي 350 غيغابايت في الحجم) هو مثال جيد على ذلك.
• موازاة البيانات - في التدريب الموازي للبيانات ، يمكن أن يتواجد النموذج في وحدة معالجة رسومات واحدة ، ولكن نظرًا لأن البيانات كبيرة جدًا ، فقد يستغرق تدريب النموذج أيامًا أو أسابيع. يمكن أن يؤدي توزيع البيانات عبر عقد GPU المتعددة إلى تقليل وقت التدريب بشكل كبير.

في هذا المنشور ، نقدم نموذجًا معماريًا لتدريب نماذج PyTorch باستخدام شعلة موزعة مرنة إطار عمل بطريقة موازية للبيانات الموزعة باستخدام خدمة أمازون مطاطا Kubernetes (أمازون EKS).

المتطلبات الأساسية المسبقة

لتكرار النتائج الواردة في هذا المنشور ، فإن الشرط الأساسي الوحيد هو حساب AWS. في هذا الحساب ، نقوم بإنشاء مجموعة EKS و أمازون FSx لستر نظام الملفات. نقوم أيضًا بدفع صور الحاوية إلى ملف سجل الأمازون المرنة للحاويات (Amazon ECR) في الحساب. يتم توفير تعليمات إعداد هذه المكونات حسب الحاجة في جميع أنحاء المنشور.

مجموعات EKS

Amazon EKS هي خدمة حاويات مُدارة لتشغيل تطبيقات Kubernetes وتوسيع نطاقها على AWS. باستخدام Amazon EKS ، يمكنك تشغيل وظائف التدريب الموزعة بكفاءة باستخدام الأحدث الأمازون الحوسبة المرنة السحابية (Amazon EC2) دون الحاجة إلى تثبيت مستوى أو عقد التحكم الخاصة بك وتشغيلها وصيانتها. إنه مشهور منسق لتعلم الآلة (ML) وسير عمل الذكاء الاصطناعي. تبدو مجموعة EKS النموذجية في AWS مثل الشكل التالي.

لقد أطلقنا مشروع مفتوح المصدر ، AWS DevOps لـ EKS (aws-do-eks)، والذي يوفر مجموعة كبيرة من البرامج النصية والأدوات سهلة الاستخدام والقابلة للتكوين لتوفير مجموعات EKS وتشغيل وظائف التدريب الموزعة. تم بناء هذا المشروع وفقًا لمبادئ هل الإطار: البساطة والمرونة والعالمية. يمكنك تكوين المجموعة التي تريدها باستخدام ملف eks.conf file ثم قم بتشغيله عن طريق تشغيل ملف eks-create.sh النصي. يتم توفير إرشادات مفصلة في جيثب ريبو.

تدريب نماذج PyTorch باستخدام Torch Distributed Elastic

Torch Distributed Elastic (TDE) هي مكتبة PyTorch أصلية لتدريب نماذج التعلم العميق واسعة النطاق حيث يكون من الأهمية بمكان قياس موارد الحوسبة ديناميكيًا بناءً على التوافر. ال TorchElastic Controller لـ Kubernetes هو تطبيق Kubernetes أصلي لـ TDE يدير تلقائيًا دورة حياة الكبسولات والخدمات المطلوبة لتدريب TDE. يسمح بتحجيم موارد الحوسبة ديناميكيًا أثناء التدريب حسب الحاجة. كما يوفر تدريبًا على تحمل الأخطاء من خلال استعادة الوظائف من فشل العقدة.

في هذا المنشور ، نناقش خطوات تدريب PyTorch شبكة فعالة-B7 و ريسنت 50 النماذج التي تستخدم IMAGEnet البيانات بطريقة موزعة مع TDE. نحن نستخدم PyTorch البيانات الموزعة الموازية API ووحدة التحكم Kubernetes TorchElastic ، وتشغيل وظائفنا التدريبية على مجموعة EKS التي تحتوي على عقد GPU متعددة. يوضح الرسم التخطيطي التالي مخطط العمارة لهذا التدريب النموذجي.

يتكون TorchElastic for Kubernetes بشكل أساسي من مكونين: وحدة تحكم TorchElastic Kubernetes (TEC) وخادم المعلمات (إلخ). وحدة التحكم مسؤولة عن مراقبة وإدارة وظائف التدريب ، ويتعقب خادم المعلمات عقد العمال للمزامنة الموزعة واكتشاف الأقران.

لكي تتمكن وحدات التدريب من الوصول إلى البيانات ، نحتاج إلى حجم بيانات مشترك يمكن تركيبه بواسطة كل جراب. بعض الخيارات للأحجام المشتركة من خلال واجهة تخزين الحاوية (CSI) برامج تشغيل مدرجة في AWS DevOps لـ EKS . نظام ملفات أمازون المرن (Amazon EFS) و FSx للبريق.

إعداد الكتلة

في تكوين المجموعة لدينا ، نستخدم مثيل c5.2xlarge واحد لبودات النظام. نستخدم ثلاث مثيلات p4d.24xlarge كقرون عاملة لتدريب نموذج EfficientNet. لتدريب ResNet50 ، نستخدم مثيلات p3.8xlarge كقرون عاملة. بالإضافة إلى ذلك ، نستخدم نظام الملفات المشتركة FSx لتخزين بيانات التدريب الخاصة بنا ومصنوعات النماذج.

تم تجهيز مثيلات AWS p4d.24xlarge بـ محول النسيج المرن (EFA) لتوفير التواصل بين العقد. سنناقش التعليم للجميع لاحقًا في هذا المنشور. لتمكين الاتصال من خلال EFA ، نحتاج إلى تكوين إعداد الكتلة من خلال ملف .yaml. ان مثال على الملف يتم توفيره في مستودع GitHub.

بعد تكوين ملف .yaml هذا بشكل صحيح ، يمكننا تشغيل الكتلة باستخدام البرنامج النصي المتوفر في GitHub repo:

./eks-create.sh

الرجوع إلى جيثب ريبو للحصول على تعليمات مفصلة.

لا يوجد فرق عمليًا بين تشغيل المهام على p4d.24xlarge و p3.8xlarge. الخطوات الموضحة في هذا المنشور تعمل لكليهما. الاختلاف الوحيد هو توفر EFA على مثيلات p4d.24xlarge. بالنسبة للطرز الأصغر مثل ResNet50 ، فإن الشبكات القياسية مقارنة بشبكات EFA لها تأثير ضئيل على سرعة التدريب.

FSx لنظام الملفات Luster

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

بافتراض أن مجموعة EKS تعمل ، وأن معرف الشبكة الفرعية لمنطقة توافر الخدمات معروف ، يمكننا إعداد نظام ملفات FSx من خلال توفير المعلومات الضرورية في fsx.conf ملف كما هو موضح في التمهيدي وتشغيل نشر النصي في FSX مجلد. يقوم هذا بإعداد السياسة الصحيحة ومجموعة الأمان للوصول إلى نظام الملفات. يقوم البرنامج النصي أيضًا بتثبيت ملف سائق CSI ل FSx كشيطان. أخيرًا ، يمكننا إنشاء مطالبة وحدة التخزين الثابتة FSx في Kubernetes من خلال تطبيق ملف .yaml واحد:

kubectl apply -f fsx-pvc-dynamic.yaml

يؤدي هذا إلى إنشاء نظام ملفات FSx في منطقة توافر الخدمات المحددة في ملف fsx.conf ملف ، وأيضًا إنشاء مطالبة ثابتة بالوحدة fsx-pvc، والتي يمكن تركيبها بواسطة أي من الكبسولات في الكتلة بطريقة القراءة والكتابة والكتابة (RWX).

في تجربتنا ، استخدمنا بيانات ImageNet الكاملة ، والتي تحتوي على أكثر من 12 مليون صورة تدريبية مقسمة إلى 1,000 فصل. يمكن تنزيل البيانات من ملف موقع ImageNet الإلكتروني. تحتوي كرة TAR الأصلية على العديد من الأدلة ، ولكن بالنسبة لتدريب نموذجنا ، فنحن مهتمون بها فقط ILSVRC/Data/CLS-LOC/والذي يتضمن train و val الدلائل الفرعية. قبل التدريب ، نحتاج إلى إعادة ترتيب الصور في ملف val دليل فرعي لمطابقة بنية الدليل المطلوبة من قبل PyTorch مجلد الصور صف دراسي. يمكن القيام بذلك باستخدام ملف بيثون النصي بعد نسخ البيانات إلى وحدة التخزين الثابتة في الخطوة التالية.

لنسخ البيانات من ملف خدمة تخزين أمازون البسيطة (Amazon S3) إلى نظام ملفات FSx ، نقوم بإنشاء صورة Docker تتضمن برامج نصية لهذه المهمة. تم تضمين مثال Dockerfile و shell script في ملف منظمة التضامن المسيحي الدولية مجلد داخل GitHub repo. يمكننا بناء الصورة باستخدام ملف build.sh ثم ادفعه إلى Amazon ECR باستخدام ملف push.sh النصي. قبل استخدام هذه البرامج النصية ، نحتاج إلى توفير URI الصحيح لمستودع ECR في ملف .env ملف في المجلد الجذر من GitHub repo. بعد دفع صورة Docker إلى Amazon ECR ، يمكننا تشغيل pod لنسخ البيانات عن طريق تطبيق ملف .yaml ذي الصلة:

kubectl apply -f fsx-data-prep-pod.yaml

يقوم الكبسولة بتشغيل البرنامج النصي تلقائيًا data-prep.sh لنسخ البيانات من Amazon S3 إلى وحدة التخزين المشتركة. نظرًا لأن بيانات ImageNet تحتوي على أكثر من 12 مليون ملف ، فإن عملية النسخ تستغرق ساعتين. نص بايثون imagenet_data_prep.py يتم تشغيله أيضًا لإعادة ترتيب val مجموعة البيانات كما هو متوقع بواسطة PyTorch.

تسريع الشبكة

يمكننا استخدام محول النسيج المرن (EFA) بالاشتراك مع أنواع مثيلات EC2 المدعومة لتسريع حركة مرور الشبكة بين عقد GPU في مجموعتك. يمكن أن يكون هذا مفيدًا عند تشغيل وظائف تدريب كبيرة موزعة حيث قد يكون اتصال الشبكة القياسي بمثابة عنق زجاجة. يتم تضمين البرامج النصية لنشر واختبار المكون الإضافي لجهاز EFA في مجموعة EKS التي نستخدمها هنا في ملف efa-device-plugin مجلد في GitHub repo. لتمكين وظيفة مع EFA في مجموعة EKS الخاصة بك ، بالإضافة إلى عقد المجموعة التي تحتوي على الأجهزة والبرامج الضرورية ، يجب نشر المكون الإضافي لجهاز EFA في المجموعة ، ويجب أن يكون لحاوية وظيفتك CUDA و NCCL متوافقان الإصدارات تثبيت.

لإثبات تشغيل اختبارات NCCL وتقييم أداء EFA على مثيلات p4d.24xlarge ، يجب أولاً نشر مشغل Kubeflow MPI من خلال تشغيل المطابق نشر النصي في عامل MPI مجلد. ثم نقوم بتشغيل ملف نشر البرنامج النصي وتحديث اختبار efa-nccl.yaml يظهر ذلك حدود وطلبات الموارد vpc.amazonaws.com يتم تعيينها على 4. يتم تجميع محولات EFA الأربعة المتوفرة في العقد p4d.24xlarge معًا لتوفير أقصى قدر من الإنتاجية.

يجري kubectl apply -f ./test-efa-nccl.yaml لتطبيق الاختبار ثم عرض سجلات حجرة الاختبار. يؤكد السطر التالي في إخراج السجل أنه يتم استخدام EFA:

NCCL INFO NET/OFI Selected Provider is efa

يجب أن تبدو نتائج الاختبار مشابهة للمخرجات التالية:

[1,0]<stdout>:#                                                       out-of-place                       in-place
[1,0]<stdout>:#       size         count      type   redop     time   algbw   busbw  error     time   algbw   busbw  error
[1,0]<stdout>:#        (B)    (elements)                       (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
[1,0]<stdout>:           8             2     float     sum    629.7    0.00    0.00  2e-07    631.4    0.00    0.00  1e-07
[1,0]<stdout>:          16             4     float     sum    630.5    0.00    0.00  1e-07    628.1    0.00    0.00  1e-07
[1,0]<stdout>:          32             8     float     sum    627.6    0.00    0.00  1e-07    628.2    0.00    0.00  1e-07
[1,0]<stdout>:          64            16     float     sum    633.6    0.00    0.00  1e-07    628.4    0.00    0.00  6e-08
[1,0]<stdout>:         128            32     float     sum    627.5    0.00    0.00  6e-08    632.0    0.00    0.00  6e-08
[1,0]<stdout>:         256            64     float     sum    634.5    0.00    0.00  6e-08    636.5    0.00    0.00  6e-08
[1,0]<stdout>:         512           128     float     sum    634.8    0.00    0.00  6e-08    635.2    0.00    0.00  6e-08
[1,0]<stdout>:        1024           256     float     sum    646.6    0.00    0.00  2e-07    643.6    0.00    0.00  2e-07
[1,0]<stdout>:        2048           512     float     sum    745.0    0.00    0.01  5e-07    746.0    0.00    0.01  5e-07
[1,0]<stdout>:        4096          1024     float     sum    958.2    0.00    0.01  5e-07    955.8    0.00    0.01  5e-07
[1,0]<stdout>:        8192          2048     float     sum    963.0    0.01    0.02  5e-07    954.5    0.01    0.02  5e-07
[1,0]<stdout>:       16384          4096     float     sum    955.0    0.02    0.03  5e-07    955.5    0.02    0.03  5e-07
[1,0]<stdout>:       32768          8192     float     sum    975.5    0.03    0.06  5e-07   1009.0    0.03    0.06  5e-07
[1,0]<stdout>:       65536         16384     float     sum   1353.4    0.05    0.09  5e-07   1343.5    0.05    0.09  5e-07
[1,0]<stdout>:      131072         32768     float     sum   1395.9    0.09    0.18  5e-07   1392.6    0.09    0.18  5e-07
[1,0]<stdout>:      262144         65536     float     sum   1476.7    0.18    0.33  5e-07   1536.3    0.17    0.32  5e-07
[1,0]<stdout>:      524288        131072     float     sum   1560.3    0.34    0.63  5e-07   1568.3    0.33    0.63  5e-07
[1,0]<stdout>:     1048576        262144     float     sum   1599.2    0.66    1.23  5e-07   1595.3    0.66    1.23  5e-07
[1,0]<stdout>:     2097152        524288     float     sum   1671.1    1.25    2.35  5e-07   1672.5    1.25    2.35  5e-07
[1,0]<stdout>:     4194304       1048576     float     sum   1785.1    2.35    4.41  5e-07   1780.3    2.36    4.42  5e-07
[1,0]<stdout>:     8388608       2097152     float     sum   2133.6    3.93    7.37  5e-07   2135.0    3.93    7.37  5e-07
[1,0]<stdout>:    16777216       4194304     float     sum   2650.9    6.33   11.87  5e-07   2649.9    6.33   11.87  5e-07
[1,0]<stdout>:    33554432       8388608     float     sum   3422.0    9.81   18.39  5e-07   3478.7    9.65   18.09  5e-07
[1,0]<stdout>:    67108864      16777216     float     sum   4783.2   14.03   26.31  5e-07   4782.6   14.03   26.31  5e-07
[1,0]<stdout>:   134217728      33554432     float     sum   7216.9   18.60   34.87  5e-07   7240.9   18.54   34.75  5e-07
[1,0]<stdout>:   268435456      67108864     float     sum    12738   21.07   39.51  5e-07    12802   20.97   39.31  5e-07
[1,0]<stdout>:   536870912     134217728     float     sum    24375   22.03   41.30  5e-07    24403   22.00   41.25  5e-07
[1,0]<stdout>:  1073741824     268435456     float     sum    47904   22.41   42.03  5e-07    47893   22.42   42.04  5e-07
[1,4]<stdout>:test-efa-nccl-worker-0:33:33 [4] NCCL INFO comm 0x7fd4a0000f60 rank 4 nranks 16 cudaDev 4 busId 901c0 - Destroy COMPLETE
[1,0]<stdout>:# Out of bounds values : 0 OK
[1,0]<stdout>:# Avg bus bandwidth    : 8.23785

يمكننا أن نلاحظ في نتائج الاختبار أن الحد الأقصى للإنتاجية يبلغ حوالي 42 جيجابايت / ثانية ومتوسط ​​عرض النطاق الترددي للناقل حوالي 8 جيجابايت.

أجرينا أيضًا تجارب مع محول EFA واحد ممكّن بالإضافة إلى عدم وجود محولات EFA. تم تلخيص جميع النتائج في الجدول التالي.

وجدنا أيضًا أنه بالنسبة للنماذج الصغيرة نسبيًا مثل ImageNet ، فإن استخدام الشبكات المعجلة يقلل من وقت التدريب لكل فترة فقط بنسبة 5-8٪ بحجم دفعة 64. بالنسبة للنماذج الأكبر حجمًا وأحجام الدُفعات الأصغر ، عند الحاجة إلى زيادة اتصال الشبكة للأوزان ، فإن استخدام الشبكات المعجلة له تأثير أكبر. لاحظنا انخفاضًا في وقت التدريب في الفترة من 15 إلى 18٪ لتدريب EfficientNet-B7 مع حجم الدفعة 1. وسيعتمد التأثير الفعلي لـ EFA على تدريبك على حجم نموذجك.

مراقبة GPU

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

توجد البرامج النصية ذات الصلة بإعداد CloudWatch في مقاييس gpu مجلد. أولاً ، نقوم بإنشاء صورة Docker بامتداد amazon-cloudwatch-agent و nvidia-smi. يمكننا استخدام Dockerfile في ملف gpu-metrics مجلد لإنشاء هذه الصورة. بافتراض أن سجل ECR قد تم تعيينه بالفعل في ملف .env من الخطوة السابقة ، يمكننا بناء الصورة ودفعها باستخدام build.sh و push.sh. بعد ذلك ، يتم تشغيل ملف deploy.sh البرنامج النصي يكمل الإعداد تلقائيًا. تطلق مجموعة شيطان مع amazon-cloudwatch-agent ويدفع المقاييس المختلفة إلى CloudWatch. تظهر مقاييس وحدة معالجة الرسومات أسفل ملف CWAgent مساحة على وحدة تحكم CloudWatch. تظهر بقية المقاييس العنقودية تحت ContainerInsights مساحة الاسم.

تدريب نموذجي

توجد جميع البرامج النصية اللازمة لتدريب PyTorch في ملف وظيفة مرنة مجلد في GitHub repo. قبل بدء وظيفة التدريب ، نحتاج إلى تشغيل etcd الخادم ، الذي يستخدمه TEC لاكتشاف العامل وتبادل المعلمات. ال نشر النصي في elasticjob مجلد يفعل ذلك بالضبط.

للاستفادة من EFA في مثيلات p4d.24xlarge ، نحتاج إلى استخدام صورة Docker محددة متوفرة في معرض أمازون ECR العام التي تدعم اتصالات NCCL من خلال EFA. نحتاج فقط إلى نسخ رمز التدريب الخاص بنا إلى صورة Docker هذه. ال Dockerfile تحت عينات يُنشئ المجلد صورة لاستخدامها عند تشغيل مهمة تدريب على مثيلات p4d. كما هو الحال دائمًا ، يمكننا استخدام ملف build.sh و دفع البرامج النصية في المجلد لبناء الصورة ودفعها.

• imagenet-efa.yaml يصف الملف وظيفة التدريب. يقوم ملف .yaml هذا بإعداد الموارد اللازمة لتشغيل مهمة التدريب وأيضًا تحميل الحجم الدائم ببيانات التدريب التي تم إعدادها في القسم السابق.

هناك شيئان يستحقان الإشارة هنا. يجب تعيين عدد النسخ المتماثلة على عدد العقد المتاحة في الكتلة. في حالتنا ، قمنا بتعيين هذا على 3 لأن لدينا ثلاث عقد كبيرة p4d.24x. في ال imagenet-efa.yaml ملف nvidia.com/gpu المعلمة تحت الموارد و nproc_per_node مع args يجب تعيينها على عدد وحدات معالجة الرسومات لكل عقدة ، والتي في حالة p4d.24xlarge هي 8. أيضًا ، تحدد وسيطة العامل في برنامج Python النصي عدد وحدات المعالجة المركزية لكل عملية. لقد اخترنا هذا ليكون 4 لأنه ، في تجاربنا ، يوفر هذا الأداء الأمثل عند التشغيل على مثيلات p4d.24xlarge. هذه الإعدادات ضرورية من أجل تعظيم استخدام جميع موارد الأجهزة المتوفرة في الكتلة.

عندما تكون المهمة قيد التشغيل ، يمكننا ملاحظة استخدام GPU في CloudWatch لجميع وحدات معالجة الرسومات في المجموعة. فيما يلي مثال من إحدى وظائف التدريب لدينا مع ثلاث عقد p4d.24xlarge في المجموعة. هنا اخترنا GPU واحدًا من كل عقدة. مع الإعدادات المذكورة سابقًا ، يقترب استخدام GPU من 100٪ أثناء مرحلة التدريب للعصر لجميع العقد في المجموعة.

لتدريب نموذج ResNet50 باستخدام مثيلات p3.8xlarge ، نحتاج تمامًا إلى نفس الخطوات الموضحة لتدريب EfficientNet باستخدام p4d.24xlarge. يمكننا أيضًا استخدام نفس صورة Docker. كما ذكرنا سابقًا ، مثيلات p3.8xlarge غير مجهزة بـ EFA. ومع ذلك ، بالنسبة لطراز ResNet50 ، هذا ليس عيبًا كبيرًا. ال imagenet-fsx.yaml يقوم البرنامج النصي المتوفر في مستودع GitHub بإعداد مهمة التدريب بالموارد المناسبة لنوع العقدة p3.8xlarge. تستخدم الوظيفة نفس مجموعة البيانات من نظام ملفات FSx.

تحجيم GPU

أجرينا بعض التجارب لملاحظة كيفية قياس وقت التدريب لنموذج EfficientNet-B7 من خلال زيادة عدد وحدات معالجة الرسومات. للقيام بذلك ، قمنا بتغيير عدد النسخ المتماثلة من 1 إلى 3 في ملف التدريب .yaml الخاص بنا لكل دورة تدريبية. لاحظنا فقط وقت حقبة واحدة أثناء استخدام مجموعة بيانات ImageNet الكاملة. يوضح الشكل التالي نتائج تجربة تحجيم GPU الخاصة بنا. يمثل الخط الأحمر المنقط كيف يجب أن ينخفض ​​وقت التدريب من التشغيل باستخدام 8 وحدات معالجة رسومات عن طريق زيادة عدد وحدات معالجة الرسومات. كما نرى ، فإن القياس قريب جدًا مما هو متوقع.

وبالمثل ، حصلنا على مخطط تحجيم GPU لتدريب ResNet50 على مثيلات p3.8xlarge. في هذه الحالة ، قمنا بتغيير النسخ المتماثلة في ملف .yaml الخاص بنا من 1 إلى 4. تظهر نتائج هذه التجربة في الشكل التالي.

تنظيف

من المهم تدوير الموارد بعد تدريب النموذج لتجنب التكاليف المرتبطة بتشغيل مثيلات الخمول. مع كل برنامج نصي يُنشئ الموارد ، فإن ملف جيثب ريبو يوفر نصًا برمجيًا مطابقًا لحذفها. لتنظيف الإعداد الخاص بنا ، يجب علينا حذف نظام ملفات FSx قبل حذف الكتلة لأنها مرتبطة بشبكة فرعية في VPC للكتلة. لحذف نظام ملفات FSx ، نحتاج فقط إلى تشغيل الأمر التالي (من داخل ملف FSX مجلد):

kubectl delete -f fsx-pvc-dynamic.yaml
./delete.sh

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

./eks-delete.sh

سيؤدي هذا إلى حذف جميع البودات الموجودة وإزالة الكتلة وحذف VPC الذي تم إنشاؤه في البداية.

وفي الختام

في هذا المنشور ، قمنا بتفصيل الخطوات اللازمة لتشغيل تدريب نموذج البيانات المتوازي الموزع من PyTorch على مجموعات EKS. قد تبدو هذه المهمة شاقة ، ولكن AWS DevOps لـ EKS يوفر المشروع الذي أنشأه فريق ML Frameworks في AWS جميع البرامج النصية والأدوات اللازمة لتبسيط العملية وتسهيل الوصول إلى تدريب النموذج الموزع.

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

الموارد

عن المؤلفين

عمران يونس هو مهندس حلول رئيسي لفريق ML Frameworks في AWS. إنه يركز على التعلم الآلي واسع النطاق وأعباء عمل التعلم العميق عبر خدمات AWS مثل Amazon EKS و AWS ParallelCluster. يتمتع بخبرة واسعة في تطبيقات الميول العميقة في رؤية الكمبيوتر وإنترنت الأشياء الصناعي. حصل عمران على درجة الدكتوراه في فيزياء الجسيمات عالية الطاقة حيث شارك في تحليل البيانات التجريبية بمقاييس بيتا بايت.

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