בדף הזה מוסבר איך לתכנן את השימוש ביחידות לעיבוד טנסורים (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: The physical arrangement of the TPUs within a TPU slice. בוחרים טופולוגיה שתואמת לדרישות המקביליות של המודל.
אפשר להשתמש בטבלאות ההפניה שבדף הזה כדי לזהות אם מאגרי הצמתים שלכם הם צמתים של פרוסות TPU עם מארח יחיד או עם כמה מארחים.
בחירת מצב פעולה של GKE
אפשר להשתמש ב-TPU במצבי הפעולה הזמינים של GKE לאשכולות:
- מצב רגיל: אתם מנהלים את התשתית הבסיסית, כולל הגדרת הצמתים האישיים.
- מצב Autopilot (מומלץ): מערכת GKE מנהלת את התשתית הבסיסית, כמו הגדרת הצמתים, התאמה אוטומטית לעומס, השדרוגים האוטומטיים, הגדרות האבטחה הבסיסיות והגדרות הרשת הבסיסיות. ב-Autopilot, בוחרים סוג וטופולוגיה של TPU, ואז מציינים אותם במניפסט של Kubernetes. GKE מנהל את הקצאת הצמתים עם יחידות TPU ואת התזמון של עומסי העבודה.
כדי לבחור את מצב הפעולה של GKE שהכי מתאים לעומסי העבודה שלכם, אפשר לעיין במאמר בחירת מצב פעולה של GKE.
בחירת אפשרות לשימוש ב-TPU
כשמתכננים את הגדרות ה-TPU ב-GKE, צריך לבחור אפשרות צריכה שתואמת לצרכים של עומס העבודה. האפשרות שתבחרו לצריכת משאבים תשפיע על גרסאות ה-TPU שזמינות לכם ועל המכסה שתצטרכו להגדיר. GKE מציע את האפשרויות הבאות לשימוש ב-TPU, כדי לעזור לכם לשפר את הקצאת המשאבים והעלויות תוך שמירה על ביצועי עומסי העבודה:
- Flex-start: כדי להקצות מכונות וירטואליות מסוג Flex-start למשך עד שבעה ימים, כאשר GKE מקצה את החומרה באופן אוטומטי על בסיס הזמינות. מידע נוסף מופיע במאמר מידע על הקצאת GPU, TPU ו-H4D במצב הקצאה עם הפעלה גמישה.
- מכונות וירטואליות (VM) זמניות מסוג Spot: כדי להקצות מכונות וירטואליות זמניות מסוג Spot, אפשר לקבל הנחות משמעותיות, אבל המכונות האלה יכולות להיפסק בכל שלב, עם אזהרה של 30 שניות מראש. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot.
- מקום שמור לעתיד לפרק זמן של עד 90 יום (במצב לוח שנה): הקצאת משאבי TPU לפרק זמן של עד 90 יום. מידע נוסף זמין במאמר בנושא שליחת בקשה ל-TPU עם מקום שמור לעתיד במצב יומן.
- הזמנות של TPU: כדי לבקש מקום שמור לעתיד למשך שנה או יותר.
- על פי דרישה: כדי להשתמש ב-TPU בלי לתכנן מראש את הקיבולת. לפני שמבקשים משאבים, צריך לוודא שיש לכם מספיק מכסת משאבים לפי דרישה לסוג ולכמות הספציפיים של מכונות TPU וירטואליות. האפשרות 'על פי דרישה' היא האפשרות הכי גמישה לשימוש במשאבים, אבל אין ערובה לכך שיהיו מספיק משאבים על פי דרישה כדי לספק את הבקשה שלכם.
אם לא מציינים אפשרות אחרת, מודל הצריכה שמוגדר כברירת מחדל ל-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 |
מספר המעבדים הווירטואליים | מספר הצמתים של 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 זמין בגרסאות הבאות:
- אשכולות רגילים בגרסה 1.31.1-gke.1846000 ואילך.
- אשכולות במצב Autopilot בגרסה 1.31.2-gke.1115000 ואילך.
TPU Trillium לא תומך בהגדרה של SMT לערך
2ב-ct6e-standard-8t.אפשר להשתמש בשינוי גודל אוטומטי של 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 שבה כל הצ'יפים נמצאים במכונה וירטואלית אחת. הפעולה הזו כוללת מספר קטן יותר של צ'יפים, בדרך כלל ארבעה צ'יפים או פחות.
- Multi-host: פרוסת 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 ולעומסי עבודה של הסקת מסקנות. האזורים האלה מספקים קיבולת משמעותית של מאיצי ML. מידע נוסף זמין במאמרי העזרה בנושא אזורי AI.
במסמך הזה ובמסמכי התיעוד של GKE, המונחים 'אזורים רגילים' או 'אזורים' מתייחסים לאזורים שאינם אזורי AI בתוך Google Cloud אזור.
לפני שמשתמשים באזור AI ב-GKE, כדאי לקחת בחשבון את המאפיינים הבאים:
- אזורי ה-AI נפרדים פיזית מאזורים רגילים כדי לספק נפח אחסון וכוח נוספים. ההפרדה הזו עשויה להוביל לזמן אחזור ארוך יותר, שבדרך כלל נסבל בעומסי עבודה של AI/ML.
- לאזורי AI יש סיומת עם הסימון
ai. לדוגמה, אזור AI באזורus-central1נקראus-central1-ai1a. - בשלב הזה יש תמיכה רק במכונות וירטואליות של TPU.
- מישור הבקרה של האשכול פועל באזור רגיל אחד או יותר באותו אזור כמו אזור ה-AI.
אפשר להריץ מכונות וירטואליות בלי יחידות TPU מצורפות באזור AI רק אם מתקיימות הדרישות הבאות:
- כבר מריצים עומסי עבודה אחרים שמשתמשים במכונות וירטואליות של TPU באותו אזור.
- מכונות ה-VM שאינן TPU הן מכונות Spot VM, מכונות שמשוריינות להזמנה או מכונות שמשויכות למאגר צמתים עם יחס ספציפי בין מאיץ ל-VM למטרה כללית.
אזורי 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/ML יישארו באזורים רגילים, אלא אם תגדירו אחרת באופן מפורש. דוגמה למניפסט שמשתמש ב-nodeSelectorמופיעה במאמר הגדרת אזורי ברירת המחדל לצמתים שנוצרו אוטומטית. - GKE Standard: אם אתם מנהלים ישירות את מאגרי הצמתים, השתמשו באזור AI בדגל
--node-locationsכשאתם יוצרים מאגר צמתים. לדוגמה, אפשר לעיין במאמר בנושא פריסת עומסי עבודה של TPU ב-GKE Standard.
התאמה אוטומטית לעומס (automatic scaling) של מעבדי 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
כברירת מחדל, מכונת VM בפרוסת TPU כוללת דיסק אתחול בנפח 10GB. אם חלוקת ה-TPU שלכם צריכה אחסון נוסף לאימון או לעיבוד מקדים, או אם אתם צריכים לשמור נקודות ביקורת, אתם יכולים להשתמש באחסון Google Cloud Hyperdisk או דיסק אחסון מתמיד מאוזן אם הוא זמין ל-TPU שלכם. מידע נוסף על סוגי הדיסקים הנתמכים בכל גרסה של TPU זמין במאמר תמיכה ב-TPU ב-Google Cloud Hyperdisk ובדיסק מתמשך.
מעבד (CPU) באשכולות רגילים
הקטע הזה לא רלוונטי לאשכולות Autopilot כי GKE ממקם כל פרוסת TPU בצומת משלה. מידע נוסף על אופן הפעולה של TPU במצב טייס אוטומטי
במקרים של אשכולות רגילים, כדאי להשתמש בשיטות המומלצות הבאות לתזמון.
כדי לתזמן עומס עבודה שאינו TPU במכונה וירטואלית בצומת של פלח TPU, צריך לוודא ש-Pod של GKE יכול לסבול את ה-taint google.com/tpu. אם רוצים לפרוס את עומס העבודה לצמתים ספציפיים, משתמשים בבוררי צמתים.
ניהול משאבים ועדיפות ב-Kubernetes מתייחס למכונות וירטואליות ב-TPU באופן זהה לסוגים אחרים של מכונות וירטואליות. כדי לתת עדיפות בתזמון ל-Pods שנדרשים ל-TPU על פני Pods אחרים באותם צמתים, צריך לבקש את המקסימום של CPU או זיכרון עבור חלקי ה-TPU האלה. פרוסות TPU בעדיפות נמוכה צריכות:
- מגדירים בקשות נמוכות של מעבד וזיכרון כדי לוודא שלצומת יש מספיק משאבים להקצאה לעומסי העבודה של TPU. מידע נוסף זמין במאמר איך Kubernetes מיישם בקשות ומגבלות של משאבים.
- כדי לוודא שרכיבי ה-Pod יכולים להשתמש בכל המחזורים שלא נמצאים בשימוש, צריך להגדיר את המגבלה על השימוש ביחידת העיבוד המרכזית (CPU) ללא הגבלה.
- כדאי להגדיר מגבלות זיכרון מתאימות כדי להבטיח ש-Pods יוכלו לפעול בצורה תקינה בלי להסתכן בהוצאה של node-pressure.
אם Pod של Kubernetes לא מבקש CPU וזיכרון (גם אם הוא מבקש TPU), אז Kubernetes מחשיב אותו כ-Pod שפועל כמיטב היכולת, ואין ערובה לכך שהוא צריך CPU וזיכרון. ההתחייבויות האלה חלות רק על Pods שמבקשים באופן מפורש CPU וזיכרון. כדי לתזמן Kubernetes באופן ספציפי, צריך להגדיר את צורכי ה-Pod עם בקשת מעבד (CPU) וזיכרון מפורשת. מידע נוסף זמין במאמר בנושא ניהול משאבים עבור פודים וקונטיינרים.
מידע נוסף על שיטות מומלצות זמין במאמר שיטות מומלצות ל-Kubernetes: בקשות ומגבלות של משאבים.
הפחתת ההפרעות בעומס העבודה
אם אתם משתמשים ב-TPU כדי לאמן מודל של למידת מכונה והעומס שלכם מופרע, כל העבודה שבוצעה מאז נקודת הבדיקה האחרונה אובדת. כדי להקטין את הסיכוי להפרעה בעומס העבודה, צריך:
- הגדרת עדיפות גבוהה יותר למשימה הזו מאשר לכל שאר המשימות: אם המשאבים מוגבלים, מתזמן GKE מבצע קדימה של משימות בעדיפות נמוכה יותר כדי לתזמן משימה בעדיפות גבוהה יותר. כך גם תוכלו לוודא שעומס העבודה בעדיפות גבוהה יקבל את כל המשאבים שהוא צריך (עד למספר המשאבים הכולל שזמין באשכול). מידע נוסף זמין במאמר בנושא עדיפות של Pod ודחיקה.
- הגדרת החרגה מתחזוקה: החרגה מתחזוקה היא חלון זמן חד-פעמי שבו אסור לבצע תחזוקה אוטומטית. מידע נוסף זמין במאמר בנושא החרגות מתחזוקה.
- שימוש ב-Pods עם זמן ריצה ממושך ב-Autopilot: אפשר להשתמש ב-Pods עם זמן ריצה ממושך כדי לקבל תקופת חסד של עד שבעה ימים לפני ש-GKE יסיים את ה-Pods לצורך הקטנת קנה מידה או שדרוגי צמתים.
- שימוש בתזמון של אוספים ב-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. כדי לתזמן משימות ברמת המשימה ולבצע קדימות, צריך להשתמש בתוסף ל-Kubernetes שמארגן משימות בתורים.
אפשר להשתמש ב-Kueue כדי לתזמן את העבודות בתורים.
המאמרים הבאים
- כדי להגדיר Cloud TPU עם GKE, פועלים לפי ההוראות במאמר פריסת עומסי עבודה של TPU ב-GKE.
- שיטות מומלצות לשימוש ב-Cloud TPU למשימות של למידת מכונה.
- איך בונים למידת מכונה בקנה מידה גדול ב-Cloud TPU באמצעות GKE
- הצגת מודלים גדולים של שפה (LLM) באמצעות KubeRay ב-TPU