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

‫Managed Lustre מציע את היתרונות הבאים לעומסי עבודה של AI:

  • עלות הבעלות הכוללת (TCO) נמוכה יותר לאימון: Managed Lustre מקצרת את זמן האימון על ידי העברת נתונים לצמתי מחשוב בצורה יעילה. הפונקציונליות הזו עוזרת לצמצם את עלות הבעלות הכוללת (TCO) על אימון מודלים של AI ו-ML.
  • עלות כוללת נמוכה יותר להצגת מודלים: 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 טוענים את המודל שאומן ממופע 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 עם התוכנית הראשונית של Managed Lustre.

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

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

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

חלופות לאחסון

אפשר להשתמש ב-Cloud Storage FUSE עם Anywhere Cache לאימון, ליצירת נקודות ביקורת ולעומסי עבודה של הגשה. ‫Cloud Storage FUSE עם Anywhere Cache הוא פתרון האחסון המומלץ להסקת מסקנות ולהצגת נתונים, כי הוא זול יותר וקל יותר להסקת מסקנות בכמה אזורים בהשוואה ל-Managed Lustre. כדי להבטיח את רמת הזמינות הגבוהה ביותר, מומלץ להשתמש ב-Cloud Storage FUSE עם Anywhere 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 משתלב עם משאב 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, ולא בנקודות הבדיקה ובמודלים המאומנים. השימוש במופעי אחסון נפרדים מספק בידוד של הביצועים, משפר את האבטחה על ידי בידוד של נתוני האימון ומשפר את ההגנה על הנתונים. למרות שרשימות בקרת גישה מאפשרות לכם לנהל את האבטחה בתוך מופע יחיד, שימוש במופעים נפרדים מספק גבול אבטחה חזק יותר.

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

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

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

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

אמינות

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

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

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

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

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

תכנון הקיבולת של האשכול

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

עמידות הנתונים

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

ניהול מודלים

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

כדי לשפר את האמינות של המודל, כדאי להטמיע את Vertex AI Model Monitoring כדי לזהות סחף נתונים, לעקוב אחרי הביצועים ולזהות אנומליות בייצור.

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

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

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

כשמשתמשים במידרוג האוטומטי של אשכולות GKE, לא מפעילים התאמה אוטומטית לעומס (automatic scaling) של 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/s, מה שמספק תפוקה גבוהה של צבירת אשכולות. היכולת הזו יכולה לעזור לכם לצמצם את זמני טעינת המודלים באלפי מכונות וירטואליות. כדי לעקוב אחרי מדדים מרכזיים שיעזרו לכם לזהות צווארי בקבוק, כדאי להשתמש ב-Cloud Monitoring ולוודא שאתם פורסים קיבולת מספקת, כי הביצועים משתפרים ככל שקיבולת האחסון גדלה.

מיקום משאבים

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

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

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

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

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

פריסה

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

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

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

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

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

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

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