הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

אימון מבוזר עם Amazon EKS ו-Torch Distributed Elastic

הכשרת מודלים של למידה עמוקה מבוזרת הופכת חשובה יותר ככל שגדלים הנתונים גדלים בתעשיות רבות. יישומים רבים בראייה ממוחשבת ועיבוד שפה טבעית דורשים כיום הכשרה של מודלים של למידה עמוקה, אשר גדלים באופן אקספוננציאלי במורכבות ולעתים קרובות מאומנים עם מאות טרה-בייט של נתונים. אז זה הופך להיות חשוב להשתמש בתשתית ענן עצומה כדי להגדיל את ההכשרה של מודלים גדולים כל כך.

מפתחים יכולים להשתמש במסגרות קוד פתוח כגון PyTorch כדי לעצב בקלות ארכיטקטורות מודל אינטואיטיביות. עם זאת, קנה המידה של האימון של מודלים אלה על פני מספר צמתים יכול להיות מאתגר בגלל מורכבות התזמור המוגברת.

אימון מודל מבוזר מורכב בעיקר משתי פרדיגמות:

  • מקביל לדגם – באימון מקבילי של מודל, הדגם עצמו כל כך גדול שהוא לא יכול להיכנס לזיכרון של GPU בודד, ויש צורך במספר GPUs כדי לאמן את הדגם. דגם ה-GPT-3 של ה-Open AI עם 175 מיליארד פרמטרים הניתנים לאימון (בגודל של כ-350 GB) הוא דוגמה טובה לכך.
  • נתונים מקבילים - באימון מקביל לנתונים, המודל יכול להימצא ב-GPU יחיד, אך מכיוון שהנתונים כה גדולים, זה יכול לקחת ימים או שבועות לאמן מודל. הפצת הנתונים על פני מספר צמתים של GPU יכולה להפחית משמעותית את זמן האימון.

בפוסט זה, אנו מספקים ארכיטקטורה לדוגמה לאימון מודלים של PyTorch באמצעות לפיד מחולק אלסטית מסגרת בנתונים מבוזרים מקבילים באמצעות שירות קוברנט של אמזון (אמזון EKS).

תנאים מוקדמים

כדי לשכפל את התוצאות שדווחו בפוסט זה, התנאי המקדים היחיד הוא חשבון AWS. בחשבון זה, אנו יוצרים אשכול EKS ו- אמזון FSx עבור ברק מערכת קבצים. אנחנו גם דוחפים תמונות מיכל ל-an מרשם מיכל אלסטי של אמזון (Amazon ECR) מאגר בחשבון. הנחיות להגדרת רכיבים אלו מסופקות לפי הצורך לאורך הפוסט.

אשכולות EKS

אמזון EKS הוא שירות קונטיינר מנוהל להפעלה והרחבה של יישומי Kubernetes ב-AWS. עם Amazon EKS, אתה יכול להפעיל ביעילות עבודות הדרכה מבוזרות תוך שימוש בגרסה העדכנית ביותר ענן מחשוב אלסטי של אמזון (Amazon EC2) מופעים ללא צורך בהתקנה, הפעלה ותחזוקה של מטוס או צמתים משלך. זה פופולרי תזמורת עבור למידת מכונה (ML) וזרימות עבודה של AI. אשכול EKS טיפוסי ב-AWS נראה כמו האיור הבא.

פרסמנו פרויקט קוד פתוח, AWS DevOps עבור EKS (aws-do-eks), המספק אוסף גדול של סקריפטים וכלים קלים לשימוש וניתנים להגדרה כדי לספק אשכולות EKS ולהפעיל עבודות הדרכה מבוזרות. פרויקט זה נבנה בהתאם לעקרונות של עשה מסגרת: פשטות, גמישות ואוניברסליות. אתה יכול להגדיר את האשכול הרצוי שלך באמצעות ה eks.conf קובץ ולאחר מכן הפעל אותו על ידי הפעלת ה- eks-create.sh תַסרִיט. הנחיות מפורטות מסופקות ב- GitHub ריפו.

אימון דגמי PyTorch באמצעות Torch Distributed Elastic

