פיתוח AI למערכות משובצות (Embedded AI)

Embedded AI: היכן המודל נשבר על חומרה אמיתית

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

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

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

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

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

מה נותנת הרצת המודל על ההתקן עצמו

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

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

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

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

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

Embedded AI: השוואת מצבי פריסה

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

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

איך מתנהל הפרויקט: מביקורת המודל ועד למסירה

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

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

ערכת מסירה: ארטיפקטים, תרשימים, נהלים

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

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

המסירה נסגרת כאשר המהנדסים שלכם, בלי участиינו, מוציאים גרסה חדשה של המודל ומחזירים את הקודמת.

מקרה בוחן: קו בקרת איכות עבר להרצה מקומית

הלקוח — מפעל עם שלושה קווי מילוי. בקרת האיכות נשענה על בדיקה מדגמית של מפעיל ומצלמה ששלחה פריימים לשרת מחוץ לאולם. כשהערוץ צר, הפריימים הצטברו בבאפר, והחלטה על בקבוק הגיעה כשהוא כבר עמד על המשטח: להוציא אותו מהמשלוח משמעו מיונים ידניים של המנה. שיעור הפגמים שהוחמצו עמד על 3-4%, ותקלה בהרצה הבחינו בירידת הקצב — בממוצע כעבור 6-8 דקות.

מה עשינו

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

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

מה השתנה

• פגמים שהוחמצו למשלוח — מ-3,8% ל-0,7%: ההחלטה מתקבלת לגבי כל יחידה, ולא לפי מדגם למשמרת.
• זמן תגובה לתקלה — מ-6-8 דקות ל-2-3 שניות: כשל מאיץ נראה מיד, הקו נעצר לפי אות ולא לפי סרט ריק.
• נפח הנתונים היוצאים מהאתר — מזרם וידאו מלא ליומן אירועים: לאחסון חיצוני עוברים רק תגי פגמים ומונים.
• פסילות שגויות — פחות בשליש לאחר כיול הסף על פגמים שנצברו בקו.

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

במה שונה הרצה על ההתקן מעיבוד בשער

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

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

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

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

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

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

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

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

האם הפתרון יתאים לציוד שכבר יש לנו?

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

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

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

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

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

כדי שההערכה תהיה הנדסית ולא «בעין», נדרש מכם מינימום:

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

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

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

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