מדוע מודל על OpenVINO מאבד מהירות לאחר ההעברה
המודל מאומן, המדדים באימות מחזיקים מעמד, אך לאחר העברת המודל להתקן ההסקה צונחת פי כמה. הסיבה כמעט אף פעם אינה ברשת עצמה: צוואר הבקבוק בהסקה הוא הפער בין הגרף שהציג סטנד הבקרה ובין מה שהוא הופך להיות לאחר המרה לייצוג הביניים של OpenVINO ובנייה עבור מאיץ מסוים.
הדבר הראשון שגוזל זמן הוא אופרטורים שההתקן אינו לוקח על עצמו. התוסף מחתך את הגרף למקטעים, שכבות שאינן נתמכות מחושבות במעבד המרכזי, ובין המקטעים מתחילות העברות טנזורים לשני הכיוונים.
הוספה אחת כזו בתחילת הרשת מאפסת את הרווח מהשכבות המואצות: הזמן הולך להעתקה, והעומס על המאיץ יורד לעשרות אחוזים.
השני — גדלים דינמיים של הקלט ועיבוד מקדים. אם צורת הטנזור משתנה מפריים לפריים, הגרף נבנה מחדש בכל צורה חדשה, המטמון של מודלים שנבנו אינו פועל, והקריאות הראשונות לאחר אתחול איטיות במידה ניכרת. לצידם נמצאים שינוי גודל עם נרמול: הם נשארים על המעבד, והמאיץ עומד ללא ניצול בהמתנה לטנזור מוכן.
השלישי — זיכרון. העתקות מיותרות של חוצצי קלט, היעדר גישה משותפת לזיכרון בין היישום למאיץ, בקשה אחת בכל פעם ומספר תהליכונים שלא הותאם מביאים לעלייה בצריכה ולירידה בביצועים בבקשות מקבילות. בנפרד פוגעת קוונטיזציה "על העין": חישובים מחדש ב-float בין שכבות מחזירים חלק מהגרף למעבד.
לכן הסדר כאן הפוך מהרגיל: תחילה פרופיילינג לפי שכבות ומדידת חלקו של כל מקטע, לאחר מכן מצבי ביצועים, עיבוד מקדים, מטמון וכיול. נבחן היכן בדיוק מתבזבז הזמן וכיצד סוגרים זאת.
אפקטים מדידים של אופטימיזציה: תפוקה והשהיה
אפקט האופטימיזציה נראה רק על סטנד בקרה משוחזר: אותו זרם בקשות, סט קלט קבוע, מדידה לפני ואחרי השינויים. לכן אנו משווים לא "הפך למהיר יותר", אלא מדדים קונקרטיים — תפוקה של התקן אחד, השהיית תגובה בחציון ובזנב ההתפלגות, צריכת זיכרון שיא וצריכה במצב יציב של המודל.
האצת ההסקה של המודל נותנת גידול ישיר בתפוקה: אותו התקן משרת פי כמה יותר בקשות ביחידת זמן, משום שהמרת המודל לייצוג הביניים OpenVINO מסירה העברות מיותרות של נתונים, והקוונטיזציה מפחיתה את רוחב הסיביות של המשקלים בלי אובדן מורגש באיכות. המשאב שהתפנה עובר לזרמים מקבילים במקום להיתקע בליבה אחת.
הפחתת השהיות מורגשת לא כל כך לפי הערך הממוצע, אלא לפי הזנב: נעלמים חריגים נדירים שבגללם התגובה לא הספיקה בחלון שהוקצה. זה משנה את סוג הכשלים — בעומס שיא המערכת מחזיקה בקצב, ולא מתדרדרת לפסקי זמן, ניסיונות חוזרים של בקשות ואתחולים ידניים.
צריכת הזיכרון של המודל יורדת יחד עם רוחב הסיביות של המשקלים, לכן על המאיץ נכנסים יותר מופעים, והשירות מפסיק להיתקע במגבלה וליפול בגלל מחסור בזיכרון. יציבות תחת עומס נבדקת בריצה ארוכה: הצריכה מגיעה לרמה קבועה ואינה עולה שעות, תור הבקשות אינו מתפזר.
את התוצאה מתעדים בדוח עם מדידות לפני ואחרי: גרפי השהיה, תפוקה במספר נתון של תהליכונים, צריכת זיכרון בריצה ארוכה. מהם רואים איזה מרווח נותר לגידול בתעבורה בלי החלפת חומרה.
אפשרויות עבודה עם OpenVINO: המרה ומצבי פריסה
ב-OpenVINO דרכים אלה אינן מחליפות זו את זו: המרת המודל, קוונטיזציה של משקלים, מצבי פריסה על מאיצים שונים ועבודה בסביבת המקור בלי המרה. להלן מה שאנו באמת משווים בפרויקטים, עם המגבלות של כל אפשרות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| המרה לייצוג ביניים | הפעלה על מעבד או גרפיקה מובנית; המודל אומן מחוץ לסביבת היעד | שכבות לא סטנדרטיות מתארות ידנית, חלק מהפעולות מועברות באופן לא מדויק |
| קוונטיזציה של משקלים לאחר אימון | נדרשים גודל ארטיפקט קטן יותר והשהיה קטנה יותר; אובדן של עשיריות האחוז מותר | ירידה בשכבות נדירות, נדרש סט בקרה לקבלה |
| קוונטיזציה עם אימון נוסף | הדיוק קריטי ופשוט דחיסה לא מחזיק מעמד | ארוך יותר: נדרשת גישה למערך האימון והרצת אימון נוסף |
| פריסה על כמה מאיצים | פרופיל העומס אינו אחיד: חלק מהשכבות משתלמות יותר בהתקן אחר | מוגדר לפלטפורמה מסוימת, העברה לחומרה אחרת דורשת בדיקה |
| בלי המרה, בסביבת המקור | לוחות הזמנים אינם מאפשרים מיגרציה, המודל מהודר באותה סביבה שבה אומן | אובד הרווח מאופטימיזציה לחומרת היעד |
מועמדים בוחרים באמצעות מדידות: מצלמים פרופיל עומס על מדגם מייצג, מריצים שניים-שלושה וריאנטים ישירות ומתעדים השהיה, גודל ארטיפקט ומדד איכות בתיעוד — כדי שההחלטה תיבדק מחדש בעת החלפת חומרה.
כיצד אנו מיישמים אופטימיזציה: שלבי העבודה ההנדסית
סדר העבודה נבנה כך שכל שלב ייתן תוצאה מדידה ונקודת חזרה לאחור. מתחילים בביקורת של המודל ושל סכימת ההרצה שלו במוצר — בלי זה האופטימיזציה הופכת לניחוש, ואת האיכות צריך לבדוק מחדש כבר במתאר הייצור.
סדר השלבים
- ביקורת המודל וסכימת ההרצה. מפרקים את הגרף, מאתרים אופרטורים שאינם מתאימים לחומרת היעד ובודקים כיצד המודל נקרא כעת. בפלט — רשימת צווארי בקבוק ותוכנית עבודה.
- המרה והשוואה. מעבירים את המודל לפורמט OpenVINO ומשווים את הפלטים לגרסת המקור על מדגם בקרה. פער מעל הסבילות מנתחים מיד, ולא לאחר ההרצה.
- כיול ההרצה. מתאימים את דיוק החישובים, מספר התהליכונים ומצב ההסקה לחומרה מסוימת — מעבד שרת, גרפיקה מובנית או נפרדת. מסירים העתקות מיותרות של נתונים בין השלבים.
- קוונטיזציה עם בקרת איכות. מעבירים את המשקלים לדיוק שלם ועוקבים אחרי הידרדרות במחלקות שבהן המודל טעה גם קודם. להאצה אין משמעות אם חלקם של החיוביים השגויים עולה.
- בדיקה על נתונים אמיתיים. מריצים מדגם מתעבורת הייצור: משווים איכות, זמן תגובה וצריכת משאבים לפני ואחרי. בנפרד בודקים עומס שיא, ולא ערכים ממוצעים.
- מסירת הפתרון. מוסרים קונפיגורציות, סקריפטים לבנייה והוראות להמרה חוזרת, ומכשירים את הצוות. לאחר מכן עדכון גרסאות המודל עובר בלעדינו.
בכל שלב נשאר עקבות: רואים מה ובכמה הואץ ולאן לחזור לאחור אם גרסה חדשה של המודל תתנהג אחרת.
מה נשאר אצלכם: קונפיגורציות, סכימות ותקנות
התוצאה המוחשית היא לא "כיווננו והלכנו", אלא ערכה שלפיה המהנדסים שלכם ירימו וישנו את המערכת בלעדינו. להלן מה בדיוק נמסר בסיום העבודה.
- קבצי קונפיגורציה של הסביבה: תלויות ריצה, משתנים, פרמטרים של תהליכוני הרצה ופרופילים לסוגי צמתים שונים — עם ציון מה משתנה במעבר לשרת אחר.
- סכימות הרצה ואינטגרציות: זרימת נתונים מהמקור להסקה, נקודות כניסה, תורים, פסקי זמן ומקומות שבהם נוצר לרוב צוואר הבקבוק.
- סקריפטים להמרה ולקוונטיזציה של המודל לפורמט OpenVINO עם סט כיול קבוע — הרצה חוזרת מניבה אותו ארטיפקט.
- תקנון עדכון המודל: קבלת גרסה חדשה, הרצה על פרוסה של תעבורה אמיתית, תנאי חזרה לאחור לגרסה הקודמת וקריטריונים שבהם החזרה לאחור מופעלת אוטומטית.
- הוראות לבנייה חוזרת: מהמשקלים המקוריים ועד לארטיפקט המוכן, עם בדיקת התאמת פלטים על סט בקרה.
- סט רגרסיה: פרוסת נתונים שמורה וערכי סף של מדדים שלפיהם משוות גרסאות.
- מדיניות גישה: תפקידים, הפרדת הרשאות לייצוא משקלים ולשינוי קונפיגורציה, היכן נשמרים ארטיפקטים ומי קורא אותם.
- יומן הנחות ומגבלות ידועות — כדי שהשלב הבא לא יתחיל במחקר חוזר של אותו דבר.
כל סעיף נבדק בקבלה: אנו מריצים את המערכת לפי ההוראות שנמסרו בסביבה נקייה, ואם משהו אינו משוחזר — משלימים את התיעוד, ולא מסבירים במילים.
מקרה בוחן: כיצד הסרנו השהיות בהתקנים לאחר אופטימיזציה
מה היה לפני האופטימיזציה
אלינו הגיעה צוות עם פיילוט עובד על צי התקנים בלי מאיצים ייעודיים: מודל זיהוי הניב תוצאה נכונה, אך זמן התגובה גדל באופן ליניארי עם מספר הזרמים במקביל. בהתקן אחד התגובה נכנסה לנורמה, בשמונה — תור הבקשות הצטבר מהר יותר ממה שהמערכת הספיקה לפרק, ובעומס שיא חלק מהפריימים פשוט אבדו.
שיעור שגיאות הזיהוי עמד על כ-6%, ובזינוק הגיע ל-12% — המפעילים בדקו את הפלט ידנית, ומשמעות האוטומציה נמוגה.
מה שינינו
תחילה העברנו את הרצת המודל ל-Intel OpenVINO: המירו את הגרף לייצוג ביניים ובנו אותו עבור קונפיגורציית חומרה מסוימת, במקום לפרק בכל פעם את הפורמט המקורי.
לאחר מכן עברנו קוונטיזציה של משקלים — את האיכות בדקנו על מדגם מוחזק, ולא "על העין", תוך התאמת סף הפעלה כך שהירידה בדיוק תישאר בגבולות המותרים.
בנפרד כתבנו מחדש את העיבוד המקדים: הסרנו העתקות מיותרות של פריים, הוצאנו את הנרמול לשלב משותף ועברנו מעיבוד פריט בודד לעיבוד באצוות. זה נתן מרווח ביצועים עוד לפני שנגענו במודל עצמו.
מה קרה בסוף
השהיית התגובה הצטמצמה פי ארבעה, זרם הפריימים המעובדים גדל פי שלושה על אותו צי התקנים — לא היה צורך לרכוש מאיצים נוספים. שיעור שגיאות הזיהוי ירד מ-6% ל-2%, ובשיא — מ-12% ל-4%.
בזינוק עומס פי שלושה התור כבר אינו גדל: המערכת שומרת על זמן תגובה בטווח הנורמה, והמפעיל מתערב רק במקרי גבול.
מה לעשות אם ההמרה פוגעת בדיוק המודל?
הפער כמעט אף פעם אינו נוצר "בכל המודל" — הוא מתרכז במספר שכבות. הצעד הראשון — להריץ את אותו קלט דרך המודל המקורי והמודל המומר, להוציא את פלטי שכבות הביניים ולהשוות. כך רואים היכן מצטברת השגיאה: בקלט, לאחר איחוד פעולות או כבר בשכבות האחרונות.
לרוב הדיוק יורד בקוונטיזציה של אקטיבציות — סט הכיול נאסף על התפלגות נתונים לא נכונה. בדיקת איכות המודל מתחילה ממנו: הסט צריך לשחזר קלטים אמיתיים, כולל מחלקות נדירות וערכים קיצוניים. אם אספו אותו "על העין", טווחי האקטיבציות נחתכים, והמודל מאבד ביטחון בדוגמאות גבול.
לאחר מכן — שכבות רגישות: משאירים אותן בדיוק מלא, ומקוונטים רק את שאר הגרף. זה מאפשר לבצע המרה חוזרת בלי אימון מחדש — המשקלים אינם משתנים, משתנה סט הגדרות הבנייה ורשימת החריגים.
סטייה מותרת מתעדים לפני תחילת העבודה: למשל, המדד על סט אימות אינו גרוע מהמקור בשיעור מוסכם. אז הקבלה אינה הופכת לוויכוח, וכל בנייה מחדש מלווה בהרצת רגרסיה ובדוח פער לפי שכבות.
ב-Intel OpenVINO יש אמצעים מובנים להשוואת פלטים וסטטיסטיקה לפי שכבות — אנו משתילים אותם בצינור הבנייה, כדי שאובדן דיוק ייתפס בשלב ההמרה, ולא בסביבת העבודה.
שאלות טכניות ששואלים לפני תחילת הפרויקט
לפני ההתחלה צוות ההנדסה של הלקוח בודק לא מילים כלליות, אלא פרטים קונקרטיים: מה בדיוק משתנה במתאר שלהם, אילו צמתים נפגעים וכיצד לחזור לאחור אם משהו משתבש. להלן השאלות שעולות לרוב, עם תשובות ענייניות.
המודל כבר מאומן — יהיה צורך לאמן אותו מחדש?
לא. אנו עובדים עם משקלים מוכנים: ממירים את הגרף לייצוג הביניים OpenVINO, מתאימים גדלי קלט ומכיילים. האימון והתיוג נשארים בצד שלכם, אין צורך בגישה למערך הנתונים — די במדגם מייצג לבקרת איכות.
הקוונטיזציה פוגעת בדיוק?
קוונטיזציה של 8 סיביות כמעט תמיד משנה את המדדים — השאלה היא בכמה. אנו מודדים איכות על סט אימות לפני ואחרי, מחזיקים סף הידרדרות מוסכם, ואת השכבות הרגישות משאירים ב-16 סיביות. אם הסף אינו עובר — עוברים למצב משולב, ולא "סוחטים" האצה על חשבון התוצאה.
האם זה יעבוד על צי ההתקנים שכבר מותקן?
הגרף נבנה עבור דורות מסוימים של מעבדים וגרפיקה מובנית; בצמתים ישנים נשארת נסיגה תקינה למעבד המרכזי, והיישום אינו קורס. לפני פריסה מריצים את אותו סט קלטים בכל סוג התקן ומשווים פלטים — פערים נראים לפני העלאה לפעילות.
כיצד לעדכן מודלים בהתקנים ובמה למדוד את התוצאה?
מייצאים ארטיפקט עם גרסאות, את הבנייה הקודמת מחזיקים לצד: העדכון והחזרה לגרסה הקודמת אורכים דקות ואינם דורשים התקנה מחדש של הסביבה. השהיה לבקשה אחת ותפוקה נמדדות לפני ואחרי — ההחלטה נראית במספרים, ולא במילים.
נדון במשימה שלכם: מה נדרש מכם ומאיתנו
כדי שהערכת פרויקט אופטימיזציה ל-OpenVINO תתבסס על מדידות, ולא על הנחות, נדרש סט מינימלי של נתונים על המודל וסביבת עבודתו. להלן מה אנו מבקשים מכם ומה נחזיר בתגובה.
מה נדרש להתחלה
- מודל בצורתו המקורית: משקלים ותיאור ארכיטקטורה ממסגרת האימון — מכך תלוי היקף ההמרה לייצוג ביניים.
- חומרת היעד: סוג המאיץ ומערכת ההפעלה שבה תעבוד ההסקה.
- מדד איכות וירידה מותרת לאחר דחיסת המשקלים.
- אופן העבודה: זמן תגובה, מספר זרמים מקבילים, מגבלות זיכרון.
- סט ייחוס של כמה מאות דוגמאות אמיתיות להשוואת תשובות לפני ואחרי.
- מגבלות המתאר: הרשאות, מדיניות אבטחה, האם ניתן לייצא משקלים מחוץ לתשתית.
מה נחזיר
- תוכנית לפי שלבים: המרה לייצוג ביניים, התאמת דיוק הקוונטיזציה, השוואה, בנייה ופריסה.
- פרוטוקול השוואה עם פער לכל פלט של המודל וסט כיול עבורו.
- הערכת לוחות זמנים והרכב העבודה עם קריטריוני קבלה בכל שלב.
- רשימת סיכונים: פעולות שהתוסף המיועד לא יתמוך בהן ויהיה צורך להשאיר במעבד.
תארו את המשימה והעבירו את המודל עם סט הייחוס — נחזור עם הערכה ותוכנית עבודה. אם חלק מהנתונים אינו זמין, נתעד זאת כסיכון וניקח בחשבון בחישובים.