‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פריסת עומסי עבודה של TPU ב-GKE Standard

Standard

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

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

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את הנושאים הבאים:

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

תכנון ההגדרה של TPU

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

מוודאים שיש לכם מכסת TPU

בקטעים הבאים מוסבר איך לוודא שיש לכם מספיק מכסת שימוש ב-TPU כשאתם משתמשים ב-TPU ב-GKE.

מכסה למכונות וירטואליות לפי דרישה או במודל Spot

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

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

כדי ליצור מאגר צמתים של פרוסות TPU על פי דרישה או במחיר מוזל ב-GKE, צריך מכסת Compute Engine API. המכסה של Compute Engine API‏ (compute.googleapis.com) שונה מהמכסה של Cloud TPU API‏ (tpu.googleapis.com), שנדרשת כשיוצרים יחידות TPU באמצעות Cloud TPU API.

כדי לבדוק את המגבלה ואת השימוש הנוכחי במכסת Compute Engine API עבור TPU, פועלים לפי השלבים הבאים:

נכנסים לדף Quotas במסוף Google Cloud :

לפתיחת הדף Quotas

בתיבה Filter, מבצעים את הפעולות הבאות:

משתמשים בטבלה הבאה כדי לבחור ולהעתיק את מאפיין המכסה בהתאם לגרסת ה-TPU ולסוג המכונה. לדוגמה, אם אתם מתכננים ליצור צמתים של TPU v5e על פי דרישה, שסוג המכונה שלהם מתחיל ב-ct5lp-, אתם צריכים להזין Name: TPU v5 Lite PodSlice chips.

גרסת TPU, סוג המכונה מתחיל ב-	המאפיין והשם של המכסה עבור מופעים על פי דרישה	המאפיין והשם של המכסה למכונות Spot²
‫TPU v3, `ct3-`	Dimensions (e.g. location): tpu_family:CT3	לא רלוונטי
‫TPU v3,‏ `ct3p-`	Dimensions (e.g. location): tpu_family:CT3P	לא רלוונטי
‫TPU v4,‏ `ct4p-`	Name: TPU v4 PodSlice chips	Name: Preemptible TPU v4 PodSlice chips
‫TPU v5e,‏ `ct5lp-`	Name: TPU v5 Lite PodSlice chips	Name: Preemptible TPU v5 Lite Podslice chips
‫TPU v5p, `ct5p-`	Name: TPU v5p chips	Name: Preemptible TPU v5p chips
‫TPU Trillium, `ct6e-`	Dimensions (e.g. location): tpu_family:CT6E	Name: Preemptible TPU slices v6e
‫Ironwood (TPU7x), `tpu7x-standard-4t`	Dimensions (e.g. location): tpu_family:tpu7x	Name: Preemptible TPU slices tpu7x

בוחרים את המאפיין Dimensions (e.g. locations) (מאפיינים (למשל מיקומים)) ומזינים region: ואחריו את שם האזור שבו מתכננים ליצור יחידות TPU ב-GKE. לדוגמה, מזינים region:us-west4 אם מתכננים ליצור צמתים של חלקי TPU באזור us-west4-a. מכסת ה-TPU היא אזורית, ולכן כל האזורים באותו אזור צורכים את אותה מכסת TPU.

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

כשיוצרים הזמנה של TPU, גם המגבלה וגם ערכי השימוש הנוכחיים של המכסה המתאימה גדלים במספר הצ'יפים בהזמנת ה-TPU. לדוגמה, כשיוצרים הזמנה ל-16 שבבי TPU v5e שסוג המכונה שלהם מתחיל ב-ct5lp- , הערכים של Limit ושל Current usage במכסת TPU v5 Lite PodSlice chips באזור הרלוונטי גדלים ב-16.

כשיוצרים מאגר צמתים של פרוסת TPU, משתמשים בדגלים --reservation ו---reservation-affinity=specific כדי ליצור מכונה שמורה. אפשר להזמין TPU כשרוכשים התחייבות. ↩
כשיוצרים מאגר צמתים של פלח TPU, משתמשים בדגל --spot כדי ליצור מכונת Spot. ↩

מכסות למשאבי GKE נוספים

יכול להיות שתצטרכו להגדיל את מכסות GKE הבאות באזורים שבהם GKE יוצר את המשאבים שלכם.

מכסת דיסקים מתמידים (persistent disk) מסוג SSD‏ (GB): דיסק האתחול של כל צומת Kubernetes דורש 100GB כברירת מחדל. לכן, צריך להגדיר את המכסה הזה לפחות בגובה של מכפלת מספר הצמתים המקסימליים של GKE שאתם צופים ליצור ב-100GB (צמתים * 100GB).
מכסת כתובות IP בשימוש: כל צומת Kubernetes צורך כתובת IP אחת. לכן, צריך להגדיר את המכסה הזו לפחות כמספר המקסימלי של צמתי GKE שאתם צפויים ליצור.
מוודאים ש-max-pods-per-node תואם לטווח של רשת המשנה: כל צומת Kubernetes משתמש בטווחים משניים של כתובות IP עבור קבוצות Pod. לדוגמה, max-pods-per-node של 32 דורש 64 כתובות IP, שמתורגמות לרשת משנה ‎ /26 לכל צומת. חשוב לציין שאסור לשתף את הטווח הזה עם אף אשכול אחר. כדי להימנע ממיצוי טווח כתובות ה-IP, משתמשים בדגל --max-pods-per-node כדי להגביל את מספר הפודים שאפשר לתזמן בצומת. המכסה של max-pods-per-node צריכה להיות לפחות גבוהה כמו המספר המקסימלי של צמתי GKE שאתם מתכננים ליצור.

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

בדיקה שההזמנה זמינה

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

כדי לראות אילו הזמנות קיימות בפרויקט וכמה שבבי TPU בהזמנת TPU זמינים, צופים ברשימת ההזמנות.

יצירת אשכול

gcloud

יוצרים אשכול GKE במצב רגיל באזור עם יחידות TPU זמינות.

שיטה מומלצת:

משתמשים באשכולות אזוריים, שמספקים זמינות גבוהה של רמת הבקרה של Kubernetes.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

מחליפים את מה שכתוב בשדות הבאים:

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

Cluster Toolkit

