מידע על צריכת GPU,‏ TPU ו-H4D במצב הקצאת משאבים עם הפעלה גמישה

טייס אוטומטי רגילה

בדף הזה מוסבר על flex-start ב-Google Kubernetes Engine‏ (GKE). התכונה 'הפעלה גמישה', שמבוססת על Dynamic Workload Scheduler, מספקת טכניקה גמישה וחסכונית לשימוש במשאבי מחשוב מיוחדים, כמו יחידות GPU או TPU, כשצריך להריץ עומסי עבודה של AI/ML.

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

המידע בדף הזה יכול לעזור לכם:

הסבר על האופן שבו פועל flex-start ב-GKE.
החליטו אם התחלה גמישה (Flex-start) מתאימה לעומס העבודה שלכם.
מחליטים איזו הגדרה של הפעלה גמישה מתאימה לעומס העבודה.
ניהול שיבושים כשמשתמשים במכונות VM עם Flex-start.
הסבר על המגבלות של מכונות וירטואליות עם הפעלה גמישה ב-GKE.

הדף הזה מיועד לאדמינים ולמפעילים של פלטפורמות ולמהנדסי למידת מכונה (ML) שרוצים לבצע אופטימיזציה של תשתית המאיצים עבור עומסי העבודה שלהם.

מתי כדאי להשתמש בשיטת flex-start

מומלץ להשתמש ב-flex-start אם עומסי העבודה שלכם עומדים בכל התנאים הבאים:

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

תמחור Flex-start

מומלץ להשתמש ב-Flex-start אם נפח העבודה שלכם דורש הקצאה דינמית של משאבים לפי הצורך, למשך עד שבעה ימים עם הזמנות לטווח קצר, ללא ניהול מורכב של מכסות וגישה חסכונית. התכונה 'התחלה גמישה' מבוססת על Dynamic Workload Scheduler והחיוב מתבצע לפי התמחור של Dynamic Workload Scheduler:

הנחה (עד 53%) על vCPU,‏ GPU ו-TPU.
התשלום מתבצע לפי שימוש.

דרישות

כדי להשתמש בהתחלה גמישה ב-GKE, האשכול צריך לעמוד בדרישות הבאות:

כדי להריץ יחידות GPU, צריך להשתמש ב-GKE מגרסה 1.32.2-gke.1652000 ואילך.
כדי להריץ TPU, צריך לעיין בדרישות הגרסה של GKE במאמר תכנון TPU ב-GKE. התכונה 'התחלה גמישה' תומכת בגרסה ובאזורים הבאים:
- ‫Ironwood (TPU7x) (תצוגה מקדימה) ב-us-central1-c.
- ‫TPU Trillium‏ (v6e) בasia-northeast1-b, בus-east5-a ובus-east5-b.
- ‫TPU v5e ב-us-west4-a.
- ‫TPU v5p ב-us-east5-a.
אין תמיכה ב-TPU v3 וב-TPU v4.

איך פועל מצב אספקה עם התחלה גמישה

בשיטת flex-start, אתם מציינים את קיבולת המחשוב הנדרשת (כמו מעבדי GPU או TPU) בעומסי העבודה. בנוסף, באשכולות רגילים, אתם יכולים להגדיר הפעלה גמישה במאגרי צמתים ספציפיים. ‫GKE מקצה באופן אוטומטי מכונות וירטואליות עם הפעלה גמישה על ידי השלמת התהליך הבא כשהקיבולת הופכת לזמינה:

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

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

הגדרות Flex-start

‫GKE תומך בהגדרות הבאות של flex-start:

Flex-start, שבו GKE מקצה משאבים מצומת לצומת. במקרה הזה, צריך להגדיר את הדגל --flex-start רק במהלך יצירת הצומת.
‫Flex-start with queued provisioning, שבו GKE מקצה את כל המשאבים הנדרשים בו-זמנית. כדי להשתמש בהגדרה הזו, צריך להוסיף את הדגלים --flex-start ו-enable-queued-provisioning כשיוצרים את מאגר הצמתים. ‫GKE פועל לפי התהליך שמתואר בקטע איך פועל מצב הקצאת משאבים עם הפעלה גמישה במסמך הזה, אבל הוא גם פועל לפי התנאים הבאים:
- מתזמן ההפעלה ממתין עד שכל המשאבים המבוקשים יהיו זמינים באזור אחד.
- כל ה-Pods של עומס העבודה יכולים לפעול יחד בצמתים שהוקצו לאחרונה.
- הצמתים שהוקצו לא מנוצלים מחדש בין הפעלות של עומסי עבודה.
הערה: באשכולות שמופעלת בהם גרסה GKE 1.29.1-gke.1708000 ואילך, מתבצעת אופטימיזציה של בחירת האזור כדי להקטין את זמני ההמתנה. יכול להיות שגרסאות קודמות יחוו המתנה ארוכה יותר בתור.

בטבלה הבאה מוצגת השוואה בין ההגדרות של התחלה גמישה (Flex-start):

	Flex-start	התחלה גמישה עם הקצאת הרשאות בתור
