בינה מלאכותית לא מקוונת באנדרואיד: TensorFlow Lite עם האצת GPU/NNAPI

בינה מלאכותית לא מקוונת באנדרואיד: TensorFlow Lite עם האצת GPU/NNAPI

לעתים קרובות אנו נתקלים במצב הזה: יש לכם מודל זיהוי עצמים מאומן ב-PyTorch ואתם רוצים להריץ אותו על סמארטפון ללא אינטרנט. אתם ממירים אותו ל-TensorFlow Lite, מוסיפים אותו ל-assets—וב-Pixel 6 לבדיקה הוא טס. אבל על Samsung Galaxy A21s (Exynos) האפליקציה קורסת עם OutOfMemoryError, ועל Xiaomi Redmi Note 8 (Qualcomm) היא עובדת אבל מגמגמת. הסיבה היא בחירת ה-delegate לזירוז וניהול הזיכרון. TensorFlow Lite הוא התקן דה-פקטו ל-ML על המכשיר, אבל השילוב שלו דורש הבנה מעמיקה של מאפייני החומרה. החיסכון במחשוב ענן יכול להגיע ל-90%—אלפי דולרים בחודש עבור שירות ייצור—אבל רק עם יישום נכון. הצוות שלנו סיפק פתרונות ל-40+ פרויקטים, עם חיסכון ממוצע של $1500–$3000 בחודש לכל לקוח. עבור לקוח לוגיסטי אחד, פרסנו מודל זיהוי חבילות על סורקי אנדרואיד, וקיצצנו את עלויות עיבוד הענן מ-$5,000 בחודש לכמעט אפס. הפתרון החזיר את עצמו תוך פחות משני חודשים.

תיעוד רשמי של TensorFlow Lite

איך להמיר מודל עם אובדן מינימלי?

השלב הראשון הוא לייצא את המודל מ-PyTorch/ONNX ל-TensorFlow. לאחר מכן השתמשו ב-TFLiteConverter עם אופטימיזציות. עבור INT8, כוילו על מערך נתונים מייצג. דוגמה:

converter = tf.lite.TFLiteConverter.from_saved_model("model_tf")
converter.optimizations = [tf.lite.Optimize.DEFAULT] # динамическая квантизация FP16
converter.target_spec.supported_types = [tf.float16] # для GPU delegate
converter.representative_dataset = representative_dataset # для INT8 (калибровка)
tflite_model = converter.convert()
with open("model_fp16.tflite", "wb") as f:
    f.write(tflite_model)

למה בחירת ה-Delegate קריטית לביצועים?

אנו משתמשים בתצורה היברידית: GPU עם גיבוי ל-XNNPACK ו-NNAPI כמוצא אחרון. כך זה נראה בקוד:

import org.tensorflow.lite.gpu.GpuDelegate
import org.tensorflow.lite.gpu.CompatibilityList

val compatList = CompatibilityList()
val options = Interpreter.Options().apply {
    if (compatList.isDelegateSupportedOnThisDevice) {
        addDelegate(GpuDelegate(compatList.bestOptionsForThisDevice))
    } else {
        // Fallback: сначала NNAPI, если не сработает — XNNPACK
        setUseNNAPI(true)
        setUseXNNPACK(true)
    }
    setNumThreads(Runtime.getRuntime().availableProcessors())
}

var interpreter: Interpreter? = null
try {
    interpreter = Interpreter(FileUtil.loadMappedFile(context, "model_fp16.tflite"), options)
    // Тестовый прогон (нужен для выявления ошибок NNAPI)
    interpreter.run(testInput, testOutput)
} catch (e: Exception) {
    Log.w("ML", "NNAPI failed, fallback to CPU: ${e.message}")
    options.setUseNNAPI(false)
    interpreter = Interpreter(modelBuffer, options)
}

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

ניהול באפרים: ByteBuffer לעומת TensorBuffer

