Запуск 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) Чому вибір делегата критичний для продуктивності?
| Делегат | Вимоги | Прискорення vs CPU | Обмеження |
|---|---|---|---|
| GPU Delegate | OpenGL ES 3.1 / Vulkan | 3–7× | Не всі операції (FP32/FP16) |
| NNAPI | Android 8.1+, NPU/DSP | 2–10× | Залежить від чипа, нестабільний на старих ROM |
| Hexagon (QC) | Snapdragon з DSP | 3–8× | Тільки Qualcomm |
| XNNPACK | CPU | baseline | — |
Ми використовуємо гібридну конфігурацію: 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. Якщо розбіжність вища, повертаємося до етапу конвертації: змінюємо оптимізації або замінюємо чутливі шари.
Таблиця продуктивності на різних чипах (приклад)
| Пристрій | Чип | GPU Delegate (ms) | CPU (ms) | Прискорення |
|---|---|---|---|---|
| Pixel 6 | Tensor | 12 | 85 | 7× |
| Samsung A21s | Exynos | 45 (fallback CPU) | 150 | ~3× |
| Xiaomi Redmi Note 8 | Snapdragon 665 | 22 | 95 | 4.3× |
Що входить в роботу
- Конвертація моделі з вашого фреймворку (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 для автомобільної та медичної індустрії. Зв'яжіться з нами для точної оцінки вашого завдання — ми надішлемо план і терміни безкоштовно.