הגדרת Cluster Toolkit
פריסת אשכול GKE TPU באמצעות תוכנית Blueprint של Cluster Toolkit (למשל gke-tpu-v6e או gke-tpu-7x. תוכניות Blueprint של TPU v4,‏ v5e ו-v5p זמינות במאגר GitHub של Cluster Toolkit):
```
gcluster deploy examples/gke-tpu-7x/gke-tpu-7x.yaml \
  --vars project_id=PROJECT_ID,deployment_name=DEPLOYMENT_NAME,zone=ZONE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫DEPLOYMENT_NAME: שם הפריסה של Cluster Toolkit (שהוא גם השם של אשכול GKE).
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫ZONE: שם האזור בהתאם לגרסת ה-TPU שבה רוצים להשתמש. כדי לזהות מיקום זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE. כדי להשתמש בקיבולת שהוזמנה, צריך לוודא שמשתמשים באזור שבו הוזמנה הקיבולת.

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

הקצאת מעבדי TPU

כדי להקצות TPU ב-GKE, יש לכם את אפשרויות ההגדרה הבאות:

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

יצירה ידנית של מאגר צמתים

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

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

אפשר ליצור מאגר צמתים של פרוסת TPU במארח יחיד באמצעות Google Cloud CLI,‏ Terraform או מסוף Google Cloud .

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

מחליפים את מה שכתוב בשדות הבאים:

‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
‫LOCATION: שם האזור בהתאם לגרסת ה-TPU שבה רוצים להשתמש. כדי לזהות מיקום זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE.
‫CLUSTER_NAME: שם האשכול.
‫NODE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר שבהם GKE יוצר את מאגר הצמתים.
אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.
‫MACHINE_TYPE: הגרסה והסוג של ה-TPU. לדוגמה, משתמשים ב-tpu7x-standard-4t עבור Ironwood ‏ (TPU7x).

אפשר גם להשתמש בדגלים הבאים:

‫--num-nodes=NUM_NODES: המספר הראשוני של הצמתים במאגר הצמתים בכל אזור.

שיטה מומלצת:
אם משתמשים בדגל enable-autoscaling עבור מאגר הצמתים, צריך להגדיר את num-nodes לערך 0 כדי שהמערכת להגדלה אוטומטית של הקיבולת תקצה צמתים נוספים ברגע שעומסי העבודה דורשים זאת.
‫--reservation=RESERVATION_NAME: השם של ההזמנה ש-GKE משתמש בה כשיוצרים את מאגר הצמתים. אם לא מציינים את הדגל הזה, GKE משתמש ב-TPU שזמינים. מידע נוסף על הזמנות של TPU זמין במאמר מידע על הזמנות של Cloud TPU.
‫--node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: מציין ל-GKE שמאגר הצמתים של פרוסת ה-TPU במארח יחיד הוא חלק מאוסף. משתמשים בדגל הזה אם התנאים הבאים מתקיימים:
- מאגר הצמתים מריץ עומס עבודה של הסקה במאגר הצמתים החדש.
- מאגר הצמתים משתמש ב-TPU Trillium.
- במאגר הצמתים לא נעשה שימוש במכונות וירטואליות מסוג Spot.
מידע נוסף על ניהול תזמון איסוף מופיע במאמר בנושא ניהול תזמון איסוף בפרוסות TPU עם מארח יחיד.
‫--enable-autoscaling: יצירת מאגר צמתים עם הפעלה של שינוי גודל אוטומטי. נדרשים הדגלים הנוספים הבאים:
- ‫--total-min-nodes=TOTAL_MIN_NODES: מספר הצמתים המינימלי במאגר הצמתים.
- ‫--total-max-nodes=TOTAL_MAX_NODES: המספר המקסימלי של כל הצמתים במאגר הצמתים.
- ‫--location-policy=ANY: לתת עדיפות לשימוש בהזמנות שלא נעשה בהן שימוש ולהפחית את הסיכון להפסקת השימוש במכונות וירטואליות במודל Spot.
‫--spot: מגדיר את מאגר הצמתים לשימוש במכונות וירטואליות במודל Spot עבור הצמתים במאגר הצמתים. אי אפשר לשנות את ההגדרה הזו אחרי שיוצרים את מאגר הצמתים.
‫--flex-start: הגדרת מאגר הצמתים לשימוש במכונות וירטואליות מסוג Flex-start. מכונות וירטואליות מסוג Flex-start נוצרות באמצעות אפשרות הצריכה flex-start. מידע נוסף זמין במאמר הרצת עומס עבודה קטן של אצווה באמצעות מכונות וירטואליות עם TPU ו-Flex-start.

רשימה מלאה של כל הדגלים שאפשר לציין מופיעה במאמר העזר בנושא gcloud container clusters create.

Terraform

ודאו שאתם משתמשים בגרסה 4.84.0 ואילך של ספק google.
מוסיפים את הבלוק הבא להגדרות של Terraform:

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

מחליפים את מה שכתוב בשדות הבאים:

‫NODE_POOL_RESOURCE_NAME: השם של משאב מאגר הצמתים בתבנית Terraform.
PROJECT_ID: מזהה הפרויקט.
‫CLUSTER_NAME: השם של האשכול הקיים.
‫POOL_NAME: השם של מאגר הצמתים שרוצים ליצור.
‫CLUSTER_LOCATION: אזורי המחשוב של האשכול. מציינים את האזור שבו גרסת ה-TPU זמינה. מידע נוסף זמין במאמר בנושא בחירת גרסה וטופולוגיה של TPU.
‫NODE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר שבהם GKE יוצר את מאגר הצמתים.
אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.
‫MACHINE_TYPE: סוג מכונת ה-TPU לשימוש. כדי לראות סוגי מכונות שתואמים ל-TPU, אפשר להשתמש בטבלה שבמאמר בחירת גרסת ה-TPU.

אפשר גם להשתמש במשתנים הבאים:

‫autoscaling: יצירת מאגר צמתים עם הפעלה של שינוי גודל אוטומטי. בפרוסת TPU של מארח יחיד, GKE מבצעת שינוי גודל בין הערכים TOTAL_MIN_NODES ו-TOTAL_MAX_NODES.
- ‫TOTAL_MIN_NODES: מספר הצמתים המינימלי במאגר הצמתים. השדה הזה הוא אופציונלי, אלא אם מצוין גם שינוי גודל אוטומטי.
- ‫TOTAL_MAX_NODES: המספר המקסימלי של כל הצמתים במאגר הצמתים. השדה הזה הוא אופציונלי, אלא אם מצוין גם שינוי גודל אוטומטי.
‫RESERVATION_NAME: אם משתמשים במידע על הזמנות של Cloud TPU, זוהי רשימת התוויות של משאבי ההזמנה שבהן צריך להשתמש כשיוצרים את מאגר הצמתים. מידע נוסף על אכלוס השדה RESERVATION_LABEL_VALUES ב-reservation_affinity זמין במאמר בנושא Terraform Provider.
‫spot: מגדיר את מאגר הצמתים לשימוש ב-VM במודל Spot עבור צמתי ה-TPU. אי אפשר לשנות את ההגדרה הזו אחרי שיוצרים את מאגר הצמתים. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot.
‫flex_start: מגדיר את מאגר הצמתים לשימוש באפשרות הצריכה flex-start. אי אפשר להגדיר את הערך true אם האפשרות spot מופעלת. התכונה 'התחלה גמישה' נתמכת ב-GKE בגרסה ‎1.33.0-gke.1712000 ואילך.

המסוף

כדי ליצור מאגר צמתים עם מעבדי TPU:

נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

מעבר אל Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
לוחצים על הכרטיסייה Nodes (צמתים).
לוחצים על Create user-managed node pool (יצירת מאגר צמתים בניהול המשתמש).
בקטע פרטי מאגר צמתים, מסמנים את התיבה ציון מיקומי צמתים.
בוחרים את האזור בהתאם לגרסת ה-TPU שבה רוצים להשתמש. כדי לזהות אזור זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE.
בחלונית הניווט, לוחצים על צמתים.
בקטע Machine Configuration (הגדרת המכונה), בוחרים באפשרות TPUs.
בתפריט הנפתח סדרה, בוחרים אחת מהאפשרויות הבאות:
- ‫CT3: TPU v3, single host device
- ‫CT3P: TPU v3, multi host pod slice
- ‫CT4P: TPU v4
- ‫CT5LP: TPU v5e
- ‫CT5P: TPU v5p
- ‫CT6E: TPU Trillium (v6e)
בתפריט הנפתח Machine type (סוג המכונה), בוחרים את שם המכונה שרוצים להשתמש בה עבור הצמתים. בעזרת הטבלה בחירת גרסת ה-TPU אפשר להגדיר את סוג המכונה ואת טופולוגיית ה-TPU שיוצרים מאגר צמתים של פרוסת TPU עם מארח יחיד.
בתפריט הנפתח TPU Topology (טופולוגיית TPU), בוחרים את הטופולוגיה הפיזית של פרוסת ה-TPU.
בתיבת הדו-שיח נדרשים שינויים, לוחצים על ביצוע שינויים.
מוודאים שBoot disk type (סוג דיסק האתחול) הוא Standard persistent disk (דיסק מתמיד סטנדרטי) או SSD persistent disk (דיסק מתמיד שמבוסס על SSD).
אופציונלי: מסמנים את תיבת הסימון Enable nodes on spot VMs כדי להשתמש במכונות וירטואליות זמניות (Spot) בשביל הצמתים במאגר הצמתים.
לוחצים על יצירה.

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

השלבים ליצירת מאגר צמתים של פרוסת TPU עם כמה מארחים שונים, בהתאם לגרסת ה-TPU שבה אתם משתמשים: Ironwood‏ (TPU7x) או גרסה קודמת של TPU.

‫Ironwood (TPU7x)

אפשר ליצור מאגר צמתים של פרוסת TPU מרובת-מארחים בגרסה Ironwood‏ (TPU7x) באמצעות Google Cloud CLI או Terraform:

gcloud

כדי ליצור מאגר צמתים של פרוסת TPU עם כמה מארחים באמצעות Ironwood‏ (TPU7x), צריך קודם ליצור מדיניות של עומס עבודה.

יוצרים מדיניות של עומס עבודה:
```
gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫WORKLOAD_POLICY_NAME: שם למדיניות של עומס העבודה.
- ‫TPU_TOPOLOGY: טופולוגיית TPU Ironwood‏ (TPU7x). לדוגמה, 2x2x2. כדי לראות את כל הטופולוגיות הנתמכות של Ironwood ‏ (TPU7x), אפשר לעיין בקטע בנושא טופולוגיה.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫REGION: האזור של מדיניות עומס העבודה. מדיניות עומס עבודה היא משאב אזורי, ואפשר לעשות בה שימוש חוזר במאגרי צמתים שחולקים את אותה טופולוגיה.
יוצרים את מאגר הצמתים עם מדיניות עומס העבודה:
```
gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=tpu7x-standard-4t \
  --placement-policy=WORKLOAD_POLICY_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --node-locations=NODE_ZONE \
  --project=PROJECT_ID \
  --reservation=RESERVATION_NAME \
  --reservation-affinity=specific
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
- ‫CLUSTER_NAME: השם של אשכול GKE.
- ‫WORKLOAD_POLICY_NAME: השם של מדיניות עומס העבודה שיצרתם.
- ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור לאשכולות אזוריים.
- ‫NODE_ZONE: שם האזור בהתאם לגרסת ה-TPU שבה רוצים להשתמש.
  אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.
  כדי לזהות מיקום זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫RESERVATION_NAME: השם של ההזמנה לשימוש.
בפקודה הזו, הדגל --tpu-topology הוחלף בדגל --placement-policy.

Terraform

ודאו שאתם משתמשים בגרסה 4.84.0 ואילך של ספק google.
יוצרים מדיניות של עומס עבודה:
```
resource "google_compute_resource_policy" {
  name   = "WORKLOAD_POLICY_NAME"
  region = CLUSTER_LOCATION
  workload_policy {
    type = "HIGH_THROUGHPUT"
    accelerator_topology = "TPU_TOPOLOGY"
  }
}
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫WORKLOAD_POLICY_NAME: שם למדיניות של עומס העבודה.
- ‫CLUSTER_LOCATION: מיקום החישוב של האשכול. מומלץ להשתמש באשכול אזורי כדי לשפר את המהימנות של מישור הבקרה של Kubernetes. אפשר גם להשתמש באשכול אזורי. מידע נוסף זמין במאמר בחירת גרסה וטופולוגיה של TPU.
- ‫TPU_TOPOLOGY: טופולוגיית TPU Ironwood‏ (TPU7x). לדוגמה, 2x2x2. כדי לראות את כל הטופולוגיות הנתמכות של Ironwood‏ (TPU7x), אפשר לעיין במאמר בנושא תכנון של יחידות TPU.
מידע נוסף על ההפניה google_compute_resource_policy זמין במאמר Terraform Provider.
מוסיפים את הבלוק הבא להגדרות של Terraform:
```
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    policy_name = WORKLOAD_POLICY_NAME
  }
}
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_RESOURCE_NAME: השם של משאב מאגר הצמתים בתבנית Terraform.
- PROJECT_ID: מזהה הפרויקט.
- ‫CLUSTER_NAME: השם של האשכול הקיים שאליו רוצים להוסיף את מאגר הצמתים.
- ‫POOL_NAME: השם של מאגר הצמתים שרוצים ליצור.
- ‫NODE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר שבהם GKE יוצר את מאגר הצמתים.
  אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.
- ‫NUM_NODES: מספר הצמתים במאגר הצמתים. הערך חייב להיות אפס או מכפלה של מספר שבבי ה-TPU חלקי ארבע, כי בכל צומת של פרוסת TPU מרובת מארחים יש ארבעה שבבים. לדוגמה, אם TPU_TOPOLOGY הוא 4x8, יש 32 שבבים, ולכן NUM_NODES צריך להיות 8. מידע נוסף על טופולוגיות של TPU זמין בטבלה שבמאמר בחירת גרסת ה-TPU.
- ‫TPU_TOPOLOGY: מציין את הטופולוגיה הפיזית שנבחרה עבור פרוסת ה-TPU. הפורמט של הטופולוגיה תלוי בגרסת ה-TPU שבה אתם משתמשים. מידע נוסף על טופולוגיות של TPU זמין בטבלה שבקטע בחירת טופולוגיה.
אפשר גם להשתמש במשתנים הבאים:
- ‫RESERVATION_NAME: אם משתמשים בהזמנת TPU, צריך לספק רשימה של תוויות משאבי הזמנה לשימוש כשיוצרים את מאגר הצמתים. מידע נוסף על אכלוס השדה RESERVATION_LABEL_VALUES ב-reservation_affinity זמין במאמר בנושא Terraform Provider.
- ‫autoscaling: יצירת מאגר צמתים עם הפעלה של שינוי גודל אוטומטי. כש-GKE מבצע שינוי גודל של מאגר צמתים של פרוסת TPU מרובת מארחים, הוא מבצע שינוי גודל אטומי של מאגר הצמתים מאפס לגודל המקסימלי.
  - ‫MAX_NODES: הגודל המקסימלי של מאגר הצמתים. הערך צריך להיות שווה למכפלה של הערכים שמוגדרים ב-TPU_TOPOLOGY ({A}x{B}x{C}) חלקי מספר השבבים בכל מכונה וירטואלית. לדוגמה, אם הערך של TPU_TOPOLOGY הוא 2x2x2, המוצר הוא 8. מכיוון שלכל מכונה וירטואלית ב-tpu7x-standard-4t יש 4 שבבים, מספר הצמתים הוא 2.
- ‫spot: מאגר הצמתים שישתמש במכונות וירטואליות במודל Spot עבור צמתי חלוקת ה-TPU. אי אפשר לשנות את ההגדרה הזו אחרי שיוצרים את מאגר הצמתים. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot.
- ‫flex_start: מאגר הצמתים שישתמש באפשרות הצריכה flex-start. אי אפשר להגדיר את ההגדרה הזו לערך true אם ההגדרה spot מופעלת.

גרסאות אחרות של TPU

אפשר ליצור מאגר צמתים של פרוסת TPU עם כמה מארחים בגרסאות v3,‏ v4,‏ v5p,‏ v5e ו-Trillium ‏ (v6e) באמצעות Google Cloud CLI,‏ Terraform או Google Cloud המסוף.

gcloud

  gcloud container node-pools create POOL_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --cluster=CLUSTER_NAME \
      --node-locations=NODE_ZONE \
      --machine-type=MACHINE_TYPE \
      --tpu-topology=TPU_TOPOLOGY \
      [--num-nodes=NUM_NODES] \
      [--spot \]
      [--flex-start \]
      [--enable-autoscaling \
        --max-nodes MAX_NODES]
      [--reservation-affinity=specific \
      --reservation=RESERVATION_NAME] \
      [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
      [--placement-type=COMPACT]

מחליפים את מה שכתוב בשדות הבאים:

‫POOL_NAME: השם של מאגר הצמתים החדש.
‫CONTROL_PLANE_LOCATION: שם האזור בהתאם לגרסת ה-TPU שבה רוצים להשתמש. כדי לזהות מיקום זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE.
‫CLUSTER_NAME: שם האשכול.
‫NODE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר שבהם GKE יוצר את מאגר הצמתים.
אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.
‫MACHINE_TYPE: סוג המכונה לשימוש בצמתים. מידע נוסף על סוגי המכונות הזמינים מופיע במאמר בחירת גרסת ה-TPU.
‫TPU_TOPOLOGY: הטופולוגיה הפיזית של פרוסת ה-TPU. הפורמט של הטופולוגיה תלוי בגרסת ה-TPU. מידע נוסף על טופולוגיות של TPU זמין בטבלה שבקטע בחירת טופולוגיה.

מידע נוסף זמין במאמר בנושא טופולוגיה.

אפשר גם להשתמש בדגלים הבאים:
‫NUM_NODES: מספר הצמתים במאגר הצמתים. הערך צריך להיות אפס או מכפלת הערכים שמוגדרים ב-TPU_TOPOLOGY ({A}x{B}x{C}) חלקי מספר השבבים בכל מכונה וירטואלית. ב-TPU v4 וב-TPU v5e עם כמה מארחים, מספר השבבים בכל מכונה וירטואלית הוא ארבע. לכן, אם TPU_TOPOLOGY הוא 2x4x4 (TPU v4 עם ארבעה שבבים בכל מכונה וירטואלית), אז NUM_NODES הוא 32 חלקי 4, כלומר 8. אם לא מציינים את הדגל הזה, מספר הצמתים מחושב ומוגדר כברירת מחדל על סמך הטופולוגיה וסוג המכונה.
‫RESERVATION_NAME: השם של ההזמנה ש-GKE משתמש בה כשיוצרים את מאגר הצמתים. אם לא מציינים את הדגל הזה, GKE משתמש במאגרי צמתים זמינים של פרוסות TPU. מידע נוסף על הזמנות TPU זמין במאמר הזמנת TPU.
‫--spot: מגדיר את מאגר הצמתים לשימוש במכונות וירטואליות במודל Spot עבור צמתי חלוקת ה-TPU. אי אפשר לשנות את ההגדרה הזו אחרי שיוצרים את מאגר הצמתים. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot.
‫--flex-start: הגדרת מאגר הצמתים לשימוש במכונות וירטואליות מסוג Flex-start. מכונות וירטואליות עם הפעלה גמישה נוצרות באמצעות אפשרות הצריכה flex-start, שנתמכת ב-GKE מגרסה ‎1.33.0-gke.1712000 ואילך.
‫--enable-autoscaling: יצירת מאגר צמתים עם הפעלה של שינוי גודל אוטומטי. כש-GKE מבצע שינוי גודל של מאגר צמתים של פרוסת TPU מרובת מארחים, הוא מבצע שינוי גודל אטומי של מאגר הצמתים מאפס לגודל המקסימלי.
- ‫MAX_NODES: הגודל המקסימלי של מאגר הצמתים. חובה להשתמש בדגל --max-nodes אם מציינים את --enable-autoscaling, והערך שלו צריך להיות שווה למכפלה של הערכים שמוגדרים ב-TPU_TOPOLOGY ({A}x{B}x{C}) חלקי מספר השבבים בכל מכונה וירטואלית.
‫--node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: מציין ל-GKE שמאגר הצמתים של פרוסת ה-TPU עם כמה מארחים הוא אוסף. משתמשים בדגל הזה אם התנאים הבאים מתקיימים:
- מאגר הצמתים מריץ עומסי עבודה של היקשים.
- מאגר הצמתים משתמש ב-TPU Trillium.
- אי אפשר לתזמן איסוף נתונים במכונות וירטואליות במודל Spot.
מידע נוסף על ניהול תזמון איסוף מופיע במאמר בנושא ניהול תזמון איסוף בפרוסות TPU מרובות מארחים.
‫--placement-type=COMPACT: יצירת מאגר צמתים עם הפעלת מיקום קומפקטי. חובה להשתמש באפשרות הזו עם הדגל --tpu-topology. מידע נוסף זמין במאמרים בנושא יצירת מדיניות מיקום קומפקטית וטופולוגיה של TPU.

Terraform

ודאו שאתם משתמשים בגרסה 4.84.0 ואילך של ספק google.
מוסיפים את הבלוק הבא להגדרות של Terraform:
```
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_RESOURCE_NAME: השם של משאב מאגר הצמתים בתבנית Terraform.
- PROJECT_ID: מזהה הפרויקט.
- ‫CLUSTER_NAME: השם של האשכול הקיים שאליו רוצים להוסיף את מאגר הצמתים.
- ‫POOL_NAME: השם של מאגר הצמתים שרוצים ליצור.
- ‫CLUSTER_LOCATION: מיקום החישוב של האשכול. מומלץ להשתמש באשכול אזורי כדי לשפר את המהימנות של מישור הבקרה של Kubernetes. אפשר גם להשתמש באשכול אזורי. מידע נוסף זמין במאמר בנושא בחירת גרסה וטופולוגיה של TPU.
- ‫NODE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר שבהם GKE יוצר את מאגר הצמתים.
  אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.
- ‫NUM_NODES: מספר הצמתים במאגר הצמתים. הערך חייב להיות אפס או מכפלה של מספר שבבי ה-TPU חלקי ארבע, כי בכל צומת של פרוסת TPU מרובת מארחים יש 4 שבבים. לדוגמה, אם TPU_TOPOLOGY הוא 4x8, יש 32 צ'יפים, ולכן NUM_NODES צריך להיות 8. מידע נוסף על טופולוגיות של TPU זמין בטבלה שבמאמר בחירת גרסת ה-TPU.
- ‫TPU_TOPOLOGY: מציין את הטופולוגיה הפיזית של חלוקת ה-TPU. הפורמט של הטופולוגיה תלוי בגרסת ה-TPU שבה אתם משתמשים. מידע נוסף על טופולוגיות של TPU זמין בטבלה שבקטע בחירת טופולוגיה.
אפשר גם להשתמש במשתנים הבאים:
- ‫RESERVATION_NAME: אם משתמשים בהזמנת TPU, זוהי רשימת התוויות של משאבי ההזמנה שבהן צריך להשתמש כשיוצרים את מאגר הצמתים. מידע נוסף על אכלוס השדה RESERVATION_LABEL_VALUES ב-reservation_affinity זמין במאמר בנושא Terraform Provider.
- ‫autoscaling: יצירת מאגר צמתים עם הפעלה של שינוי גודל אוטומטי. כש-GKE מבצע שינוי גודל של מאגר צמתים של פרוסת TPU מרובת מארחים, הוא מבצע שינוי גודל אטומי של מאגר הצמתים מאפס לגודל המקסימלי.
  - ‫MAX_NODES: הגודל המקסימלי של מאגר הצמתים. הערך הזה צריך להיות שווה למכפלה של הערכים שמוגדרים ב-TPU_TOPOLOGY ({A}x{B}x{C}) חלקי מספר השבבים בכל מכונה וירטואלית).
