הגדרת Kubeflow על Kubernetes: תהליכי ML מקצה לקצה

התקנת Kubeflow: היכן נשבר אימון המודלים

אימון מודלים באשכול אינו מתחיל בפלטפורמה, אלא בכאב: סקריפטים מורצים ידנית ממכונות העבודה, מערכי הנתונים יושבים על המחשבים הניידים של המהנדסים, והרצה חוזרת משחזרת את הקודמת "בערך". Kubeflow התקנה נדרשת בדיוק כאן — היא הופכת הרצות מפוזרות לתהליך מנוהל עם היסטוריה ובעלים לכל משימה.

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

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

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

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

מה נותן קו אימון אחיד: מהירות ואמינות

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

Kubeflow נפרס מעל האשכול ולוקח על עצמו את תזמור השלבים האלה: ביומן רואים באיזה שלב, עם אילו נתוני קלט ובאיזו תוצאה עברה כל הרצה.

מהירות מחזור אימון המודלים

בעבר המחזור "עריכת מאפיינים → אימון → בדיקה" התארך, משום שהמשאבים לאימון הוקצו ידנית, ונתוני הביניים הועברו בין הסביבות בהעתקה. בקו מנוהל המשאבים לכל שלב מוגדרים מראש, השלבים רצים במקביל במקום שבו אין תלות ביניהם, והנתונים מועברים בהפניה לגרסה הנדרשת של מערך הנתונים.

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

אמינות ושחזור תוצאות

כל הרצה נשמרת יחד עם גרסת הקוד, גרסת הנתונים וערכי הפרמטרים — אפשר לחזור על הניסוי כעבור חודש ולקבל את אותה תוצאה, ולא אחת "בערך דומה". ניהול גרסאות המודלים חי באותו יומן: רואים איזה מודל נמצא כעת בעבודה, על מה אומן ובמה הוא שונה מהקודם. החזרה לגרסה קודמת אורכת דקות, ושחזור הניסויים נשען על יומן ההרצות, ולא על הזיכרון של מי שהריץ אותן.

אפשרויות התקנת Kubeflow: אשכול, ענן, היברידי

את Kubeflow ב-Kubernetes פורסים באחת משלוש דרכים: התקנה בענן על אשכול מנוהל, מקומית על חומרה משלכם, או בתשתית היברידית שבה הליבה נשארת בהיקף מאובטח והאימון הכבד יוצא החוצה. מה שמכריע אינו האופנה, אלא היכן נמצאים הנתונים ומי אחראי על החומרה.

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

מתי מתאימה כל אפשרות

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

מגבלות שכדאי להכיר מראש

בענן אתם מקבלים את הכללים של אחרים: חלק מהגדרות הרשת ומאגרי האחסון אינם זמינים, והמשאבים נשכרים לפי שיא. במקומית הכול נתקל בחומרה — הרחבה דורשת אספקות חדשות וזמן להעלאה.

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

שלבי ההטמעה: סקר, תכנית, הגדרה, בדיקה, מסירה

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

הכנה וסקר

1. סקר תשתית. מרכיבים מפה של אשכולות, צמתים, מאגרי אחסון ודרכי הרצת האימון: היכן המשאבים עומדים בטל, היכן מצטבר תור, מי ואיך מוציא נתונים. בפלט — תכנית ורשימת צווארי בקבוק.
2. תיאום התכנית. מגדירים גבולות מעגלים, פרופילי משתמשים, מכסות וכללי שימוש משותף במאיצים, כדי שניסוי אחד לא יתפוס את כל האשכול.
3. הגדרת גישה לנתונים. מחברים אחסון אובייקטים ובסיסי נתונים, מתארים כרכים, ומפרידים קריאה וכתיבה לפי תפקידים. הנתונים נשארים אצלכם — משתנות רק דרכי הגישה.

הגדרה, בדיקה ומסירה

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

ערכת המסירה: קונפיגורציות, תכניות, נהלים, תיעוד

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

מה כלול בערכת המסירה

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

תיעוד ונהלי תפעול

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

בפועל: איך קיצרנו פי שלושה את בניית המודלים הידנית

הלקוח — צוות מוצר שאימן מודלי המלצות לשירותים שלו. בניית גרסה חדשה נמשכה אצלו כשלושה שבועות: האימון הורץ ידנית, הארטיפקטים הועתקו לדיסק משותף, והקונפיגורציה הועברה לצוות סמוך בטקסט בצ'אט. להלן נפרק מה שינינו ב-Kubeflow וכיצד חישבנו את התוצאה.

מה היה לפני

קו האימון חי באוסף סקריפטים ומחברות: אפשר היה לחזור על ניסוי קודם רק מהזיכרון, וחלק מהשלבים נשען על מהנדס אחד. עד 80% מהפעולות בוצעו ביד — מהפקת הנתונים ועד העברת המודל המוכן. כ-20% מהזמן הוקדשו לתיאום סביבות.

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

מה השתנה אחרי

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

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

במה קו מנוהל שונה מאוסף סקריפטים

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

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

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

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

ספקות טכניים: בידוד, הרשאות, חזרה לגרסאות

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

כיצד מחלקים הרשאות להרצות ולשינויים?

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

אפשר לחזור עם המודל לגרסה קודמת?

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

איך מזהים דעיכה באימון לפני הפרסום?

לכל הרצה נכתבות מטריקות איכות, משך השלבים וצריכת משאבים. בחריגה מסף או בנפילת משימה מגיעה התראה, ולא "התברר כעבור שבוע".

מה עושים עם סקריפטי האימון שכבר נכתבו?

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

ממה להתחיל

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