אופטימיזציה של עומסי עבודה של AI ולמידת מכונה באמצעות Google Cloud Managed Lustre

Last reviewed 2025-08-21 UTC

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

‫Managed Lustre היא מערכת קבצים מקבילה (PFS) מתמשכת ומנוהלת באופן מלא Google Cloudשמבוססת על EXAScaler Lustre של DDN. ‫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 כדי לבצע אופטימיזציה של הביצועים של עומס עבודה של אימון מודל ועומס עבודה של הצגת מודל:

ארכיטקטורה שמשתמשת ב-Managed Lustre כדי לבצע אופטימיזציה של הביצועים של עומס עבודה של אימון מודל ועומס עבודה של הגשת מודל.

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

  • אשכול Google Kubernetes Engine‏ (GKE):‏ GKE מנהל את המארחים של המחשוב שבהם מתבצעים תהליכי האימון וההפעלה של מודלים של AI ו-ML. ‫GKE מנהל את התשתית הבסיסית של האשכולות, כולל מישור הבקרה, הצמתים וכל רכיבי המערכת.
  • ‫Kubernetes Scheduler: מישור הבקרה של 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): יחידות GPU ו-TPU הן מאיצי מכונה מיוחדים שמשפרים את הביצועים של עומסי העבודה של ה-AI וה-ML. כדי להבטיח יעילות ותאימות אופטימליות, מומלץ להשתמש באותו סוג של מאיץ לכל עומס העבודה של ה-AI ולמידת המכונה. מידע נוסף על בחירת סוג המעבד המתאים מופיע בהמשך המאמר בקטע אפשרויות של מאיצים.
  • ‫Managed Lustre: ‫Managed Lustre מאיץ את האימון של AI ו-ML ואת ההצגה שלהם על ידי מתן PFS מתמשך עם ביצועים גבוהים, שעבר אופטימיזציה לזמן אחזור נמוך ולתפוקה גבוהה. בהשוואה לשימוש ב-Cloud Storage בלבד, שימוש ב-Managed Lustre מקצר משמעותית את זמן האימון ומשפר את מהירות התגובה של המודלים במהלך ההצגה. השיפורים האלה מורגשים במיוחד בעומסי עבודה תובעניים שדורשים גישה מהירה ועקבית לנתונים משותפים.
  • ‫Cloud Storage FUSE: ‫Cloud Storage FUSE מספק אחסון מתמשך וחסכוני לעומסי העבודה שלכם ב-AI וב-ML. ‫Cloud Storage משמש כמאגר מרכזי של מערכי נתונים לא מעובדים לאימון, נקודות ביקורת של מודלים וגיבויים של מודלים. השימוש ב-Cloud Storage עוזר להבטיח עמידות של הנתונים, זמינות לטווח ארוך וחסכוניות בנתונים שלא נמצאים בשימוש פעיל בחישובים.

עומס עבודה של אימון

