Інтеграція On-Device ML моделі (TensorFlow Lite) для офлайн AI в Android-застосунку

Інтеграція On-Device ML моделі (TensorFlow Lite) для офлайн AI у Android додатках

TensorFlow Lite—стандарт де-факто для запуску ML-моделей на Android. Але «додати tflite файл до assets»—це лише початок. Реальна інтеграція включає вибір делегату прискорення, управління пам'яттю буферів, обробку несумісностей пристроїв та тестування числової точності.

Конвертація моделі у TFLite

З PyTorch через ONNX:

# PyTorch → ONNX
python -c "
import torch, onnx
model = MyModel(); model.eval()
torch.onnx.export(model, torch.zeros(1,3,224,224), 'model.onnx',
    opset_version=17, input_names=['input'], output_names=['output'])
"

# ONNX → TFLite через onnx-tf
pip install onnx-tf tensorflow
onnx-tf convert -i model.onnx -o model_tf
tflite_convert --saved_model_dir=model_tf --output_file=model.tflite

Або безпосередньо з TensorFlow SavedModel:

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

Делегати прискорення: що вибрати

// GPU Delegate—найбільш універсальний
import org.tensorflow.lite.gpu.GpuDelegate
import org.tensorflow.lite.gpu.CompatibilityList

val compatList = CompatibilityList()
val options = Interpreter.Options()

if (compatList.isDelegateSupportedOnThisDevice) {
    val delegateOptions = compatList.bestOptionsForThisDevice
    options.addDelegate(GpuDelegate(delegateOptions))
} else {
    // Fallback: NNAPI або CPU з XNNPACK
    options.setUseNNAPI(true)
    options.setUseXNNPACK(true)
}
options.setNumThreads(4)

val interpreter = Interpreter(
    FileUtil.loadMappedFile(context, "model_fp16.tflite"),
    options
)

NNAPI на практиці нестійкий: на одних пристроях дає 5× прискорення, на інших—краш з NNAPIDelegate: Failed to invoke the model через несумісні операції. Обов'язково—try/catch з fallback на CPU:

try {
    options.setUseNNAPI(true)
    interpreter = Interpreter(modelBuffer, options)
    // Тестовий прогон для перевірки
    interpreter.run(testInput, testOutput)
} catch (e: Exception) {
    Log.w("ML", "NNAPI failed, falling back to CPU: ${e.message}")
    options.setUseNNAPI(false)
    interpreter = Interpreter(modelBuffer, options)
}

Управління буферами: ByteBuffer проти TensorBuffer

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

// Через TFLite Support Library (рекомендую)
val imageProcessor = ImageProcessor.Builder()
    .add(ResizeOp(224, 224, ResizeOp.ResizeMethod.BILINEAR))
    .add(NormalizeOp(127.5f, 127.5f))  // нормалізація [-1, 1]
    .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

ResizeOp на CPU неочікувано повільний для великих зображень (Full HD → 224×224 займає 20–40 мс). Альтернатива: попередній ресайз через Bitmap.createScaledBitmap() або через RenderScript (застарілий) / Camera2 вихідний розмір.

Інтеграція CameraX

val imageAnalyzer = ImageAnalysis.Builder()
    .setTargetResolution(Size(640, 480))
    .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST)  // не копимо чергу
    .build()
    .also {
        it.setAnalyzer(cameraExecutor) { imageProxy ->
            val bitmap = imageProxy.toBitmap()
            runInference(bitmap)
            imageProxy.close()  // КРИТИЧНО: інакше CameraX зависнє
        }
    }

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

Числова точність після конвертації

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

Для перевірки—порівнюємо виходи оригінальної PyTorch моделі та TFLite на однакових входах:

# Тест збігу виходів
import numpy as np
original_out = pytorch_model(test_input).detach().numpy()
tflite_out = run_tflite(interpreter, test_input)
print(f"Max difference: {np.max(np.abs(original_out - tflite_out))}")
# Норма: < 0.01 для FP16, < 0.05 для INT8

Розміщення моделі

.tflite файл—у assets/. При першому запуску копіюємо в filesDir або використовуємо MappedByteBuffer напрямку з assets для zero-copy завантаження:

fun loadModelFile(context: Context, filename: String): MappedByteBuffer {
    val fileDescriptor = context.assets.openFd(filename)
    val inputStream = FileInputStream(fileDescriptor.fileDescriptor)
    return inputStream.channel.map(
        FileChannel.MapMode.READ_ONLY,
        fileDescriptor.startOffset,
        fileDescriptor.declaredLength
    )
}

MappedByteBuffer—OS не копіює файл у RAM при завантаженні, а маппує напрямку. Для великих моделей (50–200 MB) істотно.

Процес

Конвертація з вихідного формату → оцінка делегатів на цільових пристроях → інтеграція з fallback-логікою → тест числової точності → профілювання через Android Profiler + TFLite Model Benchmark Tool.

Кошторис за часом

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