SageMaker מפסיקה להפיל אימונים בגלל מחסור בשרתים

אין דרך נעימה להתעורר בשתיים בלילה משגיאת InsufficientCapacityError, במיוחד כשרצתה פקודה קריטית לאימון שחיכה ימים בתור. ב-15 בספטמבר 2026, AWS הכריזה על פיצ'ר שמטפל בנקודת החיכוך הזאת: הגדרת רשימת עדיפויות של מופעים (Instance preference lists). היכולת נתמכת ב-Amazon SageMaker AI Training Jobs ובעבודות Amazon SageMaker Processing Jobs. במקום לנעול משימה לשרת בודד, מגדירים עד 5 סוגי מופעים בקריאת API אחת. המערכת סורקת בזיכרון, מקצה את המופע הפנוי הראשון, ומתחילה בריצה.

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

סוף לסקריפטים שקורסים בלילה

עד העדכון הנוכחי, מהנדסים שרצו להבטיח רציפות עבודה נאלצו לבנות סקריפטים שבירים של ניסיונות חוזרים (retries) שבדקו סטטוסים, ביטלו בקשות תקועות וניסו להרים שרתים אחרים. כעת, מנגנון התזמון של Amazon SageMaker AI מריץ סריקה אחת של רשימת ההעדפות ומקצה מיד את המשאב הפנוי הראשון. אם אף אחד מחמשת המופעים אינו זמין, העבודה אינה נכשלת מיד אלא מועברת לתור אירועים יעיל, שממתין להתפנות משאבים ומבצע ניסיון הקצאה אוטומטי.

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

שילוב בין שמור לחופשי

היכולת החדשה מתחברת ישירות למנגנון Flexible Training Plans, שמאפשר לארגונים לשריין מראש קיבולת מעבדי GPU לתקופות קבועות ובתעריף מוזל. מעכשיו תוכלו להגדיר את המכסה השמורה בראש רשימת העדיפויות באמצעות שיוך ה-TrainingPlanArn שלה, ולהגדיר חלופות מבוססות On-Demand בהמשך הרשימה. התזמון יבדוק קודם את המכסה המוזלת השמורה, ואם היא תפוסה לחלוטין, יגלוש אוטומטית למופעים חופשיים כדי לא לעכב את הפייפליין.

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

התאמת שקילות חומרה בקוד

תכונה שימושית ברשימת העדיפויות היא היכולת לקבוע כמות שונה של מופעים עבור כל שורה ברשימה כדי לשמור על כוח עיבוד מאוזן. בדוקומנטציה של AWS מציגים דוגמה שבה עבודה מקבלת בעדיפות ראשונה 2 מופעי ml.g6.48xlarge (עם 8 כרטיסי L40S בכל מופע, 16 בסך הכל). אם הם אינם זמינים, היא עוברת להקצאה של 4 מופעי ml.g5.48xlarge (עם 8 כרטיסי A10G בכל מופע, 32 בסך הכל) כדי לפצות על ביצועים נמוכים יותר לכל כרטיס בודד.

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

המלכודת של מופעי מעבד

האותיות הקטנות של AWS כוללות הגבלה מהותית במנגנון התור. פרמטר MaxPendingTimeInSeconds עובד רק אם רשימת העדיפויות כוללת לפחות מופע מחשוב מואץ אחד, כגון משפחות ml.p, ml.g או שבבי Trainium של AWS (משפחת ml.trn). אם תגדירו עבודת אימון או עיבוד שמבוססת כולה על שרתי CPU רגילים (כמו מופעי ml.c או ml.m), המערכת תסרוק את הרשימה פעם אחת בלבד. במצב כזה, אם אף שרת לא יימצא פנוי באותו רגע, העבודה לא תיכנס לתור המתנה אלא תיכשל מיד, ללא תלות בערך הזמן שהוגדר.

מה לבדוק לפני שמגדירים

לפני שמטמיעים את הרשימות החדשות ב-Python SDK v3, בדקו את מגבלות הזמינות הגיאוגרפית. באזור ישראל (il-central-1), היצע המופעים המואצים מוגבל לעיתים ביחס לאזורים מרכזיים בארצות הברית ובאירופה. צוותים ישראליים שמחויבים לרגולציה מקומית ולריבונות מידע אינם יכולים להפנות עומסים למחוזות אחרים. עליכם לוודא שהמופעים המוגדרים ברשימה אכן קיימים פיזית באזור וב-Subnet שהוקצו לעבודה. בנוסף, מומלץ לוודא שסקריפטי האימון מופעלים עם כלי דוגמת torchrun התומך בהקצאת תהליכים דינמית לפי כמות הכרטיסים הזמינה.

החומרה אולי מחכה בתור, אבל החשבון בסוף החודש יגיע בזמן.