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

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

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

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

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

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

מתי כדאי להשתמש בשיטת 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) בעומסי העבודה. בנוסף, באשכולות Standard, אתם יכולים להגדיר הפעלה גמישה במאגרי צמתים ספציפיים. מכונות וירטואליות עם הפעלה גמישה מוקצות אוטומטית ב-GKE בתהליך הבא, כשקיבולת הופכת לזמינה:

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

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

הגדרות Flex-start

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

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

  • ‫Flex-start with queued provisioning, שבו 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 מקצה את כל המשאבים הנדרשים בו-זמנית.
מורכבות ההגדרה פחות מורכבות. ההגדרה הזו דומה למכונות VM לפי דרישה ולמכונות VM מסוג Spot. מורכבים יותר. מומלץ מאוד להשתמש בכלי לניהול מכסות, כמו Kueue.
תמיכה בסוגי מחשוב בהתאמה אישית כן לא
מיחזור צמתים כן לא
מחיר Flex Start SKU Flex Start SKU
מכסה
אסטרטגיית שדרוג הצומת שדרוגים לזמן קצר שדרוגים לזמן קצר
סימון gcloud container node pool create --flex-start
  • --flex-start
  • --enable-queued-provisioning
קדימה, מתחילים יחידות GPU: TPUs: הפעלת עומס עבודה גדול עם הפעלה גמישה באמצעות הקצאת משאבים בתור

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • ‫creationTimestamp יחד עם maxRunDurationSeconds
    • leadTimeSeconds

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

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

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

  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

מידע נוסף על שימוש במיחזור צמתים זמין במדריך 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 נכשלות.

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