הגדרת NVIDIA NCCL לאימון מרובה-GPU

NCCL: מדוע אימון על מספר מאיצים אינו מתאים לקנה מידה

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

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

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

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

מה נותנת תקשורת מכווננת בין מאיצים

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

לאחר הגדרה מפורשת של הסכמה (אלגוריתם, רמת גישה ישירה, ממשק הרשת הנדרש, הצמדת תהליכים לקישורים) רוחב הפס של התקשורת עולה פי 1.5–2, ושלב הסנכרון מפסיק להיות החלק היקר ביותר בריצה.

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

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

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

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

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

NCCL: סכמות קישור בין מאיצים, אפשרויות ומגבלות

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

סכמות וגבולות היישום שלהן

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

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

שלבי הכוונון: מביקורת הצומת ועד מסירת הנהלים

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

1. ביקורת האשכול. מפיקים מפת קשרים בין המאיצים והצמתים: היכן התקשורת עוברת ישירות, היכן דרך חוליה מתווכת, והאם הערוץ זהה בכל הצמתים. בפלט — רשימת צמתים שמתנהגים אחרת מהשאר.
2. פרופיל עומס. מריצים אימון אמיתי עם מדידת זמן השלב והחלק שתופסת התקשורת בין ההתקנים — נראה מה מאט: הרשת, סנכרון הגרדיאנטים או הכנת הנתונים.
3. סכמת תקשורת. לפי הפרופיל בוחרים אלגוריתמים של פעולות קולקטיביות, גודל באפר וסדר התקשורת בין קבוצות: באפר גדול נותן זרימה אחידה, קטן — השהיה נמוכה יותר בשלבים קצרים.
4. כוונון. מכניסים שינויים אחד-אחד ואחרי כל אחד חוזרים על המדידה — כך ניכר תרומת השינוי, ולא האפקט המצטבר של עשרה משתנים. את הקונפיגורציה מחזיקים במאגר קוד.
5. בדיקה תחת עומס. מספר משימות במקביל, ניתוק צומת, חיבור מחדש: פיזור זמן השלב צריך להישאר בגבולות המותרים.
6. מבחני קבלה. משווים זמן שלב וניצולת מאיצים לפני ואחרי, מריצים תרחישי כשל, קובעים ערכי בקרה שלפיהם הצוות בודק את האשכול לאחר שינויים.
7. מסירה. מוסרים נוהל: כיצד לשנות פרמטרים, לאן להסתכל בירידת מהירות, אילו מדידות להפיק לפני שחרור.

קונפיגורציות, סכמות טופולוגיה ונוהלי הרצה

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

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

מקרה בוחן: כיצד ביטלנו את הבטלה של המאיצים בריצות ארוכות

מה נשבר

אשכול עם כמה עשרות מאיצים, ריצות אימון ארוכות. המשימות נפלו בשעה 5–8: התקשורת הקולקטיבית של גרדיאנטים נתלתה, הדרגות חיכו זו לזו, והמשימה הוסרה על ידי פסק זמן של שומר. הפעלה מחדש ארכה 40–60 דקות — חימום מטמונים, טעינת נתונים מחדש, יישור מצב; זמן שימושי ביממה נותר פחות מחצי.

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

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

מה שינינו

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

ריצה של 11 שעות עוברת בלי אף כשל סנכרון, שיעור ההרצות המוצלחות — 9 מתוך 10 לעומת 1 מתוך 3. שחזור לאחר נפילה אורך כ-6 דקות: המצב עולה מנקודת הביקורת האחרונה. זמן האפוק התקצר בכחמישית, והשחזוריות נשמרת בגבולות הרעש — אותם נתונים ואותו זרע נותנים מדדים תואמים.

NCCL: מה לעשות אם האשכול כבר פרוס והתקשורת מאטה

תשובה קצרה: אם האימון כבר רץ והאשכול עובד, אין צורך להרכיב מחדש את הסביבה. NCCL מטפלת בפעולות קולקטיביות כמו all-reduce, ואת רוב האובדנים מסיר בחירת הובלה, מספר הערוצים ופרמטרי הבאפר.

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

יש לנו כמה מודלי אימון שונים — האם קונפיגורציה אחת לכולם?

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

בריצות ארוכות התקשורת מאטה — כיצד לתפוס זאת?

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

מה יישאר לנו לאחר המסירה והאם זה לא ישבור משימות שכנות?

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

נדבר על המשימה: מה לשלוח להערכה ולתוכנית

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

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

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