מידע על אפשרויות צריכת מאיצים לעומסי עבודה של AI/ML ב-GKE

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

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

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

הסבר על אפשרויות הצריכה

אפשר לבחור מבין האפשרויות הבאות כדי להשתמש במאיצים ב-GKE:

  • על פי דרישה: אתם משתמשים במעבדי TPU או GPU ב-GKE בלי לתכנן מראש את הקיבולת. לפני שמבקשים משאבים, צריך לוודא שיש מספיק מכסה לפי דרישה לסוג ולכמות הספציפיים של המאיצים. השימוש על פי דרישה הוא האפשרות הכי גמישה, אבל אין ערובה לכך שיהיו מספיק משאבים על פי דרישה כדי לספק את הבקשה שלכם.
  • הזמנות: אתם מזמינים משאבים לתקופה מוגדרת. הזמנה יכולה להיות אחת מהאפשרויות הבאות:
    • הזמנות עתידיות: אתם מזמינים משאבים לתקופות ארוכות יותר בדרך כלל, לזמן ספציפי בעתיד. יש לכם גישה בלעדית למשאבים המוזמנים למשך התקופה הזו. כדי להזמין בעתיד, צריך ליצור קשר עם מנהל חשבונות טכני (TAM). מידע נוסף זמין במאמרים בנושא TPU ו-GPU.
    • מקום שמור לעתיד לפרק זמן של עד 90 יום (במצב יומן): אתם מבקשים קיבולת לפרק זמן מסוים, והיועץ ביומן מציע תאריכים פנויים. הזמנות עתידיות לפרק זמן של עד 90 ימים (במצב יומן) מאפשרות גמישות רבה יותר לפרקי זמן קצרים יותר וחיפוש קיבולת בשירות עצמי. מידע נוסף זמין במאמר בנושא בקשות למקום שמור לעתיד במצב יומן.
    • מקום שמור על פי דרישה: אתם יכולים לבקש הקצאה של מקום שמור על פי דרישה ברגע שהקיבולת תהיה זמינה, בדומה לאפשרות על פי דרישה. בזמן שההזמנה פעילה, אתם משלמים על המשאבים בין אם אתם משתמשים בהם ובין אם לא.
  • התחלה גמישה: אתם מאבטחים משאבים שהוקצו בצפיפות לעומסי עבודה לטווח קצר בלי הזמנה. אתם מבקשים מספר ספציפי של מעבדי GPU או TPU, ו-Compute Engine מקצה אותם כשקיבולת הופכת לזמינה. ה-GPU או ה-TPU פועלים ללא הפרעה למשך עד שבעה ימים. מידע נוסף זמין במאמר בנושא הקצאת משאבים עם גמישות בהתחלה.
  • Spot: אתם מקצים מכונות וירטואליות מסוג Spot, וכך נהנים מהנחות משמעותיות. עם זאת, יכול להיות שמכונות וירטואליות מסוג Spot יידחקו בכל שלב, עם אזהרה של 30 שניות. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot.

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

הסבר על מכסת המאיצים ב-GKE

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

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

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

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

  • Google Cloud בחשבונות לתקופת ניסיון בחינם יש מגבלות על בקשות להגדלת מכסות של משאבים בעלי ערך גבוה כמו יחידות GPU ו-TPU. כדי לקבל גישה למכסת התאוצה, צריך לשדרג לחשבון בתשלום.

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

זיהוי אפשרות צריכה

השיקולים הבאים יעזרו לכם לבחור את אפשרות הצריכה הטובה ביותר לעומס העבודה שלכם ב-AI/ML:

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

בחירת אפשרות צריכה

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

אפשרות צריכה פרמטרים של הקצאת הרשאות מאיצים נתמכים פרטים דוגמאות לעומסי עבודה
הזמנות על פי דרישה
  • זמן הקצאת המשאבים: מיידי (בהזמנה שאושרה)
  • תוחלת החיים: לטווח ארוך (לכל הזמנה)
  • כל GPU (למעט A4X,‏ A4 או A3 Ultra)
  • כל TPU
  • עלות: אתם מחויבים על תקופת ההזמנה המלאה.
  • מכסה: המכסה גדלה באופן אוטומטי לפני שהקיבולת מועברת.
  • עומסי עבודה (workloads) גדולים שפועלים לאורך זמן, כמו אימון מראש של מודלים בסיסיים או הסקת מסקנות (inference) בכמה מארחים.
  • עומסי עבודה בסביבת ייצור.
הזמנות עתידיות
  • זמן הקצאת המשאבים: מיידי (בהזמנה שאושרה)
  • תוחלת חיים: לטווח ארוך (לכל הזמנה)
  • G2
  • A2
  • ‫A3 High עם 8 מעבדי GPU
  • A3 Mega
  • A3 Edge
  • עלות: אתם מחויבים על תקופת ההזמנה המלאה.
  • מכסה: המכסה גדלה באופן אוטומטי לפני שהקיבולת מועברת.
  • עומסי עבודה (workloads) גדולים שפועלים לאורך זמן, כמו אימון מראש של מודלים בסיסיים או הסקת מסקנות (inference) בכמה מארחים.
  • עומסי עבודה בסביבת ייצור.
הזמנות עתידיות ל-90 יום (במצב יומן)
  • זמן הקצאת המשאבים: מיידי (בהזמנה שאושרה)
  • משך החיים: עד 90 ימים
  • A4
  • A3 Ultra
  • A3 Mega
  • ‫A3 High עם 8 מעבדי GPU
  • A3 Edge
  • ‫Ironwood (TPU7x)
  • TPU v6e
  • TPU v5p
  • TPU v5e
  • עלות: בהנחה (עד 53%). החיוב הוא על תקופת ההזמנה.
  • מכסה: אין חיוב על מכסה.
  • עומסי עבודה מבוזרים שפועלים לזמן קצר, כמו כוונון עדין של מודלים, סימולציות או הסקת מסקנות באצווה, שבהם נדרשת שעת התחלה מדויקת.
  • עומסי עבודה להערכת פלטפורמה, להשוואה או לבדיקת אופטימיזציה.
מצב הקצאת משאבים מסוג Flex-start
  • זמן הקצאה: על פי דרישה (בכפוף לזמינות)
  • משך החיים: עד 7 ימים לכל הקצאה
  • כל משפחות ה-GPU חוץ מ-A4X
  • כל הגרסאות של TPU
  • עומסי עבודה של אצווה, כמו אימון מודלים קטנים, כוונון עדין או הסקת מסקנות ניתנת להרחבה, שבהם זמן ההתחלה גמיש.
  • עומסי עבודה ל-POC או לבדיקות שילוב.
מכונות וירטואליות במודל Spot
  • זמן הקצאה: על פי דרישה (בכפוף לזמינות)
  • משך החיים: משתנה, אפשר להקדים את סיום ההפעלה עם אזהרה של 30 שניות
  • כל משפחות ה-GPU חוץ מ-A4X
  • כל הגרסאות של TPU
  • עומסי עבודה עם עדיפות נמוכה יותר ועמידות בפני תקלות, כמו CI/CD, ניתוח נתונים או מחשוב עתיר ביצועים (HPC).
  • עומסי עבודה שניתן להפריע להם בקלות.
על פי דרישה (יחידות GPU או יחידות TPU)
  • זמן הקצאת הרישיון: מיידי (בכפוף לזמינות)
  • תוחלת חיים: ללא הגבלה
  • כל משפחות ה-GPU, מלבד A4X, ‏ A4 או A3 Ultra
  • כל הגרסאות של TPU
  • עלות: אתם משלמים לפי השימוש.
  • מכסה: המכסה בתעריף על פי דרישה של GPU או TPU מחויבת.
  • עומסי עבודה למטרות כלליות שנדרש להם ביצוע מיידי.