זמינות	תצוגה מקדימה	זמינות לכלל המשתמשים (GA) הערה: בגרסת טרום-השקה (Preview), התכונה 'התחלה גמישה' תומכת בדגלים `flex-start` ו-`enable-queued-provisioning`.
מאיצים נתמכים	GPU ‫TPU במאגרי צמתים של פרוסות TPU עם מארח יחיד ובמאגרי צמתים של פרוסות TPU עם כמה מארחים	GPU ‫TPU במאגרי צמתים של פרוסות TPU עם כמה מארחים
גודל מומלץ של עומס העבודה	קטן עד בינוני, כלומר עומס העבודה יכול לפעול בצומת יחיד. לדוגמה, ההגדרה הזו מתאימה אם אתם מריצים משימות אימון קטנות, הסקת מסקנות אופליין או משימות אצווה.	בינוני עד גדול, כלומר עומס העבודה יכול לפעול בכמה צמתים. עומס העבודה שלכם דורש כמה משאבים, ואי אפשר להתחיל להריץ אותו עד שכל הצמתים יוקצו ויהיו מוכנים בו-זמנית. לדוגמה, ההגדרה הזו מתאימה אם אתם מריצים עומסי עבודה של אימון מבוזר של למידת מכונה.
סוג הקצאת ההרשאות	‫GKE מקצה צומת אחד בכל פעם כשהמשאבים זמינים. ב-TPU, ‏ GKE יוצר צומת אחד בכל פעם במאגרי צמתים של פרוסות TPU עם מארח יחיד, ואת הפרוסה כולה בכל פעם במאגרי צמתים של פרוסות TPU עם כמה מארחים.	‫GKE מקצה את כל המשאבים הנדרשים בו-זמנית.
מורכבות ההגדרה	פחות מורכב. ההגדרה הזו דומה למכונות VM לפי דרישה ולמכונות VM מסוג Spot.	מורכבות יותר. מומלץ מאוד להשתמש בכלי לניהול מכסות, כמו Kueue.
תמיכה בסוגי מחשוב בהתאמה אישית	כן	לא
מיחזור צמתים	כן	לא
מחיר	מק"ט של Flex Start	מק"ט של Flex Start
מכסה	מכסת ה-GPU שניתן לקטוע מכסת TPU ניתנת להפקעה	מכסת ה-GPU שניתן לקטוע מכסת TPU ניתנת להפקעה
אסטרטגיית שדרוג הצומת	שדרוגים לזמן קצר	שדרוגים לזמן קצר
סימון `gcloud container node pool create`	`--flex-start`	`--flex-start` `--enable-queued-provisioning`
קדימה, מתחילים	‫GPUs: הצגת מודלים גדולים של שפה (LLM) ב-GKE באמצעות אסטרטגיית הקצאת GPU עם אופטימיזציה של עלויות וזמינות גבוהה הרצה של עומס עבודה קטן באצווה עם מעבדי GPU ומצב הקצאת משאבים עם הפעלה גמישה TPUs: הפעלת עומס עבודה קטן של אצווה באמצעות מעבדי TPU ומצב הקצאת משאבים עם הפעלה גמישה	הפעלת עומס עבודה גדול עם הקצאת משאבים בתור

אופטימיזציה של הגדרת גמישות בתחילת העבודה

כדי ליצור תשתית AI/ML חזקה וחסכונית, אפשר לשלב הגדרות של flex-start עם תכונות זמינות של GKE. מומלץ להשתמש בסוגי מחשוב כדי להגדיר רשימה עם עדיפות של תצורות צמתים על סמך הדרישות של עומס העבודה. ‫GKE יבחר את ההגדרה המתאימה ביותר על סמך הזמינות והעדיפות שהגדרתם.

ניהול שיבושים בעומסי עבודה שמשתמשים ב-Dynamic Workload Scheduler

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

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

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

שיטות מומלצות לצמצום שיבושים בעומסי עבודה בצמתים שמשתמשים בשדרוגים לזמן קצר

צמתים שמשתמשים במכונות וירטואליות עם הפעלה גמישה וצמתים שמשתמשים בהקצאת משאבים בתור מוגדרים אוטומטית לשימוש בשדרוגים לזמן קצר כשהאשכול מריץ גרסה 1.32.2-gke.1652000 ואילך.

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

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

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

שיטות מומלצות לצמצום שיבושים בעומס העבודה של צמתים להקצאת משאבים בתור בלי שדרוגים לזמן קצר

צמתים שמשתמשים בהקצאת משאבים בתור באשכול שמריץ גרסת GKE מוקדמת מ-1.32.2-gke.1652000 לא משתמשים בשדרוגים לזמן קצר. אשכולות ששודרגו לגרסה 1.32.2-gke.1652000 ואילך עם צמתים קיימים של הקצאת משאבים בתור מתעדכנים אוטומטית לשימוש בשדרוגים לזמן קצר.

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

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

שיקולים להעברת אשכול לשדרוגים לטווח קצר

כשמשדרגים את האשכול לגרסה ‎1.32.2-gke.1652000 ואילך, GKE מעדכן את הצמתים הקיימים באמצעות הקצאת משאבים בתור כדי להשתמש בשדרוגים לזמן קצר. ‫GKE לא מעדכן הגדרות אחרות, כמו הפעלה של שדרוגים אוטומטיים של צמתים, אם השבתתם אותם למאגר צמתים ספציפי.

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

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

