בדף הזה מתוארות הטכניקות הזמינות שבהן אפשר להשתמש כדי להשיג מאיצי מחשוב, כמו מעבדי 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), הערכת פלטפורמה, פיתוח או בדיקה של אפליקציה, הכנסה לשימוש או אופטימיזציה.
- זמן הקצאת המשאבים: צריך לקבוע אם עומס העבודה דורש ביצוע מיידי או שאפשר להריץ אותו בעתיד. אם אפשר להפעיל את התהליך בעתיד, צריך לקבוע את מידת הגמישות של שעת ההתחלה.
- איזון בין עלות לביצועים: כדאי להעריך את הדרישות של עומס העבודה ואת מגבלות התקציב כדי לבחור את המאיץ הכי חסכוני. כדאי לשקול את האיזון בין העלות של המאיצים לבין מאפייני הביצועים שלהם. חשוב לזכור שמאיצי ביצועים חדשים עשויים לשפר את יחסי העלות-ביצועים.
בחירת אפשרות צריכה
הטבלה הבאה תעזור לכם לבחור את אפשרות הצריכה המתאימה:
| אפשרות צריכה | פרמטרים של הקצאת הרשאות | מאיצים נתמכים | פרטים | דוגמאות לעומסי עבודה |
|---|---|---|---|---|
| הזמנות על פי דרישה |
|
|
|
|
| הזמנות עתידיות |
|
|
|
|
| הזמנות עתידיות ל-90 יום (במצב יומן) |
|
|
|
|
| מצב הקצאת משאבים מסוג Flex-start |
|
|
|
|
| מכונות וירטואליות במודל Spot |
|
|
|
|
| על פי דרישה (יחידות GPU או יחידות TPU) |
|
|
|
אופטימיזציה של עלויות והקצאת עומסי עבודה באמצעות ComputeClasses
אתם יכולים להשתמש ב-ComputeClasses כדי לנהל באופן דינמי ולאוטומטי את אסטרטגיית השימוש במאיצים, על ידי הגדרת רשימה של תצורות חלופיות שמבוססת על עדיפות. במהלך פעולות הרחבה, GKE מנסה להקצות צמתים בהתאם להיררכיית העדיפויות שהגדרתם.
ברשימה הבאה מפורטות אפשרויות הצריכה שזמינות עם ComputeClasses ומוסבר איך להגדיר אותן. דוגמאות למניפסטים מלאים של YAML מופיעות במאמר דוגמאות לאפשרויות צריכה עם ComputeClasses.
- Reservations: אפשר להגדיר את שם ההזמנה בשדה
reservationsב-ComputeClass. כך המערכת תנסה קודם להשתמש בקיבולת שהזמנתם ב-GKE לפני שתחזור לשימוש בקיבולת הרגילה. - מצב הקצאת משאבים עם התחלה גמישה: מפעילים את התור הגמיש באמצעות השדה
flexStartב-ComputeClass, ומגדירים את משכי הזמן להחלפת צומת הגיבוי באמצעות השדותnodeRecycling. - מכונות וירטואליות זמניות מסוג Spot: מגדירים את השדה
spotלערךtrueכדי להנחות את GKE להשתמש במכונות וירטואליות זמניות מסוג Spot כשמקצים צמתים לכלל העדיפות הזה. - קיבולת לפי דרישה בשילוב עם מדיניות מיקום מרובת אזורים:
מצהירים על הגדרות ברירת המחדל של המכונות ברשימת העדיפויות ומגדירים אסטרטגיית מיקום חלופית באמצעות השדות
location.
ב-ComputeClasses אין תמיכה בהזמנות עתידיות או בהזמנות עתידיות ל-90 ימים (במצב יומן).
דוגמאות לאפשרויות צריכה עם ComputeClasses
בקטעים הבאים מופיעות דוגמאות להגדרות של האסטרטגיות האלה.
הזמנות עם הגדרת חזרה למצב ראשוני
ההגדרה הזו מתאימה במיוחד לעומסי עבודה שיכולים להתמודד עם שיבושים, ולא לעומסי עבודה שתלויים בנתונים קבועים או שצריכים לפעול עד הסוף.
ההגדרה הזו קובעת אסטרטגיה גמישה לחזרה לגרסה קודמת באמצעות השלבים הבאים:
- צריכת הזמנות קודמת: מערכת GKE מנסה להקצות צמתים באמצעות הזמנת הקיבולת הספציפית שרכשתם מראש.
- חזרה ל-Flex-start: אם נעשה שימוש מלא בקיבולת של ההזמנה, GKE חוזר למשאבי Flex-start עם הנחה לטווח קצר.
- חזרה לשימוש על פי דרישה: כגיבוי אחרון, GKE מקצה משאבים רגילים על פי דרישה.
מעבר חזרה להזמנות: הפעלת העברה פעילה מורה ל-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
מצב הקצאת משאבים עם גמישות בהתחלה, עם הגדרה של מיחזור צמתים
ההגדרה הזו מנהלת קיבולת מוזלת לפרקי זמן קצרים עם זמינות רציפה באמצעות השלבים הבאים:
- בקשה של מכונות וירטואליות מסוג Flex-start: GKE מבקש מופעים של מכונות וירטואליות מתור ההמתנה של Flex-start (שפועלות ללא הפרעה למשך עד שבעה ימים).
- מעקב אחרי תפוגת החכירה: GKE עוקב אחרי משך הזמן שנותר עד לתפוגה של הצמתים הפעילים עם הפעלה גמישה.
- הפעלת מיחזור של צומת: עשרים דקות (1,200 שניות) לפני שתוקף השכירות של מכונת ה-VM יפוג, GKE מקצה באופן אוטומטי צומת חלופי.
תזמון מחדש של עומסי עבודה: עומסי העבודה מועברים לצומת החדש, והביצוע שלהם נמשך ללא הפרעה בשירות.
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
הגדרת מדיניות הקצאה של מספר אזורים
ההגדרה הזו עוקפת את ההגבלות על היצע במקרה של זמינות באזור יחיד באמצעות השלבים הבאים:
- הגדרת אזורי יעד: אפשר לציין כמה אזורי גיבוי (כמו
us-central1-a,us-central1-bו-us-central1-c) בכללי העדיפות. - הרחבת פרמטרי הטירגוט: מגדירים את מדיניות המיקום לערך
ANY. ההגדרה הזו מורה לכלי לשינוי גודל האשכול לחפש קיבולת נדרשת בכל האזורים שצוינו. - ניתוח הזמינות באזורים: במהלך אירועי הגדלה, GKE סורק את האזורים שצוינו.
הקצאת משאבים באזורים זמינים: 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