Torch Distributed Elastic (TDE) היא ספריית PyTorch מקורית לאימון מודלים של למידה עמוקה בקנה מידה גדול, שבהן חיוני להרחיב את משאבי המחשוב באופן דינמי על בסיס זמינות. ה TorchElastic Controller עבור Kubernetes הוא מימוש מקורי של Kubernetes עבור TDE שמנהל אוטומטית את מחזור החיים של הפודים והשירותים הנדרשים לאימון TDE. זה מאפשר קנה מידה דינמי של משאבי מחשוב במהלך האימון לפי הצורך. זה גם מספק הכשרה סובלנית לתקלות על ידי שחזור עבודות מכשל בצמתים.

בפוסט זה, אנו דנים בצעדים לאימון PyTorch EfficientNet-B7 ו 50. ResNetXNUMX דגמים המשתמשים אימג'נט נתונים בצורה מבוזרת עם TDE. אנו משתמשים ב- PyTorch DistributedDataParallel API ובקר Kubernetes TorchElastic, ולהפעיל את עבודות ההדרכה שלנו באשכול EKS המכיל מספר צמתי GPU. התרשים הבא מציג את דיאגרמת הארכיטקטורה עבור אימון מודל זה.

הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

TorchElastic for Kubernetes מורכב בעיקר משני רכיבים: בקר TorchElastic Kubernetes (TEC) ושרת הפרמטרים (וכו'). הבקר אחראי על ניטור וניהול עבודות ההדרכה, ושרת הפרמטרים עוקב אחר צמתי העובדים לצורך סנכרון מבוזר וגילוי עמיתים.

על מנת שתרמי ההדרכה יוכלו לגשת לנתונים, אנו זקוקים לנפח נתונים משותף שניתן להרכיב על ידי כל פוד. כמה אפשרויות עבור כרכים משותפים דרך ממשק אחסון מיכל מנהלי התקנים (CSI) הכלולים ב AWS DevOps עבור EKS יש לו מערכת הקבצים של אמזון אלסטית (Amazon EFS) ו FSx עבור Luster.

הגדרת אשכול

בתצורת האשכולות שלנו, אנו משתמשים במופע אחד של c5.2xlarge עבור תרמילים של מערכת. אנו משתמשים בשלושה מופעים של p4d.24xlarge כתרמיל עובדים כדי להכשיר מודל EfficientNet. עבור הדרכה של ResNet50, אנו משתמשים במופעים של p3.8xlarge בתור תרמילים של עובדים. בנוסף, אנו משתמשים במערכת קבצים משותפת FSx כדי לאחסן את נתוני האימון שלנו וחפצי מודל.

מופעי AWS p4d.24xlarge מצוידים ב מתאם בד אלסטי (EFA) לספק רשת בין צמתים. אנו דנים יותר ב-EFA בהמשך הפוסט. כדי לאפשר תקשורת דרך EFA, עלינו להגדיר את הגדרת האשכול באמצעות קובץ yaml. א קובץ לדוגמא מסופק במאגר GitHub.

לאחר הגדרת קובץ yaml זה כהלכה, נוכל להפעיל את האשכול באמצעות הסקריפט המסופק ב-Repo GitHub:

./eks-create.sh

עיין ב GitHub ריפו להוראות מפורטות.

אין כמעט הבדל בין הפעלת עבודות ב-p4d.24xlarge ו-p3.8xlarge. השלבים המתוארים בפוסט זה עובדים עבור שניהם. ההבדל היחיד הוא הזמינות של EFA במופעי p4d.24xlarge. עבור דגמים קטנים יותר כמו ResNet50, לרשתות סטנדרטיות בהשוואה לרשתות EFA יש השפעה מינימלית על מהירות האימון.

FSx עבור מערכת הקבצים לוסטר

FSx מיועד לעומסי עבודה מחשוב בעלי ביצועים גבוהים ומספק זמן אחזור של תת אלפיות השנייה באמצעות נפחי אחסון של כוננים מוצקים. בחרנו ב-FSx מכיוון שהוא סיפק ביצועים טובים יותר כשהתרחבנו למספר רב של צמתים. פרט חשוב שיש לציין הוא ש-FSx יכול להתקיים רק באזור זמינות יחיד. לכן, כל הצמתים הנגישים למערכת הקבצים FSx צריכים להתקיים באותו אזור זמינות כמו מערכת הקבצים FSx. דרך אחת להשיג זאת היא לציין את אזור הזמינות הרלוונטי בקובץ .yaml של אשכול עבור קבוצות הצמתים הספציפיות לפני יצירת האשכול. לחלופין, אנו יכולים לשנות את חלק הרשת של קבוצת קנה המידה האוטומטי עבור צמתים אלה לאחר הגדרת האשכול, ולהגביל אותו לשימוש בתת רשת אחת. ניתן לעשות זאת בקלות בקונסולת אמזון EC2.

בהנחה שאשכול ה-EKS פועל, ומזהה רשת המשנה של אזור הזמינות ידוע, נוכל להגדיר מערכת קבצים FSx על ידי אספקת המידע הדרוש ב- fsx.conf קובץ כמתואר בסעיף readme ומפעיל את deploy.sh תסריט ב FSX תיקייה. זה מגדיר את קבוצת המדיניות והאבטחה הנכונים לגישה למערכת הקבצים. הסקריפט גם מתקין את מנהל התקן CSI עבור FSx כ-demonset. לבסוף, נוכל ליצור את 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 וסקריפט מעטפת כלולים ב- CSI תיקיה בתוך ה-Repo GitHub. אנחנו יכולים לבנות את התמונה באמצעות ה build.sh סקריפט ולאחר מכן דחוף אותו לאמזון ECR באמצעות push.sh תַסרִיט. לפני השימוש בסקריפטים אלה, עלינו לספק את ה-URI הנכון עבור מאגר ה-ECR ב- .env קובץ בתיקיית השורש של ריפו GitHub. לאחר שנדחף את תמונת Docker לאמזון ECR, נוכל להפעיל פוד להעתקת הנתונים על ידי החלת קובץ ה-.yaml הרלוונטי:

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

הפוד מריץ את הסקריפט באופן אוטומטי data-prep.sh כדי להעתיק את הנתונים מאמזון S3 לנפח המשותף. מכיוון שלנתוני ImageNet יש יותר מ-12 מיליון קבצים, תהליך ההעתקה לוקח כמה שעות. התסריט של Python imagenet_data_prep.py מופעל גם כדי לסדר מחדש את val מערך נתונים כצפוי על ידי PyTorch.

האצת רשת

אנו יכולים להשתמש במתאם בד אלסטי (EFA) בשילוב עם סוגי מופעי EC2 נתמכים כדי להאיץ את תעבורת הרשת בין צמתי ה-GPU באשכול שלך. זה יכול להיות שימושי בעת הפעלת עבודות הכשרה מבוזרות גדולות שבהן תקשורת רשת רגילה עשויה להוות צוואר בקבוק. סקריפטים לפריסה ובדיקה של תוסף מכשיר EFA באשכול ה-EKS שבו אנו משתמשים כאן כלולים ב- efa-device-plugin תיקיה ב-Repo GitHub. כדי לאפשר עבודה עם EFA באשכול ה-EKS שלך, בנוסף לצמתי האשכולות עם החומרה והתוכנה הדרושים, יש לפרוס את הפלאגין של מכשיר ה-EFA באשכול, ולמיכל העבודה שלך צריך להיות CUDA ו-NCCL תואמים גירסאות מותקן.

כדי להדגים הפעלת בדיקות NCCL והערכת הביצועים של EFA במופעים של p4d.24xlarge, ראשית עלינו לפרוס את האופרטור Kubeflow MPI על ידי הפעלת ההפעלה התואמת deploy.sh תסריט ב mpi-מפעיל תיקייה. ואז אנחנו מפעילים את deploy.sh תסריט ועדכן את test-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 GB/sek ורוחב הפס הממוצע של האוטובוס הוא כ-8 GB.

ערכנו גם ניסויים עם מתאם EFA יחיד מופעל, כמו גם ללא מתאמי EFA. כל התוצאות מסוכמות בטבלה הבאה.

מספר מתאמי EFA ספק נבחר Net/OFI ממוצע רוחב פס (GB/s) מקסימום רוחב פס (GB/s)
4 Efa 8.24 42.04
1 Efa 3.02 5.89
0 שקע 0.97 2.38

מצאנו גם שעבור דגמים קטנים יחסית כמו 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. מדדי ה-GPU מופיעים תחת CWAgent מרחב שמות בקונסולת CloudWatch. שאר מדדי האשכול מופיעים תחת ContainerInsights מרחב שמות.

אימון מודל

כל הסקריפטים הדרושים לאימון PyTorch נמצאים ב- ג'וב אלסטי תיקיה ב-Repo GitHub. לפני השקת עבודת ההדרכה, עלינו להפעיל את etcd שרת, המשמש את TEC לגילוי עובדים והחלפת פרמטרים. ה deploy.sh תסריט ב elasticjob התיקייה עושה בדיוק את זה.

כדי לנצל את היתרונות של EFA במופעי p4d.24xlarge, עלינו להשתמש בתמונת Docker ספציפית הזמינה ב- גלריה ציבורית של אמזון ECR התומך בתקשורת NCCL דרך EFA. אנחנו רק צריכים להעתיק את קוד ההדרכה שלנו לתמונת Docker זו. ה דוקרפיל תחת דגימות התיקייה יוצרת תמונה לשימוש בעת הפעלת עבודת אימון במופעי p4d. כמו תמיד, אנחנו יכולים להשתמש ב- build.sh ו push.sh סקריפטים בתיקייה כדי לבנות ולדחוף את התמונה.

השמיים imagenet-efa.yaml הקובץ מתאר את עבודת ההדרכה. קובץ yaml זה מגדיר את המשאבים הדרושים להפעלת עבודת ההדרכה וגם מעלה את עוצמת הקול הקבועה עם נתוני ההדרכה שהוגדרו בסעיף הקודם.

ראוי לציין כאן כמה דברים. יש להגדיר את מספר ההעתקים למספר הצמתים הזמינים באשכול. במקרה שלנו, הגדרנו את זה ל-3 כי היו לנו שלושה צמתים p4d.24xlarge. בתוך ה imagenet-efa.yaml קובץ, nvidia.com/gpu פרמטר תחת משאבים ו nproc_per_node תחת args צריך להיות מוגדר למספר ה-GPUs לצומת, שבמקרה של p4d.24xlarge הוא 8. כמו כן, ארגומנט העובד עבור הסקריפט של Python קובע את מספר המעבדים לכל תהליך. בחרנו את זה להיות 4 מכיוון שבניסויים שלנו, זה מספק ביצועים אופטימליים בעת הפעלה על מופעים של p4d.24xlarge. הגדרות אלו נחוצות על מנת למקסם את השימוש בכל משאבי החומרה הזמינים באשכול.

כאשר העבודה פועלת, אנו יכולים לצפות בשימוש ב-GPU ב-CloudWatch עבור כל ה-GPUs באשכול. להלן דוגמה מאחת מעבודות ההדרכה שלנו עם שלושה צמתים p4d.24xlarge באשכול. כאן בחרנו GPU אחד מכל צומת. עם ההגדרות שהוזכרו קודם לכן, השימוש ב-GPU קרוב ל-100% במהלך שלב האימון של התקופה עבור כל הצמתים באשכול.

הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

לאימון מודל ResNet50 באמצעות מופעי p3.8xlarge, אנו זקוקים לאותם שלבים בדיוק כפי שתוארו עבור אימון EfficientNet באמצעות p4d.24xlarge. אנחנו יכולים גם להשתמש באותה תמונת Docker. כפי שהוזכר קודם לכן, מופעי p3.8xlarge אינם מצוידים ב-EFA. עם זאת, עבור דגם ResNet50, זה לא חיסרון משמעותי. ה imagenet-fsx.yaml הסקריפט המסופק במאגר GitHub מגדיר את עבודת ההדרכה עם משאבים מתאימים לסוג הצומת p3.8xlarge. העבודה משתמשת באותו מערך נתונים ממערכת הקבצים FSx.

קנה מידה של GPU

הרצנו כמה ניסויים כדי לראות כיצד זמני האימון משתנים עבור מודל EfficientNet-B7 על ידי הגדלת מספר ה-GPUs. לשם כך, שינינו את מספר ההעתקים מ-1 ל-3 בקובץ yaml האימון שלנו עבור כל ריצת אימון. ראינו רק את הזמן לתקופה בודדת תוך כדי שימוש במערך הנתונים המלא של ImageNet. האיור הבא מציג את התוצאות עבור ניסוי קנה המידה של GPU שלנו. הקו המקווקו האדום מייצג כיצד זמן האימון אמור לרדת מריצה באמצעות 8 GPUs על ידי הגדלת מספר ה-GPUs. כפי שאנו יכולים לראות, קנה המידה די קרוב לצפוי.

הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

באופן דומה, השגנו את עלילת קנה המידה של GPU עבור אימון ResNet50 במופעים של p3.8xlarge. במקרה זה, שינינו את ההעתקים בקובץ yaml שלנו מ-1 ל-4. התוצאות של ניסוי זה מוצגות באיור הבא.

הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

לנקות את

חשוב להקטין משאבים לאחר אימון מודלים כדי למנוע עלויות הכרוכות בהפעלת מקרי סרק. עם כל סקריפט שיוצר משאבים, ה GitHub ריפו מספק סקריפט תואם כדי למחוק אותם. כדי לנקות את ההגדרה שלנו, עלינו למחוק את מערכת הקבצים FSx לפני מחיקת האשכול מכיוון שהוא משויך לרשת משנה ב-VPC של האשכול. כדי למחוק את מערכת הקבצים FSx, אנחנו רק צריכים להפעיל את הפקודה הבאה (מתוך FSX תיקיה):

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

שימו לב שזה לא רק ימחק את אמצעי האחסון המתמשך, זה גם ימחק את מערכת הקבצים FSx, וכל הנתונים במערכת הקבצים יאבדו. לאחר השלמת שלב זה, נוכל למחוק את האשכול על ידי שימוש בסקריפט הבא ב- לשעבר תיקייה:

./eks-delete.sh

פעולה זו תמחק את כל הפודים הקיימים, תסיר את האשכול וימחק את ה-VPC שנוצר בהתחלה.

סיכום

בפוסט זה, פירטנו את השלבים הדרושים להפעלת אימון מודלים מקבילים של PyTorch נתונים מבוזרים על אשכולות EKS. משימה זו אולי נראית מרתיעה, אבל AWS DevOps עבור EKS הפרויקט שנוצר על ידי צוות ML Frameworks ב-AWS מספק את כל התסריטים והכלים הדרושים כדי לפשט את התהליך ולהפוך אימון מודל מבוזר לנגיש בקלות.

למידע נוסף על הטכנולוגיות המשמשות בפוסט זה, בקר אמזון EKS ו לפיד מחולק אלסטית. אנו ממליצים לך ליישם את הגישה המתוארת כאן למקרי שימוש משלך בהדרכה מבוזרת.

משאבים


על המחברים

הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.עמרן יונוס הוא צוות אדריכל פתרונות ראשי עבור ML Frameworks ב-AWS. הוא מתמקד בלמידת מכונה בקנה מידה גדול ועומסי עבודה של למידה עמוקה בשירותי AWS כמו Amazon EKS ו-AWS ParallelCluster. יש לו ניסיון רב ביישומי הישענות עמוקה בראייה ממוחשבת וב-IoT תעשייתי. אימראן השיג את הדוקטורט שלו בפיזיקה של חלקיקים באנרגיה גבוהה, שם הוא היה מעורב בניתוח נתונים ניסיוניים בסולם פטה-בתים.

הכשרה מבוזרת עם Amazon EKS ו- Torch Distributed Elastic PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.אלכס יאנקולסקי הוא ארכיטקט תוכנה ותשתית מלא שאוהב לעשות עבודה מעשית ומעמיקה. כיום הוא אדריכל פתרונות ראשי ללמידת מכונה בניהול עצמי ב-AWS. בתפקידו הוא מתמקד בסיוע ללקוחות עם קונטיינריזציה ותזמור של עומסי עבודה של ML ו-AI בשירותי AWS המונעים על ידי קונטיינרים. הוא גם המחבר של הקוד הפתוח תעשה מסגרת וקברניט דוקר שאוהב ליישם טכנולוגיות מכולות כדי להאיץ את קצב החדשנות תוך פתרון האתגרים הגדולים בעולם. במהלך 10 השנים האחרונות, אלכס עבד על מאבק בשינויי האקלים, דמוקרטיזציה של AI ו-ML, הפיכת נסיעות לבטוחות יותר, שירותי בריאות טובים יותר ואנרגיה חכמה יותר.

בול זמן:

עוד מ למידת מכונות AWS