פיתוח Machine Learning (Core ML) לאפליקציות iOS

פיתוח Machine Learning (Core ML) לאפליקציות iOS

למה Core ML במקום עיבוד בענן?

המרת מודל מסביבת Python לייצור במובייל נתקלת מיד בבעיות של אי-תאימות פורמט, השהיית עיבוד, ואין מנגנון עדכון ללא שחרור ל-App Store. Core ML פותר את הבעיות הללו באופן טבעי – אבל רק אם הוא משולב כראוי בארכיטקטורת האפליקציה. השלמנו למעלה מ-50 אינטגרציות של Core ML ומבטיחים פעולה יציבה במכשירים החל מ-iPhone 8. עיבוד במכשיר מבטל עיכובי רשת ושומר על פרטיות נתוני המשתמש. לפרטים נוספים על יכולות Core ML, ראו את התיעוד הרשמי של Apple.

איך להימנע מטעויות נפוצות באינטגרציית Core ML

הטעות הנפוצה ביותר היא המרת מודל מבלי להתחשב בחומרת היעד. coremltools מאפשר לך לציין minimum_deployment_target וסוג יחידת עיבוד: cpuOnly, cpuAndGPU, cpuAndNeuralEngine. אם תשמיט cpuAndNeuralEngine עבור A12+, המודל לא ירוץ על Neural Engine ויבוצע על CPU, מה שאיטי פי 5–10 עבור רשתות קונבולוציה. המהנדסים שלנו מוסמכים על ידי Apple ותמיד בוחרים בתצורה האופטימלית.

בעיה שנייה היא פורמט הקלט. Core ML מצפה ל-CVPixelBuffer עם kCVPixelFormatType ספציפי. אם האפליקציה מקבלת UIImage מהמצלמה דרך AVCapturePhotoOutput, יש צורך בהמרת ביניים דרך CIImage → CVPixelBuffer. ביצוע זה על ה-main thread הוא דרך בטוחה לאובדן פריימים. כל שרשרת הצילום והעיבוד צריכה לרוץ על DispatchQueue עם .userInteractive QoS או דרך מסגרת Vision, שמנהלת את הבופרים בעצמה.

Vision + CoreML הוא השילוב הנכון לרוב המשימות: VNCoreMLRequest מטפל בקנה מידה, נורמליזציה וניהול בופרים. אבל אם אתה צריך עיבוד רציף על זרם וידאו, השתמש ב-VNSequenceRequestHandler – הוא שומר מצב בין פריימים.

איך אנחנו מבטיחים מהירות עיבוד

אנחנו מתחילים בביקורת של המודל המקורי: פורמט (ONNX, TensorFlow SavedModel, PyTorch TorchScript), גודל משקלים, מספר פעולות. להמרה אנו משתמשים ב-coremltools 7.x, למודלים מכומתים – ct.optimize.coreml עם LinearQuantizer או PalettizationConfig. כימות 8-bit מקטין את גודל המודל פי 4 ללא אובדן דיוק משמעותי ברוב המסווגים.

דוגמה מהפרקטיקה: לקוח פינטק רצה זיהוי זיוף מסמכים במכשיר. מודל TFLite המקורי (MobileNetV3, 12 MB) לקח 280 ms ב-iPhone 12. לאחר המרה ל-.mlpackage עם computeUnits = .cpuAndNeuralEngine ודחיסת Float16 – 34 ms באותו מכשיר. בנוסף, עטפנו את העיבוד ב-MLModelConfiguration עם allowLowPrecisionAccumulationOnGPU = true. החיסכון בתשתית השרת הגיע עד 70%.

נתונים מהדוגמה הרשמית של מדריך האופטימיזציה של Apple Core ML אם אתה רוצה אופטימיזציה דומה, צור קשר לביקורת של המודל שלך.

מה מספק כימות מודל?

כימות 8-bit באמצעות LinearQuantizer מקטין את גודל המודל פי 4 ומאיץ את העיבוד עד פי 2 בחומרה נתמכת. למשימות סיווג, ירידת הדיוק היא פחות מ-1%. אם נדרש דיוק מקסימלי, אנו משתמשים בחצי דיוק (Float16) – הגודל קטן בחצי ללא אובדן דיוק. הניסיון שלנו מראה שרוב המודלים ניתנים לכימות בטוח ל-8-bit.

איך אנחנו מעדכנים מודלים ללא שחרור

כדי לעדכן מודלים ללא שחרור, אנו מגדירים הורדה דרך CloudKit או אחסון מותאם S3. MLModel(contentsOf:) מקבל URL מקומי – המודל מורד ברקע, מאומת עם SHA-256, ומוחלף אטומית באמצעות FileManager.replaceItem. הגרסה הישנה נשמרת כגיבוי.

מבחינה ארכיטקטונית, כל שכבת ה-ML מבודדת למודול נפרד (Swift Package) עם פרוטוקול MLInferenceService. זה מאפשר החלפת יישומים בבדיקות ושימוש חוזר במספר יעדים.

מה כלול בעבודה

1. ביקורת של המודל המקורי ובחירת נתיב ההמרה.
2. המרה ל-.mlmodel / .mlpackage דרך coremltools.
3. אופטימיזציה: כימות, pruning, בחירת יחידת עיבוד.
4. אינטגרציה דרך Vision או API ישיר של MLModel.
5. הגדרת עדכוני מודל OTA (CloudKit / S3).
6. בדיקות יחידה של העיבוד עם קלט/פלט ייחוס.
7. פרופילינג דרך Xcode Instruments (Core ML Instrument).

קבל ייעוץ על אינטגרציית Core ML עוד היום. צור קשר לביקורת של המודל שלך – נחשב לוחות זמנים ועלות.

לוח זמנים

אינטגרציה של מודל מומר מוכן לאפליקציה קיימת – מ-3 עד 5 ימי עסקים. אם נדרשים המרה, אופטימיזציה והגדרת עדכוני OTA מאפס – 1–2 שבועות. העלות מחושבת באופן אישי לאחר ניתוח הדרישות והמודל המקורי.