- ‫spot: מאפשרת למאגר הצמתים להשתמש במכונות וירטואליות במודל Spot עבור צמתי פרוסת ה-TPU. אי אפשר לשנות את ההגדרה הזו אחרי שיוצרים את מאגר הצמתים. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot.
- ‫flex_start: מגדיר את מאגר הצמתים לשימוש באפשרות הצריכה flex-start. אי אפשר להגדיר את הערך true אם האפשרות spot מופעלת.

המסוף

כדי ליצור מאגר צמתים עם מעבדי TPU:

נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

מעבר אל Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
לוחצים על הכרטיסייה Nodes (צמתים).
לוחצים על Create user-managed node pool (יצירת מאגר צמתים בניהול המשתמש).
בקטע פרטי מאגר צמתים, מסמנים את התיבה ציון מיקומי צמתים.
בוחרים את שם האזור בהתאם לגרסת ה-TPU שרוצים להשתמש בה. כדי לזהות מיקום זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE.
בחלונית הניווט, לוחצים על צמתים.
בקטע Machine Configuration (הגדרת המכונה), בוחרים באפשרות TPUs.
בתפריט הנפתח סדרה, בוחרים אחת מהאפשרויות הבאות:
- ‫CT3: TPU v3, single-host device
- ‫CT3P: TPU v3, multi-host pod slice
- ‫CT4P: TPU v4
- ‫CT5LP: TPU v5e
- ‫CT5P: TPU v5p
- ‫CT6E: TPU Trillium (v6e)
בתפריט הנפתח Machine type (סוג המכונה), בוחרים את שם המכונה שרוצים להשתמש בה עבור הצמתים. כדי להגדיר את סוג המכונה ואת טופולוגיית ה-TPU שיוצרים מאגר צמתים של פרוסת TPU מרובת מארחים, אפשר להיעזר בטבלה בחירת גרסת ה-TPU.
בתפריט הנפתח TPU Topology (טופולוגיית TPU), בוחרים את הטופולוגיה הפיזית של פרוסת ה-TPU.
בתיבת הדו-שיח נדרשים שינויים, לוחצים על ביצוע שינויים.
מוודאים שBoot disk type (סוג דיסק האתחול) הוא Standard persistent disk (דיסק מתמיד סטנדרטי) או SSD persistent disk (דיסק מתמיד שמבוסס על SSD).
אופציונלי: מסמנים את תיבת הסימון Enable nodes on spot VMs כדי להשתמש במכונות וירטואליות מסוג Spot עבור הצמתים במאגר הצמתים.
לוחצים על יצירה.

שימוש בהקצאת צמתים אוטומטית ב-GKE

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

כדי להפעיל הקצאת משאבים אוטומטית של מאגר צמתים, עורכים את מגבלות המשאבים של TPU באשכול:
```
  gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY \
      --min-accelerator=type=TPU_TYPE,count=MINIMUM_TPU_COUNT \
      --max-accelerator=type=TPU_TYPE,count=MAXIMUM_TPU_COUNT
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TPU_TYPE: סוג ה-TPU. לדוגמה, משתמשים ב-tpu7x-standard-4t עבור Ironwood‏ (TPU7x).
- ‫MINIMUM_TPU_COUNT: המספר המינימלי של שבבי TPU מהסוג שצוין שיכולים להיות באשכול. אם הערך שאתם מציינים גדול ממספר שבבי ה-TPU בפרוסת TPU מרובת מארחים, GKE מסיר את כל הצמתים בפרוסה. ההגדלה או ההקטנה של מאגרי צמתים עם כמה מארחים מתבצעת בין 0 לבין מספר הצמתים בפלח, ללא ערכי ביניים.
- ‫MAXIMUM_TPU_COUNT: המספר המקסימלי של שבבי TPU מהסוג שצוין שיכולים להיות באשכול. במקרים של חלקי TPU מרובי-מארחים, צריך לציין ערך שגדול ממספר הצ'יפים בכל חלק, כדי ש-GKE יוכל לשנות את גודל החלק באופן אטומי. מספר השבבים בפרוסה הוא תוצאה של טופולוגיית ה-TPU. לדוגמה, אם הטופולוגיה היא 2x2x2, מספר הצ'יפים בפרוסה הוא 8, כלומר הערך של MAXIMUM_TPU_COUNT צריך להיות גדול מ-8.

הגדרת ComputeClasses בהתאמה אישית

אפשר גם להגדיר את GKE כך שיבקש TPU במהלך פעולות שינוי גודל שיוצרות צמתים חדשים באמצעות ComputeClasses מותאמים אישית.

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

בקטעים הבאים מוסבר איך ליצור ComputeClass בהתאמה אישית ואז ליצור Job שמשתמש ב-TPU שהוגדרו ב-ComputeClass.

יצירת ComputeClass בהתאמה אישית

השלבים ליצירת ComputeClass מותאם אישית בהתאם לכללי TPU שונים בהתאם לגרסת ה-TPU שבה אתם משתמשים: Ironwood‏ (TPU7x) או גרסה קודמת של TPU.

‫Ironwood (TPU7x)

יוצרים מדיניות של עומס עבודה. השלב הזה נדרש רק אם יוצרים מאגר צמתים עם כמה מארחים, והוא תלוי בטופולוגיה שבוחרים. אם אתם משתמשים במאגר צמתים עם מארח יחיד, אתם יכולים לדלג על השלב הזה.
```
gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫WORKLOAD_POLICY_NAME: שם למדיניות של עומס העבודה.
- ‫TPU_TOPOLOGY: טופולוגיית TPU Ironwood‏ (TPU7x). לדוגמה, משתמשים ב-2x2x2. מידע נוסף על כל הטופולוגיות הנתמכות של Ironwood ‏ (TPU7x) זמין בקטע על טופולוגיה.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫REGION: האזור של מדיניות עומס העבודה. מדיניות עומס עבודה היא משאב אזורי, ואפשר להשתמש בה במאגרי צמתים.

שומרים את קובץ המניפסט הבא בשם tpu-compute-class.yaml:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
    - tpu:
        type: tpu7x
        topology: TPU_TOPOLOGY
        count: 4
      placement:
        policyName: WORKLOAD_POLICY_NAME
  nodePoolAutoCreation:
    enabled: true

(אופציונלי) אפשר להשתמש בהזמנה ספציפית או בחלק ספציפי של הזמנה. לדוגמה, אפשר להוסיף את specs למניפסט ComputeClass:
```
  reservations:
    affinity: Specific
    specific:
      - name: RESERVATION_NAME
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
          reservationSubBlock:
            name: RESERVATION_SUB_BLOCK_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫RESERVATION_NAME: השם של הזמנת הקיבולת ב-Compute Engine.
- ‫RESERVATION_BLOCK_NAME: השם של בלוק הזמנת הקיבולת ב-Compute Engine.
- ‫RESERVATION_SUB_BLOCK_NAME: השם של תת-הבלוק של הזמנת הקיבולת ב-Compute Engine.
מידע נוסף מופיע במאמר שימוש במשאבים שמורים באזור.

גרסאות אחרות של TPU

כדי להקצות TPU מדור v3,‏ v4,‏ v5p,‏ v5e או v6e ‏ (Trillium) באמצעות ComputeClass מותאם אישית שמוגדר ל-TPU, מבצעים את השלבים הבאים:

שומרים את קובץ המניפסט הבא בשם tpu-compute-class.yaml:
```
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - spot: true
    tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - flexStart:
      enabled: true
    tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  nodePoolAutoCreation:
    enabled: true
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TPU_TYPE: סוג ה-TPU לשימוש, כמו tpu-v4-podslice. הערך חייב להיות ערך שנתמך על ידי GKE.
- ‫TOPOLOGY: סידור הצ'יפים של TPU בפרוסת ה-TPU, כמו 2x2x4. צריך לבחור טופולוגיה נתמכת לסוג ה-TPU שנבחר.
- ‫NUMBER_OF_CHIPS: מספר שבבי ה-TPU שהקונטיינר ישתמש בהם. הערכים של limits ושל requests חייבים להיות זהים.
פורסים את ComputeClass:
```
kubectl apply -f tpu-compute-class.yaml
```
מידע נוסף על ComputeClasses ו-TPU בהתאמה אישית זמין במאמר הגדרת TPU.

יצירת משימה שצורכת TPU

שומרים את קובץ המניפסט הבא בשם tpu-job.yaml:

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

