בדף הזה מוסבר איך לתכנן את השימוש ביחידות לעיבוד טנסורים (TPU) ב-Google Kubernetes Engine (GKE) כדי להקטין את הסיכון לבעיות בהגדרת ה-TPU, לשגיאות שקשורות לזמינות או להפרעות שנובעות מחריגה מהמכסה.
לפני שמשתמשים ב-TPU ב-GKE, חשוב להכיר את ההגדרות והטרמינולוגיה של TPU ב-GKE.
תכנון ההגדרה של TPU
כדי לעבוד עם TPU באשכולות GKE, צריך לתכנן את ההגדרה שלהם. מומלץ לפעול לפי השלבים הבאים:
בחירת מצב פעולה של GKE: הרצת עומסי עבודה ב-TPU באשכול GKE Autopilot או Standard.
שיטה מומלצת: שימוש באשכול Autopilot כדי ליהנות מחוויית Kubernetes בניהול מלא.
בחירת גרסת ה-TPU: לסוגים שונים של TPU יש יכולות שונות, כמו יחס עלות-תועלת, קצב אימון וזמן אחזור של הצגת מודעות. סוגי ה-TPU משפיעים על קיבולת המעבד והזיכרון הזמינים.
אימות הזמינות של TPU: מכשירי TPU זמינים באזורים ספציפיים Google Cloud. כדי להשתמש בסוג TPU בעומס העבודה של GKE, האשכול צריך להיות באזור נתמך עבור הסוג הזה.
Choose the TPU Topology: המיקום הפיזי של יחידות ה-TPU בתוך פרוסת TPU. בוחרים טופולוגיה שמתאימה לדרישות המקביליות של המודל.
אפשר להשתמש בטבלאות ההפניה שבדף הזה כדי לזהות אם מאגרי הצמתים שלכם הם צמתים של פרוסות TPU עם מארח יחיד או עם כמה מארחים.
בחירת מצב פעולה של GKE
אתם יכולים להשתמש ביחידות TPU במצבי הפעולה הזמינים של GKE לאשכולות:
- מצב רגיל: אתם מנהלים את התשתית הבסיסית, כולל הגדרת הצמתים האישיים.
- מצב Autopilot (מומלץ): GKE מנהל את התשתית הבסיסית, כמו הגדרת הצמתים, שינוי גודל אוטומטי, שדרוגים אוטומטיים, הגדרות אבטחה בסיסיות והגדרת רשת בסיסית. ב-Autopilot, בוחרים סוג וטופולוגיה של TPU, ואז מציינים אותם במניפסט של Kubernetes. GKE מנהל את הקצאת הצמתים עם יחידות TPU ואת התזמון של עומסי העבודה.
כדי לבחור את מצב הפעולה של GKE שהכי מתאים לעומסי העבודה שלכם, אפשר לעיין במאמר בחירת מצב פעולה של GKE.
בחירת אפשרות צריכת TPU
כשמתכננים את הגדרות ה-TPU ב-GKE, צריך לבחור אפשרות צריכה שתואמת לצרכים של עומס העבודה. הבחירה שלכם באפשרות הצריכה משפיעה על גרסאות ה-TPU שזמינות ועל המכסה שצריך להגדיר. GKE מציע את האפשרויות הבאות לשימוש ב-TPU, כדי לעזור לכם לבצע אופטימיזציה של הקצאת המשאבים והעלויות תוך שמירה על הביצועים של עומסי העבודה:
- התחלה גמישה (Flex-start): כדי להקצות מכונות וירטואליות מסוג Flex-start למשך עד שבעה ימים, כש-GKE מקצה את החומרה באופן אוטומטי על בסיס המאמץ המרבי (best-effort) בהתאם לזמינות. מידע נוסף מופיע במאמר מידע על הקצאת GPU, TPU ו-H4D במצב הקצאה "התחלה גמישה".
- VM במודל Spot: אתם יכולים לקבל הנחות משמעותיות על הקצאת VM במודל Spot, אבל יכול להיות שהמכונות האלה יופסקו בכל שלב, עם אזהרה של 30 שניות. מידע נוסף זמין במאמר בנושא VM במודל Spot.
- מקום שמור לעתיד ל-90 יום (במצב לוח שנה): כדי להקצות משאבי TPU לתקופה של עד 90 יום, לפרק זמן מוגדר. מידע נוסף זמין במאמר בקשת יחידות TPU עם מקום שמור לעתיד במצב לוח שנה.
- מקומות שמורים ל-TPU: כדי לבקש מקום שמור לעתיד לשנה או יותר.
- על פי דרישה: כדי לצרוך יחידות TPU בלי להגדיר קיבולת מראש. לפני שמבקשים משאבים, צריך לוודא שיש לכם מספיק מכסה על פי דרישה לסוג ולכמות הספציפיים של TPU VM. האפשרות 'על פי דרישה' היא הגמישה ביותר לצריכה; עם זאת, אין ערובה לכך שיהיו מספיק משאבים זמינים כדי לענות על הבקשה שלכם.
אם לא מציינים אפשרות אחרת, מודל הצריכה שמוגדר כברירת מחדל ל-TPU ב-GKE הוא על פי דרישה. כדי לבחור את אפשרות הצריכה שמתאימה לדרישות של עומס העבודה, אפשר לעיין במאמר מידע על אפשרויות צריכת מאיצים לעומסי עבודה של AI/ML ב-GKE.
בחירת גרסת ה-TPU
למכונות הווירטואליות בפרוסת TPU יש את המאפיינים הטכניים הבאים.
רגילה
| גרסת ה-TPU | סוג המכונה | cloud.google.com/gke-tpu-accelerator |
מספר המעבדים הווירטואליים | מספר הצ'יפים בכל מכונה וירטואלית | מספר צומתי NUMA | הסבירות להפקעה |
|---|---|---|---|---|---|---|
| Ironwood (TPU7x) | tpu7x-standard-4t |
tpu7x |
224 | 4 | 2 | לא רלוונטי |
| TPU Trillium (v6e) | ct6e-standard-1t |
tpu-v6e-slice |
44 | 1 | 1 | גבוה יותר |
| TPU Trillium (v6e) | ct6e-standard-4t |
tpu-v6e-slice |
180 | 4 | 1 | בינוני |
| TPU Trillium (v6e) | ct6e-standard-8t |
tpu-v6e-slice |
180 | 8 | 2 | נמוך יותר |
| TPU v5p |
ct5p-hightpu-4t |
tpu-v5p-slice |
208 | 4 | 2 | לא רלוונטי |
| TPU v5e |
ct5lp-hightpu-1t |
tpu-v5-lite-podslice |
24 | 1 | 1 | גבוה יותר |
| TPU v5e |
ct5lp-hightpu-4t |
tpu-v5-lite-podslice |
112 | 4 | 1 | בינוני |
| TPU v5e |
ct5lp-hightpu-8t |
tpu-v5-lite-podslice |
224 | 8 | 1 | נמוכה |
| TPU v4 |
ct4p-hightpu-4t |
tpu-v4-podslice |
240 | 4 | 2 | לא רלוונטי |
| TPU v3 (מארח יחיד בלבד) |
ct3-hightpu-4t |
tpu-v3-device |
96 | 4 | 2 | לא רלוונטי |
| TPU v3 |
ct3p-hightpu-4t |
tpu-v3-slice |
48 | 4 | 1 | לא רלוונטי |
סוגי מכונות ct5lp- עם כמה מארחים מתאימים יותר להצגת מודלים גדולים או לאימון. מכונות מרובות מארחים ct5lp- מחוברות זו לזו באמצעות קישורים מהירים.
טייס אוטומטי
| גרסת ה-TPU | cloud.google.com/gke-tpu-accelerator |
מספר המעבדים הווירטואליים (vCPU) | מספר צמתי NUMA | מספר מקסימלי של שבבי TPU בצומת של פרוסת TPU |
|---|---|---|---|---|
| Ironwood (TPU7x) | tpu7x |
224 | 2 | 2048 |
| TPU Trillium (v6e) | tpu-v6e-slice |
44 עד 180 | 1 עד 2 | 256 |
| TPU v5p |
tpu-v5p-slice |
208 | 2 | 6,144 |
| TPU v5e |
tpu-v5-lite-podslice |
24 עד 224 | 1 | 256 |
| TPU v4 |
tpu-v4-podslice |
240 | 2 | 4,096 |
| TPU v3 (מארח יחיד בלבד) |
tpu-v3-device |
96 | 2 | 8 |
| TPU v3 |
tpu-v3-slice |
48 | 1 | 256 |
כדי להחליט באיזו הגדרת TPU להשתמש, אפשר לעיין במפרטים ובמחירים של TPU במסמכי התמחור של Cloud TPU.
מגבלות
כשבוחרים את ה-TPU לשימוש, חשוב להביא בחשבון את המגבלות האלה:
ל-Ironwood (TPU7x) יש את המגבלות הבאות:
- אשכולות רגילים בגרסה 1.34.0-gke.2201000 ואילך.
- אשכולות Autopilot בגרסה 1.34.1-gke.3084001 ואילך.
- יש תמיכה רק ב-Google Cloud Hyperdisk Balanced ו-Hyperdisk ML.
TPU Trillium זמין בגרסאות הבאות:
- אשכולות Standard בגרסה 1.31.1-gke.1846000 ואילך.
- אשכולות במצב Autopilot בגרסה 1.31.2-gke.1115000 ואילך.
ב-TPU Trillium אי אפשר להגדיר SMT ל-
2ב-ct6e-standard-8t.אפשר להשתמש בהתאמה אוטומטית לעומס (automatic scaling) של TPU v5p באשכולות GKE עם מישורי בקרה שפועלים בגרסה 1.29.2-gke.1035000 או 1.28.7-gke.1020000 לפחות.
כדי להשתמש בהזמנות של קיבולת, צריך להשתמש בהזמנה ספציפית.
אפשר להריץ עד 256 פודים במכונת TPU וירטואלית אחת.
הקצאת העלויות ומדידת השימוש ב-GKE לא כוללות נתונים על השימוש ב-TPU או על העלויות שלהם.
המידרוג האוטומטי של האשכול מבטל פעולות של הרחבה אנכית של מאגרי צומתי TPU שנשארות בסטטוס המתנה במשך יותר מ-10 שעות. המידרוג האוטומטי של האשכול מנסה שוב לבצע פעולות כאלה של הגדלת הקיבולת כשהמשאבים זמינים. התנהגות כזו עלולה להקטין את זמינות ה-TPU אם לא משתמשים בהזמנות.
אין תמיכה בצומתי Ubuntu.
ארכיטקטורת TPU Node הוצאה משימוש. TPU v3 היא הגרסה היחידה של TPU שעדיין תומכת בארכיטקטורת TPU Node ב-GKE.
אימות הזמינות של TPU ב-GKE
מכשירי TPU זמינים באזורים מסוימים Google Cloud . כדי להשתמש בסוג TPU באשכול GKE, האשכול צריך להיות באזור נתמך עבור הסוג הזה.
רגילה
| גרסת ה-TPU | סוג המכונה מתחיל ב- | גרסת GKE מינימלית | זמינות | תחום (zone) |
|---|---|---|---|---|
| TPU Ironwood (TPU7x) |
tpu7x-standard-4t
|
1.34.0-gke.2201000 | GA |
|
| TPU Trillium (v6e) |
ct6e-
|
1.31.2-gke.1115000 | GA |
|
| TPU v5e |
ct5lp-
|
1.27.2-gke.2100 | GA |
|
| TPU v5p |
ct5p-
|
1.28.3-gke.1024000 | GA |
|
| TPU v4 |
ct4p-
|
1.26.1-gke.1500 | GA |
|
| TPU v3 |
ct3p-
|
1.31.1-gke.1146000 | GA |
|
| TPU v3 |
ct3-
|
1.31.0-gke.1500 | GA |
|
טייס אוטומטי
| גרסת ה-TPU |
cloud.google.com/gke-tpu-accelerator
|
גרסת GKE מינימלית | זמינות | תחום (zone) |
|---|---|---|---|---|
| TPU Ironwood (TPU7x) |
tpu7x
|
1.34.1-gke.3084001 | GA |
|
| TPU Trillium (v6e) |
tpu-v6e-slice
|
1.31.2-gke.1384000 | GA |
|
| TPU v5e |
tpu-v5-lite-podslice
|
1.27.2-gke.2100 | GA |
|
| TPU v5p |
tpu-v5p-slice
|
1.28.3-gke.1024000 | GA |
|
| TPU v4 |
tpu-v4-podslice
|
1.26.1-gke.1500 | GA |
|
| TPU v3 |
tpu-v3-slice
|
1.31.1-gke.1146000 | GA |
|
| TPU v3 |
tpu-v3-device
|
1.31.0-gke.1500 | GA |
|
בחירת טופולוגיה
אחרי שבוחרים גרסת TPU, בוחרים טופולוגיה נתמכת. טופולוגיה מגדירה את הסידור הפיזי של שבבי TPU בתוך פרוסת TPU. טופולוגיות גדולות יותר מספקות יותר שבבי TPU, שמאפשרים עיבוד מקביל יותר כדי לאמן מודלים גדולים מהר יותר או עם קבוצות נתונים גדולות יותר.
למרות ש-GKE מנהל באופן אוטומטי את הקצאת המכונות הווירטואליות, חשוב להבין את ההבדל בין מאגרי צמתים עם מארח יחיד לבין מאגרי צמתים עם כמה מארחים, כדי להבין איך מספר הצ'יפים בטופולוגיה קשור למכונות הווירטואליות הבסיסיות:
- Single-host: פרוסת TPU שבה כל הצ'יפים נמצאים במכונה וירטואלית אחת. התהליך הזה כולל מספר קטן יותר של צ'יפים, בדרך כלל ארבעה צ'יפים או פחות.
- מארחים מרובים: פרוסת TPU שבה הצ'יפים מפוזרים בין כמה מכונות וירטואליות. זה נפוץ ברוב עומסי העבודה של TPU בהיקף גדול.
אם תבקשו טופולוגיה שבה המספר הכולל של שבבים גדול ממספר השבבים שזמינים במכונה וירטואלית אחת לגרסת ה-TPU הזו, GKE יקצה אותה באופן אוטומטי כסביבה מרובת מארחים. בתרחיש הזה, GKE מפעיל כמה צמתים כדי לחלק את השבבים.
לדוגמה, נניח שיש סוג מכונה ct6e-standard-4t וטופולוגיה 4x4:
- לסוג המכונה
ct6e-standard-4tיש 4 שבבים לכל מכונה וירטואלית. - הטופולוגיה
4x4דורשת 16 שבבים בסך הכול (4 * 4). - מכיוון ש-16 (מספר השבבים בטופולוגיה) גדול מ-4 (מספר השבבים בכל מכונת VM), ההגדרה הזו יוצרת מאגר צמתים של פרוסת TPU עם כמה מארחים. GKE יחלק את 16 הצ'יפים בין 4 מכונות וירטואליות.
אתם יכולים להיעזר בטבלה הבאה כדי לבחור את סוג המכונה והטופולוגיה של ה-TPU שמתאימים לתרחיש לדוגמה שלכם:
רגילה
אחרי שבוחרים סוג וטופולוגיה של TPU, מציינים אותם במניפסט של עומס העבודה. הוראות מפורטות מופיעות במאמר פריסת עומסי עבודה של TPU ב-GKE Standard.
| גרסת ה-TPU | סוג המכונה | סוג מאגר הצמתים | מפרטים טכניים |
|---|---|---|---|
| Ironwood (TPU7x) | tpu7x-standard-4t |
מארח יחיד |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
מארחים מרובים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
מארחים מרובים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x-standard-4t |
מארחים מרובים |
|
| TPU Trillium (v6e) | ct6e-standard-1t |
מארח יחיד |
|
| TPU Trillium (v6e) | ct6e-standard-8t |
מארח יחיד |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
מארח יחיד |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
כמה מארחים |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
כמה מארחים |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
מארחים מרובים |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
מארחים מרובים |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
מארחים מרובים |
|
| TPU Trillium (v6e) | ct6e-standard-4t |
כמה מארחים |
|
| TPU v5p | ct5p-hightpu-4t |
מארח יחיד |
|
| TPU v5p | ct5p-hightpu-4t |
כמה מארחים |
|
| TPU v5p | ct5p-hightpu-4t |
כמה מארחים |
|
| TPU v5p | ct5p-hightpu-4t |
כמה מארחים |
|
| TPU v5p | ct5p-hightpu-4t |
כמה מארחים |
|
| TPU v5e | ct5lp-hightpu-1t |
מארח יחיד |
|
| TPU v5e | ct5lp-hightpu-4t |
מארח יחיד |
|
| TPU v5e | ct5lp-hightpu-8t |
מארח יחיד |
|
| TPU v5e | ct5lp-hightpu-4t |
מארחים מרובים |
|
| TPU v5e | ct5lp-hightpu-4t |
כמה מארחים |
|
| TPU v5e | ct5lp-hightpu-4t |
מארחים מרובים |
|
| TPU v5e | ct5lp-hightpu-4t |
כמה מארחים |
|
| TPU v5e | ct5lp-hightpu-4t |
כמה מארחים |
|
| TPU v4 | ct4p-hightpu-4t |
מארחים מרובים |
|
| TPU v4 | ct4p-hightpu-4t |
כמה מארחים |
|
| TPU v4 | ct4p-hightpu-4t |
כמה מארחים |
|
| TPU v4 | ct4p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3-hightpu-4t |
מארח יחיד |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
| TPU v3 | ct3p-hightpu-4t |
כמה מארחים |
|
-
החישוב מתבצע על ידי חלוקת מוצר הטופולוגיה בארבע. ↩
טייס אוטומטי
אחרי שבוחרים סוג וטופולוגיה של TPU, מציינים אותם במניפסט של עומס העבודה. הוראות מפורטות מופיעות במאמר בנושא פריסת עומסי עבודה של TPU ב-GKE Autopilot.
| גרסת ה-TPU | סוג המכונה | סוג מאגר הצמתים | מפרטים טכניים |
|---|---|---|---|
| Ironwood (TPU7x) | tpu7x |
מארח יחיד |
|
| Ironwood (TPU7x) | tpu7x |
מארחים מרובים |
|
| Ironwood (TPU7x) | tpu7x |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x |
כמה מארחים |
|
| Ironwood (TPU7x) | tpu7x |
כמה מארחים |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
מארח יחיד |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
מארח יחיד |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
מארח יחיד |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
כמה מארחים |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
מארחים מרובים |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
מארחים מרובים |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
מארחים מרובים |
|
| TPU Trillium (v6e) | tpu-v6e-slice |
כמה מארחים |
|
| TPU v5p | tpu-v5p-slice |
מארח יחיד |
|
| TPU v5p | tpu-v5p-slice |
כמה מארחים |
|
| TPU v5p | tpu-v5p-slice |
כמה מארחים |
|
| TPU v5p | tpu-v5p-slice |
כמה מארחים |
|
| TPU v5p | tpu-v5p-slice |
כמה מארחים |
|
| TPU v5p | tpu-v5p-slice |
כמה מארחים |
|
| TPU v5e | tpu-v5-lite-podslice |
מארח יחיד |
|
| TPU v5e | tpu-v5-lite-podslice |
מארח יחיד |
|
| TPU v5e | tpu-v5-lite-podslice |
מארח יחיד |
|
| TPU v5e | tpu-v5-lite-podslice |
מארחים מרובים |
|
| TPU v5e | tpu-v5-lite-podslice |
כמה מארחים |
|
| TPU v5e | tpu-v5-lite-podslice |
מארחים מרובים |
|
| TPU v5e | tpu-v5-lite-podslice |
כמה מארחים |
|
| TPU v5e | tpu-v5-lite-podslice |
כמה מארחים |
|
| TPU v5e | tpu-v5-lite-podslice |
כמה מארחים |
|
| TPU v4 | tpu-v4-podslice |
מארח יחיד |
|
| TPU v4 | tpu-v4-podslice |
מארחים מרובים |
|
| TPU v4 | tpu-v4-podslice |
כמה מארחים |
|
| TPU v4 | tpu-v4-podslice |
כמה מארחים |
|
| TPU v4 | tpu-v4-podslice |
מארחים מרובים |
|
| TPU v4 | tpu-v4-podslice |
כמה מארחים |
|
| TPU v3 | tpu-v3-slice |
כמה מארחים |
|
| TPU v3 | tpu-v3-slice |
כמה מארחים |
|
| TPU v3 | tpu-v3-slice |
כמה מארחים |
|
| TPU v3 | tpu-v3-slice |
כמה מארחים |
|
| TPU v3 | tpu-v3-slice |
כמה מארחים |
|
| TPU v3 | tpu-v3-device |
מארח יחיד |
|
-
החישוב מתבצע על ידי חלוקת מוצר הטופולוגיה בארבע. ↩
יש תמיכה בטופולוגיות בהתאמה אישית ליותר מ-64 שבבים. התנאים הבאים חלים:
- אם יש יותר מ-64 שבבים, המספרים
{A},{B}ו-{C}צריכים להיות כפולות של 4 - הטופולוגיה הגדולה ביותר היא
16x16x24 - הערכים צריכים להיות
{A}≤{B}≤{C}, למשל8x12x16.
- אם יש יותר מ-64 שבבים, המספרים
-
אין תמיכה בטופולוגיות בהתאמה אישית.
הגדרות מתקדמות
בקטעים הבאים מתוארות שיטות מומלצות לתזמון של הגדרות TPU מתקדמות.
אזורי AI
אזורי AI הם אזורים מיוחדים שמשמשים לאימון AI/ML ולעומסי עבודה של היקש. באזורים האלה יש קיבולת משמעותית של מאיצי למידת מכונה. מידע נוסף זמין במאמר בנושא אזורים עם AI.
במסמך הזה ובמסמכי התיעוד של GKE, המונחים 'תחומים רגילים' או 'תחומים' מתייחסים לתחומים שאינם תחומים של AI בתוך Google Cloud אזור.
לפני שמשתמשים באזור AI ב-GKE, כדאי לקחת בחשבון את המאפיינים הבאים:
- אזורי AI מופרדים פיזית מאזורים רגילים כדי לספק נפח אחסון וחשמל נוספים. ההפרדה הזו עלולה לגרום לזמן אחזור ארוך יותר, שבדרך כלל אפשר לסבול בעומסי עבודה של AI/ML.
- לאזורי AI יש סיומת עם הסימון
ai. לדוגמה, אזור AI באזורus-central1נקראus-central1-ai1a. - בשלב הזה יש תמיכה רק במכונות וירטואליות של TPU.
- מישור הבקרה של האשכול פועל באזור רגיל אחד או יותר באותו אזור כמו אזור ה-AI.
אפשר להריץ מכונות וירטואליות בלי יחידות TPU מצורפות באזור AI רק אם מתקיימות הדרישות הבאות:
- כבר מריצים עומסי עבודה אחרים שמשתמשים במכונות וירטואליות של TPU באותו אזור.
- המכונות הווירטואליות שהן לא TPU VM הן VM במודל Spot, שקשורות למקום שמור או שהן חלק ממאגר צמתים עם יחס ספציפי בין המאיץ למכונה הווירטואלית לשימוש כללי.
אזורי AI חולקים רכיבים, כמו חיבורי רשת ופריסות תוכנה, עם אזורים רגילים שיש להם את אותו סיומת באותו אזור. לעומסי עבודה של זמינות גבוהה, מומלץ להשתמש באזורים שונים. לדוגמה, לא מומלץ להשתמש גם ב-
us-central1-ai1aוגם ב-us-central1-aכדי להשיג זמינות גבוהה.
כברירת מחדל, GKE לא פורס את עומסי העבודה שלכם באזורי AI. כדי להשתמש באזור AI, צריך להגדיר אחת מהאפשרויות הבאות:
- (מומלץ) ComputeClasses: מגדירים את העדיפות הכי גבוהה לבקשת TPU על פי דרישה באזור AI. בעזרת ComputeClasses אתם יכולים להגדיר רשימה של הגדרות חומרה לעומסי העבודה שלכם לפי סדר עדיפויות. לדוגמה, ראו מידע על ComputeClasses.
- Node auto-provisioning: use a
nodeSelectorornodeAffinityin your Pod specification to instruct node auto-provisioning to create a node pool in the AI zone. אם עומס העבודה לא מטרגט באופן מפורש אזור AI, הקצאת צמתים אוטומטית מתייחסת רק לאזורים רגילים או לאזורים מ---autoprovisioning-locationsכשיוצרים מאגרי צמתים חדשים. ההגדרה הזו עוזרת לוודא שעומסי עבודה שלא מריצים מודלים של AI או למידת מכונה יישארו באזורים רגילים, אלא אם תגדירו אחרת באופן מפורש. דוגמה למניפסט שמשתמש ב-nodeSelectorמופיעה במאמר הגדרת אזורי ברירת המחדל לצמתים שנוצרו באופן אוטומטי. - GKE Standard: אם אתם מנהלים ישירות את מאגרי הצמתים, השתמשו באזור AI בדגל
--node-locationsכשאתם יוצרים מאגר צמתים. לדוגמה, אפשר לעיין במאמר בנושא פריסת עומסי עבודה של TPU ב-GKE Standard.
התאמה אוטומטית לעומס (autoscaling) של מעבדי TPU ב-GKE
GKE תומך ביחידות לעיבוד טנסורים (TPU) כדי להאיץ את עומסי העבודה של למידת מכונה. גם מאגר צמתים של פרוסת TPU במארח יחיד וגם מאגר צמתים של פרוסת TPU בכמה מארחים תומכים בהתאמה אוטומטית לעומס (autoscaling) ובהקצאת משאבים אוטומטית.
אם מגדירים את הדגל --enable-autoprovisioning באשכול GKE, GKE יוצר או מוחק מאגרי צמתים של חלקי TPU עם מארח יחיד או עם כמה מארחים, עם גרסת TPU וטופולוגיה שעומדות בדרישות של עומסי עבודה בהמתנה.
כשמשתמשים ב---enable-autoscaling, מערכת GKE משנה את גודל מאגר הצמתים בהתאם לסוג שלו, באופן הבא:
מאגר צמתים של פרוסת TPU במארח יחיד: GKE מוסיף או מסיר צומתי TPU במאגר הצמתים הקיים. מאגר הצמתים יכול להכיל כל מספר של צמתי TPU בין אפס לבין הגודל המקסימלי של מאגר הצמתים, כפי שנקבע על ידי האפשרויות --max-nodes ו---total-max-nodes. כשמאפשרים שינוי גודל של מאגר הצמתים, לכל צומתי ה-TPU במאגר הצמתים יש את אותו סוג מכונה ואותה טופולוגיה. במאמר יצירת מאגר צמתים מוסבר איך ליצור מאגר צמתים של פרוסות TPU במארח יחיד.
מאגר צמתים של פרוסת TPU מרובת מארחים: מערכת GKE מבצעת הגדלה אטומית של מאגר הצמתים מאפס למספר הצמתים שנדרש כדי להתאים לטופולוגיית ה-TPU. לדוגמה, אם יש מאגר צמתים של TPU עם סוג מכונה
ct5lp-hightpu-4tוטופולוגיה של16x16, מאגר הצמתים מכיל 64 צמתים. המידרוג האוטומטי של GKE עוזר לוודא שבמאגר הצמתים הזה יש בדיוק 0 או 64 צמתים. כשמצמצמים את הקיבולת, GKE מפנה את כל הפודים המתוזמנים ומרוקן את כל מאגר הצמתים לאפס. במאמר יצירת מאגר צמתים מוסבר איך ליצור מאגר צמתים של פרוסת TPU עם כמה מארחים.
הקצאת נפח אחסון נוסף לפרוסת TPU
מכונה וירטואלית בפרוסת TPU כוללת כברירת מחדל דיסק אתחול בנפח 10GB. אם פרוסת ה-TPU שלכם צריכה נפח אחסון נוסף לאימון או לעיבוד מקדים, או אם אתם צריכים לשמור נקודות ביקורת, אתם יכולים להשתמש באחסון Google Cloud Hyperdisk או דיסק אחסון מתמיד מאוזן אם הוא זמין ל-TPU שלכם. מידע נוסף על סוגי הדיסקים הנתמכים בכל גרסה של TPU זמין במאמר תמיכה ב-TPU ב-Google Cloud Hyperdisk וב-Persistent Disk.
מעבד (CPU) לאשכולות רגילים
הקטע הזה לא רלוונטי לאשכולות Autopilot כי GKE ממקם כל פרוסת TPU בצומת משלה. מידע נוסף זמין במאמר איך יחידות TPU פועלות במצב Autopilot.
בקטרי Standard, כדאי להשתמש בשיטות המומלצות הבאות לתזמון.
כדי לתזמן עומס עבודה שלא קשור ל-TPU במכונה וירטואלית בצומת של פרוסת TPU, צריך לוודא שה-Pod ב-GKE יכול לסבול את ה-taint של google.com/tpu. אם רוצים לפרוס את עומס העבודה בצמתים ספציפיים, משתמשים בבוררי צמתים.
ניהול משאבים ועדיפות ב-Kubernetes מתייחס למכונות וירטואליות ביחידות TPU באותו אופן כמו לסוגים אחרים של מכונות וירטואליות. כדי לתת עדיפות בתזמון ל-Pods שנדרשים ל-TPU על פני Pods אחרים באותם צמתים, צריך לבקש את השימוש המקסימלי ב-CPU או בזיכרון עבור חלקי ה-TPU האלה. פרוסות TPU בעדיפות נמוכה צריכות:
- כדי לוודא שבצומת יש מספיק משאבים שאפשר להקצות לעומסי העבודה של ה-TPU, מגדירים בקשות נמוכות למעבד (CPU) ולזיכרון. מידע נוסף זמין במאמר איך Kubernetes מיישם הקצאות משאבים ומגבלות.
- כדי לוודא ש-Pods יכולים להשתמש בכל המחזורים שלא בשימוש, צריך להגדיר את מגבלת המעבד ללא הגבלה (unlimited).
- כדאי להגדיר מגבלות זיכרון מתאימות כדי לוודא ש-Pods יכולים לפעול בצורה תקינה בלי להסתכן בהוצאה של node-pressure.
אם Kubernetes Pod לא מבקש מעבד וזיכרון (גם אם הוא מבקש TPU), Kubernetes מחשיב אותו כ-Pod שפועל כמיטב היכולת, ואין ערובה לכך שהוא צריך מעבד וזיכרון. רק Pods שמבקשים במפורש מעבד וזיכרון מקבלים את ההבטחות האלה. כדי לתזמן Kubernetes באופן ספציפי, צריך להגדיר את הצרכים של ה-Pod עם בקשת מעבד וזיכרון מפורשת. מידע נוסף זמין במאמר בנושא ניהול משאבים עבור פודים וקונטיינרים.
מידע נוסף על שיטות מומלצות זמין במאמר שיטות מומלצות ל-Kubernetes: הקצאות משאבים ומגבלות.
הפחתת ההפרעות בעומס העבודה
אם אתם משתמשים ב-TPU כדי לאמן מודל של למידת מכונה ועומס העבודה שלכם מופסק, כל העבודה שבוצעה מאז נקודת הבדיקה האחרונה אובדת. כדי להקטין את הסיכוי להפרעה בעומס העבודה, צריך לבצע את הפעולות הבאות:
- הגדרת עדיפות גבוהה יותר למשימה הזו בהשוואה לכל המשימות האחרות: אם המשאבים מוגבלים, המתזמן של GKE מפקיע משימות בעדיפות נמוכה יותר כדי לתזמן משימה בעדיפות גבוהה יותר. כך גם תוכלו לוודא שעומס העבודה בעדיפות גבוהה יקבל את כל המשאבים שהוא צריך (עד למשאבים הכוללים שזמינים באשכול). מידע נוסף זמין במאמר בנושא עדיפות של Pod ודחיקה.
- הגדרת החרגה מתחזוקה: החרגה מתחזוקה היא חלון זמן חד-פעמי שבו אסור לבצע תחזוקה אוטומטית. מידע נוסף זמין במאמר בנושא החרגות מתחזוקה.
- שימוש בפודים עם זמן ריצה מורחב ב-Autopilot: משתמשים בפודים עם זמן ריצה מורחב כדי לקבל תקופת חסד של עד שבעה ימים לפני ש-GKE מסיים את הפודים לצורך צמצום או שדרוג של צמתים.
- שימוש בתזמון איסוף ב-TPU Trillium: אתם יכולים להשתמש באוספים כדי לציין שמאגר של צומתי פרוסות TPU הוא חלק מעומס עבודה של הצגת מודעות. Google Cloud מגביל ומייעל את ההפרעות לפעולות של עומסי עבודה של הסקת מסקנות. מידע נוסף על תזמון איסוף
ההמלצות האלה עוזרות לצמצם את ההפרעות, אבל לא למנוע אותן. לדוגמה, עדיין יכולה להתרחש הפסקה זמנית בגלל כשל בחומרה או הפסקה זמנית לצורך דפרגמנטציה. באופן דומה, הגדרת החרגה של תחזוקה ב-GKE לא מונעת אירועי תחזוקה ב-Compute Engine.
שמרו נקודות ביקורת לעיתים קרובות והוסיפו קוד לסקריפט האימון כדי להתחיל מנקודת הביקורת האחרונה כשהאימון יתחדש.
טיפול בשיבושים שנגרמים בגלל תחזוקת צמתים
הצמתים של GKE שמארחים את ה-TPU כפופים לאירועי תחזוקה או לשיבושים אחרים שעלולים לגרום לסגירת הצמתים. באשכולות GKE שבהם מישור הבקרה מריץ את גרסה 1.29.1-gke.1425000 ואילך, אפשר להגדיר את GKE כך שיסיים את עומסי העבודה בצורה תקינה, כדי לצמצם את ההפרעה לעומסי העבודה.
כדי להבין, להגדיר ולנטר אירועי שיבוש שעשויים להתרחש בצמתי GKE שמריצים עומסי עבודה של AI/ML, אפשר לעיין במאמר ניהול שיבושים בצמתי GKE עבור מעבדי GPU ו-TPU.
ניצול מקסימלי של ה-TPU
כדי להפיק את המקסימום מההשקעה ב-TPU, כדאי לתזמן שילוב של עדיפויות למשימות ולהוסיף אותן לתור כדי למקסם את משך הזמן שבו ה-TPU פועלים. כדי לתזמן משימות ברמת המשימה ולבצע דחיקה (preemption), צריך להשתמש בתוסף ל-Kubernetes שמארגן משימות בתורים.
אפשר להשתמש ב-Kueue כדי לתזמן את העבודות בתורים.
המאמרים הבאים
- כדי להגדיר Cloud TPU עם GKE, פועלים לפי ההוראות במאמר פריסת עומסי עבודה של TPU ב-GKE.
- מידע ולמידה על שיטות מומלצות לשימוש ב-Cloud TPU למשימות של למידת מכונה.
- איך בונים למידת מכונה בקנה מידה גדול ב-Cloud TPU באמצעות GKE
- הפעלת מודלים גדולים של שפה (LLM) באמצעות KubeRay ב-TPU