פיתוח פלטפורמה להפצה ומונטיזציה של מודלי AI

מדוע פלטפורמת הפצת מודלי AI מתקעית בקנה מידה

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: אפקטים מדידים

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

מהירות הפצת המודל למוצר

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

התאוששות לאחר כשל של מודל

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

עמידות בפני כשל

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

שקיפות הצריכה

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

הפחתת העומס מעל המהנדסים

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

אפשרויות אספקת מודלים: מרשם, שער, חלון ראווה

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

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

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

כיצד אנחנו מטמיעים: שלבי העבודה ההנדסית

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

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

מה נשאר אצל הלקוח: ארטיפקטים ומסמכים

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

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

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

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

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

לפני: שחרור כפעולה ידנית

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

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

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

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

במה מרשם מודלים שונה מפלטפורמת הפצה?

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

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

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

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

ספקות טכניים ומגבלות

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

כיצד הפלטפורמה עובדת בקו סגור?

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

כיצד להחזיר גרסת מודל לאחור במוצר?

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

מי מלווה את הפלטפורמה לאחר ההשקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

מה כדאי לתעד בתיאור:

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

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

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