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

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

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

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

איך יחידות TPU פועלות ב-Autopilot

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

  • גרסת ה-TPU בשדה spec.nodeSelector.
  • טופולוגיית ה-TPU בשדה spec.nodeSelector. הטופולוגיה צריכה להיות נתמכת על ידי גרסת ה-TPU שצוינה.
  • מספר שבבי ה-TPU בשדות spec.containers.resources.requests ו-spec.containers.resources.limits.

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

יחידות TPU ב-Autopilot תואמות ליכולות הבאות:

  1. Spot Pods
  2. הזמנות של קיבולת ספציפית
  3. Extended run time Pods
  4. Flex-start

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

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

תמחור

למידע על תמחור, אפשר לעיין במאמר תמחור של Autopilot.

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

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

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם אשכול Autopilot שפועלת בו גרסה GKE 1.32.3-gke.1927000 ואילך. הוראות מפורטות מופיעות במאמר בנושא יצירת אשכול Autopilot.
  • כדי להשתמש ב-TPU שמורים, צריך לוודא שיש לכם הזמנת קיבולת ספציפית. הוראות מפורטות מופיעות במאמר שימוש בנכסים ששוריינו.

הקצאת מכסות ליחידות TPU ולמשאבים אחרים של GKE

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

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

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

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

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

    לפתיחת הדף Quotas

  2. בתיבה Filter:

    1. בטבלה הבאה אפשר לבחור ולהעתיק את מאפיין המכסה על סמך גרסת ה-TPU והערך בבורר הצמתים של cloud.google.com/gke-tpu-accelerator. לדוגמה, אם אתם מתכננים ליצור צמתים של TPU v5e על פי דרישה, שהערך שלהם בבורר הצמתים cloud.google.com/gke-tpu-accelerator הוא tpu-v5-lite-podslice, צריך להזין Name: TPU v5 Lite PodSlice chips.

      גרסת ה-TPU, cloud.google.com/gke-tpu-accelerator המאפיין והשם של המכסה עבור מופעים על פי דרישה המאפיין והשם של המכסה למכונות Spot2
      ‫TPU v3,‏
      tpu-v3-device 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 לא רלוונטי
      ‫TPU v3,‏
      tpu-v3-slice 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 לא רלוונטי
      ‫TPU v4,‏
      tpu-v4-podslice 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      ‫TPU v5e,
      tpu-v5-lite-podslice 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      ‫TPU v5p,
      tpu-v5p-slice 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      ‫TPU Trillium,
      tpu-v6e-slice 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e
      ‫Ironwood (TPU7x),
      tpu7x 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

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

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

כשיוצרים הזמנה של TPU, גם המגבלה וגם ערכי השימוש הנוכחיים של המכסה המתאימה גדלים במספר הצ'יפים בהזמנת ה-TPU. לדוגמה, אם נוצרת הזמנה של 16 שבבי TPU v5e, והערך שלהם בבורר הצמתים cloud.google.com/gke-tpu-accelerator הוא tpu-v5-lite-podslice, אז הערכים Limit ו-Current usage במכסת TPU v5 Lite PodSlice chips באזור הרלוונטי גדלים ב-16.

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

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

  • מכסת דיסק מתמיד 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.

  1. פלטפורמות כמו JAX,‏ PyTorch ו-TensorFlow ניגשות ל-TPU VM באמצעות libtpuהספרייה המשותפת. ‫libtpu כולל את מהדר XLA, את תוכנת זמן הריצה של TPU ואת מנהל ההתקן של TPU. כל גרסה של PyTorch ו-JAX דורשת גרסה מסוימת של libtpu.so. כדי למנוע התנגשויות בין גרסאות של חבילות, מומלץ להשתמש בתמונה שנוצרה על ידי JAX AI. כדי להשתמש ב-TPU ב-GKE, צריך לוודא שאתם משתמשים בגרסאות הבאות: ‫tpu7x
    סוג ה-TPU גרסה libtpu.so
    ‫Ironwood‏ (TPU7x)
    TPU Trillium (v6e)
    tpu-v6e-slice
    TPU v5e
    tpu-v5-lite-podslice
    TPU v5p
    tpu-v5p-slice
    • תמונת AI מומלצת של JAX: ‏ jax0.4.35-rev1 ואילך
    • הגרסה המומלצת של jax[tpu]:‏ 0.4.19 ואילך.
    • גרסת torchxla[tpuvm] מומלצת: מומלץ להשתמש בגרסת build לילית מ-23 באוקטובר 2023.
    ‫TPU v4
    tpu-v4-podslice
    TPU v3
    tpu-v3-slice
    tpu-v3-device
  2. במניפסט של עומס העבודה, מוסיפים בוררי צמתים של 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.