בארכיטקטורה שלמעלה, אלה השלבים בזרימת הנתונים במהלך האימון של המודל:

  1. העלאת נתוני אימון ל-Cloud Storage: אתם מעלים נתוני אימון לקטגוריה של Cloud Storage, שמשמשת כמאגר מרכזי מאובטח וניתן להרחבה, וכמקור אמת.
  2. העתקת נתונים אל Managed Lustre: קורפוס נתוני האימון מועבר על ידי ייבוא נתונים למופע Managed Lustre מ-Cloud Storage. העברת נתוני האימון מאפשרת לכם לנצל את היכולות של מערכת הקבצים של Managed Lustre, שהיא מערכת קבצים בעלת ביצועים גבוהים, כדי לבצע אופטימיזציה של מהירויות טעינת הנתונים ועיבוד הנתונים במהלך אימון המודל.
  3. הפעלת משימות אימון ב-GKE: תהליך אימון המודל מופעל בצמתי GKE. שימוש ב-Managed Lustre כמקור הנתונים במקום טעינת נתונים מ-Cloud Storage ישירות מאפשר לצמתי GKE לגשת לנתוני האימון ולטעון אותם במהירות גבוהה יותר ועם זמן אחזור נמוך יותר. בנוסף, Managed Lustre מאפשר לקצר את הזמן עד להתחלת ההעברה של הבייט הראשון, כפי שנמדד על ידי המהירות שבה מגיע בייט התגובה הראשון (TTFB). השימוש ב-Managed Lustre עוזר לקצר את זמני טעינת הנתונים ולהאיץ את תהליך האימון הכולל, במיוחד כשמדובר במערכי נתונים גדולים עם קבצים קטנים לקריאה ומודלים מורכבים. בהתאם לדרישות של עומס העבודה, אפשר להשתמש במעבדי GPU או TPU. מידע על בחירת סוג מעבד מתאים מופיע בהמשך המאמר בקטע אפשרויות של מאיצים.
  4. שמירת נקודות ביקורת של ההכשרה ב-Managed Lustre: במהלך תהליך ההכשרה, נקודות הביקורת נשמרות ב-Managed Lustre על סמך מדדים או מרווחי זמן שאתם מגדירים. נקודות הבדיקה מתעדות את מצב המודל במרווחי זמן קבועים. אפשר לייצא את נקודות הבדיקה ל-Cloud Storage כדי לאחסן אותן לטווח ארוך.

עומס עבודה של שרת

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

  1. טעינת המודל לצורך מילוי בקשות: כשהמודל מוכן לפריסה, GKE Pods טוענים את המודל שאומן ממופע Managed Lustre לצמתים שממלאים בקשות. אם למכונת Managed Lustre שבה השתמשתם במהלך האימון יש קיבולת IOPS מספקת, והיא נמצאת באותו אזור כמו המאיצים שלכם, תוכלו להשתמש באותה מכונת Managed Lustre כדי להפעיל את המודל. שימוש חוזר במכונה של Managed Lustre מאפשר שיתוף יעיל של משאבים בין אימון לבין הצגת מודלים. כדי לשמור על ביצועים אופטימליים ועל תאימות, צריך להשתמש באותו סוג של מעבד GPU או TPU שבחרתם לצמתים של GKE לצורך הצגת מודלים.
  2. בקשת הסקה: משתמשי האפליקציה שולחים בקשות הסקה דרך נקודות הקצה של השרת. הבקשות האלה מופנות לשירות Cloud Load Balancing. ‫Cloud Load Balancing מפיץ את הבקשות הנכנסות בין קונטיינרים שממלאים בקשות באשכול GKE. החלוקה הזו מבטיחה שאף קונטיינר לא יהיה עמוס מדי, ושהבקשות יעובדו ביעילות.
  3. הצגת בקשות להסקת מסקנות: כשמתקבלת בקשה להסקת מסקנות, צמתי המחשוב ניגשים למודל שנטען מראש כדי לבצע את החישובים הדרושים וליצור תחזית.
  4. העברת התגובה: קונטיינרים להצגת מודעות שולחים את התגובות בחזרה דרך 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 שנועדו במיוחד להבנה ולעיבוד של נתונים מבוססי-טקסט. מודלי שפה גדולים מאומנים לפי מערכי נתונים עצומים של טקסטים, מה שמאפשר להם לבצע מגוון משימות, כולל תרגום אוטומטי, מענה לשאלות וסיכום טקסט. כדי לאפשר אימון יעיל ועיבוד באצווה, למודל ה-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 כדי לבצע פריסה באמצעות התוכנית הראשונית המנוהלת של Lustre.

אפשרויות של מאיץ

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

Google Cloud

סקירה כללית של עקרונות והמלצות בנושא ארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloudמופיעה בפרספקטיבה של AI ו-ML ב-Well-Architected Framework.

אבטחה, פרטיות ותאימות

