מידע על מעבדי TPU ב-GKE

במאמר הזה מוסבר איך Cloud TPU פועל עם Google Kubernetes Engine‏ (GKE), כולל מינוח, היתרונות של יחידות לעיבוד טנסורים (TPU) ושיקולים לגבי תזמון עומסי עבודה. יחידות TPU הן מעגלים משולבים לאפליקציות ספציפיות (ASIC) שפותחו על ידי Google כדי להאיץ עומסי עבודה של למידת מכונה שמשתמשים במסגרות כמו TensorFlow,‏ PyTorch ו-JAX.

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

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

יתרונות השימוש במעבדי TPU ב-GKE

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

היתרונות של שימוש ב-TPU ב-GKE כוללים:

  • סביבת הפעלה עקבית: אפשר להשתמש בפלטפורמה אחת לכל עומסי העבודה של למידת מכונה ועומסי עבודה אחרים.
  • שדרוגים אוטומטיים:‏ GKE מבצע עדכוני גרסה באופן אוטומטי, וכך מצמצם את התקורה התפעולית.
  • איזון עומסים:‏ GKE מחלק את העומס, וכך מקטין את זמן האחזור ומשפר את המהימנות.
  • התאמה אוטומטית לעומס:‏ GKE מתאים אוטומטית את משאבי ה-TPU כדי לעמוד בדרישות של עומסי העבודה.
  • ניהול משאבים: בעזרת Kueue, מערכת תורים מבוססת-Kubernetes, אתם יכולים לנהל משאבים בכמה דיירים בארגון באמצעות תורים, הפסקה זמנית, תעדוף ושיתוף הוגן.
  • אפשרויות של ארגז חול: GKE Sandbox עוזר להגן על עומסי העבודה באמצעות gVisor. מידע נוסף זמין במאמר GKE Sandbox.

תחילת העבודה עם Ironwood (TPU7x)

‫Ironwood‏ (TPU7x) הוא ה-TPU מהדור השביעי של Google, שנועד לעומסי עבודה של AI בקנה מידה גדול. מידע נוסף על היתרונות של Ironwood ‏ (TPU7x) זמין במאמר מידע על Ironwood ‏ (TPU7x) ב-GKE.

מינוח שקשור למעבדי TPU ב-GKE

במסמך הזה אנחנו משתמשים במינוח הבא שקשור ל-TPU:

  • עמידות של Cloud TPU ICI: תכונה שעוזרת לשפר את הסבילות לתקלות של הקישורים האופטיים ושל מתגי המעגלים האופטיים (OCS) שמקשרים בין יחידות TPU בתוך קוביות. מידע נוסף זמין במאמר בנושא ארכיטקטורת TPU.
  • קוביית TPU: טופולוגיה של 4x4x4 שבבי TPU שמחוברים זה לזה. האפשרות הזו רלוונטית רק לטופולוגיות ב-3-tuples‏ ({A}x{B}x{C}).
  • ‫TPU type: סוג ה-Cloud TPU, כמו v5e.
  • TPU slice: אוסף של צ'יפים שנמצאים כולם באותו TPU Pod ומחוברים באמצעות חיבורים מהירים בין הצ'יפים (ICI). הפריסה מתוארת במונחים של צ'יפים או TensorCores, בהתאם לגרסת ה-TPU.
  • צומת TPU slice: צומת Kubernetes שמיוצג על ידי מכונה וירטואלית יחידה עם שבב TPU אחד או יותר שמחוברים זה לזה.
  • מאגר צמתים של פרוסות TPU: קבוצה של צמתי Kubernetes באותו אשכול, שלכולם יש את אותה הגדרת TPU.
  • טופולוגיית TPU: המספר והסידור הפיזי של שבבי ה-TPU בפרוסת TPU.
  • אטומי: ב-GKE, כל הצמתים המקושרים נחשבים ליחידה אחת. במהלך פעולות שינוי גודל, GKE משנה את הגודל של כל קבוצת הצמתים ל-0 ויוצר צמתים חדשים. אם מכונה בקבוצה נכשלת או מסיימת את הפעולה, GKE יוצר מחדש את כל קבוצת הצמתים כיחידה חדשה.
  • בלתי משתנה: אי אפשר להוסיף ידנית צמתים חדשים לקבוצת הצמתים המקושרים. עם זאת, אתם יכולים ליצור מאגר צמתים חדש עם טופולוגיית ה-TPU הרצויה ולתזמן עומסי עבודה במאגר הצמתים החדש.

