במסמך הזה בGoogle Cloud Well-Architected Framework: AI and ML perspective מפורטים עקרונות והמלצות שיעזרו לכם לבצע אופטימיזציה של הביצועים של עומסי העבודה של AI ו-ML ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון האופטימיזציה של הביצועים ב-Well-Architected Framework.
מערכות AI ו-ML מאפשרות לארגון שלכם להשתמש באוטומציה מתקדמת ולקבל החלטות מושכלות. הביצועים של המערכות האלה יכולים להשפיע ישירות על גורמים חשובים שמניעים את העסק, כמו הכנסות, עלויות ושביעות רצון לקוחות. כדי לממש את הפוטנציאל המלא של מערכות AI ו-ML, צריך לבצע אופטימיזציה של הביצועים שלהן בהתאם ליעדים העסקיים ולדרישות הטכניות שלכם. תהליך האופטימיזציה של הביצועים כולל לעיתים קרובות פשרות. לדוגמה, בחירת עיצוב שמספק את הביצועים הנדרשים עשויה להוביל לעלויות גבוהות יותר. ההמלצות במסמך הזה מתמקדות בשיפור הביצועים, ולא בהיבטים אחרים.
כדי לבצע אופטימיזציה של הביצועים של AI ו-ML, צריך לקבל החלטות לגבי גורמים כמו ארכיטקטורת המודל, הפרמטרים ואסטרטגיית האימון. כשמקבלים את ההחלטות האלה, חשוב לקחת בחשבון את מחזור החיים המלא של מערכות ה-AI וה-ML ואת סביבת הפריסה שלהן. לדוגמה, מודלים גדולים מאוד של שפה יכולים להשיג ביצועים טובים מאוד בתשתית אימון עצומה, אבל יכול להיות שהם לא ישיגו ביצועים טובים בסביבות עם מגבלות קיבולת, כמו מכשירים ניידים.
ההמלצות במסמך הזה ממופות לעקרונות הליבה הבאים:
- הגדרת יעדי ביצועים ושיטות הערכה
- הפעלת ניסויים לעיתים קרובות ומעקב אחריהם
- בנייה ואוטומציה של תשתית לאימון ולהצגת מודלים
- התאמת בחירות עיצוביות לדרישות הביצועים
- קישור מדדי ביצועים לבחירות עיצוב והגדרה
הגדרת יעדי ביצועים ושיטות הערכה
האסטרטגיה והיעדים העסקיים שלכם הם הבסיס לשימוש בטכנולוגיות AI ו-ML. תרגמו את היעדים העסקיים שלכם למדדי ביצועים מרכזיים (KPI) שאפשר למדוד. דוגמאות למדדי KPI: סך ההכנסות, העלויות, שיעור ההמרה, שיעור שימור הלקוחות או שיעור הנטישה, שביעות רצון הלקוחות ושביעות רצון העובדים.
הגדרת יעדים ריאליים
על פי השיטות המומלצות של Site Reliability Engineering (SRE), היעדים של שירות צריכים לשקף רמת ביצועים שעומדת בדרישות של לקוחות טיפוסיים. כלומר, יעדי השירות צריכים להיות ריאליים מבחינת היקף וביצועי התכונות.
יעדים לא ריאליים עלולים להוביל לבזבוז משאבים ולשיפור ביצועים מינימלי. מודלים שמספקים את הביצועים הכי טובים לא תמיד מובילים לתוצאות עסקיות אופטימליות. יכול להיות שיידרשו יותר זמן ועלות כדי לאמן ולהפעיל מודלים כאלה.
כשמגדירים יעדים, חשוב להבחין בין יעדי איכות ליעדי ביצועים ולתת להם עדיפות:
- איכות מתייחסת למאפיינים מובנים שקובעים את הערך של ישות. כך תוכלו להעריך אם הישות עומדת בציפיות ובסטנדרטים שלכם.
- ביצועים מתייחסים ליעילות ולאפקטיביות של פעולת ישות מסוימת או של מימוש המטרה שלשמה היא נועדה.
מהנדסי למידת מכונה יכולים לשפר את מדדי הביצועים של מודל במהלך תהליך האימון. Gemini Enterprise Agent Platform מספק שירות הערכה שמהנדסי למידת מכונה יכולים להשתמש בו כדי להטמיע מעקב סטנדרטי וחוזר אחר מדדי איכות. יעילות החיזוי של מודל מציינת את רמת הביצועים של המודל בסביבת ייצור או בזמן הסקת מסקנות. כדי לעקוב אחרי הביצועים, אפשר להשתמש ב-Cloud Monitoring וב-Model Monitoring ב-Gemini Enterprise Agent Platform. כדי לבחור מודלים מתאימים ולהחליט איך לאמן אותם, צריך לתרגם את היעדים העסקיים לדרישות טכניות שקובעות את מדדי האיכות והביצועים.
כדי להבין איך להגדיר יעדים ריאליים ולזהות מדדי ביצוע מתאימים, כדאי לעיין בדוגמה הבאה של מערכת לזיהוי הונאות שמבוססת על AI:
- יעד עסקי: במערכת לזיהוי הונאות, יעד עסקי לא ריאלי הוא זיהוי מדויק של 100% מהעסקאות ההונאות תוך ננו-שנייה אחת, בשיא התנועה של 100 מיליארד עסקאות בשנייה. יעד ריאלי יותר הוא לזהות עסקאות הונאה ברמת דיוק של 95% תוך 100 אלפיות השנייה, לגבי 90% מהתחזיות באינטרנט בשעות העבודה בארה"ב, בנפח שיא של מיליון עסקאות בשנייה.
- מדדי ביצועים: זיהוי הונאות הוא בעיה של סיווג. אפשר למדוד את האיכות של מערכת לזיהוי הונאות באמצעות מדדים כמו recall, ציון F1 ודיוק. כדי לעקוב אחרי הביצועים או המהירות של המערכת, אפשר למדוד את זמן האחזור של ההסקה. יכול להיות שזיהוי עסקאות שעלולות להיות הונאה חשוב יותר מדיוק. לכן, יעד ריאלי יכול להיות שיעור גבוה של שליפה עם זמן אחזור של p90 שנמוך מ-100 אלפיות השנייה.
מעקב אחר הביצועים בכל השלבים במחזור החיים של המודל
במהלך הניסויים והאימון, ואחרי פריסת המודל, חשוב לעקוב אחרי מדדי ה-KPI ולבדוק אם יש חריגות מהיעדים העסקיים. אסטרטגיית מעקב מקיפה עוזרת לכם לקבל החלטות חשובות לגבי איכות המודל וניצול המשאבים, כמו:
- להחליט מתי להפסיק עבודת אימון.
- קביעה אם הביצועים של מודל מסוים יורדים בסביבת הייצור.
- שיפור העלות וזמן היציאה לשוק של מודלים חדשים.
מעקב במהלך ניסויים ואימונים
המטרה של שלב הניסוי היא למצוא את הגישה הכוללת האופטימלית, את ארכיטקטורת המודל ואת ההיפרפרמטרים למשימה ספציפית. בדיקות עוזרות לכם לקבוע באופן איטרטיבי את ההגדרה שמספקת ביצועים אופטימליים ואת הדרך לאמן את המודל. המעקב עוזר לכם לזהות ביעילות תחומים פוטנציאליים לשיפור.
כדי לעקוב אחרי איכות המודל ויעילות האימון, מהנדסי למידת מכונה צריכים לבצע את הפעולות הבאות:
- אפשר לראות תצוגה חזותית של איכות המודל ומדדי הביצועים של כל ניסוי.
- הצגה ויזואלית של תרשימי מודלים ומדדים, כמו היסטוגרמות של משקלים והטיות.
- ייצוג חזותי של נתוני האימון.
- אלגוריתמים לאימון פרופילים בחומרה שונה.
כדי לעקוב אחרי ניסויים ואימונים, כדאי לפעול לפי ההמלצות הבאות:
| היבט הניטור | המלצה |
|---|---|
| איכות המודל | כדי להציג באופן חזותי ולעקוב אחרי מדדי ניסויים כמו דיוק, וכדי להציג באופן חזותי את ארכיטקטורת המודל או נתוני האימון, אפשר להשתמש ב-TensorBoard. TensorBoard הוא חבילת כלים בקוד פתוח שתואמת למסגרות למידת מכונה כמו: |
| מעקב אחר ניסויים | Experiments on Gemini Enterprise Agent Platform integrates with managed enterprise-grade Vertex AI TensorBoard instances to support experiment tracking. השילוב הזה מאפשר אחסון ושיתוף מהימנים של יומנים ומדדים. כדי לאפשר לכמה צוותים ולאנשים פרטיים לעקוב אחרי ניסויים, מומלץ להשתמש בעיקרון של הרשאות מינימליות. |
| יעילות בהדרכה ובניסויים | Agent Platform מייצאת מדדים אל Monitoring ואוספת נתוני טלמטריה ויומנים באמצעות סוכן יכולת צפייה. אפשר להציג את המדדים בצורה ויזואלית במסוף Google Cloud . אפשר גם ליצור לוחות בקרה או התראות על סמך המדדים האלה באמצעות Monitoring. מידע נוסף זמין במאמר מעקב אחרי מדדים של Agent Platform. |
| מעבדי GPU של NVIDIA | סוכן תפעול מאפשר מעקב אחרי GPU ב-Compute Engine ובמוצרים אחרים ש-Ops Agent תומך בהם. אפשר גם להשתמש בNVIDIA Data Center GPU Manager (DCGM), חבילת כלים לניהול ולמעקב אחרי יחידות GPU של NVIDIA בסביבות אשכולות. מעקב אחרי מעבדי GPU של NVIDIA שימושי במיוחד לאימון מודלים של למידה עמוקה ולהצגתם. |
| ניפוי באגים מעמיק | כדי לנפות באגים בבעיות בקוד האימון או בהגדרות של משימת אימון מנוהלת ב-Gemini Enterprise Agent Platform, אפשר לבדוק את קונטיינר האימון באמצעות סשן מעטפת אינטראקטיבי. |
מעקב במהלך ההצגה: חיזוי בסטרימינג
אחרי שמאמנים מודל ומייצאים אותו אל Model Registry ב-Gemini Enterprise Agent Platform, אפשר ליצור נקודת קצה (endpoint) של Agent Platform. נקודת הקצה הזו מספקת נקודת קצה (endpoint) של HTTP למודל.
Model Monitoring on Agent Platform עוזר לכם לזהות שינויים גדולים בחלוקה של תכונות קלט או פלט. אפשר גם לעקוב אחרי שיוך תכונות בסביבת הייצור בהשוואה להתפלגות בסיסית. ההתפלגות הבסיסית יכולה להיות קבוצת נתונים לאימון או להתבסס על התפלגויות קודמות של תנועת גולשים בייצור. שינוי בפיזור הצגת המודעות עשוי להצביע על ירידה בביצועים החזויים בהשוואה לביצועים בתקופת הלמידה.
- בחירת יעד מעקב: בהתאם לרגישות של תרחיש שימוש לשינויים בנתונים שמסופקים למודל, אפשר לעקוב אחרי סוגים שונים של יעדים: סחף של תכונות קלט, סחף של פלט ושיוך תכונות. התכונה 'מעקב אחרי מודלים' ב-Agent Platform v2 מאפשרת לעקוב אחרי מודלים שפורסים בפלטפורמת הגשה מנוהלת כמו Agent Platform, וגם בשירותים באירוח עצמי כמו Google Kubernetes Engine (GKE). בנוסף, כדי לעקוב אחרי הביצועים ברמה מפורטת, אפשר לעקוב אחרי פרמטרים ברמת המודל ולא ברמת נקודת הקצה.
- מעקב אחרי מודלים של AI גנרטיבי: כדי לשמור על יציבות ולצמצם את זמן האחזור, במיוחד בנקודות קצה של LLM, מומלץ להגדיר מערכת מעקב חזקה. מודלים של Gemini מספקים מדדים מובנים, כמו זמן עד לטוקן הראשון (TTFT), שאפשר לגשת אליהם ישירות בMetrics Explorer. כדי לעקוב אחרי קצב העברת הנתונים, זמן האחזור ושיעורי השגיאות בכלGoogle Cloud המודלים, אפשר להשתמש בלוח הבקרה של יכולת הצפייה במודלים.
מעקב במהלך ההצגה: חיזוי באצווה
כדי לעקוב אחרי חיזוי אצווה, אפשר להריץ משימות הערכה רגילות בשירות ההערכה של Agent Platform. Model Monitoring on Agent Platform supports monitoring of batch inferences. אם אתם משתמשים ב-Batch כדי להריץ את עומס העבודה של ההצגה, אתם יכולים לעקוב אחרי צריכת המשאבים באמצעות המדדים ב-Metrics Explorer.
אוטומציה של ההערכה לצורך שחזור ותקנון
כדי להעביר מודלים מאבות טיפוס למערכות ייצור אמינות, צריך תהליך הערכה סטנדרטי. התהליך הזה עוזר לכם לעקוב אחרי ההתקדמות בין האיטרציות, להשוות בין מודלים שונים, לזהות הטיה ולצמצם אותה, ולוודא שאתם עומדים בדרישות הרגולטוריות. כדי להבטיח שניתן יהיה לשחזר את התוצאות ולהתאים את התהליך לעומסים משתנים, צריך לבצע אוטומציה של תהליך ההערכה.
כדי לתקנן את תהליך ההערכה של ביצועי למידת המכונה ולהפוך אותו לאוטומטי, צריך לבצע את השלבים הבאים:
- הגדרת אינדיקטורים כמותיים ואיכותיים.
- תבחרו מקורות נתונים וטכניקות מתאימים.
- לייצר סטנדרטיזציה של צינור עיבוד הנתונים להערכה.
השלבים האלה מתוארים בקטעים הבאים.
1. הגדרת אינדיקטורים כמותיים ואיכותיים
מדדים מבוססי-מחשוב מחושבים באמצעות נוסחאות מספריות. חשוב לזכור שהמדדים של הפסד האימון עשויים להיות שונים ממדדי ההערכה שרלוונטיים ליעדים העסקיים. לדוגמה, מודל שמשמש לזיהוי הונאות בפיקוח עשוי להשתמש בהפסד אנטרופיה צולבת לאימון. עם זאת, כדי להעריך את ביצועי ההסקה, מדד רלוונטי יותר יכול להיות החזרה, שמציין את הכיסוי של עסקאות הונאה. Agent Platform מספקת שירות להערכת מדדים כמו recall, דיוק והשטח מתחת לעקומת הדיוק וה-recall (AuPRC). מידע נוסף זמין במאמר בנושא הערכת מודלים ב-Agent Platform.
אי אפשר לחשב באופן אובייקטיבי אינדיקטורים איכותיים, כמו רמת השפה או ערך הבידור של תוכן שנוצר על ידי AI. כדי להעריך את האינדיקטורים האלה, אפשר להשתמש באסטרטגיה LLM-as-a-judge או בשירותי תיוג אנושיים כמו Labelbox.
2. בחירת מקורות נתונים וטכניקות מתאימים
הערכה היא בעלת מובהקות סטטיסטית כשהיא מופעלת על נפח מינימלי מסוים של דוגמאות מגוונות. בוחרים את מערכי הנתונים והטכניקות שבהם רוצים להשתמש להערכות, באמצעות גישות כמו הבאות:
- קבוצת נתונים מוזהבת: דגימות נתונים מהימנות, עקביות ומדויקות שמשקפות את התפלגות ההסתברות של מודל בסביבת ייצור.
- LLM-as-a-judge: הערכת הפלט של מודל גנרטיבי באמצעות LLM. הגישה הזו רלוונטית רק למשימות שבהן מודל LLM יכול להעריך מודל.
- משוב מהמשתמשים: כדי לתכנן שיפורים עתידיים, כדאי לאסוף משוב ישירות מהמשתמשים כחלק מתנועת הייצור.
בהתאם לטכניקת ההערכה, לגודל ולסוג של נתוני ההערכה ולתדירות ההערכה, אפשר להשתמש ב-BigQuery או ב-Cloud Storage כמקורות נתונים, כולל בשירות ההערכה של Agent Platform.
- ב-BigQuery אפשר להשתמש בפקודות SQL כדי להריץ משימות של הסקת מסקנות, כמו עיבוד שפה טבעית ותרגום אוטומטי. מידע נוסף זמין במאמר סקירה כללית של פתרונות ספציפיים למשימות.
- Cloud Storage מספק פתרון אחסון חסכוני לקבוצות נתונים גדולות.
3. סטנדרטיזציה של צינור עיבוד הנתונים להערכה
כדי להפוך את תהליך ההערכה לאוטומטי, אפשר להשתמש בשירותים ובכלים הבאים:
- שירות ההערכה של Agent Platform: מספק פרימיטיבים מוכנים לשימוש כדי לעקוב אחרי ביצועי המודל כחלק ממחזור החיים של ה-ML ב-Agent Platform.
- שירות להערכת AI גנרטיבי: מאפשר להעריך כל מודל או אפליקציה גנרטיביים, ולהשוות את תוצאות ההערכה לשיקול הדעת וללקריטריונים שלכם. השירות הזה גם עוזר לכם לבצע משימות מיוחדות כמו הנדסת הנחיות, יצירה משופרת באמצעות אחזור (RAG) ואופטימיזציה של סוכני AI.
- הכלי האוטומטי להשוואה זה לצד זה (AutoSxS) של Agent Platform: תומך בהערכה מבוססת-מודל של זוגות.
- Kubeflow: מספק רכיבים מיוחדים להרצת הערכות של מודלים.
הפעלת ניסויים בתדירות גבוהה ומעקב אחריהם
כדי לבצע אופטימיזציה יעילה של ביצועי ה-ML, אתם צריכים פלטפורמה ייעודית, עוצמתית ואינטראקטיבית לניסויים. הפלטפורמה צריכה לכלול את היכולות הבאות:
- לסייע בפיתוח איטרטיבי, כדי שהצוותים יוכלו לעבור מרעיון לתוצאות מאומתות במהירות, באמינות ובקנה מידה.
- הצוותים יכולים למצוא בקלות את ההגדרות האופטימליות שבהן הם יכולים להשתמש כדי להפעיל משימות אימון.
- לספק גישה מבוקרת לנתונים, לתכונות ולכלים רלוונטיים כדי לבצע ניסויים ולעקוב אחריהם.
- תמיכה בשחזור ובמעקב אחר שושלת הנתונים.
התייחסות לנתונים כשירות
כדי לבודד עומסי עבודה ניסיוניים ממערכות ייצור ולהגדיר אמצעי אבטחה מתאימים לנכסי הנתונים, אפשר להשתמש בטכניקות הבאות:
| טכניקה | תיאור | יתרונות |
|---|---|---|
| בידוד משאבים | בידוד המשאבים של סביבות שונות
בפרויקטים נפרדים Google Cloud . לדוגמה, הקצאת משאבים לסביבות פיתוח, Staging וייצור בפרויקטים נפרדים כמו ml-dev, ml-staging ו-ml-prod. |
בידוד משאבים עוזר למנוע מעומסי עבודה ניסיוניים לצרוך משאבים שמערכות ייצור צריכות. לדוגמה, אם אתם משתמשים בפרויקט יחיד לניסויים ולייצור, יכול להיות שניסוי ינצל את כל יחידות ה-GPU הזמינות של NVIDIA A100 לאימון מנוהל של Agent Platform. הדבר עלול לגרום לשיבושים בהדרכה מחדש של מודל ייצור קריטי. |
| זהות ובקרת גישה | החלת העקרונות של אפס אמון והרשאות מינימליות ושימוש בחשבונות שירות ספציפיים לעומס העבודה. הענקת גישה באמצעות תפקידים מוגדרים מראש בניהול זהויות והרשאות גישה (IAM), כמו משתמש ב-Agent Platform (roles/aiplatform.user). |
הגישה הזו עוזרת למנוע פעולות מקריות או זדוניות שעלולות לפגוע בניסויים. |
| אבטחת רשת | בידוד תעבורת הרשת באמצעות רשתות של ענן וירטואלי פרטי (VPC) ואכיפת היקפים של אבטחה באמצעות VPC Service Controls. | הגישה הזו עוזרת להגן על מידע אישי רגיש ומונעת מתעבורת נתונים ניסיונית להשפיע על שירותי הייצור. |
| בידוד נתונים | אחסון נתונים ניסיוניים בקטגוריות נפרדות של Cloud Storage ובמערכי נתונים נפרדים ב-BigQuery. | בידוד הנתונים מונע שינוי לא מכוון של נתוני הייצור. לדוגמה, בלי בידוד נתונים, ניסוי עלול לשנות בטעות את ערכי התכונות בטבלה ב-BigQuery משותפת, מה שעלול להוביל לירידה משמעותית ברמת הדיוק של המודל בסביבת הייצור. |
מציידים את הצוותים בכלים המתאימים
כדי ליצור קבוצה מותאמת של כלים שיזרזו את כל מחזור החיים של הניסוי – החל מחיפוש נתונים ועד לאימון ולניתוח של המודל – אפשר להשתמש בטכניקות הבאות:
- יצירת אב טיפוס אינטראקטיבי: כדי לחקור נתונים במהירות, לבדוק השערות וליצור אב טיפוס של קוד, אפשר להשתמש ב-Colab Enterprise או במופעים מנוהלים של JupyterLab ב-Gemini Enterprise Agent Platform Workbench. מידע נוסף זמין במאמר בנושא בחירת פתרון למחברת.
- אימון מודלים שניתן להרחבה: הפעלת משימות אימון בשירות מנוהל שתומך באימון מבוזר ובמשאבי מחשוב שניתנים להרחבה, כמו יחידות GPU ו-TPU. הגישה הזו עוזרת לקצר את זמן ההכשרה מימים לשעות, ומאפשרת לבצע יותר ניסויים במקביל. מידע נוסף זמין במאמר בנושא שימוש ברכיבים מיוחדים לאימון.
- למידת מכונה בתוך מסד הנתונים: אימון מודלים ישירות ב-BigQuery ML באמצעות SQL. הטכניקה הזו עוזרת למנוע העברת נתונים ומאיצה את תהליך הניסויים עבור אנליסטים ומשתמשים שמתמקדים ב-SQL.
- מעקב אחרי ניסויים: יצירת היסטוריה של נתוני ניסויים שאפשר לחפש ולהשוות, על ידי רישום פרמטרים, מדדים וארטיפקטים לכל הרצה של ניסוי. למידע נוסף, אפשר לקרוא את המאמר בנושא יצירת מערכת לשושלת נתונים ומודלים.
- אופטימיזציה של AI גנרטיבי: כדי לשפר את הביצועים של אפליקציות AI גנרטיבי, צריך להתנסות בהנחיות, בבחירת מודלים ובכוונון עדין. כדי לנסח הנחיות במהירות, אפשר להשתמש ב-Agent Studio ב-Gemini Enterprise Agent Platform. כדי להתנסות במודלים בסיסיים (כמו Gemini) ולמצוא מודל שמתאים לתרחיש השימוש וליעדים העסקיים שלכם, אפשר להשתמש ב-Model Garden.
סטנדרטיזציה לשחזור ויעילות
כדי לוודא שהניסויים צורכים משאבים בצורה יעילה ומניבים תוצאות עקביות ומהימנות, כדאי להשתמש בגישות הבאות כדי לתקנן את הניסויים ולהפוך אותם לאוטומטיים:
- שימוש בקונטיינרים כדי להבטיח סביבות עקביות: אפשר לארוז את קוד האימון ואת התלויות כקונטיינרים של Docker. ניהול הקונטיינרים והצגתם באמצעות Artifact Registry. כך אפשר לשחזר בעיות במכונות שונות על ידי חזרה על ניסויים בסביבות זהות. פלטפורמת הסוכנים מספקת קונטיינרים מוכנים מראש לאימון ללא שרת.
- אוטומציה של תהליכי עבודה של למידת מכונה כצינורות עיבוד נתונים: אפשר לתזמן את תהליך העבודה של למידת המכונה מקצה לקצה כצינור עיבוד נתונים מקודד באמצעות צינורות עיבוד נתונים של Gemini Enterprise Agent Platform. הגישה הזו עוזרת לאכוף עקביות, להבטיח שניתן יהיה לשחזר את התוצאות ולעקוב באופן אוטומטי אחרי כל הארטיפקטים והמטא-נתונים ב-Vertex ML Metadata.
- הפיכת הקצאת המשאבים לאוטומטית באמצעות תשתית כקוד (IaC): הגדרה ופריסה של סביבות ניסוי סטנדרטיות באמצעות כלי IaC כמו Terraform. כדי לוודא שכל פרויקט עומד בסדרת הגדרות סטנדרטית לאבטחה, לרשת ולניהול, משתמשים במודולים של Terraform.
יצירה ואוטומציה של תשתית לאימון ולפריסה
כדי לאמן מודלים של AI ולהכניס אותם לשימוש בסביבת הייצור, צריך להגדיר פלטפורמה חזקה שתומכת בפיתוח, בפריסה ובהכנסה לשימוש בסביבת הייצור יעילים ואמינים. הפלטפורמה הזו מאפשרת לצוותים שלכם לשפר ביעילות את האיכות והביצועים של ההדרכה וההצגה לאורך זמן.
שימוש ברכיבים ייעודיים לאימון
פלטפורמת אימון אמינה עוזרת לשפר את הביצועים ומספקת גישה סטנדרטית לאוטומציה של משימות שחוזרות על עצמן במחזור החיים של למידת מכונה – מהכנת הנתונים ועד אימות המודל.
איסוף נתונים והכנה: כדי לאמן את המודל בצורה יעילה, צריך לאסוף ולהכין את הנתונים שנדרשים לאימון, לבדיקה ולאימות. יכול להיות שהנתונים מגיעים ממקורות שונים ושהם מסוגי נתונים שונים. בנוסף, צריך לעשות שימוש חוזר בנתונים רלוונטיים בין הרצות של אימון המודל ולשתף תכונות בין צוותים. כדי לשפר את היכולת לחזור על שלב איסוף הנתונים וההכנה שלהם, כדאי לפעול לפי ההמלצות הבאות:
- שיפור יכולת הגילוי של נתונים באמצעות Knowledge Catalog.
- ריכוז הנדסת התכונות בAgent Platform Feature Store.
- עיבוד מראש של נתונים באמצעות Dataflow.
הרצת אימון: כשמאמנים מודל, משתמשים בנתונים כדי ליצור אובייקט מודל. כדי לעשות את זה, צריך להגדיר את התשתית והתלות הנדרשות של קוד האימון. צריך גם להחליט איך לשמור את מודלי האימון, לעקוב אחרי התקדמות האימון, להעריך את המודל ולהציג את התוצאות. כדי לשפר את יכולת השחזור של האימון, כדאי לפעול לפי ההמלצות הבאות:
- פועלים לפי ההנחיות שבמאמר אוטומציה של הערכה לצורך שחזור ותקנון.
- כדי לשלוח משימות אימון בצומת עובד אחד או יותר בלי לנהל את ההקצאה או התלות של התשתית הבסיסית, משתמשים במשאב
CustomJobב-Agent Platform Managed Training. אפשר גם להשתמש במשאבCustomJobכדי להריץ משימות של כוונון היפר-פרמטרים. - אופטימיזציה של תפוקת התזמון באמצעות Dynamic Workload Scheduler או הזמנות ל-Agent Platform Managed Training.
- רושמים את המודלים במרשם המודלים ב-Gemini Enterprise Agent Platform.
תזמור אימון: פריסת עומסי עבודה של אימון כשלבים של פייפליין באמצעות Agent Platform Pipelines. השירות הזה מספק שירותים מנוהלים של Kubeflow ושל TFX. מגדירים כל שלב בצינור כרכיב שפועל במאגר. כל רכיב פועל כמו פונקציה, עם פרמטרים של קלט וארטיפקטים של פלט שהופכים לקלט של הרכיבים הבאים בצינור. כדי לייעל את היעילות של צינור המכירות, כדאי לעיין בהמלצות שבטבלה הבאה:
מטרה המלצות הטמעה של אוטומציה בסיסית. - משתמשים ברכיבי Kubeflow Pipelines.
- כדי ליצור עיצובים מתקדמים של צינורות, כמו שערים מותנים, אפשר להשתמש ב-Control Flows.
- משלבים את הידור צינור עיבוד הנתונים כחלק מתהליך ה-CI/CD.
- מריצים את צינור עיבוד הנתונים באמצעות Cloud Scheduler.
שיפור המהירות והיעילות. - כדי להגדיל את מהירות האיטרציות ולצמצם את העלויות, אפשר להשתמש במטמון הביצוע של צינורות Agent Platform Pipelines.
- מציינים את הגדרות המכונה לכל רכיב על סמך דרישות המשאבים של כל שלב.
הגברת החוסן. - כדי לשפר את העמידות מפני בעיות זמניות בלי שתצטרכו להתערב ידנית, אתם יכולים להגדיר ניסיונות חוזרים.
- כדי לזהות כשלים במהירות ולבצע איטרציות ביעילות, צריך להגדיר מדיניות כשל.
- כדי לטפל בכשלים, מגדירים התראות באימייל.
הטמעה של ניהול ומעקב. - כדי להתנסות בהגדרות שונות של מודלים או בהגדרות שונות של אימון, מוסיפים הרצות של צינורות לניסויים.
- מעקב אחרי יומנים ומדדים של צינורות עיבוד נתונים ב-Agent Platform.
- פועלים לפי ההמלצות במאמר מעקב אחר הביצועים בכל השלבים של מחזור החיים של המודל.
שימוש בתשתית ייעודית לחיזוי
כדי להפחית את העבודה הקשה שנדרשת לניהול התשתית ולפריסת המודלים, כדאי לבצע אוטומציה של תהליכי המשימות שחוזרים על עצמם. גישה ממוקדת-שירות מאפשרת לכם להתמקד במהירות ובקיצור הזמן להשגת ערך (TTV). כדאי לעיין בהמלצות הבאות:
| המלצה | שיטות |
|---|---|
| הטמעה של פריסה אוטומטית. |
|
| כדאי להשתמש בתכונות של שינוי גודל מנוהל. |
|
| אופטימיזציה של זמן האחזור והתפוקה בנקודות הקצה של Agent Platform. |
|
| אופטימיזציה של ניצול המשאבים. |
|
| אופטימיזציה של פריסת המודל. |
|
| מעקב אחרי הביצועים. |
|
התאמת בחירות העיצוב לדרישות הביצועים
כשאתם בוחרים עיצובים כדי לשפר את הביצועים, כדאי לבדוק אם הבחירות האלה תומכות בדרישות העסקיות שלכם או שהן בזבזניות ולא מועילות. כדי לבחור תשתית, מודלים והגדרות מתאימים, צריך לזהות צווארי בקבוק בביצועים ולהעריך איך הם קשורים למדדי הביצועים. לדוגמה, גם במאיצי GPU חזקים מאוד, יכולים להיווצר צווארי בקבוק בביצועים של משימות אימון. צווארי הבקבוק האלה יכולים להיגרם מבעיות קלט/פלט של נתונים בשכבת האחסון או ממגבלות ביצועים של המודל.
התמקדות בביצועים הוליסטיים של תהליך העבודה של למידת המכונה
ככל שהדרישות לאימון גדלות מבחינת גודל המודל וגודל האשכול, שיעור הכשלים ועלויות התשתית עשויים לעלות. לכן, העלות של כשל עשויה לגדול באופן ריבועי. אי אפשר להסתמך רק על מדדים קונבנציונליים של יעילות משאבים, כמו ניצול FLOPs של מודל (MFU). כדי להבין למה MFU לא יכול להיות מדד מספיק לביצועים הכוללים של אימון, כדאי לבדוק את מחזור החיים של משימת אימון טיפוסית. מחזור החיים מורכב מהתהליך המחזורי הבא:
- יצירת אשכול: הקצאת צמתים של עובדים.
- אתחול: האימון מאותחל בצמתי העובדים.
- הרצת אימון: המשאבים משמשים להעברה קדימה או אחורה.
- הפרעה: תהליך האימון מופרע במהלך יצירת נקודת ביקורת של המודל או בגלל קדימות של צומת עובד.
אחרי כל הפרעה, התהליך הקודם חוזר על עצמו.
שלב ההרצה של האימון מהווה חלק קטן ממחזור החיים של משימת ML. לכן, הניצול של צמתי העובדים בשלב ההרצה של האימון לא מצביע על היעילות הכוללת של העבודה. לדוגמה, גם אם שלב ההרצה של האימון מתבצע ביעילות של 100%, היעילות הכוללת עשויה להיות נמוכה אם יש הפרעות לעיתים קרובות או אם לוקח הרבה זמן לחדש את האימון אחרי הפרעות.
אימוץ ומעקב אחרי מדדי קצב העברת נתונים
כדי להבטיח מדידה ואופטימיזציה הוליסטיות של הביצועים, כדאי להפסיק להתמקד במדדים קונבנציונליים של יעילות המשאבים כמו MFU, ולהתחיל להתמקד בgoodput. המדד 'קצב העברת נתונים נטו' מתייחס לזמינות ולניצול של האשכולות ושל משאבי המחשוב, ועוזר למדוד את יעילות המשאבים בכמה שכבות.
המדדים של קצב העברת נתונים יעיל מתמקדים בהתקדמות הכוללת של עבודה, ולא במצב העבודה. מדדי Goodput עוזרים לכם לבצע אופטימיזציה של משימות אימון כדי להשיג שיפורים מוחשיים בפריון ובביצועים הכוללים.
המדד 'קצב העברת נתונים נטו' מאפשר לכם להבין ברמה מפורטת את ההפסדים הפוטנציאליים ביעילות באמצעות המדדים הבאים:
- Scheduling goodput הוא חלק מהזמן שבו כל המשאבים שנדרשים לאימון או להצגת מודעות זמינים לשימוש.
- Runtime goodput מייצג את שיעור השלבים המועילים באימון שהושלמו במהלך תקופה נתונה.
- התפוקה של התוכנית היא הביצועים המקסימליים של החומרה או של יחידת ה-MFU שאפשר להפיק ממאיץ במהלך משימת אימון. היא תלויה בניצול יעיל של משאבי המחשוב הבסיסיים במהלך האימון.
אופטימיזציה של תפוקה טובה בתזמון
כדי לבצע אופטימיזציה של תזמון התפוקה הטובה של עומס עבודה, צריך לזהות את דרישות התשתית הספציפיות של עומס העבודה. לדוגמה, יש דרישות שונות להסקת מסקנות באצווה, להסקת מסקנות בסטרימינג ולאימון:
- עומסי עבודה (workloads) של הסקת מסקנות באצווה יכולים להתמודד עם הפרעות ועיכובים מסוימים בזמינות המשאבים.
- עומסי עבודה של הסקת מסקנות בסטרימינג דורשים תשתית ללא מצב.
- עומסי עבודה של אימון דורשים התחייבויות ארוכות טווח לגבי התשתית.
בחירת מצבי זמינות מתאימים
במחשוב ענן, זמינות היא היכולת להקצות משאבים כשנדרשים. Google Cloud מספקת את מצבי הזמינות הבאים:
- On-demand VMs: אתם מקצים מכונות וירטואליות ב-Compute Engine כשצריך אותן ומריצים את עומסי העבודה במכונות הווירטואליות. בקשת ההקצאה כפופה לזמינות של משאבים, כמו מעבדי GPU. אם אין מספיק משאבים מהסוג המבוקש, הבקשה תיכשל.
- מכונות וירטואליות מסוג Spot: אתם יוצרים מכונות וירטואליות באמצעות קיבולת מחשוב לא מנוצלת. החיוב על מכונות וירטואליות במודל Spot הוא במחיר מוזל בהשוואה למכונות וירטואליות על פי דרישה, אבלGoogle Cloud יכול להיותשמכונות וירטואליות במודל Spot יידחקו בכל שלב. מומלץ להשתמש במכונות Spot VM לעומסי עבודה ללא מצב (stateless) שיכולים להיכשל בצורה מסודרת כשמכונות ה-VM המארחות נדחקות.
- הזמנות:: אתם מזמינים קיבולת כמאגר של מכונות וירטואליות. הזמנות מתאימות לעומסי עבודה שנדרשת בהם הבטחת קיבולת. כדי למקסם את התפוקה של התזמון, כדאי להשתמש בהזמנות כדי לוודא שהמשאבים זמינים כשצריך אותם.
Dynamic Workload Scheduler: מנגנון ההקצאה הזה מכניס לתור בקשות למכונות וירטואליות עם GPU במאגר ייעודי. הכלי Dynamic Workload Scheduler עוזר לכם להימנע מהמגבלות של מצבי הזמינות האחרים:
- מצבים של חוסר במלאי במצב לפי דרישה.
- מגבלת חוסר המצב וסיכון ההדחה של מכונות וירטואליות מסוג Spot.
- ההשלכות של הזמנות על העלות והזמינות.
בטבלה הבאה מופיע סיכום של מצבי ההשגה של שירותי Google Cloudוקישורים למסמכי תיעוד רלוונטיים:
תכנון אירועי תחזוקה
כדי לשפר את קצב העברת הנתונים של התזמון, כדאי לצפות מראש את התחזוקה והשדרוגים של התשתית ולתכנן אותם.
ב-GKE אפשר לקבוע מתי אפשר לבצע תחזוקה אוטומטית של האשכולות. מידע נוסף זמין במאמר בנושא חלונות תחזוקה והחרגות.
Compute Engine מספק את היכולות הבאות:
- כדי להשאיר מכונה וירטואלית פעילה במהלך אירוע במארח, כמו תחזוקה מתוכננת של החומרה הבסיסית, Compute Engine מבצע מיגרציה פעילה של המכונה הווירטואלית למארח אחר באותו אזור. מידע נוסף זמין במאמר בנושא תהליך מיגרציה פעילה במהלך אירועי תחזוקה.
- כדי לקבוע איך מופעלת תגובה של מופע כשנדרשת תחזוקה של המארח הבסיסי או כשמתרחשת שגיאה, אפשר להגדיר מדיניות תחזוקה של המארח עבור המופע.
מידע על תכנון אירועים במארח שקשורים לאשכולות גדולים של אימון ב-AI Hypercomputer זמין במאמר ניהול אירועים במארח במכונות וירטואליות לחישוב.
אופטימיזציה של קצב העברת הנתונים בזמן הריצה
תהליך אימון המודל מופרע לעיתים קרובות על ידי אירועים כמו יצירת נקודת ביקורת של המודל וקדימות של משאבים. כדי לבצע אופטימיזציה של התפוקה הטובה בזמן הריצה, צריך לוודא שהמערכת מחדשת את האימון וההסקת מסקנות בצורה יעילה אחרי שהתשתית הנדרשת מוכנה ואחרי כל הפרעה.
במהלך אימון המודל, חוקרי AI משתמשים בנקודות ביקורת כדי לעקוב אחרי ההתקדמות ולצמצם את אובדן הלמידה שנגרם בגלל הקצאות משאבים שבוטלו. גודלי מודלים גדולים יותר גורמים להפסקות ארוכות יותר בנקודות הביקורת, מה שמשפיע עוד יותר על היעילות הכוללת. אחרי שיבושים, צריך להפעיל מחדש את אפליקציית האימון בכל צומת באשכול. ההפעלה מחדש עשויה להימשך זמן מה כי צריך לטעון מחדש את הארטיפקטים הנדרשים.
כדי לשפר את התפוקה של זמן הריצה, אפשר להשתמש בטכניקות הבאות:
| טכניקה | תיאור |
|---|---|
| הטמעת שמירת נקודות ביקורת אוטומטית. | הוספת נקודות לשמירה על ההתקדמות בתדירות גבוהה מאפשרת לעקוב אחרי התקדמות האימון ברמה מפורטת. עם זאת, תהליך האימון מופסק בכל נקודת ביקורת, מה שמקטין את התפוקה הטובה של זמן הריצה. כדי למזער את ההפרעות, אפשר להגדיר יצירה אוטומטית של נקודות ביקורת, שבהן אות ה-SIGTERM של המארח מפעיל את היצירה של נקודת ביקורת. הגישה הזו מגבילה את ההפרעות של יצירת נקודות ביקורת למקרים שבהם המארח צריך תחזוקה. חשוב לזכור שחלק מכשלי החומרה לא מפעילים אותות SIGTERM, ולכן צריך למצוא איזון מתאים בין יצירת נקודות ביקורת אוטומטית לבין אירועי SIGTERM. אפשר להגדיר יצירה אוטומטית של נקודות ביקורת באמצעות הטכניקות הבאות:
|
| שימוש בשיטות מתאימות לטעינת מאגרי תגים. | באשכול GKE, יכול להיות שיעבור זמן מה עד שהצמתים יסיימו לטעון את הארטיפקטים הנדרשים, כמו נתונים או נקודות ביקורת של המודל, לפני שהם יוכלו להמשיך את משימות האימון. כדי לקצר את הזמן שנדרש לטעינה מחדש של הנתונים ולהמשך האימון, אפשר להשתמש בטכניקות הבאות:
מידע נוסף על קיצור הזמן של טעינת הנתונים מחדש זמין במאמר בנושא טיפים וטריקים לקיצור זמן האחזור של הפעלה במצב התחלתי ב-GKE. |
| שימוש במטמון של הקומפילציה. | אם האימון דורש מחסנית מבוססת-קומפילציה, כדאי לבדוק אם אפשר להשתמש במטמון קומפילציה. כשמשתמשים במטמון של קומפילציה, גרף החישוב לא עובר קומפילציה מחדש אחרי כל הפרעה לאימון. החיסכון בזמן ובעלויות שמתקבלים כתוצאה מכך מועיל במיוחד כשמשתמשים ב-TPU. JAX מאפשרת לכם לאחסן את מטמון הקומפילציה בקטגוריה של Cloud Storage ואז להשתמש בנתונים שבמטמון במקרה של הפרעות. |
אופטימיזציה של התפוקה האפקטיבית של התוכנית
התפוקה הטובה של התוכנית מייצגת את שיא ניצול המשאבים במהלך האימון, וזו הדרך המקובלת למדוד את יעילות האימון וההצגה. כדי לשפר את התפוקה של התוכנית, צריך אסטרטגיית הפצה אופטימלית, חפיפה יעילה בין חישוב לתקשורת, גישה אופטימלית לזיכרון וצינורות יעילים.
כדי לבצע אופטימיזציה של קצב העברת הנתונים (goodput) של התוכנית, אפשר להשתמש בשיטות הבאות:
| האסטרטגיה | תיאור |
|---|---|
| שימוש באפשרויות התאמה אישית ברמת המסגרת. | מסגרות או קומפיילרים כמו Accelerated Linear Algebra (XLA) מספקים הרבה רכיבים חשובים של תפוקה טובה של תוכנית. כדי לבצע אופטימיזציה נוספת של הביצועים, אפשר להתאים אישית רכיבים בסיסיים של תרשים החישוב. לדוגמה, Pallas תומך בקרנלים מותאמים אישית למעבדי TPU ולמעבדי GPU. |
| העברת הזיכרון ל-DRAM של המארח. | לאימון בקנה מידה גדול, שדורש נפח זיכרון גבוה במיוחד ממאיצים, אפשר להעביר חלק מהשימוש בזיכרון ל-DRAM של המארח. לדוגמה, XLA מאפשר להפחית עומס של הפעלות מודלים מהמעבר קדימה לזיכרון המארח, במקום להשתמש בזיכרון של המאיץ. באמצעות האסטרטגיה הזו, אפשר לשפר את ביצועי האימון על ידי הגדלת קיבולת המודל או גודל האצווה. |
| שימוש בקוונטיזציה במהלך האימון. | כדי לשפר את יעילות האימון ואת התפוקה של התוכנית, אפשר להשתמש בכימות מודלים במהלך האימון. השיטה הזו מצמצמת את הדיוק של הגרדיאנטים או המשקלים במהלך שלבים מסוימים של האימון, ולכן התפוקה הטובה של התוכנית משתפרת. עם זאת, יכול להיות שהאסטרטגיה הזו תדרוש מאמץ הנדסי נוסף במהלך פיתוח המודל. מידע נוסף זמין במקורות המידע הבאים: |
| הטמעת מקביליות. | כדי להגדיל את ניצול משאבי החישוב הזמינים, אפשר להשתמש באסטרטגיות של מקביליות ברמת המודל במהלך האימון ובעת טעינת הנתונים. מידע על מקביליות של מודלים זמין במאמרים הבאים:
כדי להשיג מקביליות נתונים, אפשר להשתמש בכלים כמו:
|
התמקדות בדרישות ספציפיות לעומסי עבודה
כדי לוודא שמאמצי האופטימיזציה של הביצועים יהיו יעילים והוליסטיים, צריך להתאים את החלטות האופטימיזציה לדרישות הספציפיות של עומסי העבודה של האימון וההסקה. בחירת מודלים מתאימים של AI ושימוש באסטרטגיות רלוונטיות לאופטימיזציה של הנחיות. בחירת מסגרות וכלים מתאימים על סמך הדרישות של עומסי העבודה.
זיהוי דרישות ספציפיות לעומסי עבודה
כדאי להעריך את הדרישות והמגבלות של עומסי העבודה בתחומים הבאים:
| אזור | תיאור |
|---|---|
| דרישות לגבי משימות ואיכות | הגדרת המשימה המרכזית של עומס העבודה ורמת הביצועים הבסיסית. עונים על שאלות כמו:
|
| הקשר להצגת מודעות | לנתח את הסביבה התפעולית שבה אתם מתכננים לפרוס את המודל. להקשר של הצגת המודעות יש לרוב השפעה משמעותית על החלטות העיצוב. כדאי להביא בחשבון את הגורמים הבאים:
|
| יכולות צוות וכלכלה | להעריך את הערך העסקי של רכישת הפתרון לעומת העלות והמורכבות של בנייה ותחזוקה שלו. כדאי לבדוק אם לצוות שלכם יש את הכישורים המיוחדים שנדרשים לפיתוח מודל בהתאמה אישית, או אם שירות מנוהל יכול לספק לכם ערך מהר יותר. |
בחירת מודל מתאים
אם API או מודל פתוח יכולים לספק את הביצועים והאיכות הנדרשים, כדאי להשתמש ב-API או במודל האלה.
למשימות ספציפיות למודאליות כמו זיהוי תווים אופטי (OCR), הוספת תוויות ופיקוח על תוכן, כדאי לבחור ממשקי ML API כמו אלה:
לגבי אפליקציות של AI גנרטיבי, כדאי להשתמש במודלים של Google כמו Gemini, Imagen ו-Veo.
אפשר לעיין בModel Garden ולבחור מתוך אוסף של מודלים בסיסיים ומודלים ספציפיים למשימות של Google. ב-Model Garden יש גם מודלים פתוחים כמו Gemma ומודלים של צד שלישי, שאפשר להריץ ב-Agent Platform או לפרוס בסביבות זמן ריצה כמו GKE.
אם אפשר להשלים משימה באמצעות ML API או מודל AI גנרטיבי, כדאי לשקול את מורכבות המשימה. למשימות מורכבות, מודלים גדולים כמו Gemini עשויים לספק ביצועים טובים יותר ממודלים קטנים יותר.
שיפור האיכות באמצעות הנחיות טובות יותר
כדי לשפר את איכות ההנחיות בקנה מידה נרחב, אפשר להשתמש בכלי לשיפור ההנחיות ב-Agent Platform. אין צורך לכתוב מחדש באופן ידני את ההנחיות וההודעות למערכת. כלי האופטימיזציה של ההנחיות תומך בגישות הבאות:
- אופטימיזציה ללא דוגמאות: גישה עם זמן אחזור נמוך שמשפרת הנחיה יחידה או הוראת מערכת בזמן אמת.
- אופטימיזציה מבוססת-נתונים: גישה מתקדמת לשיפור ההנחיות. במסגרת הגישה הזו, המערכת מעריכה את התשובות של המודל להנחיות לדוגמה בהשוואה למדדי הערכה ספציפיים.
הנחיות נוספות לאופטימיזציה של הנחיות זמינות במאמר סקירה כללית של אסטרטגיות להנפקת הנחיות.
שיפור הביצועים של נקודות קצה של למידת מכונה ו-AI גנרטיבי
כדי לשפר את זמן האחזור או את קצב העברת הנתונים (טוקנים לשנייה) של נקודות קצה של ML ו-AI גנרטיבי, כדאי לפעול לפי ההמלצות הבאות:
- שמירת תוצאות במטמון באמצעות Memorystore.
- בממשקי API של AI גנרטיבי, כדאי להשתמש בטכניקות הבאות:
- שמירת הקשר במטמון: השגת חביון נמוך יותר לבקשות שמכילות תוכן שחוזר על עצמו.
- תפוקה מוקצית: שיפור התפוקה של נקודות הקצה של Gemini על ידי הקצאת קיבולת תפוקה.
- למודלים באירוח עצמי, כדאי להשתמש במסגרות האופטימיזציה הבאות להסקת מסקנות:
Framework מחברות ומדריכים מאגרי תגים מותאמים של vLLM ב-Model Garden פריסת מודלים פתוחים באמצעות קונטיינרים מוכנים מראש הסקת מסקנות מבוססת-GPU ב-GKE הסקת מסקנות מבוססת-TPU
שימוש בפתרונות עם תכנות מינימלי ובכוונון
אם מודלים שאומנו מראש לא עונים על הדרישות שלכם, אתם יכולים לשפר את הביצועים שלהם בדומיינים ספציפיים באמצעות הפתרונות הבאים:
- AutoML הוא פתרון עם תכנות מינימלי לשיפור התוצאות של היקש, עם מינימום מאמץ טכני למגוון רחב של משימות. AutoML מאפשר ליצור מודלים שעברו אופטימיזציה בכמה מימדים: ארכיטקטורה, ביצועים ושלב האימון (באמצעות שמירת נקודות ביקורת).
- התאמה עוזרת לכם להשיג איכות גבוהה יותר, יצירה יציבה יותר וחביון נמוך יותר עם הנחיות קצרות וללא הרבה נתונים. מומלץ להתחיל את תהליך ההתאמה באמצעות ערכי ברירת המחדל של היפרפרמטרים. מידע נוסף זמין במאמר Supervised Fine Tuning for Gemini: A best practices guide (כוונון עדין מפוקח של Gemini: מדריך שיטות מומלצות).
אופטימיזציה של אימון בניהול עצמי
במקרים מסוימים, יכול להיות שתחליטו לאמן מחדש מודל או לנהל באופן מלא משימת כוונון עדין. הגישה הזו דורשת מיומנויות מתקדמות וזמן נוסף, בהתאם למודל, למסגרת ולמשאבים שבהם משתמשים.
כדאי להשתמש באפשרויות של מסגרות שעברו אופטימיזציה לשיפור הביצועים, כמו:
שימוש בתמונות או בקונטיינרים של למידה עמוקה, שכוללים את יחסי התלות העדכניים של התוכנה וספריות ספציפיות ל-Google Cloud.
הרצת אימון מודלים באמצעות Ray ב- Google Cloud:
- Ray on Gemini Enterprise Agent Platform מאפשר לכם להשתמש במסגרת האימון המבוזרת של Ray ב-Compute Engine או ב-GKE, ומפשט את התקורה של ניהול המסגרת.
- אתם יכולים לנהל את Ray ב-GKE בעצמכם באמצעות KubeRay, על ידי פריסה של Ray operator באשכול קיים.
פריסת עומסי עבודה של אימון באשכול מחשוב שמוקצה באמצעות Cluster Toolkit בקוד פתוח. כדי להקצות ביעילות אשכולות שעברו אופטימיזציה לביצועים, משתמשים בתוכניות מבוססות YAML. ניהול האשכולות באמצעות מתזמנים כמו Slurm ו-GKE.
לאמן ארכיטקטורות של מודלים רגילים באמצעות מתכונים שעברו אופטימיזציה ל-GPU.
כדי לשפר את הביצועים, כדאי לבנות ארכיטקטורות ושיטות אימון באמצעות הטכניקות הבאות:
- מטמיעים אימון מבוזר ב-Agent Platform או במסגרות שמתוארות למעלה. אימון מבוזר מאפשר מקביליות של מודלים ומקביליות של נתונים, שיכולות לעזור להגדיל את גודל מערך הנתונים לאימון ואת גודל המודל, וגם לקצר את זמן האימון.
- כדי לאמן את המודל ביעילות ולבחון הגדרות שונות של ביצועים, מומלץ להריץ את התהליך של יצירת נקודות ביקורת במרווחים מתאימים. מידע נוסף זמין במאמר בנושא אופטימיזציה של קצב העברת נתונים נטו בזמן ריצה.
אופטימיזציה של הצגת מודעות בניהול עצמי
כדי להפעיל את המודלים באופן עצמאי, צריך לבצע פעולות הסקה יעילות ולקבל תפוקה גבוהה (מספר ההסקות ליחידת זמן).
כדי לבצע אופטימיזציה של המודל להסקת מסקנות, אפשר להיעזר בשיטות הבאות:
קוונטיזציה: הקטנת גודל המודל על ידי ייצוג הפרמטרים שלו בפורמט עם דיוק נמוך יותר. הגישה הזו עוזרת לצמצם את צריכת הזיכרון ואת זמן האחזור. עם זאת, כימות אחרי האימון עלול לשנות את איכות המודל. לדוגמה, כימות אחרי אימון עלול לגרום לירידה ברמת הדיוק.
- כימות אחרי אימון (PTQ) הוא משימה שניתנת לחזרה. PTQ נתמך ב-frameworks מובילים של ML כמו PyTorch ו-TensorFlow.
- אפשר לתזמן את PTQ באמצעות צינור עיבוד נתונים ב-Agent Platform Pipelines.
- כדי לייצב את ביצועי המודל וליהנות מהקטנת גודל המודל, אפשר להשתמש ב-Qwix.
Tensor parallelism: שיפור התפוקה של ההסקה על ידי חלוקת עומס החישוב בין כמה מעבדי GPU.
אופטימיזציה של הזיכרון: הגדלת התפוקה ואופטימיזציה של שמירת תשומת לב במטמון, גדלי אצווה וגדלי קלט.
שימוש במסגרות שעברו אופטימיזציה להסקת מסקנות, כמו:
- למודלים גנרטיביים, משתמשים במסגרת פתוחה כמו MaxText, MaxDiffusion או vLLM.
- הפעלת קובצי אימג' מוכנים מראש של קונטיינרים ב-Agent Platform לצורך חיזויים והסברים. אם בוחרים ב-TensorFlow, צריך להשתמש בזמן הריצה האופטימלי של TensorFlow. זמן הריצה הזה מאפשר הסקה יעילה יותר ובעלות נמוכה יותר מאשר קונטיינרים מוכנים מראש שמשתמשים ב-TensorFlow בקוד פתוח.
- להריץ הסקת מסקנות בכמה מחשבים באמצעות מודלים גדולים ב-GKE באמצעות LeaderWorkerSet (LWS) API.
- אפשר להשתמש בשרת ההיסק של NVIDIA Triton ב-Agent Platform.
- כדי לפשט את הפריסה של עומסי עבודה של הסקת מסקנות ב-GKE, אפשר להשתמש בהגדרות שעברו אופטימיזציה ל-LLM. מידע נוסף מופיע במאמר ניתוח הביצועים והעלויות של מודלים שמופעלים באמצעות GKE Inference.
אופטימיזציה של צריכת המשאבים על סמך יעדי הביצועים
אופטימיזציה של משאבים עוזרת להאיץ את תהליך האימון, לבצע איטרציות בצורה יעילה, לשפר את איכות המודל ולהגדיל את קיבולת ההצגה.
בחירת סוגי מעבדים מתאימים
לבחירה של פלטפורמת מחשוב יכולה להיות השפעה משמעותית על יעילות האימון של מודל.
- מודלים של למידה עמוקה פועלים היטב במעבדים גרפיים (GPU) וב-TPU, כי הם דורשים נפח זיכרון גדול וחישוב מקביל של מטריצות. מידע נוסף על עומסי עבודה שמתאימים למעבדי CPU, מעבדי GPU ומעבדי TPU זמין במאמר מתי כדאי להשתמש במעבדי TPU.
- מכונות וירטואליות שמותאמות לצריכת מעבד גבוהה הן אידיאליות לעומסי עבודה של HPC.
אופטימיזציה של אימון והצגה ביחידות GPU
כדי לשפר את הביצועים של עומסי עבודה של אימון והסקת מסקנות שנפרסים ב-GPU, כדאי לפעול לפי ההמלצות הבאות:
| המלצה | תיאור |
|---|---|
| בוחרים מפרטי זיכרון מתאימים. | כשבוחרים סוגי מכונות עם GPU, בוחרים מפרטי זיכרון על סמך הגורמים הבאים:
|
| הערכת הדרישות של רוחב הפס של הליבה והזיכרון. | בנוסף לגודל הזיכרון, כדאי לקחת בחשבון דרישות אחרות כמו מספר ליבות Tensor ורוחב פס של הזיכרון. הגורמים האלה משפיעים על המהירות שבה מתבצעות גישה לנתונים וחישובים בשבב. |
| בחירת סוגי מכונות GPU מתאימים | יכול להיות שתצטרכו סוגים שונים של מכונות GPU לאימון ולשירות.
מומלץ להשתמש בסוגי מכונות גדולים לאימון ובסוגי מכונות קטנים וחסכוניים להסקת מסקנות. כדי לזהות בעיות בניצול המשאבים, משתמשים בכלי מעקב כמו NVIDIA DCGM agent ומתאימים את המשאבים בהתאם. |
| שימוש בשיתוף GPU ב-GKE. | הקצאת GPU מלא למאגר יחיד עלולה להיות גישה לא יעילה במקרים מסוימים. כדי להתגבר על חוסר היעילות הזה, GKE תומך בשיטות שונות לשיתוף GPU:
כדי למקסם את ניצול המשאבים, מומלץ להשתמש בשילוב מתאים של האסטרטגיות האלה. לדוגמה, כשמבצעים וירטואליזציה של GPU גדול מסוג H100 באמצעות אסטרטגיות של שיתוף זמן ב-GPU וGPU מרובה מופעים, פלטפורמת ההצגה יכולה להגדיל או להקטין את הקיבולת שלה בהתאם לתנועת הגולשים. המשאבים של ה-GPU מוקצים מחדש בזמן אמת על סמך העומס על מאגרי המודלים. |
| אופטימיזציה של הניתוב ואיזון העומסים. | כשפורסים כמה מודלים באשכול, אפשר להשתמש ב-GKE Inference Gateway כדי לבצע ניתוב אופטימלי ואיזון עומסים. Inference Gateway מרחיב את מנגנוני הניתוב של Kubernetes Gateway API באמצעות היכולות הבאות:
|
| שיתוף משאבים עבור נקודות קצה של Agent Platform | אתם יכולים להגדיר כמה נקודות קצה של Agent Platform לשימוש במאגר משותף של משאבים. מידע נוסף על התכונה הזו ועל המגבלות שלה זמין במאמר שיתוף משאבים בין פריסות. |
אופטימיזציה של אימון והצגה ב-TPU
TPU הם שבבים של Google שעוזרים לפתור אתגרים של קנה מידה עצום באלגוריתמים של ML. הצ'יפים האלה מספקים ביצועים אופטימליים לאימון AI ולעומסי עבודה של הסקת מסקנות. בהשוואה למעבדי GPU, מעבדי TPU מספקים יעילות גבוהה יותר לאימון ולשימוש בלמידה עמוקה. מידע על תרחישי שימוש שמתאימים ל-TPU זמין במאמר מתי כדאי להשתמש ב-TPU. מעבדי TPU תואמים ל-frameworks של ML כמו TensorFlow, PyTorch ו-JAX.
כדי לשפר את הביצועים של TPU, אפשר להשתמש בטכניקות הבאות, שמתוארות במדריך הביצועים של Cloud TPU:
- מגדילים את גודל האצווה לכל יחידת זיכרון של TPU.
- מוודאים שאין יחידות TPU במצב לא פעיל. לדוגמה, מטמיעים קריאות נתונים מקבילות.
- אופטימיזציה של מהדר XLA. משנים את מימדי הטנזור לפי הצורך ונמנעים מריפוד. XLA מבצע אופטימיזציה אוטומטית של ביצועי הגרף באמצעות כלים כמו מיזוג ושידור.
אופטימיזציה של אימון ב-TPU והצגה ב-GPU
יחידות TPU תומכות בהדרכה יעילה. מעבדי GPU מספקים גמישות וזמינות רחבה יותר לעומסי עבודה של הסקה. כדי לשלב את היתרונות של TPUs ו-GPUs, אפשר לאמן מודלים ב-TPUs ולהפעיל אותם ב-GPUs. הגישה הזו יכולה לעזור לצמצם את העלויות הכוללות ולזרז את הפיתוח, במיוחד כשמדובר במודלים גדולים. למידע על המיקומים שבהם זמינים סוגי מכונות TPU ו-GPU, אפשר לעיין במאמרים אזורים ותחומים של TPU ומיקומים של GPU.
אופטימיזציה של שכבת האחסון
שכבת האחסון של התשתית לאימון ולפריסה היא קריטית לביצועים. משימות אימון ועומסי עבודה של הסקת מסקנות כוללים את הפעילויות הבאות שקשורות לאחסון:
- טעינה ועיבוד של נתונים.
- יצירת נקודות ביקורת (checkpoint) של המודל במהלך האימון.
- טעינה מחדש של קבצים בינאריים כדי להמשיך את האימון אחרי שצומת נדחק.
- טעינת המודל בצורה יעילה כדי לטפל בהסקת מסקנות בקנה מידה רחב.
הגורמים הבאים קובעים את הדרישות שלכם לגבי קיבולת אחסון, רוחב פס וזמן אחזור:
- גודל המודל
- נפח מערך הנתונים לאימון
- תדירות יצירת נקודות ביקורת
- דפוסי שינוי גודל
אם נתוני האימון שלכם נמצאים ב-Cloud Storage, אתם יכולים להשתמש בשמירת קבצים במטמון ב-Cloud Storage FUSE כדי להקטין את זמן האחזור של טעינת הנתונים. Cloud Storage FUSE מאפשר לטעון קטגוריה של Cloud Storage בצמתים של מחשוב שיש להם דיסקים מקומיים של SSD. מידע על שיפור הביצועים של Cloud Storage FUSE זמין במאמר שיטות מומלצות לשיפור הביצועים.
מחבר PyTorch ל-Cloud Storage מספק ביצועים גבוהים לקריאה ולכתיבה של נתונים. המחבר הזה שימושי במיוחד לאימון עם מערכי נתונים גדולים ולשמירת נקודות ביקורת של מודלים גדולים.
Compute Engine תומך בסוגים שונים של דיסקים לאחסון מתמיד. עם Google Cloud Hyperdisk ML, אתם יכולים להקצות את קצב העברת הנתונים ופעולות הקלט/פלט בשנייה (IOPS) הנדרשים על סמך צורכי האימון. כדי לשפר את ביצועי הדיסקים, מתחילים בשינוי הגודל של הדיסקים ואז שוקלים לשנות את סוג המכונה. מידע נוסף זמין במאמר בנושא אופטימיזציה של הביצועים של Persistent Disk. כדי לבדוק את הביצועים של קריאה וכתיבה ואת זמן האחזור בשכבת האחסון, אפשר להשתמש בכלים כמו Flexible I/O tester (FIO).
מידע נוסף על בחירה ואופטימיזציה של שירותי אחסון לעומסי עבודה של AI ולמידת מכונה זמין במאמר סקירה כללית של שירותי אחסון לעומסי עבודה של AI ולמידת מכונה ב-AI Hypercomputer.
אופטימיזציה של שכבת הרשת
כדי לבצע אופטימיזציה של הביצועים של עומסי עבודה של AI ו-ML, צריך להגדיר את רשתות ה-VPC כך שיספקו רוחב פס מספיק וקצב העברה מקסימלי עם זמן אחזור מינימלי. כדאי לשקול את ההמלצות הבאות:
| המלצה | טכניקות מומלצות להטמעה |
|---|---|
| אופטימיזציה של רשתות VPC. |
|
| ממקמים מכונות וירטואליות קרוב יותר זו לזו. |
|
| הגדרת מכונות וירטואליות לתמיכה במהירויות רשת גבוהות יותר. |
|
קישור מדדים לבדיקת ביצועים לבחירות עיצוביות והגדרות
כדי לחדש, לפתור בעיות ולחקור בעיות בביצועים, צריך ליצור קשר ברור בין בחירות עיצוביות לבין תוצאות הביצועים. צריך רשומה מהימנה של שרשרת היוחסין של נכסי ה-ML, הפריסות, הפלטים של המודלים וההגדרות והקלטות התואמים שהניבו את הפלטים.
בניית מערכת לשושלת נתונים ומודלים
כדי לשפר את הביצועים באופן מהימן, צריך להיות אפשר לעקוב אחרי כל גרסה של מודל עד לנתונים, לקוד ולהגדרות המדויקים ששימשו ליצירת המודל. ככל שמגדילים את המודל, קשה יותר לעקוב אחריו. אתם צריכים מערכת שושלת נתונים שתבצע אוטומטית את תהליך המעקב ותיצור רשומה ברורה שאפשר לשלוח לה שאילתות לגבי כל ניסוי. המערכת הזו מאפשרת לצוותים שלכם לזהות ביעילות את הבחירות שמובילות למודלים עם הביצועים האופטימליים ולשחזר אותן.
כדי לראות ולנתח את שושלת הנתונים של ארטיפקטים של פייפליין לעומסי עבודה ב-Agent Platform, אפשר להשתמש ב-Vertex ML Metadata או ב-Knowledge Catalog. שתי האפשרויות מאפשרות לרשום אירועים או ארטיפקטים כדי לעמוד בדרישות של ממשל, ולשאילת את המטא-נתונים ולאחזר מידע כשצריך. בקטע הזה מופיעה סקירה כללית של שתי האפשרויות. מידע מפורט על ההבדלים בין Vertex ML Metadata לבין Knowledge Catalog זמין במאמר מעקב אחרי שושלת הנתונים של ארטיפקטים של פייפליין.
הטמעה כברירת מחדל: Vertex ML Metadata
הפעלת הפייפליין או הניסוי הראשונים ב-Agent Platform יוצרת שירות ברירת מחדל של Vertex ML Metadata. הפרמטרים ומטא-נתוני הארטיפקטים שצינור עיבוד הנתונים צורך ומייצר נרשמים באופן אוטומטי במאגר מטא-נתונים של Vertex ML. מודל הנתונים שמשמש לארגון המטא-נתונים המאוחסנים וליצירת קשר ביניהם מכיל את הרכיבים הבאים:
- הקשר: קבוצה של ארטיפקטים וביצועים שמייצגת הרצה של ניסוי.
- הרצה: שלב בתהליך עבודה, כמו אימות נתונים או אימון מודל.
- ארטיפקט: ישות, אובייקט או נתון קלט או פלט שמיוצרים ונצרכים על ידי תהליך עבודה.
- אירוע: קשר בין ארטיפקט לבין ביצוע.
כברירת מחדל, Vertex ML Metadata מתעד ועוקב אחרי כל ארטיפקט קלט ופלט של הרצת פייפליין. הוא משלב את הארטיפקטים האלה עם Experiments on Agent Platform, מרשם המודלים ו-Agent Platform managed datasets.
Autologging היא תכונה מובנית ב-Agent Platform Managed Training שמאפשרת לרשום נתונים באופן אוטומטי ב-Experiments on Agent Platform. כדי לעקוב ביעילות אחרי ניסויים ולשפר את הביצועים, אפשר להשתמש בשילובים המובנים בין Experiments on Agent Platform לבין שירות Vertex ML Metadata המשויך.
Vertex ML Metadata מספק תחביר לסינון ואופרטורים להרצת שאילתות לגבי ארטיפקטים, הפעלות והקשרים. במקרה הצורך, הצוותים יכולים לאחזר ביעילות מידע על קישור הרישום של מודל ועל מערך הנתונים או ההערכה שלו עבור הרצת ניסוי ספציפית. הנתונים האלה יכולים לעזור למערכת לזהות מהר יותר את האפשרויות שישפרו את הביצועים. לדוגמה, אפשר להשוות בין הרצות של צינורות, להשוות בין מודלים ולהשוות בין הרצות של ניסויים. מידע נוסף, כולל דוגמאות לשאילתות, זמין במאמר ניתוח מטא נתונים של Vertex ML.
הטמעה חלופית: Knowledge Catalog
Knowledge Catalog מגלה מטא-נתונים ממשאביGoogle Cloud , כולל ארטיפקטים של Agent Platform. אפשר גם לשלב מקור נתונים מותאם אישית.
Knowledge Catalog יכול לקרוא מטא-נתונים בכמה אזורים ובמאגרים של הארגון כולו, בעוד ש-Vertex ML Metadata הוא משאב ספציפי לפרויקט. בהשוואה ל-Vertex ML Metadata, Knowledge Catalog דורש יותר מאמץ בהגדרה. עם זאת, יכול להיות ש-Knowledge Catalog יתאים לכם אם אתם צריכים שילוב עם תיק הנתונים הרחב יותר שלכם ב- Google Cloud ועם חנויות בכל הארגון.
Knowledge Catalog מגלה ומאסף מטא-נתונים של פרויקטים שבהם מופעל Data Lineage API. המטא-נתונים בקטלוג מאורגנים באמצעות מודל נתונים שכולל פרויקטים, קבוצות רשומות, רשומות והיבטים. ב-Knowledge Catalog יש תחביר ספציפי שאפשר להשתמש בו כדי לגלות ארטיפקטים. אם צריך, אפשר למפות ארטיפקטים של Vertex ML Metadata ל-Knowledge Catalog.
שימוש בכלים להסבר
ההתנהגות של מודל AI מבוססת על נתונים ששימשו לאימון המודל. ההתנהגות הזו מוצפנת כפרמטרים בפונקציות מתמטיות. יכול להיות שיהיה לכם קשה להבין בדיוק למה מודל מסוים מתנהג בצורה מסוימת. עם זאת, הידע הזה קריטי לאופטימיזציה של הביצועים.
לדוגמה, נניח שיש מודל לסיווג תמונות שנתוני האימון שלו מכילים תמונות של מכוניות אדומות בלבד. יכול להיות שהמודל ילמד לזהות את התווית 'מכונית' על סמך הצבע של האובייקט ולא על סמך המאפיינים המרחביים והצורה שלו. כשבודקים את המודל באמצעות תמונות שמוצגים בהן רכבים בצבעים שונים, יכול להיות שהביצועים של המודל ירדו. בקטעים הבאים מתוארים כלים שאפשר להשתמש בהם כדי לזהות בעיות כאלה ולנתח אותן.
זיהוי הטיות בנתונים
בשלב ניתוח הנתונים לצורך גילוי תובנות (EDA) בפרויקט ML, מזהים בעיות בנתונים, כמו מערכי נתונים עם חוסר איזון בין מחלקות והטיות.
במערכות ייצור, לעיתים קרובות מאמנים מחדש מודלים ומריצים ניסויים עם מערכי נתונים שונים. כדי לתקנן את הנתונים ולהשוות בין ניסויים, מומלץ להשתמש בגישה שיטתית ל-EDA שכוללת את המאפיינים הבאים:
- אוטומציה: ככל שגודל קבוצת הנתונים לאימון גדל, תהליך ה-EDA חייב לפעול אוטומטית ברקע.
- כיסוי רחב: כשמוסיפים תכונות חדשות, ה-EDA צריך לחשוף תובנות לגבי התכונות החדשות.
הרבה משימות של ניתוח נתונים גישושי הן ספציפיות לסוג הנתונים ולהקשר העסקי. כדי לבצע אוטומציה של תהליך ה-EDA, אפשר להשתמש ב-BigQuery או בשירות מנוהל לעיבוד נתונים כמו Dataflow. מידע נוסף זמין במאמרים בנושא סיווג נתונים לא מאוזנים ומדדים של הטיית נתונים ב-Agent Platform.
הסבר על מאפייני המודל וההתנהגות שלו
בנוסף להבנת פיזור הנתונים במערכי האימון והאימות וההטיות שלהם, צריך להבין את המאפיינים וההתנהגות של המודל בזמן החיזוי. כדי להבין את התנהגות המודל, אפשר להשתמש בכלים הבאים:
| כלי | תיאור | מטרות |
|---|---|---|
| הסברים מבוססי-דוגמאות | אתם יכולים להשתמש בהסברים מבוססי-דוגמאות ב-Vertex AI ניתן להסברה כדי להבין חיזוי על ידי איתור הדוגמאות הכי דומות מנתוני האימון. הגישה הזו מבוססת על העיקרון שלפיו קלט דומה מניב פלט דומה. |
|
| הסברים שמבוססים על תכונות | לגבי תחזיות שמבוססות על נתונים טבלאיים או על תמונות, הסברים מבוססי-מאפיינים מראים עד כמה כל מאפיין משפיע על תחזית בהשוואה לקו בסיס. Vertex AI ניתן להסברה מספק שיטות שונות לשיוך תכונות בהתאם לסוג המודל והמשימה. השיטות האלה בדרך כלל מבוססות על דגימה ועל ניתוח רגישות כדי למדוד את מידת השינוי בתוצאה בתגובה לשינויים בתכונת קלט. |
|
| What-If Tool | הכלי What-If פותח על ידי היוזמה People + AI Research (PAIR) של Google כדי לעזור לכם להבין ולראות את ההתנהגות של מודלים של תמונות וטבלאות. דוגמאות לשימוש בכלי זמינות בהדגמות האינטרנט של הכלי What-If. |
|
שותפים ביצירת התוכן
מחברים:
- Benjamin Sadik | AI and ML Specialist Customer Engineer
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
תורמי תוכן אחרים:
- Daniel Lees | Cloud Security Architect
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים