אופטימיזציה ופריסה של מודלי AI על NVIDIA Jetson

פריסת AI על Jetson: היכן הביצועים נשברים

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

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

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

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

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

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

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

מה נותנת אופטימיזציה של המודל להתקן מסוים

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

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

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

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

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

פריסת מודלים על Jetson: השוואת גישות

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

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

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

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

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

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

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

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

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

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

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

ערכת תיעוד וקונפיגורציות לאחר היישום

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

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

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

מקרה בוחן: כיצד גדלה התפוקה על ההתקן

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

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

מה עובד מחדש בצינור

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

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

מדדים לפני ואחרי

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

במה נבדלת אופטימיזציה בשרת מעבודה על ההתקן

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

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

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

מה יקרה בעת התחממות במארז סגור?

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

איך אתם מוצאים את צוואר הבקבוק בעיבוד?

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

נדון במשימה: ממה להתחיל פריסה

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

כדי לחזור עם הערכה ותוכנית, ולא עם ניחושים, נדרש מהלקוח:

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

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

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

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