סוגים של מאגרי צמתים של פרוסות TPU

‫GKE תומך בשני סוגים של מאגרי צומתי TPU:

סוג ה-TPU והטופולוגיה קובעים אם צומת ה-TPU slice יכול להיות multi-host או single-host. אנחנו ממליצים:

  • למודלים בקנה מידה גדול, משתמשים בצמתים של פרוסות TPU מרובות מארחים.
  • למודלים בקנה מידה קטן, משתמשים בצמתים של פרוסות TPU במארח יחיד.
  • להדרכה או להסקת מסקנות בקנה מידה גדול, אפשר להשתמש ב-Pathways. ‫Pathways מפשטת חישובים של למידת מכונה בהיקפים גדולים, ומאפשרת ללקוח JAX יחיד לתזמן עומסי עבודה בכמה חלקי TPU גדולים. מידע נוסף זמין במאמר בנושא Pathways.

מאגרי צמתים של פרוסות TPU עם מספר מארחים

מאגר צמתים של פרוסת TPU עם כמה מחשבים מארחים הוא מאגר צמתים שמכיל שתי מכונות וירטואליות של TPU או יותר, שמחוברות ביניהן. לכל מכונת VM מחובר מכשיר TPU. ה-TPU בפריסת TPU מרובת מארחים מחוברים באמצעות חיבור מהיר בין רכיבים (ICI). אחרי שיוצרים מאגר צמתים של חלקי TPU עם כמה מארחים, אי אפשר להוסיף לו צמתים. לדוגמה, אי אפשר ליצור מאגר צמתים של v4-32 ואז להוסיף מאוחר יותר צומת Kubernetes (TPU VM) למאגר הצמתים. כדי להוסיף פרוסת TPU לאשכול GKE, צריך ליצור מאגר צמתים חדש.

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

אם צריך לתקן צומת בפריסת TPU מרובת-מארחים, GKE משבית את כל מכונות ה-VM בפריסת ה-TPU, וכך מאלץ את פינוי כל ה-Pods של Kubernetes בעומס העבודה. אחרי שכל המכונות הוירטואליות בפרוסת ה-TPU יפעלו, אפשר יהיה לתזמן את ה-Pods של Kubernetes במכונות הוירטואליות בפרוסת ה-TPU החדשה.

הדיאגרמה הבאה מציגה פרוסת TPU עם כמה מארחים (v5e) v5litepod-16. לפרוסת ה-TPU הזו יש ארבע מכונות וירטואליות. לכל מכונה וירטואלית בפרוסת TPU יש ארבעה שבבי TPU v5e שמחוברים באמצעות חיבורים מהירים בין רכיבים (ICI), ולכל שבב TPU v5e יש ליבת Tensor אחת:

דיאגרמה של פרוסת TPU עם כמה מארחים

בתרשים הבא מוצג אשכול GKE שמכיל פרוסת TPU אחת של v5litepod-16 (v5e) TPU (טופולוגיה: 4x4) ופרוסת TPU אחת של v5litepod-8 (v5e) (טופולוגיה: 2x4):

דיאגרמה של TPU v5e Pod

מאגרי צמתים של פרוסות TPU במארח יחיד

מאגר צמתים של פרוסת מארח יחיד הוא מאגר צמתים שמכיל מכונות TPU וירטואליות עצמאיות. לכל מכונת VM מחובר מכשיר TPU. אמנם מכונות ה-VM במאגר צמתי פרוסות של מארח יחיד יכולות לתקשר באמצעות רשת מרכז הנתונים (DCN), אבל יחידות ה-TPU שמצורפות למכונות ה-VM לא מחוברות זו לזו.

