אופטימיזציית עלויות באימון ML: Spot ו-Preemptible VMs

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

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

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

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

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

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

מה משתנה לאחר המעבר לקיבולת ניתנת להפסקה

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

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

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

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

מופעי Spot, צמתים ייעודיים ובריכה היברידית

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

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

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

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

איך אנחנו פורסים אימון על צמתים ניתנים להפסקה

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

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

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

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

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

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

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

קונפיגורציות, מדיניויות ונהלים שאתם מקבלים

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

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

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

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

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

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

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

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

מה לעשות אם חלק מהקיבולת כבר תפוסה בעומס קבוע?

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

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

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

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

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

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

ספקות טכניים ותשובות בנושא צמתים ניתנים להפסקה

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

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

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

מה קורה באימון מחדש של מודל גדול?

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

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

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

• הגדרת המשימה. אילו אימונים רוצים להאיץ קודם, ואיפה צוואר הבקבוק сейчас — תור, זמן סרק של מאיצים או רזרבה עודפת של מכונות.
• נתוני פתיחה על העומס. פרופיל המשימות, דרישות זיכרון, משך ריצה אחת, מוכנות להפסקה ולהפעלה מחדש מנקודת הביקורת האחרונה.
• המעגל הנוכחי. איך בנויות ההרצות, איפה נמצאים הנתונים וארטיפקטי המודלים, האם יש נצפות ומעקב צריכה לפי צוותים.
• תוכנית הטמעה. נראה איך חלק מהצי עובר למופעי Spot עם חזרה אוטומטית לבריכה יציבה כשחסרה קיבולת.
• היקף העבודות. סימון משימות לפי התאמה להפסקה, מדיניות בחירת קיבולת, שמירת נקודות ביקורת, סקיילינג אוטומטי של התור.
• הערכת לוחות זמנים. טווח לפי שלבים — מהעברה ניסיונית של סוג משימה אחד ועד פריסה מלאה עם תוכנית נסיגה.

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