בקטע הזה מפורטים שיקולים לגבי עומסי העבודה של AI ולמידת מכונה ב-Google Cloud שעומדים בדרישות האבטחה, הפרטיות והתאימות שלכם.

אבטחת SSH

כדי לשפר את בקרת הגישה לאפליקציות שפועלות ב-GKE, אפשר להשתמש בשרת proxy לאימות זהויות (IAP). ‫IAP משתלב עם משאב GKE Ingress ועוזר לוודא שרק משתמשים מאומתים עם התפקיד הנכון בניהול הזהויות והרשאות הגישה (IAM) יכולים לגשת לאפליקציות. מידע נוסף זמין במאמרים בנושא הפעלת IAP ב-GKE ובקרת גישה באמצעות IAM.

הצפנת נתונים

כברירת מחדל, הנתונים ב-GKE, כולל נתונים שמאוחסנים במופע Managed Lustre המנוהל, מוצפנים במצב מנוחה ובזמן ההעברה באמצעות Google-owned and Google-managed encryption keys. כדי להוסיף שכבת אבטחה למידע אישי רגיש, אתם יכולים להצפין את הנתונים בשכבת האפליקציה באמצעות מפתח שנמצא בבעלותכם ומנוהל על ידי Cloud Key Management Service‏ (Cloud KMS). מידע נוסף זמין במאמר בנושא הצפנת סודות בשכבת האפליקציה.

אם אתם משתמשים באשכול GKE Standard, תוכלו להשתמש ביכולות הנוספות הבאות להצפנת נתונים:

בידוד נתונים

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

שיקולי אבטחה נוספים

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

מידע על אבטחת הפרטיות של הנתונים זמין במאמרים סקירה כללית על Sensitive Data Protection ובדיקת אחסון ומסדי נתונים למידע אישי רגיש. Google Cloud

עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security (נקודת מבט על AI ו-ML: אבטחה) ב-Well-Architected Framework.

אמינות

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

עמידות בפני הפסקות חשמל בתשתית

במצב הפעולה Autopilot שבו נעשה שימוש בארכיטקטורה הזו,‏ GKE מספק את יכולות האמינות המובנות הבאות:

  • עומס העבודה משתמש באשכול GKE אזורי. רמת הבקרה וצמתי העובדים מפוזרים על פני שלושה אזורים שונים באזור. עומסי העבודה שלכם חסינים מפני הפסקות חשמל באזור. ל-GKE אזורי יש זמן פעולה תקינה גבוה יותר בהסכם רמת השירות (SLA) מאשר ל-GKE אזורי.
  • לא צריך ליצור צמתים או לנהל מאגרי צמתים. ‫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 מבצע אופטימיזציה של יעילות התשתית של האשכול על סמך דרישות עומס העבודה. כדי לשלוט בעלויות, לא צריך לעקוב כל הזמן אחרי ניצול המשאבים או לנהל את הקיבולת.

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

ניהול המשאבים

כדי לבצע אופטימיזציה של העלות והביצועים באמצעות ניהול יעיל, משתמשים ב-Dynamic Workload Scheduler. מנהל עומסי עבודה דינמי הוא כלי לניהול משאבים ולתזמון משימות, שעוזר לשפר את הגישה למאיצי AI (GPU ו-TPU). הכלי Dynamic Workload Scheduler מתזמן את כל המאיצים בו-זמנית, ויכול לפעול בשעות שבהן העומס נמוך עם ניהול מוגדר של קיבולת המאיצים. תזמון אסטרטגי של משימות ב-Dynamic Workload Scheduler עוזר למקסם את השימוש במאיצים, לצמצם את זמן ההמתנה ולבצע אופטימיזציה של ההוצאות על הענן.

ניצול משאבים