בתרשים הבא מוצגת דוגמה לפרוסת TPU במארח יחיד שמכילה שבע מכונות v4-8:

דיאגרמה של מאגר צמתים עם פרוסות של מארח יחיד

מאפיינים של מעבדי TPU ב-GKE

ל-TPU יש מאפיינים ייחודיים שדורשים תכנון והגדרה מיוחדים.

צריכת 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 ב-GKE, צריך לבחור את אפשרות הצריכה שהכי מתאימה לדרישות של עומס העבודה.

טופולוגיה

הטופולוגיה מגדירה את הסידור הפיזי של יחידות ה-TPU בתוך פרוסת TPU. ‫GKE מספק פרוסות TPU בטופולוגיות דו-ממדיות או תלת-ממדיות, בהתאם לגרסת ה-TPU. מגדירים טופולוגיה כמספר שבבי ה-TPU בכל מימד באופן הבא:

במקרים של TPU v4,‏ v5p ו-Ironwood‏ (TPU7x) (בגרסת Preview) שמתוזמנים במאגרי צמתים של פרוסות TPU מרובות מארחים, מגדירים את הטופולוגיה ב-3-tuples‏ ({A}x{B}x{C}), לדוגמה 4x4x4. התוצאה של {A}x{B}x{C} מגדירה את מספר שבבי ה-TPU במאגר הצמתים. לדוגמה, אפשר להגדיר טופולוגיות קטנות עם פחות מ-64 שבבי TPU עם צורות טופולוגיה כמו 2x2x2, 2x2x4 או 2x4x4. אם משתמשים בטופולוגיות גדולות יותר עם יותר מ-64 שבבי TPU, הערכים שמוקצים ל-‎{A}‎, ‎{B}‎ ו-‎{C}‎ צריכים לעמוד בתנאים הבאים:

  • הערכים {A},‏ {B} ו-{C} צריכים להיות כפולות של ארבע.
  • הטופולוגיה הגדולה ביותר שנתמכת בגרסה 4 היא 12x16x16 ובגרסה 5p היא 16x16x24.
  • הערכים שמוקצים צריכים להיות בתבנית A ≤ B ≤ C. לדוגמה, 4x4x8 או 8x8x8.

שמות של סוגי מכונות

השמות של סוגי המכונות של TPUs ב-GKE משתנים בהתאם למצב האשכול ולגרסת ה-TPU:

  • ‫GKE Standard: בוחרים סוג מכונה ספציפי של Compute Engine, לדוגמה, ct6e-standard-1t ל-TPU Trillium ‏ (v6e).

  • ‫GKE Autopilot: אתם לא בוחרים סוגי מכונות באופן ישיר. במקום זאת, אתם מבקשים יחידות TPU באמצעות סוג מאיץ במניפסט של עומס העבודה. לדוגמה, אפשר להשתמש ב-tpu-v6e-slice עבור TPU Trillium‏ (v6e) או ב-tpu-v5-lite-podslice עבור TPU v5e. לאחר מכן, GKE Autopilot מקצה את הצמתים הבסיסיים עם סוגי המכונות המתאימים כדי למלא את הבקשה.

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

מצב הרשאה

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

בגרסאות 1.28 ואילך לא נדרש מצב הרשאות או יכולות מיוחדות.

איך מכשירי TPU ב-GKE פועלים

בניהול משאבים ובקביעת סדר עדיפויות ב-Kubernetes, מכונות וירטואליות ב-TPU מקבלות יחס זהה לסוגים אחרים של מכונות וירטואליות. כדי לבקש צ'יפים של TPU, משתמשים בשם המשאב google.com/tpu:

resources:
  requests:
    google.com/tpu: 4
  limits:
    google.com/tpu: 4