מחליפים את מה שכתוב בשדות הבאים:

‫NUMBER_OF_CHIPS: מספר שבבי ה-TPU שהקונטיינר ישתמש בהם. הערך של limits ושל requests חייב להיות זהה, ושווה לערך של CHIP_COUNT ב-ComputeClass המותאם אישית שנבחר.
‫MEMORY_SIZE: כמות הזיכרון המקסימלית שבה נעשה שימוש ב-TPU. מגבלות הזיכרון תלויות בגרסה ובטופולוגיה של ה-TPU שבהן אתם משתמשים. מידע נוסף על ערכי המינימום והמקסימום של מאיצים
‫NUMBER_OF_CHIPS: מספר שבבי ה-TPU שהקונטיינר ישתמש בהם. הערכים של limits ושל requests חייבים להיות זהים.

פורסים את המשרה:
```
kubectl create -f tpu-job.yaml
```
כשיוצרים את הג'וב הזה, GKE מבצע באופן אוטומטי את הפעולות הבאות:
- הקצאת צמתים להרצת ה-Pods. בהתאם לסוג ה-TPU, לטופולוגיה ולבקשות המשאבים שציינתם, הצמתים האלה הם פרוסות של מארח יחיד או פרוסות של כמה מארחים. בהתאם לזמינות של משאבי TPU בעדיפות הגבוהה ביותר, יכול להיות ש-GKE יחזור לעדיפויות נמוכות יותר כדי למקסם את הגמישות, היעילות והזמינות של קיבולת המאיץ.
- הוספת כתמי צבע ל-Pods וסבילות לצמתים כדי למנוע הפעלה של עומסי עבודה אחרים באותם צמתים שבהם מופעלים עומסי עבודה של TPU.
מידע נוסף זמין במאמר מידע על ComputeClasses בהתאמה אישית.
כדי להימנע מחיובים נוספים אחרי שסיימתם את הקטע הזה, תוכלו למחוק את המשאבים שיצרתם:
```
kubectl delete -f tpu-job.yaml
```

הכנת עומסי העבודה

עומסי עבודה של TPU מחייבים הכנה מראש.

למסגרות כמו JAX,‏ PyTorch ו-TensorFlow יש גישה למכונות וירטואליות של TPU באמצעות הספרייה המשותפת libtpu. ‫libtpu כולל את מהדר XLA, תוכנת זמן הריצה של TPU ואת מנהל ההתקן של TPU. כל גרסה של PyTorch ו-JAX דורשת גרסה מסוימת של libtpu.so. כדי למנוע התנגשויות בין גרסאות של חבילות, מומלץ להשתמש בתמונה של JAX AI. כדי להשתמש ב-TPU ב-GKE, צריך לוודא שאתם משתמשים בגרסאות הבאות: ‫tpu7x

סוג ה-TPU	גרסה `libtpu.so`
‫Ironwood (TPU7x)	תמונה מומלצת של JAX AI: ‏ jax0.8.1-rev1 ואילך הגרסה המומלצת של jax[tpu]:‏ v0.8.1
TPU Trillium (v6e) `tpu-v6e-slice`	תמונת AI מומלצת של JAX: ‏ jax0.4.35-rev1 ואילך גרסת jax[tpu] מומלצת: v0.4.9 ואילך הגרסה המומלצת של torchxla[tpuvm]: v2.1.0 ואילך
TPU v5e `tpu-v5-lite-podslice`	תמונת AI מומלצת של JAX: ‏ jax0.4.35-rev1 ואילך גרסת jax[tpu] מומלצת: v0.4.9 ואילך הגרסה המומלצת של torchxla[tpuvm]: v2.1.0 ואילך
TPU v5p `tpu-v5p-slice`	תמונת AI מומלצת של JAX: ‏ jax0.4.35-rev1 ואילך הגרסה המומלצת של jax[tpu]:‏ 0.4.19 ואילך. גרסה מומלצת של torchxla[tpuvm]: מומלץ להשתמש בגרסת nightly שנבנתה ב-23 באוקטובר 2023.
‫TPU v4 `tpu-v4-podslice`	תמונת AI מומלצת של JAX: ‏ jax0.4.35-rev1 ואילך מומלץ jax[tpu]: גרסה v0.4.4 ואילך מומלץ torchxla[tpuvm]: v2.0.0 ואילך
‫TPU v3 `tpu-v3-slice` `tpu-v3-device`	תמונת AI מומלצת של JAX: ‏ jax0.4.35-rev1 ואילך מומלץ jax[tpu]: גרסה v0.4.4 ואילך מומלץ torchxla[tpuvm]: v2.0.0 ואילך

במניפסט של עומס העבודה, מוסיפים בוררי צמתים של Kubernetes כדי לוודא ש-GKE מתזמן את עומס העבודה של TPU בסוג מכונת ה-TPU ובטופולוגיית ה-TPU שהגדרתם:
```
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
    cloud.google.com/placement-policy-name: WORKLOAD_POLICY # Required only for Ironwood (TPU7x)
  
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TPU_ACCELERATOR: השם של התאוצה של TPU. לדוגמה, משתמשים ב-tpu7x-standard-4t.
- ‫TPU_TOPOLOGY: הטופולוגיה הפיזית של פרוסת ה-TPU. הפורמט של הטופולוגיה תלוי בגרסת ה-TPU. לדוגמה, משתמשים ב-2x2x2. מידע נוסף זמין במאמר תכנון השימוש ב-TPU ב-GKE.
- ‫WORKLOAD_POLICY: השם של מדיניות עומס העבודה שרוצים להשתמש בה כדי למקם את TPU Pods. הבורר הזה של הצמתים נדרש רק ל-Ironwood‏ (TPU7x).

אחרי שמסיימים את ההכנה של עומס העבודה, אפשר להריץ Job שמשתמש ב-TPU.

בדוגמאות הבאות מוסבר איך להריץ Job שמבצע חישוב בסיסי באמצעות TPU.

הפעלת עומס העבודה בצמתים של פרוסת TPU

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

דוגמה 1: הפעלת פריסה שמבקשת TPU במפרט של ה-Pod

gcloud

‫GKE משתמש בהגדרה ב-Pod או ב-ComputeClass כדי לקבוע את ההגדרה של צמתי ה-TPU. המניפסט הבא הוא דוגמה למפרט פריסה שמבקש TPU במפרט ה-Pod. אם ההגדרה של הקצאת צמתים אוטומטית ברמת האשכול מופעלת, פריסת ה-Deployment הזו מפעילה יצירה אוטומטית של מאגר צמתים. כשיוצרים את פריסת הדוגמה הזו, GKE יוצר מאגר צמתים שמכיל פרוסת TPU v4 עם טופולוגיה של 2x2x2 ושתי מכונות ct4p-hightpu-4t.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-workload
  labels:
    app: tpu-workload
spec:
  replicas: 2
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("Total TPU chips:", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

במניפסט הזה, השדות הבאים מגדירים את תצורת ה-TPU:

‫cloud.google.com/gke-tpu-accelerator: גרסת ה-TPU והסוג שלו. לדוגמה, משתמשים ב-tpu7x-standard-4t עבור Ironwood (TPU7x).
‫cloud.google.com/gke-tpu-topology: הטופולוגיה עם מספר וסידור פיזי של שבבי TPU בתוך פרוסת TPU. לדוגמה, משתמשים ב-2x2x2.
‫limits.google.com/tpu: מספר שבבי ה-TPU לכל מכונה וירטואלית. לדוגמה, אם משתמשים ב-tpu7x-standard-4t, מספר שבבי ה-TPU לכל מכונה וירטואלית הוא 4.

Cluster Toolkit

שולחים את עומס העבודה באמצעות הפקודה gcluster job submit. מידע נוסף על אפשרויות לשליחת משימות זמין במדריך לשליחת משימות ב-Cluster Toolkit.

gcluster job submit \
  --name=WORKLOAD_NAME \
  --cluster=DEPLOYMENT_NAME \
  --project=PROJECT_ID \
  --location=ZONE \
  --compute-type=COMPUTE_TYPE \
  --topology=TOPOLOGY \
  --num-slices=1 \
  --image=us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest \
  --command="python -c 'import jax; print(\"TPU cores:\", jax.device_count())'"

מחליפים את מה שכתוב בשדות הבאים:

‫WORKLOAD_NAME: השם של עומס העבודה.
‫DEPLOYMENT_NAME: השם של פריסת Cluster Toolkit (שהוא גם השם של אשכול GKE).
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫ZONE: שם האזור בהתאם לגרסת ה-TPU שבה רוצים להשתמש. כדי לזהות מיקום זמין, אפשר לעיין במאמר זמינות של TPU ב-GKE.
‫COMPUTE_TYPE: סוג המחשוב שמתאים לסוג המאיץ של מאגר הצמתים, לדוגמה, v6e-16,‏ tpu7x-standard-4t או v5e-8.
‫TOPOLOGY: הטופולוגיה הפיזית שתואמת למאגר הצמתים, לדוגמה, 2x4 או 2x2x2.

דוגמה 2: הפעלת עומס עבודה שמציג את מספר שבבי ה-TPU הזמינים במאגר הצמתים של פרוסת TPU

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

גרסת ה-TPU‏: TPU v4
טופולוגיה: 2x2x4

הבחירה הזו של הגרסה והטופולוגיה יוצרת פרוסת רשת מרובת מארחים.

שומרים את קובץ המניפסט הבא בשם available-chips-multihost.yaml:

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-available-chips
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-available-chips
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.

פורסים את המניפסט:
```
kubectl create -f available-chips-multihost.yaml
```
‫GKE מפעיל פרוסת TPU v4 עם ארבע מכונות וירטואליות (פרוסת TPU מרובת-מארחים). הפרוסה כוללת 16 שבבי TPU שמחוברים ביניהם.

מוודאים שעבודת ה-Job יצרה ארבעה פודים:

kubectl get pods

הפלט אמור להיראות כך:

NAME                       READY   STATUS      RESTARTS   AGE
tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s

אחזור היומנים של אחד מה-Pods:
```
kubectl logs POD_NAME
```
מחליפים את POD_NAME בשם של אחד מה-Pods שנוצרו. לדוגמה, tpu-job-podslice-0-5cd8r.

הפלט אמור להיראות כך:
```
TPU cores: 16
```
אופציונלי: מסירים את עומס העבודה:
```
kubectl delete -f available-chips-multihost.yaml
```

דוגמה 3: הפעלת עומס עבודה שמציג את מספר שבבי ה-TPU הזמינים בפרוסת ה-TPU

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

גרסת ה-TPU‏: TPU v5e
טופולוגיה: 2x4

הגרסה והטופולוגיה שנבחרו יובילו לפרוסת שרת יחיד.

שומרים את קובץ המניפסט הבא בשם available-chips-singlehost.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: tpu-job-jax-v5
spec:
  restartPolicy: Never
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    securityContext:
      privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.

פורסים את המניפסט:
```
kubectl create -f available-chips-singlehost.yaml
```
‫GKE מקצה צמתים עם שמונה פרוסות TPU של מארח יחיד שמשתמשות ב-TPU v5e. לכל צומת TPU יש שמונה שבבי TPU (פרוסת TPU של מארח יחיד).
אחזור היומנים של ה-Pod:
```
kubectl logs tpu-job-jax-v5
```
הפלט אמור להיראות כך:
```
Total TPU chips: 8
```
אופציונלי: מסירים את עומס העבודה:
```
  kubectl delete -f available-chips-singlehost.yaml
  