ניהול ישיר של converter = tf.lite.TFLiteConverter.from_saved_model("model_tf") converter.optimizations = [tf.lite.Optimize.DEFAULT] # динамическая квантизация FP16 converter.target_spec.supported_types = [tf.float16] # для GPU delegate converter.representative_dataset = representative_dataset # для INT8 (калибровка) tflite_model = converter.convert() with open("model_fp16.tflite", "wb") as f: f.write(tflite_model) מהיר יותר אבל מפורט. import org.tensorflow.lite.gpu.GpuDelegate import org.tensorflow.lite.gpu.CompatibilityList val compatList = CompatibilityList() val options = Interpreter.Options().apply { if (compatList.isDelegateSupportedOnThisDevice) { addDelegate(GpuDelegate(compatList.bestOptionsForThisDevice)) } else { // Fallback: сначала NNAPI, если не сработает — XNNPACK setUseNNAPI(true) setUseXNNPACK(true) } setNumThreads(Runtime.getRuntime().availableProcessors()) } var interpreter: Interpreter? = null try { interpreter = Interpreter(FileUtil.loadMappedFile(context, "model_fp16.tflite"), options) // Тестовый прогон (нужен для выявления ошибок NNAPI) interpreter.run(testInput, testOutput) } catch (e: Exception) { Log.w("ML", "NNAPI failed, fallback to CPU: ${e.message}") options.setUseNNAPI(false) interpreter = Interpreter(modelBuffer, options) } מ-ByteBuffer נוח יותר ופחות מועד לשגיאות:

import org.tensorflow.lite.support.image.ImageProcessor
import org.tensorflow.lite.support.image.TensorImage
import org.tensorflow.lite.support.common.ops.NormalizeOp
import org.tensorflow.lite.support.image.ops.ResizeOp

val imageProcessor = ImageProcessor.Builder()
    .add(ResizeOp(224, 224, ResizeOp.ResizeMethod.BILINEAR))
    .add(NormalizeOp(127.5f, 127.5f))
    .build()

val tensorImage = TensorImage(DataType.FLOAT32)
tensorImage.load(bitmap)
val processedImage = imageProcessor.process(tensorImage)

val outputBuffer = TensorBuffer.createFixedSize(intArrayOf(1, 1000), DataType.FLOAT32)
interpreter.run(processedImage.buffer, outputBuffer.buffer)
val probabilities = outputBuffer.floatArray
val topIndex = probabilities.indices.maxByOrNull { probabilities[it] } ?: -1

שילוב CameraX

val imageAnalyzer = ImageAnalysis.Builder()
    .setTargetResolution(Size(640, 480))
    .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST)
    .build()
    .also { it.setAnalyzer(cameraExecutor) { imageProxy ->
        try {
            val bitmap = imageProxy.toBitmap()
            runInference(bitmap)
        } finally {
            imageProxy.close() // КРИТИЧНО: иначе CameraX зависнет
        }
    } }

TensorBuffer בתוך בלוק org.tensorflow.lite.support אינו אופציונלי. אם לא סוגרים את ה-ImageProxy, CameraX מפסיק לספק פריימים חדשים אחרי כמה שניות.

למה דיוק מספרי לאחר קוונטיזציה חשוב?

לאחר ההמרה, תמיד בדקו דיוק על מערך בדיקה. FP16 בדרך כלל מאבד <1%, INT8 מאבד 1–3%. אם האובדן גדול יותר, ייתכן שמערך הכיול קטן מדי או שהמודל רגיש לשכבות מסוימות. סטייה מקסימלית תקינה היא 0.01 עבור FP16 ו-0.05 עבור INT8. אם הסטייה גבוהה יותר, חזרו להמרה: שנו אופטימיזציות או החליפו שכבות רגישות.

טבלת ביצועים על שבבים שונים (דוגמה)

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

• המרת מודל מהפריימוורק שלכם (PyTorch, ONNX, SavedModel) עם בחירת אופטימיזציות.
• בחירת Delegate והתקנה עם לוגיקת גיבוי.
• שילוב עם CameraX או מקור נתונים אחר.
• בדיקת דיוק מספרי ופרופיילינג עם Android Profiler + TFLite Benchmark Tool.
• בדיקת בנייה על 10+ מכשירים פיזיים (שבבים שונים, גרסאות אנדרואיד).
• תיעוד (תיאור API, ארכיטקטורה), גישה למאגר הקוד, הדרכת מפתחים ושבועיים של תמיכה.

טעויות נפוצות בשילוב TFLite

• שכחת סגירת ImageProxy—זרם הפריימים נעצר.
• אי בדיקת תמיכת Delegate במכשיר—קריסות על שבבים ישנים.
• שימוש ב-INT8 ללא כיול—ירידת דיוק >10%.
• טעינת המודל ל-RAM ללא MappedByteBuffer—OOM במכשירים עם 2 GB RAM.

הערכות זמן

שילוב מודל TFLite בסיסי באנדרואיד לוקח 1–2 שבועות. עם לוגיקת multi-delegate, צינור CameraX, בדיקות על פארק מכשירים—3–5 שבועות. העלות מחושבת באופן אישי לפי מורכבות. קבלו ייעוץ למשימה שלכם—נספק לוחות זמנים ועלות.

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