Офлайн AI-моделі на Android: TensorFlow Lite з GPU/NNAPI-прискоренням

Запуск ML-моделі TensorFlow Lite на Android: офлайн AI без інтернету

Ми часто стикаємося з ситуацією: у вас є навчена модель детекції об'єктів на PyTorch, і ви хочете запускати її на смартфоні без інтернету. Ви конвертуєте її в TensorFlow Lite, додаєте в assets — і на тестовому Pixel 6 все літає. Але на Samsung Galaxy A21s (Exynos) застосунок вилітає з OutOfMemoryError, а на Xiaomi Redmi Note 8 (Qualcomm) — працює, але гальмує. Причина — у виборі делегата прискорення та управлінні пам'яттю. TensorFlow Lite — стандарт де-факто для on-device ML, але його інтеграція потребує глибокого розуміння апаратних особливостей. Економія на хмарних обчисленнях сягає 90% — це може становити тисячі доларів на місяць для production-сервісу, але тільки за правильної реалізації. Наша команда розробила рішення для 40+ проєктів, середня економія склала $1500–$3000 на місяць на клієнтських проєктах. Витрати на хмарні обчислення можуть сягати $10 000 на місяць, офлайн-рішення окупається за 2–3 місяці.

TensorFlow Lite official documentation

Як конвертувати модель з мінімальними втратами?

Перше, що потрібно зробити — експортувати модель з 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)

Чому вибір делегата критичний для продуктивності?

Ми використовуємо гібридну конфігурацію: GPU з fallback на 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 vs TensorBuffer

Пряме управління ByteBuffer — швидше, але багатослівно. TensorBuffer з org.tensorflow.lite.support — зручніше і менш схильне до помилок:

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 зависне
            }
        }
    }

imageProxy.close() в блоці finally — не опціонально. Якщо не закрити ImageProxy, CameraX перестає доставляти нові кадри через кілька секунд.

Чому важлива числова точність після квантизації?

Після конвертації обов'язково перевіряємо точність на тестовому наборі. FP16 зазвичай втрачає <1%, INT8 — 1–3%. Якщо втрати більші — калібрувальний датасет занадто малий або модель чутлива до конкретних шарів. Нормальне максимальне відхилення — 0.01 для FP16 і 0.05 для INT8. Якщо розбіжність вища, повертаємося до етапу конвертації: змінюємо оптимізації або замінюємо чутливі шари.

Таблиця продуктивності на різних чипах (приклад)

Що входить в роботу

• Конвертація моделі з вашого фреймворку (PyTorch, ONNX, SavedModel) з підбором оптимізацій.
• Вибір та налаштування делегата з fallback-логікою.
• Інтеграція з CameraX або іншим джерелом даних.
• Тестування числової точності та профілювання на Android Profiler + TFLite Benchmark Tool.
• Збірка на 10+ фізичних пристроях (різні чипи, версії Android).
• Документація (API опис, архітектура рішення), доступ до репозиторію з кодом, навчання розробника та 2 тижні підтримки.

Типові помилки при інтеграції TFLite

• Забули закрити ImageProxy — потік кадрів зупиняється.
• Не перевірили підтримку делегата на пристрої — вильоти на старих чипах.
• Використовували INT8 без калібрування — падіння точності >10%.
• Завантажували модель в RAM без MappedByteBuffer — OOM на пристроях з 2 ГБ.

Орієнтири за термінами

Базова інтеграція TFLite моделі в Android — 1–2 тижні. З мультиделегатною логікою, CameraX pipeline, тестуванням на парку пристроїв — 3–5 тижнів. Вартість робіт розраховується індивідуально залежно від складності. Отримайте консультацію для вашого завдання — ми розрахуємо терміни та вартість.

Ми — команда з досвідом in-house ML-розробки, сертифіковані інженери Google. За нашими плечима 40+ проєктів, включаючи застосунки з офлайн AI для автомобільної та медичної індустрії. Зв'яжіться з нами для точної оцінки вашого завдання — ми надішлемо план і терміни.