```

דוגמה 4: הפעלת עומס עבודה שמטרגט שני צמתי NUMA

כדי לשפר את ביצועי עומס העבודה, אפשר ב-GKE לפרוס את עומסי העבודה בהגדרה של כמה קונטיינרים. הפעולה הזו מקשרת כל קונטיינר למשאבי ה-CPU, הזיכרון וה-TPU בתוך צומת NUMA נתון. מידע נוסף על שיוך NUMA זמין במאמר מידע על Ironwood‏ (TPU7x) ב-GKE.

יוצרים קובץ בשם topology-manager-config.yaml עם התוכן הבא:
```
kubeletConfig:
  cpuManagerPolicy: static
  topologyManager:
    policy: best-effort
    scope: container
```
ההגדרה הזו מיישרת את המשאבים שמבוקשים על ידי קונטיינר עם צומת NUMA יחיד. ההגדרה הזו נחוצה כדי ש-GKE יוכל להקצות שבבים לעומסי עבודה של TPU עם כמה קונטיינרים. אפשרויות נוספות למדיניות מפורטות במאמר מדיניות של Topology Manager.
כדי להחיל את ההגדרה kubelet על מאגר צמתים, יוצרים מאגר צמתים חדש או מעדכנים מאגר קיים. מאגר הצמתים הזה חייב להשתמש בצמתים מסוג Ironwood ‏ (TPU7x), כמו tpu7x-standard-4t סוג המכונה, כדי להתאים לבחירת הצמתים בשלב הבא.
- כדי ליצור מאגר צמתים חדש עם Topology Manager מופעל:
```
gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=tpu7x-standard-4t \
    --system-config-from-file=topology-manager-config.yaml
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
  - ‫LOCATION: האזור של האשכול.
  - ‫CLUSTER_NAME: שם האשכול.
  - ‫NODE_ZONES: רשימה מופרדת בפסיקים של אזור אחד או יותר למאגר הצמתים.