כשמשתמשים ב-TPU ב-GKE, כדאי לקחת בחשבון את המאפיינים הבאים של TPU:

  • מכונה וירטואלית יכולה לגשת לעד 8 שבבי TPU.
  • פרוסת TPU מכילה מספר קבוע של שבבי TPU, והמספר תלוי בסוג מכונת ה-TPU שבוחרים.
  • מספר ה-google.com/tpu המבוקש צריך להיות שווה למספר הכולל של שבבי TPU שזמינים בצומת של פרוסת ה-TPU. כל קונטיינר ב-Pod של GKE שמבקש TPU חייב להשתמש בכל שבבי ה-TPU בצומת. אחרת, הפריסה תיכשל כי GKE לא יכול להשתמש בחלק מהמשאבים של TPU. כדאי להביא בחשבון את התרחישים הבאים:
    • סוג המכונה ct5lp-hightpu-4t עם טופולוגיה של 2x4 מכיל שני צמתים של TPU slice עם ארבעה צ'יפים של TPU כל אחד, כלומר סך הכול שמונה צ'יפים של TPU. עם סוג המכונה הזה, אתם יכולים:
    • אי אפשר לפרוס GKE Pod שנדרשים לו שמונה שבבי TPU בצמתים במאגר הצמתים הזה.
    • אפשר לפרוס שני Pods שכל אחד מהם דורש ארבעה שבבי TPU, כאשר כל Pod נמצא באחד משני הצמתים במאגר הצמתים הזה.
    • ‫TPU v5e עם טופולוגיה של 4x4 כולל 16 שבבי TPU בארבעה צמתים. עומס העבודה של GKE Autopilot שבוחר בהגדרה הזו צריך לבקש ארבעה שבבי TPU בכל רפליקה, לרפליקה אחת עד ארבע רפליקות.
  • באשכולים רגילים, אפשר לתזמן כמה פודים של Kubernetes במכונה וירטואלית, אבל רק קונטיינר אחד בכל פוד יכול לגשת לשבבי ה-TPU.
  • כדי ליצור פודים של kube-system, כמו kube-dns, לכל אשכול רגיל צריך להיות לפחות מאגר צמתים אחד של פרוסות שאינן TPU.
  • כברירת מחדל, לצמתים של חלקי TPU יש google.com/tpu taint שמונע מעומסי עבודה שאינם TPU להיות מתוזמנים בצמתים של חלקי TPU. עומסי עבודה שלא משתמשים ב-TPU מופעלים בצמתים שאינם TPU, וכך מפנים משאבי מחשוב בצמתים של חלקי TPU לקוד שמשתמש ב-TPU. שימו לב: הדחייה (taint) לא מבטיחה ניצול מלא של משאבי TPU.
  • ‫GKE אוסף את היומנים שנוצרים על ידי קונטיינרים שפועלים בצמתים של חלקי TPU. מידע נוסף זמין במאמר בנושא רישום ביומן.
  • מדדי ניצול של TPU, כמו ביצועים בזמן ריצה, זמינים ב-Cloud Monitoring. מידע נוסף זמין במאמר בנושא יכולת צפייה ומדדים.
  • אתם יכולים להשתמש ב-GKE Sandbox כדי להפעיל את עומסי העבודה של TPU בסביבת ארגז חול. ‫GKE Sandbox פועל עם מודלים של TPU מגרסה 4 ואילך. מידע נוסף זמין במאמר GKE Sandbox.

יצירה אוטומטית של מאגר צמתים עם מעבדי TPU

יצירה אוטומטית של מאגר צמתים תומכת ב-Cloud TPU רק בגרסאות ספציפיות של GKE:

  • ‫TPU v3: גרסה 1.31.0 ואילך.
  • ‫TPU v5 ו-TPU v4: גרסה 1.29.0 ואילך.
  • ‫TPU Trillium: גרסה 1.32.0 ואילך.
  • ‫Ironwood (TPU7x) (גרסת Preview): גרסה 1.34.1-gke.2541000 ואילך.

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

