המרת מודל ML ל-ONNX — אופטימיזציה לפריסה

מדוע המרת מודל ל-ONNX שוברת את ההסקה

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

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

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

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

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

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

מה משתנה לאחר העברת המודל לפורמט אחיד

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

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

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

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

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

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

מצבי העברה ופורמטים: השוואת גישות

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

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

שלבי העבודה: מביקורת הגרף ועד למסירה

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: האצנו את הסקת המודל בלי אימון מחדש

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

מה שינו

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

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

מה התוצאה

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

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

מה לעשות אם המודל כבר בנוי בפורמט אחר

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

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

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

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

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

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

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

ספקות טכניים סביב ONNX ותשובות המהנדסים

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

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

מה לעשות עם שכבות שאינן נמצאות במערכת הסטנדרטית?

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

האם יהיה צורך לאמן את המודל מחדש?

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

איך לוודא שהפלטים תואמים?

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

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

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

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

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

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

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

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