- כדי לעדכן מאגר צמתים קיים עם Topology Manager מופעל:
```
gcloud container node-pools update NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --system-config-from-file=topology-manager-config.yaml
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫NODE_POOL_NAME: השם של מאגר הצמתים.
  - ‫LOCATION: האזור של האשכול.
  - ‫CLUSTER_NAME: שם האשכול.

יוצרים קובץ בשם tpu-jobset.yaml עם המניפסט הבא:

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: tpu7x-test
spec:
  failurePolicy:
    maxRestarts: 0
  replicatedJobs:
    - name: tpu7x
      replicas: 1
      template:
        spec:
          parallelism: 2
          completions: 2
          backoffLimit: 0
          template:
            spec:
              subdomain: test
              restartPolicy: Never
              nodeSelector:
                cloud.google.com/gke-tpu-accelerator: tpu7x
                cloud.google.com/gke-tpu-topology: 2x2x2
              containers:
              - name: jax-tpu-1
                image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
                securityContext:
                  privileged: false
                command:
                - bash
                - -c
                - |
                  set -ex
                  python -c 'import jax; print("local devices:", jax.local_device_count(), "devices:", jax.device_count())'
                resources:
                  requests:
                    google.com/tpu: 2
                  limits:
                    google.com/tpu: 2
              - name: jax-tpu-2
                image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
                securityContext:
                  privileged: false
                command:
                - bash
                - -c
                - |
                  set -ex

                  python -c 'import jax; print("local devices:", jax.local_device_count(), "devices:", jax.device_count())'
                resources:
                  requests:
                    google.com/tpu: 2
                  limits:
                    google.com/tpu: 2

המניפסט הזה מגדיר JobSet בשם tpu7x-test, שמריץ שני מאגרי מידע ראשיים, jax-tpu-1 ו-jax-tpu-2. כל מארז מבקש שני שבבי google.com/tpu. שני השבבים האלה מגיעים מאותו צומת NUMA. כל קונטיינר מריץ סקריפט Python כדי לאמת את הגישה של JAX ל-TPU.

ההגדרה הזו של JobSet מראה שכמה קונטיינרים באותו Pod יכולים לגשת לשבבי TPU נפרדים ולהשתמש בהם.

החלת המניפסט:
```
kubectl apply -f tpu-jobset.yaml
```

דוגמה 5: הפעלת עומס עבודה של TPU עם כמה קונטיינרים באמצעות נפחים של Cloud Storage FUSE עם כמה כרטיסי NIC

בדוגמה הזו מורחבת דוגמה 4 כך שתכלול טעינה של קטגוריות Cloud Storage FUSE כנפחים באמצעות Cloud Storage FUSE. ההגדרה הזו מנצלת את היכולות של כרטיסי רשת מרובים כדי לשפר את ביצועי הרשת.

יוצרים קובץ בשם tpu7x-gcsfuse-multinic.yaml עם המניפסט הבא:

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: tpu7x-gcsfuse-multinic
spec:
  failurePolicy:
    maxRestarts: 0
  replicatedJobs:
    - name: tpu7x
      replicas: 1
      template:
        spec:
          parallelism: 2
          completions: 2
          backoffLimit: 0
          template:
            spec:
              subdomain: test
              restartPolicy: Never
              nodeSelector:
                cloud.google.com/gke-tpu-accelerator: tpu7x
                cloud.google.com/gke-tpu-topology: 2x2x2
              hostNetwork: true
              volumes:
              - name: gcs0
                csi:
                  driver: gcsfuse.csi.storage.gke.io
                  volumeAttributes:
                    bucketName: BUCKET_NAME
                    multiNICIndex: "0"
                    mountOptions: implicit-dirs
                    hostNetworkPodKSA: "true"
              - name: gcs1
                csi:
                  driver: gcsfuse.csi.storage.gke.io
                  volumeAttributes:
                    bucketName: BUCKET_NAME
                    multiNICIndex: "1"
                    mountOptions: implicit-dirs
                    hostNetworkPodKSA: "true"
              containers:
              - name: jax-tpu-1
                image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
                securityContext:
                  privileged: false
                command:
                - bash
                - -c
                - |
                  set -ex
                  python -c 'import jax; print("local devices:", jax.local_device_count(), "devices:", jax.device_count())'
                  echo "Use /gcs${WORKLOAD_NIC_PREFERRED_NUMA}/ for Cloud Storage access"
                resources:
                  requests:
                    google.com/tpu: 2
                  limits:
                    google.com/tpu: 2
                volumeMounts:
                - name: gcs0
                  mountPath: /gcs0
                  readOnly: false
                - name: gcs1
                  mountPath: /gcs1
                  readOnly: false
              - name: jax-tpu-2
                image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
                securityContext:
                  privileged: false
                command:
                - bash
                - -c
                - |
                  set -ex

                  python -c 'import jax; print("local devices:", jax.local_device_count(), "devices:", jax.device_count())'
                  echo "Use /gcs${WORKLOAD_NIC_PREFERRED_NUMA}/ for Cloud Storage access"
                resources:
                  requests:
                    google.com/tpu: 2
                  limits:
                    google.com/tpu: 2
                volumeMounts:
                - name: gcs0
                  mountPath: /gcs0
                  readOnly: false
                - name: gcs1
                  mountPath: /gcs1
                  readOnly: false

במניפסט הזה נוספים טעינות של נפח Cloud Storage FUSE אל דוגמה 4.

המאפיין multiNICIndex מצוין במאפייני נפח האחסון כדי להשתמש בממשק הרשת בצומת ה-NUMA המתאים לכל נפח אחסון.
עומס העבודה משתמש במשתנה הסביבה ${WORKLOAD_NIC_PREFERRED_NUMA} כדי לבחור את אמצעי האחסון של Cloud Storage FUSE, שמשויך לצומת NUMA שהקונטיינר מוקצה לו. ‫GKE מחדיר את המשתנה הזה לקונטיינרים בעומסי עבודה של Cloud TPU.

מחליפים את BUCKET_NAME בשם של הקטגוריה שלכם ב-Cloud Storage.

החלת המניפסט:

kubectl apply -f tpu7x-gcsfuse-multinic.yaml

שדרוג מאגרי צמתים באמצעות מאיצים (GPU ו-TPU)

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

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

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

הסרת המשאבים

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

gcloud

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

  gcloud container node-pools delete POOL_NAME \
      --location=LOCATION \
      --cluster=CLUSTER_NAME

מחליפים את מה שכתוב בשדות הבאים:

‫POOL_NAME: שם מאגר הצמתים.
‫LOCATION: מיקום המחשוב של האשכול.
‫CLUSTER_NAME: שם האשכול.

Cluster Toolkit

מחיקת הפריסה של Cluster Toolkit:

  gcluster destroy DEPLOYMENT_NAME

מחליפים את DEPLOYMENT_NAME בשם של ספריית הפריסה שנוצרה כשפרסתם את תוכנית האב.

הגדרת הגדרות נוספות

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

שימוש ב-Multislice

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

העברת הזמנת TPU

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

הפעלת הרישום ביומן

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

הגדרת תיקון אוטומטי של צמתים של חלקי TPU

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

התנאים שגורמים לצמתים לא תקינים של פרוסות TPU כוללים את התנאים הבאים:

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

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

הגדרת סגירה מבוקרת של צמתי TPU slice

באשכולות GKE עם מישור הבקרה בגרסה 1.29.1-gke.1425000 ומעלה, צומתי TPU slice תומכים באותות SIGTERM שמזהירים את הצומת מפני כיבוי קרוב. אפשר להגדיר את ההתראה על ההשבתה הקרובה עד חמש דקות מראש בצמתי TPU.

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

מניעת מצבים של חוסר אפשרות לתזמן

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

כדי להקטין את הסיכון לקיפאון בתזמון, אפשר להחיל אחת מההגדרות הבאות:

משתמשים בכללי Pod anti-affinity כדי לוודא ש-Pods מעבודות שונות לא מתוזמנים באותו מאגר של צומתי TPU או באותו דומיין טופולוגי.
משתמשים בהערת ה-annotation‏ jobset.sigs.k8s.io/exclusive-topology, שגורמת ל-JobSet לתבוע את דומיין הטופולוגיה שצוין (כמו מאגר צמתים) באופן בלעדי עבור ה-Pods שלו.

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

הפעלת קונטיינרים ללא מצב הרשאות

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

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

קונטיינר שפועל במכונה וירטואלית בפלח TPU צריך גישה למכסות גבוהות יותר של זיכרון נעול, כדי שהדרייבר יוכל לתקשר עם שבבי ה-TPU באמצעות גישה ישירה לזיכרון (DMA). כדי להפעיל את האפשרות הזו, צריך להגדיר ulimit גבוה יותר. כדי לצמצם את היקף ההרשאות במאגר התגים, מבצעים את השלבים הבאים:

עורכים את securityContext כך שיכלול את השדות הבאים:
```
securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]
```
כדי להגדיל את ulimit, מריצים את הפקודה הבאה בתוך הקונטיינר לפני שמגדירים את עומסי העבודה לשימוש במשאבי TPU:
```
ulimit -l 68719476736
```

ב-TPU v5e, אפשר להריץ קונטיינרים ללא מצב הרשאות מיוחדות באשכולות בגרסה 1.27.4-gke.900 ואילך.

ניראות ומדדים

מרכז שליטה

האפשרות 'תצפית על מאגר צמתים' במסוףGoogle Cloud זמינה לכלל המשתמשים. כדי לראות את הסטטוס של מאגרי הצמתים של TPU מרובי-מארחים ב-GKE, עוברים ללוח הבקרה GKE TPU Node Pool Status שמוצג ב-Cloud Monitoring:

מעבר לסטטוס של מאגר צמתים של GKE TPU

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

בדף Kubernetes Clusters במסוףGoogle Cloud , בכותרת Accelerators > TPU (מאיצים > TPU), מוצגים גם מדדי יכולת הצפייה ב-TPU, כמו השימוש ב-TPU, בכרטיסייה Observability (יכולת צפייה). מידע נוסף מופיע במאמר בנושא הצגת מדדי יכולת התבוננות.

מרכז הבקרה של TPU מתמלא רק אם הפעלתם מדדים של המערכת באשכול GKE.

מדדים בזמן ריצה

ב-GKE מגרסה 1.27.4-gke.900 ואילך, עומסי עבודה של TPU שמשתמשים ב-JAX מגרסה 0.4.14 ואילך ומציינים את containerPort: 8431, מייצאים מדדי ניצול של TPU בתור מדדי מערכת של GKE. המדדים הבאים זמינים ב-Cloud Monitoring כדי לעקוב אחרי ביצועי זמן הריצה של עומס העבודה של TPU:

‫Duty cycle: אחוז הזמן במהלך תקופת הדגימה האחרונה (60 שניות) שבה ליבות ה-TensorCore עיבדו באופן פעיל שבב TPU. אחוז גבוה יותר מצביע על ניצול טוב יותר של TPU.
זיכרון בשימוש: כמות הזיכרון של המאיץ שהוקצה בבייטים. נדגמים כל 60 שניות.
‫Memory total: סך הזיכרון של המאיץ בבייטים. הדגימה מתבצעת כל 60 שניות.

המדדים האלה נמצאים בסכימה של צומת Kubernetes ‏ (k8s_node) וקונטיינר Kubernetes ‏ (k8s_container).

מאגר Kubernetes:

kubernetes.io/container/accelerator/duty_cycle
kubernetes.io/container/accelerator/memory_used
kubernetes.io/container/accelerator/memory_total

צומת Kubernetes:

kubernetes.io/node/accelerator/duty_cycle
kubernetes.io/node/accelerator/memory_used
kubernetes.io/node/accelerator/memory_total

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

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

סטטוס הצומת

ב-GKE גרסה ‎1.32.1-gke.1357001 ואילך, מדד המערכת של GKE הבא חושף את מצב הצומת של GKE:

kubernetes.io/node/status_condition

בשדה condition מדווחים על התנאים בצומת, כמו Ready, ‏DiskPressure ו-MemoryPressure. בשדה status מוצג הסטטוס המדווח של התנאי, שיכול להיות True,‏ False או Unknown. זהו מדד עם סוג המשאב במעקב k8s_node.

השאילתה הזו ב-PromQL מראה אם צומת מסוים הוא Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

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

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

כדאי לבדוק במיוחד צמתים שלא מסומנים בסימן Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

אם אין נתונים, הצמתים מוכנים. תנאי הסטטוס נדגם כל 60 שניות.

אפשר להשתמש בשאילתה הבאה כדי להבין את סטטוס הצומת בכל הצי:

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

הסטטוס של מאגר הצמתים

מדד המערכת הבא של GKE עבור המשאב שבמעקב [k8s_node_pool] חושף את הסטטוס של מאגר צמתים ב-GKE:

kubernetes.io/node_pool/status

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

בשדה status מדווח הסטטוס של מאגר הצמתים, למשל Provisioning,‏ Running,‏ Error,‏ Reconciling או Stopping. עדכוני הסטטוס מתרחשים אחרי שפעולות GKE API מסתיימות.

כדי לבדוק אם סטטוס של מאגר צמתים מסוים הוא Running, משתמשים בשאילתת PromQL הבאה:

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

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

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

זמינות של מאגר צמתים

מדד המערכת הבא של GKE מראה אם מאגר צומתי TPU מרובי-מארחים זמין:

kubernetes.io/node_pool/multi_host/available

הערך של המדד הוא True אם כל הצמתים במאגר הצמתים זמינים, ו-False אחרת. המדד נדגם כל 60 שניות.

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

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

מספר ההפרעות בצומת

מדד המערכת הבא של GKE מציג את מספר ההפרעות בצומת GKE מאז הדגימה האחרונה (המדד נדגם כל 60 שניות):

kubernetes.io/node/interruption_count

השדות interruption_type (כמו TerminationEvent, ‏MaintenanceEvent או PreemptionEvent) ו-interruption_reason (כמו HostError, ‏Eviction או AutoRepair) יכולים לעזור להבין למה הייתה הפרעה בצומת.

כדי לקבל פירוט של ההפרעות והסיבות להן בצמתי TPU באשכולות בפרויקט, משתמשים בשאילתת PromQL הבאה:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

כדי לראות רק את אירועי התחזוקה של המארח, צריך לעדכן את השאילתה כדי לסנן את הערך HW/SW Maintenance בשדה interruption_reason. משתמשים בשאילתת PromQL הבאה:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

כדי לראות את מספר ההפרעות שמצטבר לפי מאגר צמתים, משתמשים בשאילתת PromQL הבאה:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

זמני השחזור (TTR) של מאגרי הצמתים

מדד המערכת הבא של GKE מציג את התפלגות משכי תקופות ההתאוששות של מאגרי צמתים של GKE עם כמה מארחים של TPU:

kubernetes.io/node_pool/accelerator/times_to_recover

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

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

אפשר להשתמש בשאילתת PromQL הבאה כדי לחשב את הזמן הממוצע לשחזור (MTTR) ב-7 הימים האחרונים באשכול:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

זמן בין הפרעות (TBI) במאגר צמתים

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

kubernetes.io/node_pool/accelerator/times_between_interruptions

כל דגימה שנרשמת במדד הזה מציינת משך זמן יחיד בין ההפרעה האחרונה לבין ההפרעה הנוכחית.

כדי לחשב את הזמן הממוצע בין הפרעות (MTBI) באשכול שלכם ב-7 הימים האחרונים, משתמשים בשאילתת PromQL הבאה:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_between_interruptions_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_between_interruptions_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

מדדי מארח

בגרסה 1.28.1-gke.1066000 של GKE ואילך, מכונות וירטואליות בפלח TPU מייצאות מדדי ניצול של TPU בתור מדדי מערכת של GKE. המדדים הבאים זמינים ב-Cloud Monitoring כדי לעקוב אחרי הביצועים של מארח ה-TPU:

‫TensorCore utilization: אחוז הניצול הנוכחי של TensorCore. הערך של TensorCore שווה לסכום של יחידות הכפל של מטריצות (MXU) בתוספת יחידת הווקטור. ערך הניצול של TensorCore הוא תוצאת החלוקה של פעולות TensorCore שבוצעו במהלך תקופת הדגימה האחרונה (60 שניות) במספר פעולות TensorCore הנתמכות במהלך אותה תקופה. ערך גבוה יותר מצביע על ניצול טוב יותר.
‫Memory bandwidth utilization: האחוז הנוכחי של רוחב הפס של זיכרון המאיץ שנמצא בשימוש. החישוב מתבצע על ידי חלוקת רוחב הפס של הזיכרון שנעשה בו שימוש במהלך תקופת דגימה (60 שניות) ברוחב הפס המקסימלי הנתמך במהלך אותה תקופת דגימה.

המדדים האלה נמצאים בסכימה של צומת Kubernetes ‏ (k8s_node) וקונטיינר Kubernetes ‏ (k8s_container).

מאגר Kubernetes:

kubernetes.io/container/accelerator/tensorcore_utilization
kubernetes.io/container/accelerator/memory_bandwidth_utilization

צומת Kubernetes:

kubernetes.io/node/accelerator/tensorcore_utilization
kubernetes.io/node/accelerator/memory_bandwidth_utilization

מידע נוסף זמין במאמרים בנושא מדדי Kubernetes ומדדי מערכת של GKE.

ניהול התזמון של האוסף

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

‫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 עם כמה מארחים

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

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

gcloud container node-pools describe NODE_POOL_NAME \
    --location LOCATION \
    --cluster CLUSTER_NAME \
    --format="json" | jq -r \
    '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'

הפלט אמור להיראות כך:

nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
gke-workload-type: HIGH_AVAILABILITY

אם מאגר של פרוסות TPU עם כמה מארחים הוא חלק מאוסף, הפלט כולל את התוויות הבאות:

cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

כדי לקבל את רשימת האוספים באשכול, מריצים את הפקודה הבאה:

#!/bin/bash

# Replace with your cluster name, project, and location
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

declare -A collection_names

node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Describe the node pool and extract labels using jq
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Add the collection name to the associative array if it's not empty
    if [[ -n "$collection_name" ]]; then
        collection_names["$collection_name"]=1
    fi
done

# Print the unique node pool collection names
echo "Unique cloud.google.com/gke-nodepool-group-name values:"
for name in "${!collection_names[@]}"; do
    echo "$name"
done

הפלט אמור להיראות כך:

Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}

כדי לקבל רשימה של מאגרי צמתים ששייכים לאוסף, מריצים את הפקודה הבאה:

#!/bin/bash

TARGET_COLLECTION_NAME=COLLECTION_NAME
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

matching_node_pools=()

# Get the list of all node pools in the cluster
node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Get the value of the cloud.google.com/gke-nodepool-group-name label
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Check if the group name matches the target value
    if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
        matching_node_pools+=("$pool")
    fi
done

# Print the list of matching node pools
echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
for pool in "${matching_node_pools[@]}"; do
    echo "$pool"
done

הפלט אמור להיראות כך:

Node pools with collection name 'COLLECTION_NAME':
{NODE_POOL_NAME_1}
{NODE_POOL_NAME_2}
{NODE_POOL_NAME_3}

כדי להגדיל את האוסף, יוצרים עוד מאגר צמתים של פרוסת TPU מרובת מארחים ומוסיפים את cloud.google.com/gke-workload-type ואת cloud.google.com/gke-nodepool-group-name. משתמשים באותו שם של אוסף במאפיין cloud.google.com/gke-nodepool-group-name ומריצים את אותו סוג של עומס עבודה. אם התכונה הקצאת צמתים אוטומטית (NAP) מופעלת באשכול, GKE יוצר באופן אוטומטי מאגרי צמתים על סמך דרישות עומס העבודה.
כדי להקטין את האוסף, מוחקים את מאגר הצמתים.
כדי למחוק את האוסף, צריך להסיר את כל מאגרי הצמתים המצורפים. אפשר למחוק את מאגר הצמתים או למחוק את האשכול. אם מוחקים את האוסף, כל האוספים שבו נמחקים.

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

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

כדי לבדוק אם הפעלתם תזמון של איסוף במאגר של פרוסות TPU במארח יחיד, מריצים את הפקודה הבאה:
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --project PROJECT_NAME \
    --location LOCATION \
    --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
```
הפלט אמור להיראות כך:
```
gke-workload-type: HIGH_AVAILABILITY
```
אם מאגר הפרוסות של TPU במארח יחיד הוא חלק מאוסף, הפלט יכלול את התווית cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.
כדי להגדיל את האיסוף, משנים את הגודל של מאגר הצמתים באופן ידני או באופן אוטומטי באמצעות הקצאה אוטומטית של צמתים.
כדי להקטין את האוסף, מוחקים את מאגר הצמתים.
כדי למחוק את האוסף, צריך להסיר את כל מאגרי הצמתים המצורפים. אפשר למחוק את מאגר הצמתים או למחוק את האשכול. אם מוחקים את האשכול, כל האוספים שבו נמחקים.

