פיתוח PyTorch Mobile: היכן האינפרנס נשבר על המכשיר
המודל אומן, המדדים על הוולידציה תקינים, אבל על המכשיר התוצאה לא תואמת לזו שבשרת. הסיבה כמעט תמיד בפער בין מסלולי החישוב: בשרת פועלים אופרטורים מסוימים עם נקודה צפה, בטלפון — ליבות מכומתות, וחלק מהשכבות מתפרשות אחרת.
השגיאה מצטברת לאורך השכבות ובפלט נותנת מחלקה אחרת או קואורדינטה מוסטת. זה נתפס רק על ידי השוואת פלטים על אותה קבוצת קלטים — מריצים את הבאטצ' הייחוס דרך בניית השרת ובניית המובייל ובוחנים את הפער בכל פלט, ולא לפי הדיוק הסופי.
הכשל השני — עלייה בזמן התגובה. על הנייר המודל נכנס בתקציב, אבל על מכשיר חי מתערבים בו חימום, החלפת תהליכונים ועבודה עם זיכרון. האינפרנס הראשון לאחר ההפעלה תמיד איטי יותר מהבאים אחריו, ולכן מדידה "בממוצע" משקרת.
אנחנו מסירים את ההתפלגות: זמן התנעה קרה, זמן מתייצב, התנהגות תחת עומס כשהממשק פעיל. אם שכבות כבדות נתקעות בתהליכון אחד, עוזרת חלוקה מחדש של החישובים והוצאת חלק מהעיבוד מחוץ למסלול הקריטי.
הכשל השלישי והיקר ביותר — קריסת האפליקציה במכשירים חלשים. מודל שחי בשלווה על מכשיר דגל, בטלפון תקציבי נתקע בזיכרון הזמין ומועבר על ידי המערכת.
מכאן שני כיווני עבודה: בקרת צריכת הזיכרון בשיא בעת טעינת המשקלים והתדרדרות תקינה, כשהמשאבים לא מספיקים — מעבר לענף מודל מוקל במקום סיום חירום.
כל שלושת הכשלים קשורים זה לזה: אופטימיזציה למהירות כמעט תמיד משנה את התוצאה המספרית, וחסכון בזיכרון משפיע על שני המדדים. לכן אנחנו מפרקים אותם יחד — כמעגל אחד, ולא בנפרד.
מה נותן מעבר המודל אל המכשיר
מעבר המודל אל המכשיר משנה את הפיזיקה של פעולת האפליקציה: האינפרנס מתבצע באופן מקומי, והתוצאה אינה תלויה באיכות הערוץ ברגע הבקשה.
עבור תרחישים שבהם המשתמש מצלם, מזהה או מסווג משהו "כאן ועכשיו", זה מהותי — האפליקציה עובדת באופן לא מקוון, ואינה מדרדרת לכדי placeholder עם אובדן הרשת.
העומס על השרת מפסיק להתאים את עצמו למספר המשתמשים. בעבר כל פריים או בקשה נשלחו לענן, ופעילות שיא הפכה לתור בבקאנד; כעת החישוב מפוזר בין המכשירים, והשרת עוסק רק בסנכרון ובעדכון המשקולות.
זמן התגובה הופך לצפוי מראש: אין סבב רשת, אין המתנה בתור — ההשהיה נקבעת רק על ידי המכשיר והיא יציבה מבקשה לבקשה.
אפקט נפרד — נעלם סוג שלם של כשלים הקשורים לניתוק הקשר ולפסקי זמן: במקום שבו בעבר המשתמש ראה שגיאה, האפליקציה ממשיכה לעבוד. פרטיות הנתונים מתחזקת כנגזרת: תמונות גולמיות, אודיו וטקסט אינם עוזבים את המכשיר, החוצה יוצאת רק התוצאה, אם היא בכלל נדרשת.
אנחנו מרכיבים את האינפרנס על PyTorch Mobile — זהו ענף בוגר עם קוונטיזציה והאצה חומרתית, ולכן המודל נכנס לגודל סביר ואינו אוכל את הסוללה.
מה זה נותן במספרים: שיעור הבקשות היוצאות לשרת יורד לאפס עבור תרחישים לא מקוונים, זמן התגובה מפסיק להיות תלוי ברשת, והוצאות על תשתית מפסיקות לגדול יחד עם קהל המשתמשים.
דרכים להפעיל מודל בטלפון: השוואה
בחירת נקודת האינפרנס היא ההחלטה הארכיטקטונית הראשונה שקובעת גם את גודל האפליקציה, גם את תרחישי העבודה ללא רשת, וגם את עלות החלק השרתי. להלן שלוש סכמות עבודה שממש בוחרים ביניהן בתחילת הפרויקט, עם תנאי ההתאמה ומה שכל אחת מגבילה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כולו על המכשיר | השהיה חשובה יותר מדיוק: זיהוי דיבור, מצלמה, מחוות, תיוג תמונות. נדרשת עבודה אופליין ובלי העברת נתונים החוצה | המודל מכווץ לתקציב הזיכרון והחום; מחלקות נדירות מאבדות דיוק; עדכון — רק עם שחרור גרסה חדשה של האפליקציה |
| סכמה היברידית | החלק הכבד מחושב בשרת, הקל — בטלפון: סינון מקדים של פריימים באופן מקומי, ניתוח מדויק בענן | נדרש חוזה מדויק בין החלקים וירידה בביצועים ברשת גרועה; קשה יותר לבדוק |
| אינפרנס שרתי בלבד | המודל מאומן מחדש לעיתים קרובות, נדרשים משקלות עדכניים וגרסה אחידה לכל הלקוחות | ללא רשת הפונקציה לא עובדת; ההשהיה תלויה בערוץ; הוצאות החישוב גדלות יחד עם מספר המשתמשים הפעילים |
סכמה היברידית בדרך כלל מנצחת במקומות שבהם זרימת הנתונים גדולה, אך האירועים השימושיים מעטים: מסנן מקומי חותך את המיותר לפני השליחה, והשרת מקבל פריימים או מקטעים שכבר נבחרו.
זה מפחית גם את השהיית התגובה וגם את העומס על החלק השרתי, אך דורש לתאר במפורש מה קורה בעת ניתוק התקשורת — אחרת הפונקציה "קופאת" בלי הסבר למשתמש.
המגבלות חשובות יותר מהיכולות: במכשיר אתם מוגבלים בזיכרון, בחום ובזמן הסוללה, בשרת — בערוץ ובעלות החישוב. לכן את בחירת הגישה מקבעים לפני תחילת אופטימיזציה של המודל: להעביר רשת מוכנה מהשרת לטלפון בדיעבד כמעט תמיד יקר יותר מאשר להקצות מראש את התקציב הנדרש בגודל ובהשהיה.
שלבי יישום: מביקורת המודל ועד למסירה
העבודה מתחילה לא בקוד, אלא בביקורת המודל: בוחנים את הארכיטקטורה, טנסורי הקלט והפלט, תלויות באופרטורים של השרת שאינם נתמכים במכשיר. בשלב זה מזהים מה יצטרך להיכתב מחדש עבור אינפרנס במובייל ומה עובר כמו שהוא — זה מסיר מחצית מההפתעות בשלב האינטגרציה.
- ביקורת המודל והדרישות. מנתחים את הגרף, מודדים את איכות הייחוס וזמן האינפרנס בשרת, קובעים יעדים במכשיר: השהיית תגובה, צריכת זיכרון, התנהגות ללא רשת.
- תרשים האינטגרציה. קובעים היכן מחושב המודל — במכשיר, בשרת או באופן היברידי, כיצד האפליקציה מקבלת ומעדכנת משקלים, מה קורה בעת חוסר בזיכרון או שלילת הרשאות.
- המרה. ממירים את המודל לפורמט מובייל, מסירים אופרטורים לא נתמכים, בודקים שהפלטים תואמים לייחוס בטווח סטייה מותר.
- אופטימיזציה. קוונטיזציה של משקלים, מיזוג אופרטורים, גיזום ענפים מיותרים — שואפים לצמצום גודל הארטיפקט וזמן התגובה, בלי לאבד איכות מעבר לסף המוסכם.
- אינטגרציה באפליקציה. מטמיעים את האינפרנס בקוד הקיים, מפרידים אותו לתהליכון נפרד כדי שהממשק לא ייחסם, מגדירים טעינה ומטמון של משקלים.
- בדיקה. מריצים מערך בדיקות על מכשירים אמיתיים מסוגים שונים, משווים מדדים לייחוס השרתי, בודקים תרחישים ללא רשת ובמצב סוללה נמוכה.
- מסירה. מוסרים את הארטיפקטים שנבנו, קונפיגורציות, הוראות לעדכון המודל וניתוח המגבלות הידועות — כדי שהצוות יוכל לפתח את הפתרון בלעדינו.
כל שלב מסתיים בארטיפקט שניתן לבדוק: דוח ביקורת, תרשים, מודל מומר, מדידות לפני ואחרי אופטימיזציה. כך בכל שלב רואים מה נעשה ואיזו תוצאה הושגה.
מה הלקוח מקבל לידיו
אנחנו מעבירים לא "אפליקציה עובדת", אלא ערכה שלמה שלפיה הצוות שלכם יוכל לתחזק ולפתח את המודל בלעדינו. כל ארטיפקט סוגר סיכון מוגדר: הקשר שאבד, בנייה שאינה ניתנת לשחזור, זכויות לא ברורות על הנתונים.
- קונפיגורציות בנייה ואינפרנס — קבצים מגורסנים עם פרמטרים של קוונטיזציה, גודל טנזור הקלט וספי הפעלה. מאפשרים לבנות מחדש את המודל אחד לאחד ולהשוות את ההתנהגות במכשיר לזו של תקן הייחוס.
- תרשימי ארכיטקטורה וזרימות נתונים — מפריים של מצלמה או אות חיישן ועד לפלט התוצאה: היכן מתבצע העיבוד המקדים, היכן האינפרנס, היכן העיבוד המאוחר. לפיהם מהנדס חדש נכנס לפרויקט בתוך ימים, לא שבועות.
- מדיניות גישה והפרדת תפקידים — מי מבין העובדים שלכם יכול לייצא משקלות, לשנות קונפיגורציה ולפרסם בנייה. בנפרד מתארים כיצד מבוטלות הרשאות עם עזיבתו של אדם.
- נוהל עדכון המודל — סדר שלב אחר שלב: אימון, ולידציה על סט נפרד, בדיקה במכשיר, פריסה לחלק מהמשתמשים, נסיגה. עם קריטריונים שבהם הגרסה נחסמת אוטומטית.
- תיעוד הנתונים — מקור מערך הנתונים, התיוג, מגבלות המדגם, מחלקות שגיאה ידועות. בלי זה האיטרציה הבאה של האימון נתקלת באותם מכשולים.
- הוראות נסיגה — כיצד להחזיר את הגרסה הקודמת של המודל במכשיר ומה קורה לנתונים המקומיים שנצברו בעת הנסיגה.
- צ'ק-ליסט קבלה — מדדי איכות על צי המכשירים ביעד, ולא רק על השרת, ורשימת תרחישים שנבדקים לפני כל גרסה.
כל זה מועבר במאגר שלכם ובמערכת ניהול הגישות שלכם — לא בסביבה סגורה של הקבלן. תארו את המשימה, ונחזור עם הערכה ותוכנית: אילו ארטיפקטים דרושים דווקא לכם, ואילו מיותרים בהיקף שלכם.
מקרה בוחן: כיצד קוצר זמן התגובה והוסרו הכשלים
הלקוח — שירות משלוחים — הגיע עם בעיה קלאסית: מודל זיהוי המסמכים פעל על השרת, וכל סריקה נשלחה לרשת. בזמן תגובה ממוצע של 4-6 שניות בערוץ חלש המשתמשים נטשו את הפעולה, ובמקרה של אובדן רשת האפליקציה הציגה שגיאה ואיבדה את הצילום שכבר בוצע.
שיעור הניסיונות הכושלים הגיע ל-18%, וזה לא היה "ממשק איטי" אלא נשירה ישירה: השליח לא הצליח לסגור את ההזמנה והתקשר לתמיכה.
מה שינו
העבירו את האינפרנס למכשיר: המודל נבנה עבור מאיצים ניידים דרך PyTorch Mobile, הגרף נחתך והמשקולות הומרו לפורמט שנקרא ללא פריקה מלאה לזיכרון. העיקר — לא ההעברה עצמה, אלא מה שסביבה: תור משימות עם עדיפויות, מטמון מקומי של התוצאות האחרונות ופולבק תקין כאשר המודל אינו בטוח בתשובה.
אז גם הופרדו שני תרחישים: אם יש רשת — מקרים כבדים עוברים לשרת, אם אין — האפליקציה פועלת באופן אוטונומי ומסתנכרנת מאוחר יותר.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובה בערוץ חלש | 4-6 ש' | 0,4-0,8 ש' |
| שיעור הניסיונות הכושלים | 18% | 2% |
| כשלים בעת אובדן רשת | קבועים | הקטגוריה בוטלה |
| גודל האפליקציה | — | +9 MB להתקנה |
יש לציין בנפרד את הכשלים בעת אובדן רשת: בעבר זה היה תרחיש לא מטופל, כעת הפעולה מסתיימת באופן מקומי, והתוצאה נשלחת עם חידוש הקשר. התמיכה הפסיקה לקבל פניות "הסריקה לא נשלחה" — הן פשוט חדלו להתקיים כקטגוריה.
במה שונה אינפרנס מקומי מאינפרנס שרתי?
אינפרנס מקומי מחשב את המודל על מכשיר המשתמש, ואינפרנס שרתי — על התשתית שלכם, וההבדל מתבטא מיד בארבעה מישורים.
השהיה: המצב המקומי אינו תלוי באיכות הרשת — התשובה מגיעה בזמן החישוב על המכשיר, בעוד שהשרתי מוסיף לעיבוד את העברת הנתונים הלוך ושוב, וברשת חלשה דווקא העברה זו הופכת לצוואר הבקבוק.
תעבורה: באינפרנס מקומי לשרת מגיעים רק תוצאות מצטברות או טלמטריה, ולא הנתונים עצמם; בשרתי, דרך הערוץ עובר כל פריים, קטע טקסט או אות, והנפח גדל באופן ליניארי עם מספר המשתמשים הפעילים.
פרטיות — ההבדל המרכזי. אינפרנס מקומי מעבד נתונים אישיים, תמונות וקול בתוך המכשיר, ושום דבר אינו יוצא החוצה: הדבר מסיר סוג שלם של סיכונים בעבודה עם מידע רגיש ומפשט את העמידה בדרישות לעיבוד נתונים.
המצב השרתי דורש העברה מאובטחת, אחסון והפרדת הרשאות גישה — קשה יותר לשלוט בכך מאשר לא להוציא נתונים אל מחוץ להיקף כלל.
עדכון המודל בנוי באופן מראה. בשרת אתם מפרסמים גרסה חדשה במקום אחד, וכל הלקוחות עובדים איתה מיד — אך משמעות הדבר גם שהאפליקציה תלויה בזמינות השירות שלכם.
באופן מקומי המודל מסופק בתוך האפליקציה או נטען כארטיפקט נפרד, ולכן העדכון דורש שחרור בחנויות או מנגנון אספקת משקלים עם בדיקת שלמות ונסיגה לגרסה הקודמת.
בפועל לרוב משלבים בין המצבים: מה שקריטי להשהיה ולפרטיות מחושב על המכשיר, ומודלים כבדים או כאלה שנקראים לעיתים רחוקות נשארים בשרת. הבחירה מוכתבת על ידי פרופיל המשימה, ולא על ידי אופנה טכנולוגית.
ספקות טכניים לפני התחלה
לפני ההתחלה כמעט תמיד עולים אותם שאלות: האם המודל יעבוד על מגוון המכשירים, האם האפליקציה תתפח, כיצד לעדכן משקלים ללא פרסום בחנות. להלן תשובות קצרות לכל אחד, כדי להסיר אי-ודאות לפני הערכה.
תאימות: האם מודל שנבנה עבור PyTorch Mobile יעבוד על מכשירים ישנים?
אנו בונים את המודל עבור ענף הריצה (runtime) המיועד ובודקים על מגוון מכשירים אמיתי: גרסת מערכת ההפעלה המינימלית הנתמכת, מכשירים חלשים, סטים שונים של פקודות. אופרטורים כבדים שאינם קיימים ב-runtime הנייד מוחלפים במקבילות נתמכות או מועברים לשרת. בפלט — מטריצת תאימות: אילו מכשירים וגרסאות מערכת הפעלה מכוסים, היכן יש ירידה בדיוק או במהירות.
גודל המודל: האם האפליקציה לא תהפוך לכבדה מדי?
קוונטיזציה של משקלים, גיזום קשרים חסרי משמעות וחלוקת המודל לחלק בסיסי ולחלק נטען מחדש מביאים להקטנה משמעותית של גודל הארטיפקט. שכבות בסיסיות נכנסות לבנייה, כבדות — נטענות לפי דרישה. את התוספת הסופית לחבילת ההתקנה שומרים בגבולות שאינם משפיעים על המרת התקנות.
עדכונים: כיצד להחליף מודל ללא פרסום בחנות האפליקציות?
את המשקלים והתצורה מוציאים לארטיפקט נפרד עם ניהול גרסאות וחתימה. האפליקציה בודקת את הגרסה, טוענת את העדכון ועוברת אליו, תוך שמירת הקודם לחזרה לאחור. כך המודל מתעדכן ללא תלות בבנייה, ועדכון כושל מוחזר לאחור ללא מעורבות המשתמש.
ניפוי באגים על מכשירים: כיצד לתפוס בעיות שאינן נראות על האמולטור?
אוספים פרופיל ביצוע על מכשירים אמיתיים: זמן אינפרנס, צריכת זיכרון, התחממות, שיעור כשלים לפי סוגי מכשירים. הלוגים והמדדים עוברים למערכת ניטור משותפת, כך שרגרסיה נראית לפני פרסום. בנפרד בודקים התנהגות בעת חוסר בזיכרון וברקע.
תמיכה במכשירים: מה עם דגמים חדשים וגרסאות מערכת הפעלה?
שומרים את ה-runtime והמודל בענף מעודכן, ומגוון הבדיקות מתווסף במכשירים חדשים עם יציאתם. הרצות רגרסיה בכל פרסום מראות היכן ההתנהגות השתנתה. זה מאפשר להוסיף מכשירים ללא כתיבה מחדש של הלוגיקה.
נדון במשימה שלכם
כדי שההערכה תהיה עניינית ולא "פחות או יותר", אנחנו צריכים הקשר של המשימה. ספרו לנו מה כבר קיים ולאיזה תוצאה אתם שואפים — לאחר מכן נשאל שאלות הבהרה ונחזור עם תוכנית עבודה ולוחות זמנים לפי שלבים.
מה עוזר לנו להעריך את הפרויקט במהירות ובמדויק:
- מטרה ותרחיש שימוש. איזו משימה פותר המודל על המכשיר: זיהוי, סיווג, איתור, עיבוד אות — ומה נחשב לתוצאה מוצלחת עבור המשתמש.
- נתונים. מה קיים כעת: נפח, תיוג, פורמטים, מקורות. אם הנתונים מועטים או אינם מתויגים — זהו שלב נפרד שאנחנו מכניסים לתוכנית מראש.
- קוד וסטאק נוכחיים. האם קיים אב-טיפוס ב-PyTorch, במה מצב צינור האימון, מה כבר הועבר למכשיר.
- פלטפורמות יעד. iOS, Android או שתיהן; אילו מגבלות על גודל האפליקציה, זמן תגובה וצריכת סוללה הן קריטיות.
- תשתית. היכן מאמנים ומאחסנים מודלים, כיצד משחררים עדכונים כעת, האם יש דרישות לפרטיות נתונים על המכשיר.
- לוחות זמנים ועדיפויות. מה חשוב יותר — פיילוט מהיר על תרחיש אחד או אינטגרציה מלאה למוצר באפליקציה מיד.
לפי נתוני פתיחה אלה אנחנו מעריכים את היקף העבודה, את הסיכונים לאיכות המודל ולביצועים על המכשיר, וכן לוח זמנים ריאלי. אנחנו חוזרים עם פירוט לפי שלבים: הכנת נתונים, אימון וולידציה, המרה ואופטימיזציה לפלטפורמות מובייל, אינטגרציה באפליקציה, מדידות על מכשירים אמיתיים.
תארו את המשימה בצורה חופשית — גם אם חלק מהנתונים עדיין חסר. נבהיר את החסר ונציע תוכנית שאפשר לצאת ממנה לדרך.