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

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

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 недель. Стоимость рассчитывается индивидуально после анализа модели и требований к производительности.