כדי למקסם את ניצול המשאבים, כדאי להשתמש במופע אחד של Managed Lustre לאימון ולשרת. איחוד של עומסי עבודה של אימון והפעלה במופע יחיד של Managed Lustre מצמצם את העלויות על ידי ביטול תשתית מיותרת ופישוט של ניהול המשאבים. עם זאת, יכול להיות שיהיה מאבק על משאבים אם שני עומסי העבודה דורשים תפוקה גבוהה. אם יש IOPS פנויים אחרי האימון, אפשר להשתמש באותו מופע כדי להאיץ את טעינת המודל לצורך מילוי בקשות. אפשר להשתמש ב-Cloud Monitoring כדי לוודא שהקצאתם מספיק משאבים כדי לעמוד בדרישות שלכם לגבי קצב העברת הנתונים.

כדי לצמצם את עלויות האחסון, אחרי האימון והשמירה של נקודות ביקורת, מייצאים את הנתונים ממופע Managed Lustre לסוג אחסון (storage class) ב-Cloud Storage בעלות נמוכה יותר. ייצוא הנתונים ל-Cloud Storage מאפשר גם להשמיד וליצור מחדש מופעים של Managed Lustre לפי הצורך בעומס העבודה.

כדי לעזור לכם לשלוט בעלויות של הקטגוריה ב-Cloud Storage, מומלץ להפעיל ניהול מחזור חיים של אובייקטים או סיווג אוטומטי. ניהול מחזור החיים של אובייקטים מעביר באופן אוטומטי נתונים ישנים או נתונים שהשימוש בהם נמוך לסוגי אחסון (storage class) זולים יותר, או מוחק את הנתונים, על סמך הכללים שאתם מגדירים. התכונה סיווג אוטומטי מעבירה נתונים בין סוגי אחסון (storage classes) על סמך דפוסי הגישה שלכם. השימוש בניהול מחזור חיים של אובייקטים או בסיווג אוטומטי עוזר להבטיח שסוג האחסון (storage class) יהיה הכי משתלם לשימוש בנתונים, כי הוא מצמצם את ההוצאות ועוזר למנוע עמלות לא צפויות על אחזור נתונים.

שיקולי עלות נוספים

עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework. מידע על אופטימיזציה של עלויות ב-GKE זמין במאמר שיטות מומלצות להרצת אפליקציות Kubernetes שעברו אופטימיזציה של עלויות ב-GKE.

מצוינות תפעולית

בקטע הזה מוסבר איך לתכנן תשתית לזרימת העבודה של AI ו-ML, כדי שתוכלו להפעיל אותה ביעילות.

ניהול מודלים

כדי לעקוב אחרי ארטיפקטים של מודלים ולנהל אותם, כולל קבצים בינאריים ומטא-נתונים, אפשר להשתמש בModel Registry ב-Gemini Enterprise Agent Platform. כך תוכלו לאחסן, לארגן ולפרוס גרסאות של מודלים בצורה חלקה.

כדי לשפר את אמינות המודל, כדאי להטמיע את Model Monitoring ב-Gemini Enterprise Agent Platform כדי לזהות סחף בנתונים, לעקוב אחרי הביצועים ולזהות אנומליות בסביבת הייצור.

התאמה אוטומטית לעומס (autoscaling) באשכול GKE

ב-Autopilot clusters, אין צורך להקצות או לנהל node pools. מאגרי הצמתים מוקצים באופן אוטומטי באמצעות הקצאת צמתים אוטומטית (NAP), והם מותאמים באופן אוטומטי לדרישות של עומסי העבודה.

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

