Интеграция On-Device ML с ONNX Runtime для мобильных приложений

Представьте: мобильное приложение, которое должно обрабатывать изображения, текст или звук без доступа к сети. Задержки на сервер недопустимы, конфиденциальность данных критична. Каждый лишний мегабайт трафика — деньги пользователя. On-device ML решает эти проблемы, а ONNX Runtime — ключевой инструмент для кроссплатформенного развёртывания. Мы интегрируем его так, чтобы модель работала одинаково быстро на iOS и Android. Переход на on-device может снизить затраты на серверную инфраструктуру до 90%, экономя сотни тысяч рублей ежемесячно при высоких нагрузках.

ONNX Runtime Mobile привлекателен одним аргументом: одна модель — обе платформы. Конвертировали PyTorch или TensorFlow в ONNX, подключили onnxruntime-android и onnxruntime-objc, запускаете один и тот же .onnx файл. На практике разница в execution providers между iOS и Android всё равно требует платформо-специфичного кода, но сама модель едина. Наш опыт — более 5 лет в мобильном ML, десятки проектов с on-device инференсом. Свяжитесь с нами для оценки вашей модели и получения предварительного расчёта.

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

Стандартный ONNX экспорт из PyTorch:

import torch import onnx from onnxsim import simplify # onnx-simplifier для оптимизации графа model = MyModel(); model.eval() dummy = torch.zeros(1, 3, 224, 224) torch.onnx.export( model, dummy, "model.onnx", opset_version=17, input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch_size"}, "output": {0: "batch_size"}} ) # Упрощение графа — убирает лишние reshape, transpose, делает граф чище model_onnx = onnx.load("model.onnx") model_simplified, check = simplify(model_onnx) onnx.save(model_simplified, "model_simplified.onnx") 

Для мобиля дополнительно — квантизация через onnxruntime.quantization:

from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( "model_simplified.onnx", "model_int8.onnx", weight_type=QuantType.QInt8 ) # Размер модели уменьшается в ~4× против FP32 

Какой Execution Provider обеспечит максимальную производительность?

Android: NNAPI vs XNNPACK

На Android выбор Execution Provider зависит от железа. NNAPI делегирует операции на NPU/DSP, давая ускорение до 2x на поддерживаемых операциях. XNNPACK — оптимизированный CPU-бэкенд, использующий SIMD-инструкции, ускоряет до 2x на CPU, но без доступа к NPU. В проекте с детекцией объектов на MediaTek Dimensity мы получили 45 мс на NNAPI против 80 мс на XNNPACK. Рекомендуем использовать NNAPI для устройств с NPU, XNNPACK как fallback.

iOS: CoreML Execution Provider

appendCoreMLExecutionProvider на iOS 13+ делегирует поддерживаемые операции в Core ML, что даёт доступ к ANE. Операции, которые Core ML не поддерживает, автоматически выполняются на CPU. В тестах на iPhone 12 мы получили ускорение 35% относительно CPU на модели ResNet-50. CoreML EP удобен для быстрого кросс-платформенного деплоя, но для максимальной производительности стоит рассмотреть нативный Core ML.

Когда ONNX Runtime лучше нативных форматов?

Используйте ONNX Runtime для прототипирования, кросс-платформенных проектов, моделей с нестандартными операциями, которые coremltools не конвертирует, и при частых обновлениях модели без пересборки конвертационного пайплайна. Если вам нужна максимальная производительность на одной платформе, выбирайте нативный формат: на iOS — Core ML с полным ANE-ускорением (обычно быстрее ORT+CoreML EP на 20–40%), на Android — TFLite + GPU Delegate (в ряде случаев быстрее ORT+NNAPI). При одноплатформенном развёртывании и критичной производительности нативное решение предпочтительнее.

Как интегрировать ONNX Runtime на Android и iOS?

Android: подключение и запуск

// build.gradle implementation("com.microsoft.onnxruntime:onnxruntime-android:1.18.0") // Создание сессии val sessionOptions = OrtSession.SessionOptions().apply { // NNAPI Execution Provider для Android NPU/DSP addNnapi(NNAPIFlags.USE_FP16) // FP16 режим в NNAPI // Или: addXnnpack(mapOf()) для XNNPACK (CPU SIMD) setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT) setIntraOpNumThreads(4) } val env = OrtEnvironment.getEnvironment() val session = env.createSession( context.assets.open("model_simplified.onnx").readBytes(), sessionOptions ) // Инференс val inputTensor = OnnxTensor.createTensor( env, FloatBuffer.wrap(preprocessedArray), longArrayOf(1, 3, 224, 224) ) val results = session.run(mapOf("input" to inputTensor)) val outputArray = (results["output"]?.value as Array<FloatArray>)[0] // Освобождение ресурсов — обязательно inputTensor.close() results.close() 

Утечки через незакрытые OnnxTensor и OrtSession.Result — частая проблема. В Kotlin используем use {} блок: results.use { ... }.

iOS: ObjC/Swift интеграция

// Package.swift или Podfile: pod 'onnxruntime-objc' import onnxruntime_objc // Настройка let env = try ORTEnv(loggingLevel: ORTLoggingLevel.warning) let options = try ORTSessionOptions() try options.setIntraOpNumThreads(4) // На iOS — CoreML Execution Provider try options.appendCoreMLExecutionProvider(withFlags: [.enableOnSubgraphs]) let session = try ORTSession( env: env, modelPath: Bundle.main.path(forResource: "model_simplified", ofType: "onnx")!, sessionOptions: options ) // Подготовка входа let inputShape: [NSNumber] = [1, 3, 224, 224] let inputData = Data(bytes: preprocessedFloats, count: preprocessedFloats.count * MemoryLayout<Float>.size) let inputTensor = try ORTValue( tensorData: NSMutableData(data: inputData), elementType: .float, shape: inputShape ) let outputs = try session.run( withInputs: ["input": inputTensor], outputNames: ["output"], runOptions: nil ) let outputTensor = outputs["output"]! let outputData = try outputTensor.tensorData() as Data let floats = outputData.withUnsafeBytes { Array($0.bindMemory(to: Float.self)) } 

Почему квантизация критична для мобильного инференса?

Квантизация уменьшает размер модели в 4 раза (50 MB → 12 MB), снижает потребление памяти и ускоряет инференс на CPU на 30-40%. Dynamic квантизация не требует калибровочных данных, но даёт чуть меньший прирост скорости, чем static. На практике мы используем static квантизацию с репрезентативным датасетом — это даёт стабильный прирост без значительной потери точности (0.5-2%).

Что делать, если операция не поддерживается?

# Проверить, какие операции поддерживает NNAPI Execution Provider python -m onnxruntime.tools.check_nnapi_supported_ops --model model.onnx # Если операция не поддерживается — она выполнится на CPU (fallback) # Это не краш, но может обнулить всё ускорение от NNAPI 

Для идентификации узких мест используйте ORT Profiling API. Он записывает время каждого оператора. Включается через options.enableProfiling("ort_profile") — генерирует JSON, открываемый в Chrome chrome://tracing. Профилирование на целевых устройствах помогает выбрать оптимальный execution provider. Например, на одном проекте мы заменили NNAPI на XNNPACK для модели с 80% несовместимых операций, что сократило инференс с 300 мс до 120 мс.

Что входит в нашу работу

• Экспорт и упрощение ONNX-графа, квантизация до Int8.
• Интеграция ONNX Runtime на iOS и Android с подбором оптимальных Execution Providers.
• Профилирование производительности на парке из 10+ реальных устройств, включая устаревшие.
• Сравнение с нативными форматами (Core ML, TFLite) и рекомендация лучшего решения.
• Документация по сборке и обновлению модели, исходный код интеграции.
• Гарантия стабильной работы и фиксация времени инференса.

Наш опыт в мобильном ML

Более 5 лет мы внедряем on-device ML в коммерческие приложения — от ритейла до медицины. Выполнили 20+ проектов с ONNX Runtime, Core ML и TFLite. Наши инженеры имеют сертификаты Apple и Google. Мы гарантируем, что модель будет работать на всех заявленных устройствах. Получите консультацию по интеграции ONNX Runtime — оценим ваш проект и предложим оптимальное решение под ключ. Закажите интеграцию ONNX Runtime для вашего приложения — обсудим детали.

Ориентиры по срокам

Базовая кросс-платформенная интеграция ONNX Runtime — 2–3 недели. С оптимизацией EP, профилированием, тестированием на парке устройств — 4–6 недель. Стоимость рассчитывается индивидуально после анализа модели и требований к производительности.