אופטימיזציה של עלויות והקצאת עומסי עבודה באמצעות ComputeClasses

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

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

  • Reservations: אפשר להגדיר את שם ההזמנה בשדה reservations ב-ComputeClass. כך המערכת תנסה קודם להשתמש בקיבולת שהזמנתם ב-GKE לפני שתחזור לשימוש בקיבולת הרגילה.
  • מצב הקצאת משאבים עם התחלה גמישה: מפעילים את התור הגמיש באמצעות השדה flexStart ב-ComputeClass, ומגדירים את משכי הזמן להחלפת צומת הגיבוי באמצעות השדות nodeRecycling.
  • מכונות וירטואליות זמניות מסוג Spot: מגדירים את השדה spot לערך true כדי להנחות את GKE להשתמש במכונות וירטואליות זמניות מסוג Spot כשמקצים צמתים לכלל העדיפות הזה.
  • קיבולת לפי דרישה בשילוב עם מדיניות מיקום מרובת אזורים: מצהירים על הגדרות ברירת המחדל של המכונות ברשימת העדיפויות ומגדירים אסטרטגיית מיקום חלופית באמצעות השדות location.

ב-ComputeClasses אין תמיכה בהזמנות עתידיות או בהזמנות עתידיות ל-90 ימים (במצב יומן).

דוגמאות לאפשרויות צריכה עם ComputeClasses

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

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

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

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

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

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: ha-gpu-fallback
    spec:
      activeMigration:
        optimizeRulePriority: true # Migrate workloads back to reservation when capacity releases
      priorities:
      # Priority 1: Consume specific corporate reservation first
      - gpu:
          type: nvidia-l4
          count: 1
        reservations:
          affinity: Specific
          specific:
          - name: reserved-l4-pool
            project: my-project
            zones: [us-central1-a]
      # Priority 2: Fallback to Flex Start (short-duration allocation)
      - gpu:
          type: nvidia-l4
          count: 1
        flexStart:
          enabled: true
      # Priority 3: Fallback to On-demand resources
      - gpu:
          type: nvidia-l4
          count: 1
    

מצב הקצאת משאבים עם גמישות בהתחלה, עם הגדרה של מיחזור צמתים

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

  1. בקשה של מכונות וירטואליות מסוג Flex-start:‏ GKE מבקש מופעים של מכונות וירטואליות מתור ההמתנה של Flex-start (שפועלות ללא הפרעה למשך עד שבעה ימים).
  2. מעקב אחרי תפוגת החכירה:‏ GKE עוקב אחרי משך הזמן שנותר עד לתפוגה של הצמתים הפעילים עם הפעלה גמישה.
  3. הפעלת מיחזור של צומת: עשרים דקות (1,200 שניות) לפני שתוקף השכירות של מכונת ה-VM יפוג, GKE מקצה באופן אוטומטי צומת חלופי.
  4. תזמון מחדש של עומסי עבודה: עומסי העבודה מועברים לצומת החדש, והביצוע שלהם נמשך ללא הפרעה בשירות.

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: flex-node-recycling
    spec:
      priorities:
      - gpu:
          type: nvidia-l4
          count: 1
        flexStart:
          enabled: true
          nodeRecycling:
            leadTimeSeconds: 1200 # Automatically launch replacement node before VM lease expires
    

הגדרת מדיניות הקצאה של מספר אזורים

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

  1. הגדרת אזורי יעד: אפשר לציין כמה אזורי גיבוי (כמו us-central1-a, us-central1-b ו-us-central1-c) בכללי העדיפות.
  2. הרחבת פרמטרי הטירגוט: מגדירים את מדיניות המיקום לערך ANY. ההגדרה הזו מורה לכלי לשינוי גודל האשכול לחפש קיבולת נדרשת בכל האזורים שצוינו.
  3. ניתוח הזמינות באזורים: במהלך אירועי הגדלה, GKE סורק את האזורים שצוינו.
  4. הקצאת משאבים באזורים זמינים:‏ GKE מקצה באופן מיידי את צמתי עומס העבודה המבוקשים בכל אזור יעד שיש בו קיבולת תואמת. השיטה הזו מונעת חסימות בתורי הקצאה.

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: broad-zonal-serving
    spec:
      priorities:
      - gpu:
          type: nvidia-l4
          count: 1
        location:
          zones: [us-central1-a, us-central1-b, us-central1-c]
          locationPolicy: ANY # Provision accelerator in any target zone with supply
    

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