בדף הזה מוסבר על יחידות GPU ב-Google Kubernetes Engine (GKE), כדי לעזור לכם לבחור את תצורת ה-GPU האופטימלית לעומסי העבודה שלכם. אם אתם רוצים לפרוס עומסי עבודה של GPU באמצעות Slurm, כדאי לעיין במאמר יצירת אשכול Slurm שעבר אופטימיזציה ל-AI.
אתם יכולים להשתמש במעבדי GPU כדי להאיץ משימות שדורשות הרבה משאבים, כמו למידת מכונה ועיבוד נתונים. המידע בדף הזה יכול לעזור לכם לבצע את הפעולות הבאות:
- לוודא שה-GPU זמין כשצריך.
- החלטה אם להשתמש ב-GPU באשכולות במצב GKE Autopilot או במצב GKE Standard.
- כדי להשתמש ביכולות ה-GPU בצורה יעילה, בוחרים תכונות שקשורות ל-GPU.
- מעקב אחרי מדדים של צומת GPU.
- שיפור האמינות של עומסי עבודה של GPU על ידי טיפול יעיל יותר בהפרעות.
הדף הזה מיועד לאדמינים ולמפעילים של פלטפורמות ולמהנדסי למידת מכונה (ML) שרוצים לוודא שתשתית ההאצה מותאמת לעומסי העבודה שלהם.
לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את הנושאים הבאים:
בחירת GPU ב-GKE
ב-GKE, האופן שבו מבקשים חומרת GPU תלוי במצב שבו משתמשים: Autopilot או Standard. ב-Autopilot, אתם מבקשים חומרת GPU על ידי ציון משאבי GPU בעומסי העבודה. במצב GKE Standard, אפשר לצרף חומרת GPU לצמתים באשכולות, ואז להקצות משאבי GPU לעומסי עבודה מבוססי-קונטיינרים שפועלים בצמתים האלה. הוראות מפורטות לגבי צירוף יחידות GPU ושימוש בהן בעומסי העבודה מופיעות במאמרים פריסת עומסי עבודה של GPU ב-Autopilot או הפעלת יחידות GPU במאגרי צמתים רגילים.
GKE מציע כמה תכונות ספציפיות ל-GPU כדי לשפר את השימוש היעיל במשאבי GPU של עומסי עבודה שפועלים בצמתים, כולל שיתוף זמן, יחידות GPU מרובות מופעים ויחידות GPU מרובות מופעים עם NVIDIA MPS.
בדף הזה מוסבר על האפשרויות לבקשת יחידות GPU ב-GKE, כולל:
- בחירת מכסת ה-GPU, המספר המקסימלי של יחידות GPU שאפשר להריץ בפרויקט
- ההבדל בין מצב אוטומטי למצב רגיל
- ניהול מחסנית ה-GPU דרך GKE או NVIDIA GPU Operator ב-GKE
- בחירת תכונות כדי לצמצם את כמות משאבי ה-GPU שלא מנוצלים
- גישה לספריות NVIDIA CUDA-X לאפליקציות CUDA
- מעקב אחרי מדדים של צומתי GPU
- טיפול בשיבושים עקב תחזוקת צמתים
- שימוש ב-GKE Sandbox כדי לאבטח עומסי עבודה של GPU
מודלים זמינים של GPU
חומרת ה-GPU שזמינה לשימוש ב-GKE היא קבוצת משנה של דגמי ה-GPU שזמינים ב-Compute Engine. החומרה הספציפית שזמינה תלויה באזור או בתחום של Compute Engine שבו נמצא האשכול. מידע נוסף על זמינות ספציפית זמין במאמר בנושא אזורים ואזורי זמינות של GPU.
סוגי המכונות עם הביצועים הכי טובים ב-Google Cloud, כמו A4X Max, A4X, A4 ו-A3 Ultra, דורשים הגדרה ספציפית כדי למקסם את הביצועים של החומרה הבסיסית. פרטים על אופן ההגדרה של אשכולות GKE לשימוש בסוגי מכונות GPU האלה מופיעים במסמכי התיעוד של AI Hypercomputer, שבהם מוסבר על היכולות של מערכת הסופר-קומפיוטר המשולבת שלGoogle Cloud.
למידע על יצירת אשכולות GKE שעברו אופטימיזציה ל-AI עם סוגי המכונות האלה, אפשר לעיין במאמרים הבאים:
- כדי לפרוס במהירות אשכולות GKE שמוכנים לייצור, יוצרים אשכול GKE שעבר אופטימיזציה ל-AI באמצעות Cluster Toolkit
- כדי להתאים אישית או להרחיב סביבות GKE קיימות של ייצור בצורה מדויקת, צריך להשתמש ב-Google Cloud CLI כדי ליצור אשכול GKE. בוחרים אחת מההוראות הבאות בהתאם לסוג המכונה ול-GPU שרוצים להשתמש בהם:
למידע על תמחור של יחידות GPU, אפשר לעיין בGoogle Cloud מק"טים ובדף התמחור של יחידות GPU.
מכסת GPU בחבילה
מכסת ה-GPU היא המספר המקסימלי של יחידות GPU שאפשר להריץ בGoogle Cloud פרויקט. כדי להשתמש ביחידות GPU באשכולות GKE, בפרויקט שלכם צריכה להיות מכסת GPU מספקת. בדף Quotas (מכסות) אפשר לוודא שיש לכם מספיק יחידות GPU זמינות בפרויקט.
המכסה של ה-GPU צריכה להיות לפחות שווה למספר הכולל של ה-GPU שאתם מתכוונים להפעיל באשכול. אם מפעילים מידרוג אוטומטי של אשכולות, צריך לבקש הקצאת GPU לפחות בהיקף ששווה למספר המקסימלי של הצמתים באשכול כפול מספר יחידות ה-GPU בכל צומת.
לדוגמה, אם אתם מצפים להשתמש בשלושה צמתים עם שני GPUs כל אחד, אז מכסת ה-GPU שנדרשת לפרויקט היא שש.
כדי לבקש מכסת GPU נוספת, פועלים לפי ההוראות לבקשת שינוי מכסה, ומשתמשים בערך gpus כמדד.
בחירת תמיכה ב-GPU באמצעות Autopilot או Standard
GPU זמין באשכולות Autopilot ו-Standard.
מומלץ להשתמש באשכולות במצב Autopilot כדי ליהנות מחוויית Kubernetes מנוהלת באופן מלא. ב-Autopilot, GKE מנהל את התקנת מנהלי ההתקנים, את שינוי הגודל של הצמתים, את הבידוד של ה-Pods ואת הקצאת הצמתים.
בטבלה הבאה מפורטים ההבדלים בין תמיכה ב-GPU בטייס אוטומטי לבין תמיכה ב-GPU רגילה:
| תיאור | טייס אוטומטי | רגילה |
|---|---|---|
| בקשת חומרת GPU | מציינים משאבי GPU בעומסי העבודה. | מצרפים חומרת GPU לצמתים באשכולות, ואז מקצים משאבי GPU לעומסי עבודה מבוססי-קונטיינרים שפועלים בצמתים האלה. |
| זמינות של חומרת GPU |
|
כל סוגי ה-GPU שנתמכים על ידי Compute Engine |
| בחירת GPU | מבקשים כמות וסוג של GPU במפרט של עומס העבודה. כברירת מחדל, Autopilot מתקין את מנהל ההתקן שמוגדר כברירת מחדל לגרסת GKE ומנהל את הצמתים. כדי לבחור גרסה ספציפית של דרייבר ב-Autopilot, אפשר לעיין במאמר בחירת דרייברים של NVIDIA עבור Autopilot GPU Pods. |
מבצעים את השלבים שמתוארים במאמר הפעלת יחידות GPU במאגרי צמתים רגילים:
|
| שיפור השימוש ב-GPU | ||
| אבטחה | ||
| תמחור | תמחור של פודים עם GPU במצב Autopilot | המחירון של מעבדים גרפיים (GPU) ב-Compute Engine |
כדי לבחור את מצב הפעולה של GKE שהכי מתאים לעומסי העבודה שלכם, אפשר לעיין במאמר בחירת מצב פעולה של GKE.
שימוש ביחידות GPU
ב-GKE יש אפשרויות שונות לשימוש ב-GPU, בהתאם לדרישות של עומס העבודה. במאמר מידע על אפשרויות צריכת מאיצים לעומסי עבודה של AI/ML ב-GKE מוסבר איך לבחור את האפשרות הכי מתאימה לתרחיש השימוש שלכם.
ניהול מחסנית ה-GPU דרך GKE או NVIDIA GPU Operator ב-GKE
כברירת מחדל, GKE מנהל את כל מחזור החיים של צמתי ה-GPU, כולל התקנה אוטומטית של מנהלי התקנים (דרייברים) של GPU, מעקב אחרי עומסי עבודה של GPU ב-GKE באמצעות NVIDIA Data Center GPU Manager (DCGM) ואסטרטגיות לשיתוף GPU.
כדאי להשתמש ב-GKE כדי לנהל את צמתי ה-GPU, כי GKE מנהל באופן מלא את מחזור החיים של צמתי ה-GPU.
כדי להתחיל להשתמש ב-GKE לניהול צמתים של GPU, בוחרים באחת מהאפשרויות הבאות:
- פריסת עומסי עבודה של GPU ב-Autopilot
- הפעלת יחידות GPU במאגרי צמתים רגילים
- פריסת אשכולות עם מעבדי GPU של NVIDIA B200 או NVIDIA H200 בנפח 141GB
אפשר להשתמש ב-NVIDIA GPU Operator כחלופה לתמיכה ב-GPU בניהול מלא ב-GKE, גם במערכת הפעלה שמותאמת לקונטיינרים (COS) וגם בתמונות צמתים של Ubuntu. בוחרים באפשרות הזו אם רוצים חוויה עקבית אצל כמה ספקי שירותי ענן, אם כבר משתמשים ב-NVIDIA GPU Operator או אם משתמשים בתוכנה שתלויה ב-NVIDIA GPU Operator. מידע נוסף זמין במאמר בנושא ניהול מחסנית ה-GPU באמצעות NVIDIA GPU Operator.
כדי לבחור את האפשרות הכי מתאימה לתרחיש השימוש שלכם, אפשר להיעזר בטבלה הבאה שמשווה בין שתי השיטות לניהול צמתי GPU ב-GKE.
| תיאור | שימוש ב-GKE לניהול צומתי GPU | שימוש ב-NVIDIA GPU Operator ב-GKE |
|---|---|---|
| ניהול מחזור החיים של צומת GPU (התקנה, שדרוג) | מנוהל באופן מלא על ידי GKE. | בניהול המשתמש. |
| התקנת מנהל התקן | התקנה אוטומטית וידנית של דרייברים של GPU. | התקנה ידנית של דרייברים של GPU. |
| בוררי צמתים | cloud.google.com/gke-gpu=true |
nvidia.com/gpu=true |
| אסטרטגיות לשיתוף GPU |
|
|
| בדיקת תקינות של צמתי GPU |
|
|
| מדדים וניראות |
|
|
אופטימיזציה של השימוש במשאבים באמצעות תכונות של GPU ב-GKE
כברירת מחדל, Kubernetes תומך רק בהקצאת מעבדי GPU כיחידות שלמות לקונטיינרים, אבל GKE מספק תכונות נוספות שבעזרתן אפשר לבצע אופטימיזציה של השימוש במשאבים של עומסי העבודה של ה-GPU.
התכונות הבאות זמינות ב-GKE כדי לצמצם את כמות משאבי ה-GPU שלא מנוצלים:
| תכונות של GPU | |
|---|---|
| מעבדים גרפיים מרובי-מופעים |
האפשרות זמינה במינויים: Autopilot ו-Standard פיצול של GPU יחיד לעד שבעה מקרים מופרדים בחומרה שאפשר להקצות כ-GPU נפרדים למאגרי תגים בצומת. כל מאגר שהוקצה מקבל את המשאבים שזמינים לאותו מופע. |
| מעבדים גרפיים (GPU) עם שיתוף זמן |
התכונה זמינה במינויים: Autopilot ו-Standard הצגת GPU יחיד כיחידות מרובות לכמה מאגרי תגים בצומת. מנהל ההתקן של ה-GPU מבצע החלפת הקשר (context-switch) ומקצה את כל משאבי ה-GPU לכל מאגר שהוקצה לפי הצורך לאורך זמן. |
| NVIDIA MPS |
התכונה זמינה בתוכנית: Standard שיתוף של GPU פיזי יחיד של NVIDIA בין כמה קונטיינרים. NVIDIA MPS היא הטמעה חלופית של CUDA API, שתואמת לבינארי, ומיועדת להפעלה שקופה של אפליקציות CUDA מרובות תהליכים במקביל במכשיר GPU יחיד. |
גישה לספריות NVIDIA CUDA-X לאפליקציות CUDA
CUDA היא פלטפורמת מחשוב מקבילי ומודל תכנות של NVIDIA ל-GPU. כדי להשתמש באפליקציות CUDA, התמונה שבה אתם משתמשים צריכה לכלול את הספריות. כדי להוסיף את הספריות של NVIDIA CUDA-X, אפשר ליצור ולהשתמש באימג' משלכם על ידי הוספת הערכים הבאים למשתנה הסביבה LD_LIBRARY_PATH במפרט הקונטיינר:
-
/usr/local/nvidia/lib64: המיקום של מנהלי ההתקנים (דרייברים) של NVIDIA. -
/usr/local/cuda-CUDA_VERSION/lib64: המיקום של ספריות NVIDIA CUDA-X בצומת.מחליפים את
CUDA_VERSIONבגרסה של תמונת CUDA-X שבה השתמשתם. חלק מהגרסאות מכילות גם כלי עזר לניפוי באגים בתיקייה/usr/local/nvidia/bin. פרטים נוספים זמינים במאמר בנושא התמונה של NVIDIA CUDA ב-DockerHub.כדי לבדוק את גרסת הדרייבר המינימלית של ה-GPU שנדרשת לגרסה של CUDA, אפשר לעיין במאמר CUDA Toolkit and Compatible Driver Versions.
באשכולות Autopilot, GKE מנהל את הבחירה וההתקנה של גרסת הדרייבר.
מעקב אחר ביצועי עומס העבודה של צומת GPU
אם באשכול GKE שלכם מופעלים מדדי מערכת, המדדים הבאים זמינים ב-Cloud Monitoring כדי לעקוב אחרי ביצועי עומס העבודה של ה-GPU:
-
מחזור פעולה (
container/accelerator/duty_cycle): אחוז הזמן במהלך תקופת הדגימה האחרונה (10 שניות) שבה המאיץ עיבד באופן פעיל. בין 1 ל-100. -
השימוש בזיכרון (
container/accelerator/memory_used): כמות הזיכרון של המאיץ שהוקצה בבייטים. -
נפח הזיכרון (
container/accelerator/memory_total): סך כל הזיכרון של המאיץ בבייטים.
המדדים האלה חלים ברמת הקונטיינר (container/accelerator) ולא נאספים עבור קונטיינרים שמתוזמנים ב-GPU שמשתמש בשיתוף זמן GPU או ב-NVIDIA MPS.
אתם יכולים להשתמש במרכזי בקרה מוגדרים מראש כדי לעקוב אחרי האשכולות עם צמתי GPU. מידע נוסף מופיע במאמר הצגת מדדי יכולת התבוננות. מידע כללי על מעקב אחרי האשכולות והמשאבים שלהם זמין במאמר יכולת צפייה ב-GKE.
הצגת מדדי השימוש של עומסי עבודה
אפשר לראות את מדדי השימוש ב-GPU של עומסי העבודה בלוח הבקרה Workloads במסוף Google Cloud .
כדי לראות את השימוש ב-GPU בעומס העבודה:
-
נכנסים לדף Workloads במסוף Google Cloud .
כניסה לדף Workloads - בוחרים עומס עבודה.
בלוח הבקרה Workloads מוצגים תרשימים של השימוש בזיכרון ה-GPU והקיבולת שלו, ושל דיוטי סייקל (Duty cycle) ב-GPU.
צפייה במדדים של NVIDIA Data Center GPU Manager (DCGM)
אפשר לאסוף ולהציג חזותית מדדים של NVIDIA DCGM באמצעות השירות המנוהל של Google Cloud ל-Prometheus. באשכולות Autopilot, GKE מתקין את הדרייברים. במקרים של אשכולות Standard, צריך להתקין את מנהלי ההתקנים (דרייברים) של NVIDIA.
הוראות לפריסת חבילת DCGM בניהול GKE זמינות במאמר איסוף מדדים של NVIDIA Data Center GPU Manager (DCGM) והצגתם.
מדדי בריאות של צמתים ושל JobSet לעומסי עבודה של GPU
בנוסף למדדים של DCGM, אתם יכולים להשתמש במדדים הבאים כדי לעקוב אחרי התקינות והביצועים של עומסי העבודה של ה-GPU, במיוחד כשמריצים אותם כ-JobSets.
מדדים של JobSet
המדדים הבאים חלים על מערכי משימות (JobSet) של GPU ו-TPU שיש להם משימה אחת משוכפלת:
kubernetes.io/jobset/times_between_interruptionskubernetes.io/jobset/times_to_recoverkubernetes.io/jobset/uptime
מידע נוסף על מדדי המערכת האלה זמין במאמר בנושא מדדי Kubernetes.
אפשר גם להשתמש בלוח הבקרה JobSet במסוף Google Cloud כדי להציג באופן חזותי את עומסי העבודה של ה-GPU ולעקוב אחריהם:
מדדי הבריאות של הצומת
המדדים הבאים ברמת הצומת רלוונטיים לכל הצמתים, כולל אלה עם מעבדי GPU:
-
kubernetes.io/node/status_condition: המדד הזה דורש GKE גרסה 1.32.1-gke.1357001 ואילך.
מדדים של הפרעה בצומת והפרעה במאגר צמתים חלים גם על צמתים שאינם TPU.
Kube-state-metrics ל-JobSets
אפשר להשתמש ב-kube-state-metrics ל-JobSets עם יחידות GPU. כדי לאסוף את המדדים האלה, צריך להשתמש ב-GKE בגרסה 1.32.1-gke.1357001 ואילך. מידע נוסף זמין במאמרי העזרה בנושא מדדים של JobSet.
טיפול בשיבושים בגלל תחזוקת צמתים
הצמתים של GKE שמארחים את יחידות ה-GPU כפופים לאירועי תחזוקה או לשיבושים אחרים שעלולים לגרום לסגירת הצומת. באשכולות GKE שמישור הבקרה שלהם פועל בגרסה 1.29.1-gke.1425000 ואילך, אפשר לצמצם את ההפרעות בעומסי העבודה על ידי הגדרת GKE להפסקת עומסי העבודה בצורה מסודרת.
כדי להבין, להגדיר ולעקוב אחרי אירועי שיבוש שעשויים להתרחש בצמתי GKE שמריצים עומסי עבודה של AI/ML, אפשר לעיין במאמר ניהול שיבושים בצמתי GKE עבור מעבדי GPU ו-TPU.