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

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

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

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

  • הסבר על האופן שבו פועל flex-start ב-GKE.
  • החליטו אם התחלה גמישה מתאימה לעומס העבודה שלכם.
  • מחליטים איזו הגדרה של "התחלה גמישה" מתאימה לעומס העבודה.
  • ניהול השיבושים כשמשתמשים ב-Flex-start VM.
  • הסבר על המגבלות של Flex-start VMs ב-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 וכל דיסק SSD מקומי שמחובר.
  • תשלום לפי שימוש (PAYG).

דרישות

כדי להשתמש ב-"התחלה גמישה" ב-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.

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

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

  1. עומס העבודה מבקש קיבולת שלא זמינה באופן מיידי. אפשר לשלוח את הבקשה הזו ישירות באמצעות מפרט עומס העבודה או באמצעות כלי תזמור כמו מחלקות מחשוב בהתאמה אישית או Kueue.
  2. מערכת GKE מזהה שהאפשרות 'הפעלה גמישה' מופעלת בצומת. אם לא מציינים את הדגל --request-valid-for-duration, עומסי עבודה של GPU יכולים להמתין עד 14 ימים למשאבים. לעומת זאת, עומסי עבודה של TPU יכולים לחכות למשך זמן לא מוגדר.
  3. המידרוג האוטומטי של האשכול מקבל את הבקשה ומחשב את מספר הצמתים הדרושים, ומתייחס אליהם כיחידה אחת.
  4. המידרוג האוטומטי של האשכול מקצה את הצמתים הנדרשים כשהם זמינים. הצמתים האלה פועלים למשך שבעה ימים לכל היותר, או למשך זמן קצר יותר אם מציינים ערך בפרמטר maxRunDurationSeconds. אם לא מציינים ערך לפרמטר maxRunDurationSeconds, ברירת המחדל היא שבעה ימים.
  5. אחרי שזמן הריצה שהגדרתם בפרמטר maxRunDurationSeconds מסתיים, מתבצעת דחיקה של הצמתים וה-Pods.
  6. אם ה-Pods מסיימים מוקדם יותר והצמתים כבר לא בשימוש, הכלי להתאמה אוטומטית של קנה המידה של האשכול מסיר אותם בהתאם לפרופיל ההתאמה האוטומטית של קנה המידה.

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

הגדרות Flex-start

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

  • הפעלה גמישה, שבה GKE מקצה משאבים מצומת לצומת. במקרה הזה, צריך להגדיר את הדגל --flex-start רק כשיוצרים את הצומת.

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

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

בטבלה הבאה מוצגת השוואה בין ההגדרות של תחילת תקופה גמישה:

התחלה גמישה (Flex-start) התחלה גמישה עם הקצאת משאבים בהמתנה
זמינות תצוגה מקדימה

זמינות לכלל המשתמשים (GA)

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

אופטימיזציה של הגדרת flex-start

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

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

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

כל הצמתים שמשתמשים ב-Flex-start VM, בהקצאת משאבים בהמתנה או בשניהם, משתמשים בשדרוגים לטווח קצר כשמישור הבקרה של האשכול מריץ את הגרסה המינימלית ל-flex-start, ‏1.32.2-gke.1652000 ואילך.

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

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

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

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

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

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

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

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

שיקולים לגבי מעבר של אשכול לשדרוגים קצרים

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

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

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

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

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

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

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

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

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

    • ‫creationTimestamp יחד עם maxRunDurationSeconds
    • leadTimeSeconds

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

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

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

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

בדוגמה הבאה של הגדרת מחלקת מחשוב מופיעים השדות 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

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

מגבלות

  • אין תמיכה באנטי-אפיניות בין פודים. הכלי למידרוג אוטומטי של אשכולות לא מתחשב בכללי אנטי-אפיניות בין פודים במהלך הקצאת צמתים, וזה עלול להוביל לעומסי עבודה שלא ניתן לתזמן. המצב הזה יכול לקרות כשמקצים צמתים לשני אובייקטים או יותר של Dynamic Workload Scheduler באותו מאגר צמתים.
  • אין תמיכה בהזמנות עם הכלי Dynamic Workload Scheduler. ב-Dynamic Workload Scheduler נדרשת ANY מדיניות המיקום, והיא היחידה שנתמכת להתאמה לעומס (scaling) של אשכולות.
  • בקשה אחת של 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.
  • אם עומס העבודה משתמש במיחזור צמתים והוא נפרס על ידי משימה, מגדירים את המשימה כך שמצב ההשלמה מוגדר ל-Indexed.
  • אובייקט ProvisioningRequest יחיד תומך רק בערך אחד ברשימה podSets. בקשות עם כמה רשומות של podSet נכשלות.

המאמרים הבאים