שינוי אוטומטי של גודל מאגר הצמתים ב-Cloud TPU

מערכת GKE משנה את הגודל של מאגרי צמתים של Cloud TPU שנוצרו באופן אוטומטי או באופן ידני, שמשתמשים ב-Cluster Autoscaler, באחת מהדרכים הבאות:

  • מאגר צמתים של פרוסת TPU עם מארח יחיד: מערכת GKE מוסיפה או מסירה צמתי TPU במאגר הצמתים הקיים. מאגר הצמתים יכול להכיל כל מספר של צמתי TPU בין אפס לבין הגודל המקסימלי של מאגר הצמתים, כפי שנקבע על ידי הדגלים של התאמה אוטומטית לעומס --max-nodes ו---total-max-nodes. לכל צמתי ה-TPU במאגר הצמתים יש את אותו סוג מכונה ואותה טופולוגיה. מידע נוסף על יצירת מאגר צמתים של פרוסת TPU במארח יחיד זמין במאמר יצירת מאגר צמתים של פרוסת TPU במארח יחיד.
  • מאגר צמתים של פרוסת TPU עם כמה מארחים: מערכת GKE מגדילה את מאגר הצמתים באופן אטומי מאפס למספר הצמתים שנדרש כדי לעמוד בדרישות הטופולוגיה של ה-TPU. לדוגמה, אם יש מאגר צמתים של TPU עם ct5lp-hightpu-4t סוג מכונה וטופולוגיה של 16x16, במאגר הצמתים תמיד יהיו 64 צמתים או אפס צמתים. מערכת GKE מצמצמת את מאגר הצמתים אם אין בו עומסי עבודה של TPU. כדי להקטין את מאגר הצמתים, GKE מוציא את כל ה-Pods המתוזמנים ומסיר את כל הצמתים במאגר הצמתים. מידע נוסף על יצירת מאגר צמתים של TPU slice עם כמה מארחים זמין במאמר יצירת מאגר צמתים של TPU slice עם כמה מארחים.

תזמון הצגת אוספים

תזמון איסוף נתמך רק ב-TPU Trillium.

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

‫TPU Trillium תומך בתזמון איסוף עבור מאגרי צמתים עם מארח יחיד ומאגרי צמתים עם כמה מארחים שמריצים עומסי עבודה של הסקה. בהמשך מוסבר איך התנהגות התזמון של איסוף הנתונים משתנה בהתאם לסוג של פרוסת TPU שבה משתמשים:

  • ‫Multi-host TPU slice: GKE groups multi-host TPU slices to form a collection. כל מאגר צמתים של GKE הוא רפליקה באוסף הזה. כדי להגדיר אוסף, יוצרים פלח TPU מרובה-מארחים ומקצים לאוסף שם ייחודי. כדי להוסיף עוד חלקי TPU לאוסף, יוצרים עוד מאגר צמתים של חלקי TPU מרובי-מארחים עם אותו שם אוסף וסוג עומס עבודה.
  • פרוסת TPU במארח יחיד:‏ GKE מתייחס לכל מאגר הצמתים של פרוסת ה-TPU במארח יחיד כאל אוסף. כדי להוסיף עוד חלקי TPU לאוסף, אפשר לשנות את הגודל של מאגר הצמתים של חלקי ה-TPU במארח יחיד.

המגבלות הבאות חלות על תזמון איסוף נתונים:

  • אפשר לתזמן אוספים רק ל-TPU Trillium.
  • אפשר להגדיר אוספים רק במהלך יצירת מאגר הצמתים.
  • אין תמיכה במכונות וירטואליות מסוג Spot.
  • במאגרי צמתים של פרוסות TPU מרובות-מארחים, כל מאגרי הצמתים באוסף צריכים להיות מאותו סוג מכונה, טופולוגיה וגרסה.

אפשר להגדיר תזמון של אוספים בתרחישים הבאים:

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

במאמרים הבאים מוסבר איך מגדירים Cloud TPU ב-GKE: