הגדרת הרחבה אוטומטית של תשתית GPU לעומסי AI

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע אוטוסקיילינג GPU לא מחזיק עומס שיא

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

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

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

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

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

מה נותן אוטוסקיילינג GPU: זמן, קיבולת, עמידות

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

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

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

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

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

השוואה בין מצבי סקיילינג של מאגר המחשוב

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

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

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

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

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

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

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

קונפיגורציות, סכימות ונהלים: מערך המסמכים

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

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

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

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

מה היה

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

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

מה עשינו

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

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

מה נהיה

ההמתנה בתור לאימון הצטמצמה מ-9 שעות ל-20–40 דקות באותם שיאים, ושיעור ההשבתה ירד מ-65% ל-18%. תקריות של מחסור בקיבולת — 0–1 ברבעון במקום 4–6 בחודש, וטיפול ידני כבר לא נדרש.

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

מה עושים אם מאגר המאיצים כבר נפרס ידנית?

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

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

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

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

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

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

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

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

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

התנעה קרה של הצומת תעכב את התנעת המשימה?

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

מה אם המכסה לקיבולת תיגמר בשיא?

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

צמתים ניתנים לקטיעה והוצאה לתחזוקה — מה עם האימון?

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

האם יהיה צורך לכתוב מחדש את קוד האימון?

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

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

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

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

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

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

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