אפשרויות להקצאת TPU ב-GKE

כדי להקצות TPU ב-GKE, יש לכם את אפשרויות ההגדרה הבאות:
  • בקשה לעומס עבודה: מציינים את גרסת ה-TPU והטופולוגיה בשדה spec.nodeSelector ואת מספר שבבי ה-TPU בקטע spec.containers.resources. כשפורסים את עומס העבודה,‏ GKE מקצה אוטומטית צמתים עם הגדרת ה-TPU הנכונה וממקם כל עומס עבודה בצומת ייעודי משלו כדי להבטיח גישה מלאה למשאבי הצומת. הוראות מפורטות מופיעות במאמר בנושא בקשת TPU בעומס עבודה.

    • הקצאת מעבדי TPU באופן מרכזי באמצעות סוגי מחשוב בהתאמה אישית

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

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

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

    ‫Ironwood‏ (TPU7x)

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

      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: האזור של מדיניות עומס העבודה. מדיניות עומס עבודה היא משאב אזורי, ואפשר להשתמש בה במאגרי צמתים.

    2. שומרים את קובץ המניפסט הבא בשם 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

    3. (אופציונלי) אפשר להשתמש בהזמנה ספציפית או בחלק ספציפי של בלוק. לדוגמה, אפשר להוסיף את 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, מבצעים את השלבים הבאים:

    1. שומרים את המניפסט הבא בתור 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 צריכים להיות זהים.

    2. פורסים את ComputeClass:

      kubectl apply -f tpu-compute-class.yaml

      מידע נוסף על ComputeClasses ו-TPU בהתאמה אישית זמין במאמר הגדרת TPU.

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

    1. שומרים את קובץ המניפסט הבא בשם 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 צריכים להיות זהים.

    2. פורסים את המשרה:

      kubectl create -f tpu-job.yaml

      כשיוצרים את הג'וב הזה, GKE מבצע באופן אוטומטי את הפעולות הבאות:

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

      מידע נוסף זמין במאמר מידע על ComputeClasses בהתאמה אישית.

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

      kubectl delete -f tpu-job.yaml

    בקשה למעבדי TPU בעומס עבודה

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

    • בוררי צמתים לגרסה ולטופולוגיה של ה-TPU
    • מספר שבבי ה-TPU עבור קונטיינר בעומס העבודה

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

    שיקולים לגבי בקשות TPU בעומסי עבודה

    רק קונטיינר אחד ב-Pod יכול להשתמש ב-TPU. מספר שבבי ה-TPU שקונטיינר מבקש חייב להיות זהה למספר שבבי ה-TPU שמחוברים לצומת בפרוסה. לדוגמה, אם מבקשים TPU v5e ‏ (tpu-v5-lite-podslice) עם טופולוגיה של 2x4, אפשר לבקש כל אחת מהאפשרויות הבאות:

    • ‫4, שיוצר שני צמתים מרובי-מארחים עם 4 שבבי TPU כל אחד
    • ‫8 chips, which creates one single-host node with 8 TPU chips

    כדי למקסם את יעילות העלות, מומלץ תמיד לצרוך את כל ה-TPU בפרוסה שאתם מבקשים. אם מבקשים פלח של שני צמתים עם 4 שבבי TPU כל אחד, צריך לפרוס עומס עבודה שפועל בשני הצמתים ומשתמש בכל 8 שבבי ה-TPU בפלח.

    יצירת עומס עבודה שמבקש יחידות TPU

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

    1. שומרים את קובץ המניפסט הבא בשם tpu-autopilot.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
  parallelism: NUM_OF_VMS
  completions: NUM_OF_VMS
  completionMode: Indexed
  template:
    spec:
      # Optional: Run in GKE Sandbox
      # runtimeClassName: gvisor
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: TPU_TYPE
        cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
        topology.kubernetes.io/zone: LOCATION
      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

      מחליפים את הערכים הבאים בסדר הזה:

      1. ‫TPU_TYPE: בוחרים את גרסת ה-TPU שבה רוצים להשתמש, למשל tpu-v5-lite-podslice. הערך חייב להיות נתמך על ידי GKE.
      2. ‫LOCATION: מאמתים את האזור שבו GKE ממקם את מכונות ה-TPU הווירטואליות.

        אופציונלי: משתמשים באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שעברו אופטימיזציה לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.

      3. ‫TPU_TOPOLOGY: בוחרים את הסידור של שבבי TPU בפרוסת ה-TPU, כמו 4x4. הטופולוגיה צריכה להיות נתמכת עבור סוג ה-TPU שנבחר.
      4. מחפשים את TPU_TYPE וTPU_TOPOLOGY שנבחרו בטבלה שבקטע בחירת טופולוגיה:
        • ‫NUM_OF_VMS: משתמשים בערך של "מספר המכונות הווירטואליות" בעמודה "מפרט טכני". מגדירים את הערך הזה בשדות parallelism ו-completions במפרט המשרה.
        • ‫NUMBER_OF_CHIPS: מזינים את מספר השבבים לכל מכונה וירטואלית. כדי לחשב את זה, מחלקים את הערך בעמודה "Number of TPU chips for the topology" בערך בעמודה "Number of VMs" בשורה שבחרתם. מגדירים את הערך הזה לבקשת המשאב google.com/tpu.
      5. ‫MEMORY_SIZE: כמות הזיכרון המקסימלית שבה ה-TPU משתמש. מגבלות הזיכרון תלויות בגרסה ובטופולוגיה של ה-TPU שבהן אתם משתמשים. מידע נוסף זמין במאמר מספר מינימלי ומקסימלי של מאיצים.

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

      • ‫image: הגדרה של תמונת ה-AI של JAX שבה ייעשה שימוש. במניפסט לדוגמה, השדה הזה מוגדר לתמונת ה-AI העדכנית ביותר של JAX. כדי להגדיר גרסה אחרת, אפשר לעיין ברשימה של תמונות מ-AI עדכניות של JAX.
      • ‫runtimeClassname: gvisor: משתמשים בדגל הזה כדי להריץ את ה-Pod הזה ב-GKE Sandbox. כדי להשתמש, מבטלים את ההערה בשורה הזו. ‫GKE Sandbox תומך ב-TPU מגרסה v4 ואילך. מידע נוסף זמין במאמר בנושא GKE Sandbox.

      לדוגמה, נניח שיש tpu-v5-lite-podslice עם טופולוגיה של 4x4. המשמעות של ההגדרה הזו היא:

      • בטופולוגיה יש 16 צ'יפים בסך הכול (4*4=16).
      • ‫tpu-v5-lite-podslice נפרס ב-ct5lp-hightpu-4t מכונות עם ארבעה צ'יפים לכל מכונה וירטואלית. המשמעות היא שכדי לקבל טופולוגיה של 4x4, צריך ארבע מכונות וירטואליות (16/4=4). לכן, צריך להגדיר את השדות parallelism ו-completions לערך 4.
      • כל קונטיינר ב-Pod מבקש ארבעה שבבי TPU, שזהה למספר השבבים לכל מכונה וירטואלית. המניפסט מציין את זה בשורה google.com/tpu: 4.

    2. פורסים את המשרה:

      kubectl create -f tpu-autopilot.yaml

      כשיוצרים את הג'וב הזה, GKE מבצע באופן אוטומטי את הפעולות הבאות:

      1. הקצאת צמתים להרצת ה-Pods. בהתאם לסוג ה-TPU, לטופולוגיה ולבקשות המשאבים שציינתם, הצמתים האלה הם פרוסות של מארח יחיד או פרוסות של כמה מארחים.
      2. הוספת taints ל-Pods ו-tolerations לצמתים כדי למנוע מעומסי עבודה אחרים לפעול באותם צמתים כמו עומסי עבודה של TPU.

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

      kubectl delete -f tpu-autopilot.yaml

    יצירת עומס עבודה שמבקש TPU ותזמון איסוף

    ב-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 עם כמה מארחים זמין לאשכולות Autopilot בגרסה 1.31.2-gke.1537000 ואילך. צומתי TPU slice עם כמה מארחים עם טופולוגיה של 2x4 נתמכים רק בגרסה 1.31.2-gke.1115000 ואילך. כדי ליצור צומתי פרוסות TPU עם כמה מארחים ולקבץ אותם כאוסף, מוסיפים את תוויות Kubernetes הבאות למפרט של עומס העבודה:

    • ‫cloud.google.com/gke-nodepool-group-name: לכל אוסף צריך להיות שם ייחודי ברמת האשכול. הערך בתווית cloud.google.com/gke-nodepool-group-name צריך לעמוד בדרישות לתוויות של אשכולות.

    • cloud.google.com/gke-workload-type: HIGH_AVAILABILITY

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

        nodeSelector:
    cloud.google.com/gke-nodepool-group-name: ${COLLECTION_NAME}
    cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
    cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
    cloud.google.com/gke-tpu-topology: 4x4
