הגדרת תשתית GPU לאימון מודלים של ML

מדוע תשתית GPU בטלה ומעכבת אימון מודלים

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות, תורים, סוגי כשלים

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

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

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

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

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

אפשרויות לארגון תשתית GPU: השוואת גישות

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: הסרנו את התור לאימון ואת הבטלה במשימות שיא

מה היה לפני

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

מה שינינו

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

מה נהיה

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

במה שונה הקצאת משאבים ידנית מתור משימות?

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

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

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

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

ספקות טכניים נפוצים לפני תחילת הפרויקט

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

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

איך לחלק משאבים בין צוותים?

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

מי אחראי לבטלה?

תורנויות, ניטור עומס וטמפרטורה, הפעלה מחדש אוטומטית של משימות שנפלו. נהלי הסלמה וזמן התאוששות целевое מתקבעים בהסכם רמת שירות מראש — לפני הכשל הראשון, ולא אחריו.

מה יקרה בעת גידול בעומס?

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

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

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

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

מה תקבלו בתגובה לתיאור המשימה:

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

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