כשמשתמשים במידרוג האוטומטי של אשכולות GKE, לא מפעילים מידרוג אוטומטי של Compute Engine לקבוצות של מופעים מנוהלים (MIG) בצמתים של האשכול. המידרוג האוטומטי של אשכול GKE נפרד מהמידרוג האוטומטי של Compute Engine. הכלי להתאמה אוטומטית לעומס באשכול GKE מיועד להתאמת עומס העבודה על ידי ניתוח של ניצול המשאבים באשכול GKE, כולל קבוצות ה-MIG הבסיסיות. שימוש בשני כלי ההתאמה האוטומטית יכול להוביל להחלטות סותרות לגבי שינוי הגודל. מידע נוסף זמין במאמר בנושא סביב גידול אוטומטי של אשכול 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. ההנחיות שבקטע הזה לא מקיפות את כל האפשרויות. למידע נוסף על אופטימיזציה של הביצועים בסביבת 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 גם לאימון וגם ליצירת נקודות ביקורת. הגישה הזו עוזרת להשתמש במשאבים בצורה יעילה, ומקטינה את העלות הכוללת של משאבי ה-GPU, כי היא מאפשרת לבצע את האימון ואת יצירת נקודות הביקורת במהירות האפשרית. כדי להשיג יצירת נקודות ביקורת מהירה, אפשר להפעיל יצירת נקודות ביקורת אסינכרונית מבוזרת. מכיוון ש-Managed Lustre הוא מתמשך, אפשר לאחסן את נקודות הבדיקה באותה מכונה. כדי לבצע אופטימיזציה נוספת של העלויות ולאחסן נתונים לטווח ארוך, כדאי לייצא את נקודות הבדיקה לקטגוריה של Cloud Storage.

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

כדי להשיג ביצועים אופטימליים במהלך הצגת המודעות, צריך לצמצם את הזמן שלוקח לטעון את המודלים לזיכרון. ‫Managed Lustre מציע תפוקה גבוהה לכל מכונה וירטואלית של יותר מ-20GB לשנייה, מה שמספק תפוקה גבוהה של צבירת אשכולות. היכולת הזו יכולה לעזור לכם לצמצם את זמני הטעינה של המודלים באלפי מכונות וירטואליות. כדי לעקוב אחרי מדדים מרכזיים שיעזרו לכם לזהות צווארי בקבוק, כדאי להשתמש ב-Cloud Monitoring ולוודא שאתם פורסים קיבולת מספקת, כי הביצועים משתפרים ככל שקיבולת האחסון גדולה יותר.

מיקום משאבים

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

  • להדרכה ולנקודות ביקורת: כדי לקבל תוצאות אופטימליות, כדאי לפרוס את הלקוחות ואת מכונות Managed Lustre באותו אזור. המיקום המשותף הזה מצמצם את זמני העברת הנתונים וממקסם את השימוש ברוחב הפס של הכתיבה ב-Managed Lustre.
  • לצורך הצגת נתונים: למרות שהמיקום המשותף עם לקוחות מחשוב באותו אזור הוא אידיאלי, יכול להיות שמספיק להשתמש במכונה אחת של Managed Lustre לכל אזור. הגישה הזו מאפשרת להימנע מעלויות נוספות שקשורות לפריסת כמה מופעים, ועוזרת למקסם את ביצועי המחשוב. עם זאת, אם אתם צריכים קיבולת או תפוקה נוספות, כדאי לפרוס יותר ממופע אחד בכל אזור.

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

שיקולי ביצועים נוספים

עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ולמידת מכונה מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.

פריסה

כדי ליצור מכונה ב-Managed Lustre ולטעון אותה, מומלץ להשתמש במודול Managed Lustre שזמין בCluster Toolkit. ערכת הכלים Cluster Toolkit היא ערכת כלים מודולרית שמבוססת על Terraform ומיועדת לפריסה של סביבות AI ו-ML שניתנות לשחזור ב-Google Cloud.

מידע על פריסה ידנית של Managed Lustre ב-GKE זמין במאמרים יצירת מכונה של Managed Lustre וקישור למכונה קיימת של Managed Lustre מ-Google Kubernetes Engine.

במאמר הגדרת רשת VPC מוסבר איך להגדיר רשת VPC ל-Managed Lustre.

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

שותפים ביצירת התוכן

מחבר: סמנתה הי | כותבת טכנית

תורמי תוכן אחרים: