תכנון והגדרה של אשכול GPU ל-ML (NVIDIA A100/H100)

הגדרת אשכול GPU: היכן מתקלקל אימון המודלים

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

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

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

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

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

מה נותן אשכול ייעודי לאימון מודלים

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

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

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

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

אפשרויות ארגון מחשוב: תשתית עצמית, שכירות, ענן

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

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

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

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

סדר היישום: מביקורת עומס ועד מסירה לתפעול

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

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

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

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

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

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

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

חפצי מסירה: תצורות, סכמות, נהלים

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

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

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

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

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

מה הראו המדדים לפני

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

מה שינו

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

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

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

במה שונה צומת אחד מהרצת אימון מבוזרת?

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

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

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

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

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

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

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

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

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

כיצד מופרדות ההרשאות בין צוותים?

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

כיצד מתעדכנת התשתית ללא השבתה?

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

מה כלול בתמיכה לאחר המסירה?

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

נדון במשימה — נחזור עם הערכה ותוכנית עבודה

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

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

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

תאר את המשימה בדרך נוחה — נחזור עם הערכה ותוכנית עבודה.