במסמך הזה מוצגת ארכיטקטורת הפניה שמראה איך אפשר להשתמש ב-Google Cloud Managed Lustre כדי לשפר את הביצועים של עומסי עבודה של AI ו-ML שנפרסים ב-Google Kubernetes Engine (GKE). קהל היעד של המאמר הזה כולל אדריכלים ומומחים טכניים שמתכננים, מקצים ומנהלים את האחסון של עומסי העבודה של ה-AI ב- Google Cloud. ההנחה במאמר היא שאתם מכירים את המושגים של Kubernetes ואת מחזור החיים, התהליכים והיכולות של למידת מכונה.
Managed Lustre היא מערכת קבצים מקבילה (PFS) מנוהלת במלואה Google Cloudומתמשכת שמבוססת על DDN's EXAScaler Lustre. Managed Lustre הוא פתרון מומלץ לעומסי עבודה של אימון AI ונקודות בקרה. הוא יעיל במיוחד להעברת עומסי עבודה קיימים מ-Lustre או מפתרונות PFS אחרים. כדי למקסם את ניצול המשאבים, עומסי עבודה שמשתמשים ב-Managed Lustre לאימון צריכים להשתמש באותה מכונה גם להצגה ולהסקת מסקנות.
Managed Lustre הוא הפתרון המומלץ לעומסי עבודה של AI שעומדים בקריטריונים הבאים:
- נדרשת קיבולת אחסון בקנה מידה של PiB.
- גישה עם זמן אחזור קצר במיוחד (פחות מאלפית השנייה) וקצב העברת נתונים גבוה.
- מספקות פעולות קלט/פלט רבות לשנייה (IOPS).
היתרונות של Managed Lustre לעומסי עבודה של AI:
- עלות בעלות כוללת (TCO) נמוכה יותר לאימון: Managed Lustre עוזר לקצר את זמן האימון על ידי העברת נתונים יעילה לצומתי מחשוב. היכולת הזו עוזרת לצמצם את עלות הבעלות הכוללת (TCO) על אימון מודלים של AI ו-ML.
- הפחתת ה-TCO של ההצגה: Managed Lustre מספק יכולות ביצועים גבוהות שמאפשרות טעינה מהירה יותר של המודל והצגה אופטימלית של היקשים. היכולות האלה עוזרות להפחית את עלויות המחשוב ולשפר את ניצול המשאבים.
- ניצול יעיל של משאבים: בעזרת Managed Lustre אפשר לשלב בין יצירת נקודות ביקורת לבין אימון במכונה אחת. שיתוף המשאבים הזה עוזר למקסם את השימוש היעיל בקצב הקריאה והכתיבה במערכת אחסון אחת עם ביצועים גבוהים.
ארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה לדוגמה לשימוש ב-Managed Lustre כדי לבצע אופטימיזציה של הביצועים של עומס עבודה של אימון מודל ועומס עבודה של הצגת מודל:
עומסי העבודה שמוצגים בארכיטקטורה הקודמת מתוארים בפירוט בסעיפים הבאים. הארכיטקטורה הזו כוללת את הרכיבים הבאים:
- אשכול GKE: GKE מנהל את המארחים של המחשוב שבהם מתבצעים תהליכי האימון וההפעלה של מודלים של AI ו-ML. GKE מנהל את התשתית הבסיסית של האשכולות, כולל מישור הבקרה, הצמתים וכל רכיבי המערכת.
- מתזמן Kubernetes: מישור הבקרה של GKE מתזמן עומסי עבודה ומנהל את מחזור החיים, ההתאמה לעומס והשדרוגים שלהם.
- רשת של ענן וירטואלי פרטי (VPC): כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת.
- Cloud Load Balancing: בארכיטקטורה הזו, Cloud Load Balancing מפזר ביעילות בקשות הסקה נכנסות ממשתמשי האפליקציה למאגרי השרתים באשכול GKE. השימוש ב-Cloud Load Balancing עוזר להבטיח זמינות גבוהה, יכולת התאמה לעומס וביצועים אופטימליים לאפליקציית ה-AI וה-ML. מידע נוסף זמין במאמר הסבר על איזון עומסים ב-GKE.
- Graphics Processing Units (מעבדים גרפיים, GPUs) או Tensor Processing Units (מעבדי טנסור, TPUs): מעבדים גרפיים ומעבדי טנסור הם מאיצי מכונה מיוחדים שמשפרים את הביצועים של עומסי העבודה של AI ו-ML. כדי להבטיח יעילות ותאימות אופטימליות, השתמשו באותו סוג של מאיץ לכל עומס העבודה של ה-AI וה-ML. מידע נוסף על בחירת סוג המעבד המתאים זמין בהמשך המאמר בקטע אפשרויות של מאיצים.
- Managed Lustre: Managed Lustre מאיץ את האימון של AI ו-ML ואת ההצגה שלהם על ידי אספקת PFS מתמשך עם ביצועים גבוהים, שעבר אופטימיזציה לזמן אחזור נמוך ולתפוקה גבוהה. בהשוואה לשימוש ב-Cloud Storage בלבד, השימוש ב-Managed Lustre מקצר משמעותית את זמן האימון ומשפר את מהירות התגובה של המודלים במהלך הצגת המודעות. השיפורים האלה באים לידי ביטוי במיוחד בעומסי עבודה תובעניים שדורשים גישה מהירה ועקבית לנתונים משותפים.
- Cloud Storage FUSE: Cloud Storage FUSE מספק אחסון מתמשך וחסכוני לעומסי העבודה שלכם ב-AI וב-ML. Cloud Storage משמש כמאגר המרכזי של מערכי הנתונים הגולמיים לאימון, נקודות הבדיקה של המודלים וגיבויי המודלים. השימוש ב-Cloud Storage עוזר להבטיח את עמידות הנתונים, הזמינות שלהם לטווח ארוך וחיסכון בעלויות של נתונים שלא משתמשים בהם באופן פעיל בחישובים.
עומס עבודה של אימון
בארכיטקטורה הקודמת, אלה השלבים בתהליך הנתונים במהלך אימון המודל:
- העלאת נתוני אימון ל-Cloud Storage: אתם מעלים נתוני אימון לקטגוריה של Cloud Storage, שמשמשת כמאגר מרכזי מאובטח וניתן להרחבה, וכמקור אמת.
- העתקת נתונים ל-Managed Lustre: קורפוס נתוני האימון מועבר על ידי ייבוא נתונים למכונה של Managed Lustre מ-Cloud Storage. העברת נתוני האימון מאפשרת לכם לנצל את היכולות של מערכת הקבצים עם הביצועים הגבוהים של Managed Lustre, כדי לשפר את מהירות הטעינה והעיבוד של הנתונים במהלך אימון המודל.
- הרצת משימות אימון ב-GKE: תהליך אימון המודל פועל בצומתי GKE. שימוש ב-Managed Lustre כמקור הנתונים במקום טעינת נתונים מ-Cloud Storage ישירות מאפשר לצמתי GKE לגשת לנתוני האימון ולטעון אותם במהירות גבוהה יותר ועם זמן אחזור נמוך יותר. בנוסף, Managed Lustre מאפשר לקצר את הזמן עד לתחילת ההעברה של הבייט הראשון, כפי שנמדד לפי המהירות שבה מגיע בייט התגובה הראשון (TTFB). השימוש ב-Managed Lustre עוזר לקצר את זמני טעינת הנתונים ולהאיץ את תהליך האימון הכולל, במיוחד במערכי נתונים גדולים עם קובצי קריאה קטנים ומודלים מורכבים. בהתאם לדרישות של עומס העבודה, אתם יכולים להשתמש במעבדי GPU או TPU. בהמשך המאמר, בקטע אפשרויות למאיצים, מוסבר איך לבחור סוג מעבד מתאים.
- שמירת נקודות ביקורת של האימון ב-Managed Lustre: במהלך תהליך האימון, נקודות הביקורת נשמרות ב-Managed Lustre על סמך מדדים או מרווחי זמן שאתם מגדירים. נקודות הבדיקה מתעדות את מצב המודל במרווחי זמן קבועים. אפשר לייצא את נקודות הבדיקה ל-Cloud Storage כדי לשמור אותן לטווח ארוך.
עומס העבודה של המודל
בארכיטקטורה שלמעלה, אלה השלבים בזרימת הנתונים במהלך הצגת המודל:
- טעינת המודל לצורך מילוי בקשות: כשהמודל מוכן לפריסה, רכיבי ה-Pod ב-GKE טוענים את המודל שאומן ממופע Managed Lustre לצמתים שממלאים בקשות. אם למכונת Managed Lustre שבה השתמשתם במהלך האימון יש קיבולת IOPS מספקת, והיא נמצאת באותו אזור כמו המאיצים, תוכלו להשתמש באותה מכונת Managed Lustre כדי להפעיל את המודל. שימוש חוזר במכונה של Managed Lustre מאפשר שיתוף יעיל של משאבים בין אימון לבין הצגת מודלים. כדי לשמור על ביצועים אופטימליים ותאימות, צריך להשתמש באותו סוג של מעבד GPU או TPU שבחרתם לצמתים של GKE לצורך הצגת מודלים.
- בקשת הסקה: משתמשים באפליקציה שולחים בקשות הסקה דרך נקודות הקצה של ההגשה. הבקשות האלה מופנות לשירות Cloud Load Balancing. Cloud Load Balancing מפיץ את הבקשות הנכנסות בין קונטיינרים להצגת מודעות באשכול GKE. החלוקה הזו עוזרת לוודא שאף קונטיינר לא עמוס מדי, ושהבקשות מעובדות ביעילות.
- טיפול בבקשות להסקת מסקנות: כשמתקבלת בקשה להסקת מסקנות, צומתי המחשוב ניגשים למודל שנטען מראש כדי לבצע את החישובים הנדרשים וליצור חיזוי.
- העברת התגובה: הקונטיינרים של הצגת המודעות שולחים את התגובות בחזרה דרך Cloud Load Balancing. Cloud Load Balancing מנתב את התשובות בחזרה למשתמשי האפליקציה המתאימים, וכך מסתיים מחזור בקשת ההסקה.
המוצרים שהשתמשו בהם
ארכיטקטורת הייחוס הזו משתמשת במוצרי Google Cloud הבאים:
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . VPC כולל קישור בין רשתות VPC שכנות (peering), Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
- Cloud Load Balancing: מגוון של מאזני עומסים גלובליים ואזוריים, עם ביצועים גבוהים ויכולת התאמה לעומס.
- Google Kubernetes Engine (GKE): שירות Kubernetes שמאפשר לפרוס ולהפעיל אפליקציות בקונטיינרים בקנה מידה נרחב באמצעות התשתית של Google.
- Cloud Storage: מאגר אובייקטים ללא הגבלה ובעלות נמוכה, לסוגי נתונים שונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לו, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
- Google Cloud Managed Lustre: מערכת קבצים מקבילה ומנוהלת במלואה לשימוש ב-AI, במחשוב עתיר ביצועים (HPC) ובאפליקציות עתירות נתונים.
תרחישים לדוגמה
Managed Lustre הוא פתרון אידיאלי לעומסי עבודה של AI שדורשים קיבולת אחסון של PiB וגישה עם חביון נמוך (פחות ממילי-שנייה) עם תפוקה גבוהה ו-IOPS גבוה. בקטע הזה מפורטות דוגמאות לתרחישים לדוגמה שבהם אפשר להשתמש ב-Managed Lustre.
עיבוד ויצירת טקסט
מודלים גדולים של שפה (LLM) הם מודלים של AI שנועדו במיוחד להבין ולעבד נתונים מבוססי-טקסט. מודלי שפה גדולים מאומנים לפי מערכי נתונים עצומים של טקסטים, מה שמאפשר להם לבצע מגוון משימות, כולל תרגום אוטומטי, מענה לשאלות וסיכום טקסט. כדי לאפשר אימון יעיל ועיבוד ברצף (batch processing), מודל ה-LLM צריך גישה לקבוצות הנתונים בזמן אחזור קצר. Managed Lustre מצטיין באפליקציות עתירות נתונים, כי הוא מספק את התפוקה הגבוהה והחביון הנמוך שנדרשים לאימון ולהסקת מסקנות, וכתוצאה מכך אפליקציות מבוססות-LLM מגיבות מהר יותר.
עיבוד של תמונה או סרטון ברזולוציה גבוהה
אפליקציות של AI ו-ML או מודלים גנרטיביים מולטי-מודאליים שמעבדים תמונות או סרטונים ברזולוציה גבוהה, כמו ניתוח של הדמיה רפואית או מערכות נהיגה אוטונומיות, דורשים נפח אחסון גדול וגישה מהירה לנתונים. Managed Lustre מספק מערכת קבצים קבועה עם ביצועים גבוהים, שמאפשרת טעינת נתונים מהירה כדי להאיץ את ביצועי האפליקציה. לדוגמה, אפשר לאחסן ב-Managed Lustre כמויות גדולות של נתוני מטופלים, כמו סריקות MRI ו-CT, ולטעון במהירות את הנתונים לצומתי מחשוב כדי לאמן מודלים. הפונקציונליות הזו מאפשרת למודלים של AI ו-ML לנתח במהירות את הנתונים לצורך אבחון וטיפול.
חלופות עיצוב
בקטע הזה מוצגות גישות עיצוב חלופיות שאפשר לשקול עבור אפליקציית ה-AI וה-ML ב- Google Cloud.
חלופה לתשתית המחשוב
ארכיטקטורת העזר במסמך הזה משתמשת ב-GKE לעומסי העבודה של AI ו-ML. בהתאם לדרישות של עומס העבודה, אתם יכולים לפרוס מכונות של Managed Lustre ב-Compute Engine באמצעות Slurm. אנחנו ממליצים על הגישה הזו אם אתם צריכים לשלב קניין רוחני (IP) של AI קנייני בסביבה שניתנת להתאמה, ואם אתם צריכים גמישות ושליטה כדי לבצע אופטימיזציה של הביצועים לעומסי עבודה מיוחדים.
ב-Compute Engine יש לכם שליטה מפורטת יותר ברמת מערכת ההפעלה בהשוואה ל-GKE. כשמשתמשים ב-Compute Engine, אפשר:
- לבחור, להגדיר ולנהל את סביבת מערכת ההפעלה במכונות הווירטואליות, כדי לעמוד בדרישות ספציפיות של עומסי עבודה.
- אתם יכולים להתאים את התשתית לצרכים המדויקים שלכם, כולל בחירה של סוגי מכונות וירטואליות ספציפיות.
- כדי לשפר את הביצועים של עומסי העבודה ב-AI, אתם יכולים להשתמש בסדרת המכונות שמותאמות למאיצים.
Slurm הוא מנהל עומסי עבודה ומשאבים בקוד פתוח, שניתן להגדיר אותו בצורה נרחבת. Slurm מציע אפשרות יעילה לניהול עומסי עבודה של AI, ומאפשר לכם לשלוט בהגדרה ובניהול של משאבי המחשוב. כדי להשתמש בגישה הזו, אתם צריכים להיות מומחים בניהול Slurm ובניהול מערכת Linux. GKE מספק סביבת Kubernetes מנוהלת שמבצעת אוטומציה של ניהול האשכולות.
למידע על פריסת Slurm, קראו את המאמר פריסת אשכול HPC באמצעות Slurm. אפשר גם לפרוס באמצעות Cluster Toolkit עם Managed Lustre starter blueprint.
אפשרויות למאיצים
מאיצי מכונות הם מעבדים ייעודיים שנועדו להאיץ את החישובים שנדרשים לעומסי עבודה של AI ו-ML. אפשר לבחור GPU או TPU.
- מאיצי GPU מספקים ביצועים מצוינים למגוון רחב של משימות, כולל עיבוד גרפי, הדרכה של למידה עמוקה ומחשוב מדעי. Google Cloud יש מבחר רחב של מעבדי GPU שמתאימים למגוון רמות ביצועים ונקודות מחיר. למידע על מודלים של GPU ועל תמחור, אפשר לעיין במאמר בנושא תמחור של GPU.
- יחידות TPU הן מאיצי AI שתוכננו בהתאמה אישית ואופטימליים לאימון ולהסקת מסקנות של מודלים גדולים של AI. יחידות TPU הן אידיאליות למגוון תרחישי שימוש, כמו צ'אטבוטים, יצירת קוד, יצירת תוכן מדיה, דיבור סינתטי, שירותי ראייה, מנועי המלצות ומודלים להתאמה אישית. מידע נוסף על מודלים של TPU ותמחור זמין במאמר בנושא תמחור TPU.
חלופות לאחסון
אפשר להשתמש ב-Cloud Storage FUSE עם Rapid Cache לאימון, לנקודות בקרה ולעומסי עבודה של הצגת מודעות. Cloud Storage FUSE עם Rapid Cache הוא פתרון האחסון המומלץ להצגת נתונים ולהסקת מסקנות, כי הוא זול יותר וקל יותר להסקת מסקנות בכמה אזורים בהשוואה ל-Managed Lustre. כדי להבטיח את רמת הזמינות הגבוהה ביותר, מומלץ להשתמש ב-Cloud Storage FUSE עם Rapid Cache ובקטגוריה שמוגדרת למספר אזורים או לשני אזורים. ההגדרה הזו מאפשרת להשתמש במודלים של AI שאומנו בכמה אזורים. עם זאת, בהשוואה למכונות של Managed Lustre, ל-Cloud Storage FUSE יכול להיות קצב העברת נתונים נמוך יותר לכל מכונה וירטואלית. מידע נוסף מופיע במאמר בנושא אופטימיזציה של עומסי עבודה של AI ו-ML באמצעות Cloud Storage FUSE.
שיקולים בתכנון
כדי לתכנן פריסה של Managed Lustre שתבצע אופטימיזציה לאבטחה, לאמינות, לעלות, לתפעול ולביצועים של עומסי העבודה של AI ו-ML ב- Google Cloud, אתם יכולים להשתמש בהנחיות שבקטעים הבאים.
סקירה כללית של עקרונות ארכיטקטוניים והמלצות שספציפיות לעומסי עבודה של AI ו-ML ב- Google Cloudזמינה בפרספקטיבת ה-AI וה-ML ב-Well-Architected Framework.
אבטחה, פרטיות ותאימות
בקטע הזה מפורטים שיקולים לגבי עומסי העבודה של AI ולמידת מכונה ב-Google Cloud שעומדים בדרישות האבטחה, הפרטיות והתאימות שלכם.
אבטחת SSH
כדי לשפר את בקרת הגישה לאפליקציות שפועלות ב-GKE, אתם יכולים להשתמש בשרת proxy לאימות זהויות (IAP). IAP משתלב עם משאב ה-Ingress של GKE ועוזר לוודא שרק משתמשים מאומתים עם התפקיד הנכון בניהול הזהויות והרשאות הגישה (IAM) יכולים לגשת לאפליקציות. למידע נוסף, קראו את המאמרים הפעלת IAP ל-GKE ובקרת גישה באמצעות IAM.
הצפנת הנתונים
כברירת מחדל, הנתונים שלכם ב-GKE, כולל הנתונים שמאוחסנים במכונה של Managed Lustre, מוצפנים במצב מנוחה ובמעבר באמצעות Google-owned and Google-managed encryption keys. אם אתם צריכים לנהל את מפתחות ההצפנה שלכם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service כדי להצפין נתונים במצב מנוחה במכונה של Managed Lustre, ואתם יכולים להצפין סודות של GKE בשכבת האפליקציה. מידע נוסף מופיע במאמרים בנושא שימוש במפתחות הצפנה בניהול הלקוח והצפנת סודות בשכבת האפליקציה.
אם אתם משתמשים באשכול GKE Standard, אתם יכולים להשתמש ביכולות ההצפנה הנוספות הבאות:
- הצפנת נתונים בשימוש (כלומר, בזיכרון) באמצעות צמתים חסויים של Google Kubernetes Engine. למידע נוסף על התכונות, הזמינות והמגבלות של Confidential GKE Nodes, קראו את המאמר הצפנת נתוני עומסי עבודה בשימוש באמצעות Confidential GKE Nodes.
- אם אתם צריכים יותר שליטה על מפתחות ההצפנה שמשמשים להצפנת התנועה של Pods בין צומתי GKE, אתם יכולים להצפין את הנתונים במעבר באמצעות מפתחות שאתם מנהלים. מידע נוסף זמין במאמר הצפנת הנתונים במעבר ב-GKE באמצעות מפתחות הצפנה בניהול המשתמשים.
בידוד נתונים
כדי לשפר את האבטחה וההגנה על הנתונים, כדאי לאחסן את נתוני האימון במכונה נפרדת של Managed Lustre, ולא באותה מכונה שבה מאוחסנים נקודות הבדיקה והמודלים המאומנים. השימוש במכונות אחסון נפרדות מספק בידוד של הביצועים, משפר את האבטחה על ידי בידוד נתוני האימון ומשפר את ההגנה על הנתונים. אמנם רשימות בקרת גישה מאפשרות לנהל את האבטחה במכונה אחת, אבל שימוש במכונות נפרדות מספק גבול אבטחה חזק יותר.
שיקולי אבטחה נוספים
במצב אוטומטי, GKE מגדיר מראש את האשכול ומנהל את הצמתים בהתאם לשיטות המומלצות לאבטחה, כדי שתוכלו להתמקד באבטחה של עומסי עבודה ספציפיים. מידע נוסף זמין במאמרים יכולות האבטחה של GKE Autopilot ואבטחת Kubernetes מוכנה להפעלה עם GKE Autopilot.
מידע על אבטחת הפרטיות של הנתונים זמין במאמרים סקירה כללית על Sensitive Data Protection ובדיקת אחסון ומסדי נתונים של Google Cloud נתונים רגישים.
עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security ב-Well-Architected Framework.
אמינות
בקטע הזה מתוארים גורמים שצריך לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לבנות תשתית אמינה ולתפעל אותה לצורך פריסה אזורית ב- Google Cloud.
עמידות בפני הפסקות חשמל בתשתית
במצב אוטומטי שמשמש בארכיטקטורה הזו, GKE מספק את יכולות האמינות המובנות הבאות:
- עומס העבודה משתמש באשכול GKE אזורי. מישור הבקרה וצומתי העובדים מפוזרים בשלושה אזורים שונים בתוך אזור. עומסי העבודה שלכם חסינים מפני הפסקות חשמל באזור. לאשכולות GKE אזוריים יש הסכם רמת שירות (SLA) עם זמן פעולה תקינה ארוך יותר מאשר לאשכולות של אזורים ספציפיים.
- אין צורך ליצור צמתים או לנהל מאגרי צמתים. GKE יוצר אוטומטית את מאגרי הצמתים ומשנה את הגודל שלהם בהתאם לדרישות של עומסי העבודה.
כדי להגדיל את הזמינות של האפליקציה, אפשר להציג אותה מכמה אזורים על ידי פריסת מכונה ב-Managed Lustre בכל אזור.
תכנון קיבולת של אשכולות
כדי לוודא שיש מספיק קיבולת GPU זמינה כשצריך אותה להתאמה אוטומטית לעומס של אשכול GKE, אתם יכולים ליצור ולהשתמש במקומות שמורים. הזמנה מספקת קיבולת מובטחת באזור ספציפי למשאב מסוים. אפשר להגדיר הקצאה לפרויקט ספציפי או לשתף אותה בין כמה פרויקטים. אתם מחויבים על משאבים מוזמנים גם אם המשאבים לא הוקצו או לא נעשה בהם שימוש. מידע נוסף מופיע במאמר בנושא שימוש במשאבים שמורים באזור.
עמידות הנתונים
כדי לגבות ולשחזר עומסי עבודה ב-GKE, צריך להפעיל את הגיבוי ל-GKE בכל אשכול. הגיבוי ל-GKE שימושי לתוכנית התאוששות מאסון (DR), לפייפליינים של CI/CD, לשכפול עומסי עבודה ולתרחישי שדרוג.
אתם יכולים לבחור עומסי עבודה ספציפיים או את כל עומסי העבודה שאתם רוצים לגבות ולשחזר. אתם יכולים גם לגבות עומסי עבודה מאשכול אחד ולשחזר אותם באשכול אחר. כדי לצמצם את זמן ההשבתה של עומסי העבודה, אתם יכולים לתזמן את הגיבויים כך שיפעלו באופן אוטומטי, וכך לשחזר במהירות את עומסי העבודה במקרה של תקרית.
שיקולים נוספים בנושא אמינות
עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של עלויות ההגדרה וההפעלה של תהליך העבודה של AI ו-ML ב- Google Cloud.
רמות הביצועים של Managed Lustre
כשיוצרים מכונה של Managed Lustre, צריך לבחור רמת ביצועים. בוחרים את הרמה המתאימה לפי דרישות הביצועים והעלות של עומס העבודה.
מודל הקצאת הצמתים
במצב Autopilot, GKE מבצע אופטימיזציה של יעילות התשתית של האשכול על סמך דרישות עומס העבודה. כדי לשלוט בעלויות, אתם לא צריכים לעקוב כל הזמן אחרי ניצול המשאבים במעקב או לנהל את הקיבולת.
אם אתם יכולים לחזות את השימוש ב-CPU, בזיכרון ובנפח האחסון הנדרש הזמני של אשכול Autopilot, תוכלו לקבל הנחות תמורת התחייבות לשימוש. כדי להפחית את עלות ההפעלה של האפליקציה, אתם יכולים להשתמש בVM במודל Spot לצומתי GKE. המחיר של VM במודל Spot נמוך יותר מזה של מכונות וירטואליות רגילות, אבל אין הבטחה לגבי הזמינות שלהן.
ניהול המשאבים
כדי לייעל את העלויות והביצועים באמצעות ניהול יעיל, השתמשו במתזמן עומסי העבודה הדינמי. התזמון הדינמי של עומסי עבודה הוא כלי לניהול משאבים ולתזמון משימות, שעוזר לשפר את הגישה למאיצי AI (GPU ו-TPU). התזמון של כל המאיצים מתבצע בו-זמנית, והוא יכול לפעול בשעות שאינן שעות השיא, עם ניהול מוגדר של קיבולת המאיצים. בעזרת תזמון אסטרטגי של משימות, Dynamic Workload Scheduler עוזר למקסם את ניצול המאיצים, לצמצם את זמן חוסר הפעילות ולבצע אופטימיזציה של ההוצאות בענן.
ניצול משאבים
כדי למקסם את ניצול המשאבים, השתמשו במכונה אחת של Managed Lustre לאימון ולשירות. איחוד עומסי העבודה של האימון וההצגה למכונה אחת של Managed Lustre מצמצם את העלויות, כי הוא מבטל את הצורך בתשתית מיותרת ומפשט את ניהול המשאבים. עם זאת, יכול להיות מאבק על משאבים אם לשני עומסי העבודה יש דרישות גבוהות של תפוקה. אם יש פעולות קלט/פלט לשנייה (IOPS) פנויות אחרי האימון, שימוש באותו מכונה יכול להאיץ את טעינת המודל לצורך הצגה. אתם יכולים להשתמש ב-Cloud Monitoring כדי לוודא שהקציתם מספיק משאבים כדי לעמוד בדרישות שלכם לגבי קצב העברת הנתונים.
כדי לצמצם את עלויות האחסון, אחרי האימון והשמירה של נקודות ביקורת, מייצאים את הנתונים ממופע Managed Lustre לסוג אחסון (storage class) ב-Cloud Storage בעלות נמוכה יותר. ייצוא הנתונים ל-Cloud Storage גם מאפשר להשמיד וליצור מחדש מכונות של Managed Lustre לפי הצורך של עומס העבודה.
כדי לעזור לכם לשלוט בעלויות של הקטגוריה ב-Cloud Storage, מומלץ להפעיל ניהול מחזור חיים של אובייקטים או סיווג אוטומטי. ניהול מחזור החיים של אובייקטים מעביר באופן אוטומטי נתונים ישנים יותר או נתונים שמשתמשים בהם פחות לסוגי אחסון זולים יותר, או מוחק את הנתונים, בהתאם לכללים שהגדרתם. התכונה "סיווג אוטומטי" מעבירה נתונים בין סוגי אחסון (storage classes) בהתאם לתדירות הגישה שלכם. שימוש בניהול מחזור חיים של אובייקטים או בסיווג אוטומטי עוזר להבטיח את סוג האחסון המשתלם ביותר לשימוש שלכם בנתונים, על ידי צמצום ההוצאות ומניעת עמלות אחזור בלתי צפויות.
שיקולי עלות נוספים
במאמר נקודת מבט של AI ו-ML: אופטימיזציה של עלויות ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של עלויות שספציפיות לעומסי עבודה של AI ו-ML. במאמר שיטות מומלצות להרצת אפליקציות Kubernetes ב-GKE עם אופטימיזציה של עלויות מוסבר איך לבצע אופטימיזציה של העלויות ב-GKE.
מצוינות תפעולית
בקטע הזה מפורטות הנחיות שיעזרו לכם לתכנן תשתית לזרימת העבודה של ה-AI ולמידת המכונה (ML), שתוכלו להפעיל ביעילות תפעולית.
ניהול מודלים
כדי לעקוב אחרי ארטיפקטים של מודלים ולנהל אותם, כולל קבצים בינאריים ומטא-נתונים, אפשר להשתמש בModel Registry ב-Gemini Enterprise Agent Platform. כך תוכלו לאחסן, לארגן ולפרוס גרסאות של מודלים בצורה חלקה.
כדי לשפר את האמינות של המודל, כדאי להטמיע את Model Monitoring ב-Gemini Enterprise Agent Platform. הכלי הזה מאפשר לזהות שינויים בנתונים, לעקוב אחרי הביצועים ולזהות חריגות בסביבת הייצור.
התאמה אוטומטית לעומס (autoscaling) באשכול GKE
ב-Autopilot clusters, אין צורך להקצות או לנהל node pools. מאגרי הצמתים מוקצים באופן אוטומטי באמצעות הקצאת צמתים אוטומטית, והם מותאמים לעומס באופן אוטומטי כדי לעמוד בדרישות של עומסי העבודה.
באשכולות GKE Standard, המידרוג האוטומטי של האשכול משנה באופן אוטומטי את מספר הצמתים במאגר הצמתים בהתאם לדרישות של עומס העבודה. כדי לשלוט בהתנהגות של ההתאמה האוטומטית לעומס של המאגר, אפשר לציין את הגודל המינימלי והמקסימלי של מאגר הצמתים.
כשמשתמשים במידרוג האוטומטי של אשכולות GKE, לא מפעילים מידרוג אוטומטי של קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine עבור צמתי האשכול. המידרוג האוטומטי של אשכול GKE נפרד מהמידרוג האוטומטי של Compute Engine. התכונה "התאמה אוטומטית לעומס באשכולות של GKE" נועדה לשנות את קנה המידה של עומס העבודה על ידי ניתוח של ניצול המשאבים באשכול של GKE, כולל קבוצות ה-MIG הבסיסיות. שימוש בשני המנגנונים יכול להוביל להחלטות סותרות לגבי שינוי קנה המידה. למידע נוסף, קראו את המאמר מידע על התאמה אוטומטית לעומס (scaling) של אשכולות GKE.
מעקב אחר מדדים
כדי לזהות צווארי בקבוק, צריך לעקוב אחרי מדדים מרכזיים כמו זמן אחזור, שיעור שגיאות ושימוש במשאבים באמצעות Cloud Monitoring. Cloud Monitoring מספק נראות בזמן אמת כדי לעקוב אחרי דפוסי השימוש במשאבים ולזהות חוסר יעילות פוטנציאלי.
ניהול האחסון
כדי לאפשר ניהול נתונים אוטומטי על סמך השימוש בקטגוריית Cloud Storage, צריך להפעיל ניהול מחזור חיים של אובייקטים או סיווג אוטומטי. ניהול מחזור החיים של אובייקטים מאפשר להעביר באופן אוטומטי נתונים ישנים או נתונים שהשימוש בהם פחות נפוץ לסוגי אחסון (storage class) זולים יותר, או למחוק את הנתונים, על סמך כללים שאתם מגדירים. התכונה "סיווג אוטומטי" מעבירה נתונים בין סוגי אחסון (storage classes) בהתאם לתדירות הגישה שלכם. שימוש בניהול מחזור חיים של אובייקטים או ב-Autoclass עוזר להבטיח יישום עקבי של מדיניות בכל תשתית האחסון, ומצמצם את הסיכון לטעויות אנוש. כך אפשר לשפר את הביצועים ולחסוך בעלויות בלי התערבות ידנית.
שיקולים תפעוליים נוספים
עקרונות והמלצות למצוינות תפעולית שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Operational excellence ב-Well-Architected Framework.
אופטימיזציה של הביצועים
בקטע הזה מפורטות הנחיות שיעזרו לכם לשפר את הביצועים של תהליך העבודה של AI ו-ML ב- Google Cloud. ההנחיות שבקטע הזה לא מקיפות את כל האפשרויות. מידע נוסף על אופטימיזציה של הביצועים בסביבת Managed Lustre מופיע במאמר שיקולי ביצועים.
שיקולי הדרכה
כל מכונה וירטואלית מסוג A3 או A4 יכולה לספק 20GB/s, בערך 2.5GB/s לכל GPU, ממכונה של Managed Lustre. לפני תחילת האימון, צריך לבצע אחזור מראש של נתוני האימון מ-Cloud Storage ולייבא אותם אל Managed Lustre כדי למזער את זמן האחזור במהלך האימון. כדי למקסם את קצב העברת הנתונים של עומס העבודה של האימון, צריך להקצות את המכונה ב-Managed Lustre בהתאם לצרכים של קצב העברת הנתונים וקיבולת האחסון. לדוגמה, מופע של Managed Lustre בגודל 20TiB מספק תפוקה כוללת של 2.5GB/s עד 20GB/s בכל הלקוחות, בהתאם לרמת הביצועים שנבחרה. אם האימון דורש קצב העברת נתונים גבוה יותר, תצטרכו להגדיל את המכונה של Managed Lustre בהתאם.
שיקולים לגבי נקודות ביקורת
כדי לנצל את קצב העברת הנתונים הגבוה של Managed Lustre ולצמצם את זמן האימון, כדאי להשתמש ב-Managed Lustre גם לאימון וגם לנקודות הבדיקה. הגישה הזו עוזרת לנצל את המשאבים ביעילות ולהפחית את עלות הבעלות הכוללת (TCO) של משאבי ה-GPU, כי היא שומרת על מהירות גבוהה גם באימון וגם בנקודות הבדיקה. כדי להשיג יצירת נקודות בקרה מהירה, אפשר להפעיל יצירת נקודות בקרה אסינכרונית מבוזרת. מכיוון ש-Managed Lustre הוא שירות מתמיד, אתם יכולים לאחסן את נקודות הבדיקה באותו מכונה. כדי לבצע אופטימיזציה נוספת של העלויות ולאחסן את הנתונים לטווח ארוך, כדאי לייצא את נקודות הבדיקה לקטגוריה של Cloud Storage.
שיקולים שקשורים להצגת המודעות
כדי להשיג ביצועים אופטימליים במהלך הצגת המודעות, צריך לצמצם את הזמן שלוקח לטעון מודלים לזיכרון. Managed Lustre מציע תפוקה גבוהה לכל מכונה וירטואלית, של יותר מ-20GB לשנייה, וכך מספק תפוקה מצטברת גבוהה של האשכול. היכולת הזו יכולה לעזור לכם לצמצם את זמני הטעינה של המודלים באלפי מכונות וירטואליות. כדי לעקוב אחרי מדדים מרכזיים שיעזרו לכם לזהות צווארי בקבוק, כדאי להשתמש ב-Cloud Monitoring ולוודא שאתם פורסים קיבולת מספקת, כי הביצועים משתפרים ככל שקיבולת האחסון גדולה יותר.
מיקום משאבים
כדי למזער את זמן האחזור ולמקסם את הביצועים, צריך ליצור את מופע Managed Lustre באזור שקרוב מבחינה גיאוגרפית ללקוחות המחשוב של GPU או TPU. בארכיטקטורה לדוגמה שמתוארת במאמר הזה, הקונטיינרים של GKE ומערכת הקבצים נמצאים באותו אזור.
- לצורך אימון ויצירת נקודות ביקורת: כדי לקבל תוצאות אופטימליות, כדאי לפרוס את הלקוחות ואת מכונות Managed Lustre באותו אזור. המיקום המשותף הזה מצמצם את זמני העברת הנתונים וממקסם את השימוש בנפח הכתיבה של Managed Lustre.
- לצורך הצגה: למרות שמומלץ למקם את הלקוחות של המחשוב באותו אזור, יכול להיות שיספיק לכם מכונה אחת של Managed Lustre בכל אזור. הגישה הזו מאפשרת להימנע מעלויות נוספות שקשורות לפריסת כמה מופעים, ועוזרת למקסם את ביצועי המחשוב. עם זאת, אם אתם צריכים קיבולת או קצב נתונים נוספים, כדאי לפרוס יותר ממכונה אחת בכל אזור.
במאמר מיקומים נתמכים מפורטים האזורים והתחומים שנתמכים במכונות של Managed Lustre.
שיקולי ביצועים נוספים
לקבלת עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ו-ML, אפשר לעיין במאמר AI and ML perspective: Performance optimization (נקודת מבט על AI ו-ML: אופטימיזציה של ביצועים) ב-Well-Architected Framework.
פריסה
כדי ליצור מכונה ב-Managed Lustre ולטעון אותה, מומלץ להשתמש במודול Managed Lustre שזמין בCluster Toolkit. Cluster Toolkit היא ערכת כלים מודולרית מבוססת-Terraform שנועדה לפריסה של סביבות AI ו-ML שניתנות לשחזור ב-Google Cloud.
מידע על פריסה ידנית של Managed Lustre ב-GKE אפשר למצוא במאמרים יצירה של מופע Managed Lustre וגישה למופעים קיימים של Managed Lustre ב-GKE באמצעות דרייבר ה-CSI של Managed Lustre.
במאמר הגדרת רשת VPC מוסבר איך מגדירים רשת VPC ל-Managed Lustre.
המאמרים הבאים
- מידע נוסף על שיטות מומלצות להטמעת למידת מכונה ב- Google Cloud
- מידע נוסף על שירותי אחסון לעומסי עבודה של AI ולמידת מכונה ב-AI Hypercomputer
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברת: סמנתה הי | כותבת טכנית
תורמי תוכן אחרים:
- דין הילדברנד | מנהל טכני, משרד ה-CTO
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- שון דרינגטון | מנהל קבוצת מוצרים, אחסון