פריסת בינה מלאכותית על Raspberry Pi עם האצת חומרה

פריסת AI על Raspberry Pi: היכן נשבר פלט המודל

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

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

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

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

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

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

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

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

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

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

אפשרויות הרצת המודל: השוואת גישות

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

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

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

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

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

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

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

מה אנחנו מוסרים ללקוח: תצורות, סכמות, נהלים

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

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

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

מקרה בוחן: זיהוי מקומי על התקן היקפי

מה היה

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

מה עשינו ומה השגנו

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

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

שיעור האירועים המוחמצים ירד מ-11% ל-0.4% באותו מספר מצלמות ואותו אורך משמרת. הפעלות מחדש למשמרת: היו 6–8, הפכו לאפס במשך חודש תצפיות.

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

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

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

האם הלוח יתחמם יתר על המידה תחת עומס?

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

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

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

כיצד מוגבלת הגישה למכשיר עצמו?

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

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

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

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

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

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

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

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

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

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

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

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

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

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