בעיות מוכרות

יכול להיות שהכלי לשינוי גודל האשכול יחשב באופן שגוי את הקיבולת של צמתי פרוסת TPU חדשים לפני שהצמתים האלה ידווחו על יחידות TPU זמינות. יכול להיות שהמידרוג האוטומטי של האשכול יבצע לאחר מכן הרחבה נוספת, וכתוצאה מכך ייצרו יותר צמתים מהנדרש. המידרוג האוטומטי של האשכול מצמצם את מספר הצמתים הנוספים, אם הם לא נדרשים, אחרי פעולת צמצום רגילה.
הכלי להתאמה אוטומטית של אשכולות מבטל את הגדלת מספר הצמתים במאגרי צמתים של חלקי TPU שנשארים במצב המתנה יותר מ-10 שעות. הכלי Cluster Autoscaler ינסה שוב לבצע את פעולות הגדלת הקיבולת האלה מאוחר יותר. ההתנהגות הזו עשויה להפחית את הזמינות של TPU ללקוחות שלא משתמשים בהזמנות.
עומסי עבודה שאינם TPU שיש להם טולרנטיות ל-taint של TPU יכולים למנוע את הקטנת מאגר הצמתים אם הם נוצרים מחדש במהלך הניקוז של מאגר הצמתים של פרוסת ה-TPU.
מדד השימוש ברוחב פס של הזיכרון לא זמין ב-TPU מדגם v5e.

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

לפני שמתחילים

תכנון ההגדרה של TPU

מוודאים שיש לכם מכסת TPU

מכסה למכונות וירטואליות לפי דרישה או במודל Spot

מכסות למשאבי GKE נוספים

בדיקה שההזמנה זמינה

יצירת אשכול

gcloud

Cluster Toolkit

הקצאת מעבדי TPU

יצירה ידנית של מאגר צמתים

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

gcloud

Terraform

המסוף

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

‫Ironwood (TPU7x)

gcloud

Terraform

גרסאות אחרות של TPU

gcloud

Terraform

המסוף

שימוש בהקצאת צמתים אוטומטית ב-GKE

הגדרת ComputeClasses בהתאמה אישית

יצירת ComputeClass בהתאמה אישית

‫Ironwood (TPU7x)

גרסאות אחרות של TPU

יצירת משימה שצורכת TPU

הכנת עומסי העבודה

הפעלת עומס העבודה בצמתים של פרוסת TPU

דוגמה 1: הפעלת פריסה שמבקשת TPU במפרט של ה-Pod

gcloud

Cluster Toolkit

דוגמה 2: הפעלת עומס עבודה שמציג את מספר שבבי ה-TPU הזמינים במאגר הצמתים של פרוסת TPU

דוגמה 3: הפעלת עומס עבודה שמציג את מספר שבבי ה-TPU הזמינים בפרוסת ה-TPU

דוגמה 4: הפעלת עומס עבודה שמטרגט שני צמתי NUMA

דוגמה 5: הפעלת עומס עבודה של TPU עם כמה קונטיינרים באמצעות נפחים של Cloud Storage FUSE עם כמה כרטיסי NIC

שדרוג מאגרי צמתים באמצעות מאיצים (GPU ו-TPU)

הסרת המשאבים

gcloud

Cluster Toolkit

הגדרת הגדרות נוספות

שימוש ב-Multislice

העברת הזמנת TPU

הפעלת הרישום ביומן

הגדרת תיקון אוטומטי של צמתים של חלקי TPU

הגדרת סגירה מבוקרת של צמתי TPU slice

מניעת מצבים של חוסר אפשרות לתזמן

הפעלת קונטיינרים ללא מצב הרשאות

ניראות ומדדים

מרכז שליטה

מדדים בזמן ריצה

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

סטטוס הצומת

הסטטוס של מאגר הצמתים

זמינות של מאגר צמתים

מספר ההפרעות בצומת

זמני השחזור (TTR) של מאגרי הצמתים

זמן בין הפרעות (TBI) במאגר צמתים

מדדי מארח

ניהול התזמון של האוסף

ניהול תזמון של אוספים במאגרי צמתים של פרוסות TPU עם כמה מארחים

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

בעיות מוכרות

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

פריסת עומסי עבודה של TPU ב-GKE Standard