...

    שימוש בפרוסת TPU עם מארח יחיד

    תזמון איסוף ב-TPU slice nodes של מארח יחיד זמין באשכולות Autopilot בגרסה 1.31.2-gke.1088000 ואילך. כדי ליצור צומתי פרוסות TPU במארח יחיד ולקבץ אותם כאוסף, מוסיפים את התווית cloud.google.com/gke-workload-type:HIGH_AVAILABILITY במפרט עומס העבודה.

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

      nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
    cloud.google.com/gke-tpu-topology: 2x2
    cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
  ...

    שימוש בסוגי מחשוב מותאמים אישית לפריסת אוסף

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

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

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

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

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

    1. שומרים את קובץ המניפסט הבא בשם 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.
        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.
    2. פורסים את המניפסט: 
      kubectl create -f available-chips-multihost.yaml

      ‫GKE מריץ פרוסת TPU v4 עם ארבע מכונות וירטואליות (פרוסת TPU מרובת-מארחים). הפרוסה כוללת 16 שבבי TPU שמחוברים ביניהם.

    3. מוודאים שהמשימה יצרה ארבעה פודים: 
      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
    4. מקבלים את היומנים של אחד מה-Pods: 
      kubectl logs POD_NAME

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

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

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

    דוגמה: הצגת שבבי ה-TPU בצומת יחיד

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

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

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

    1. שומרים את קובץ המניפסט הבא בשם 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.
    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.
    2. פורסים את המניפסט: 
      kubectl create -f available-chips-singlehost.yaml

      ‫GKE מקצה צמתים עם שמונה פרוסות TPU במארח יחיד שמשתמשות ב-TPU v5e. לכל צומת TPU יש שמונה שבבי TPU (פרוסת TPU של מארח יחיד).

    3. אחזור היומנים של ה-Pod: 
      kubectl logs tpu-job-jax-v5

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

      Total TPU chips: 8
    4. אופציונלי: מסירים את עומס העבודה: 
        kubectl delete -f available-chips-singlehost.yaml

    מעקב אחרי מעבדי TPU

    מרכז שליטה

    האפשרות 'תצפית על מאגר צמתים' במסוף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:

    • מחזור פעילות: אחוז הזמן במהלך תקופת הדגימה האחרונה (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 מדווח על התפלגות משך תקופת השחזור של מאגרי צמתים של TPU עם כמה מארחים ב-GKE:

    • 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]))

    מדדי מארח

    ב-GKE מגרסה 1.28.1-gke.1066000 ואילך, מכונות וירטואליות בפרוסת 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.

    רישום ביומן

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

    המלצות לעומסי עבודה של TPU ב-Autopilot

    ההמלצות הבאות יכולות לשפר את היעילות של עומסי העבודה ב-TPU:

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

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

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

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

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

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

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