מיחזור צמתים ב-flex-start

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

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

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

תהליך המיחזור של הצמתים כולל את השלבים הבאים:

שלב המיחזור: מערכת GKE מוודאת שלצומת עם הקצאת משאבים בהתחלה גמישה יש את השדה nodeRecycling עם הפרמטר leadTimeSeconds שהוגדר. אם כן, מערכת GKE מתחילה את השלב של מיחזור הצומת כשהתאריך הנוכחי גדול מההפרש בין הערכים בשדות הבאים או שווה לו:
- ‫creationTimestamp יחד עם maxRunDurationSeconds
- leadTimeSeconds
הדגל creationTimeStamp כולל את השעה שבה הצומת נוצר. אפשר לציין את השדה maxRunDurationSeconds בסוג מחשוב מותאם אישית, והערך שמוגדר כברירת מחדל הוא שבעה ימים.
יצירת צומת: תהליך היצירה של הצומת החדש מתחיל, ועובר דרך שלבי ההמתנה בתור וההקצאה. משך שלב ההמתנה בתור יכול להשתנות באופן דינמי בהתאם לאזור ולקיבולת של המאיץ הספציפי.
מבודדים את הצומת שמגיע לסוף משך הזמן של שבעה ימים: אחרי שהצומת החדש פועל, הצומת הישן מבודד. הפעולה הזו מונעת תזמון של Pods חדשים במכונה. ה-Pods הקיימים בצומת הזה ממשיכים לפעול.
ביטול הקצאת משאבים של צומת: בסופו של דבר, המערכת מבטלת את הקצאת המשאבים של הצומת שמגיע לסוף משך הזמן של שבעה ימים, אחרי תקופה מתאימה. כך אפשר לוודא שעומסי העבודה הפעילים הועברו לצומת החדש.

בדוגמה הבאה של הגדרת מחלקת מחשוב מופיעים השדות leadTimeSeconds ו-maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

מידע נוסף על שימוש במיחזור צמתים זמין במדריך Serve LLMs on GKE with a cost-optimized and high-availability GPU provisioning strategy.

מגבלות

אין תמיכה באנטי-אפיניות בין פודים. המידרוג האוטומטי של האשכול לא מתחשב בכללי אנטי-אפיניות בין פודים במהלך הקצאת הצמתים, מה שעלול להוביל לעומסי עבודה שלא ניתן לתזמן. המצב הזה יכול לקרות כשמקצים צמתים לשני אובייקטים או יותר של Dynamic Workload Scheduler באותו מאגר צמתים.
אין תמיכה בהזמנות עם הכלי Dynamic Workload Scheduler. כשיוצרים את מאגר הצמתים, צריך לציין את הדגל --reservation-affinity=none. הכלי Dynamic Workload Scheduler דורש וגם תומך רק בANY מדיניות המיקום להתאמה אוטומטית לעומס של גודל האשכול.
בקשה אחת של Dynamic Workload Scheduler יכולה ליצור עד 1,000 מכונות וירטואליות (VM), שהוא המספר המקסימלי של צמתים לכל אזור עבור מאגר צמתים יחיד.
‫GKE משתמש במכסת ACTIVE_RESIZE_REQUESTS של Compute Engine כדי לשלוט במספר הבקשות של Dynamic Workload Scheduler שממתינות בתור. כברירת מחדל, המכסה הזו מוגבלת ל-100 בקשות לכל פרויקט. Google Cloudאם תנסו ליצור בקשה ל-Dynamic Workload Scheduler שגדולה מהמכסה הזו, הבקשה החדשה תיכשל.
מאגרי צמתים שמשתמשים ב-Dynamic Workload Scheduler רגישים לשיבושים כי הצמתים מוקצים יחד. מידע נוסף זמין במאמר בנושא ניהול שיבושים בעומסי עבודה שמשתמשים ב-Dynamic Workload Scheduler.
יכול להיות שיוצגו עוד מכונות וירטואליות לזמן קצר במסוף Google Cloud . ההתנהגות הזו מכוונת, כי יכול להיות ש-Compute Engine ייצור מכונות וירטואליות ואז יסיר אותן מיד עד שיהיה נפח אחסון לצירוף כל המכונות הנדרשות.
אין תמיכה ב-Spot VMs.
‫Dynamic Workload Scheduler לא תומך בכוננים זמניים. חובה להשתמש בנפחי אחסון מתמיד לאחסון. כדי לבחור את סוג האחסון הטוב ביותר שמשתמש בנפחי אחסון קבועים, אפשר לעיין במאמר סקירה כללית על אחסון באשכולות GKE.
אם עומס העבודה משתמש במיחזור צמתים והוא נפרס על ידי Job, צריך להגדיר את ה-Job עם מצב השלמה שמוגדר ל-Indexed.
אובייקט ProvisioningRequest יחיד תומך רק בערך אחד ברשימה podSets. בקשות עם כמה רשומות podSet נכשלות.