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

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

Мы различаем два принципиально разных подхода: приложение с on-device AI и приложение, которое просто вызывает облачное API. Первое работает без интернета, не отправляет данные пользователя на сторонние серверы и отвечает за 50 миллисекунд. Второе зависит от задержки сети и тарифного плана. Выбор архитектуры — ключевой этап, который напрямую влияет на стоимость, приватность и пользовательский опыт. Наш опыт показывает: в 70% проектов on-device инференс оказывается дешевле в долгосрочной перспективе за счёт исключения серверных затрат.

Как выбрать между CoreML и TFLite для on-device инференса?

CoreML — нативный фреймворк Apple для запуска ML-моделей на устройстве. Поддерживает Neural Engine (начиная с A11 Bionic), GPU и CPU как fallback. Модели конвертируются в формат .mlmodel через coremltools из PyTorch, ONNX или TensorFlow. Конвертация — не всегда тривиальна: кастомные слои требуют реализации MLCustomLayer, а квантизация до INT8 иногда заметно роняет точность на специфических данных. Мы гарантируем, что итоговая модель проходит валидацию на реальных данных до и после конвертации.

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На Android использует NNAPI (Neural Networks API) для хардварного ускорения — с Android 10 NNAPI стабильнее, до этого лучше явно использовать GPU delegate через GpuDelegate. Типичная ошибка: модель обучена на нормализованных данных в диапазоне [0,1], а в приложении на вход подаётся [0,255] — инференс работает, но с бессмысленными результатами без ошибки. Мы включаем модуль автоматической валидации входных данных в SDK.

Для задач классификации изображений, детекции объектов и сегментации доступны готовые оптимизированные модели. YOLOv8 в CoreML формате запускает детекцию кадра 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite с GPU delegate — около 8 мс на Pixel 7 при классификации.

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. Apple Intelligence использует собственные модели через Private Cloud Compute, но для сторонних разработчиков доступны другие пути.

llama.cpp с Metal backend на iOS — работающий подход для phi-3-mini (3.8B параметров, 4-bit квантизация, ~2.3 ГБ). Инференс: 15–25 токенов/секунду на iPhone 15 Pro. Для интеграции в Swift используем Swift Package llama.swift или обёртку через C-интерфейс llama.h. Бинарник к приложению не прикладываем — модель скачивается при первом запуске и хранится в Application Support. Наши сертифицированные разработчики настраивают инкрементальную загрузку, чтобы не блокировать первый запуск.

На Android аналог — Google AI Edge (бывший MediaPipe LLM Inference API) с поддержкой Gemma-2B. Работает через GPU delegate, на Tensor G3 чипе Pixel 8 Pro — около 20 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция OpenAI API и других облачных моделей

Для сценариев, где cloud inference допустим, интеграция OpenAI, Anthropic или Google Gemini — это HTTP клиент + streaming SSE. В Swift удобно через AsyncThrowingStream для стриминговых ответов. В Kotlin — через Flow.

Критически важно: API-ключи никогда не хранятся в бандле приложения. Даже обфусцированный ключ извлекается из IPA за 10 минут через strings или frida. Правильная архитектура: мобильное приложение → собственный backend → OpenAI API. Backend контролирует rate limiting, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

• Обученная и квантизированная модель под целевое устройство (документация по метрикам)
• SDK для интеграции (Swift/Kotlin/Flutter) с примерами вызова
• Тесты производительности на 3–5 реальных устройствах
• Инструкция по обновлению модели OTA
• Поддержка при прохождении модерации App Store / Google Play (проверка соответствия Guidelines 4.2, 5.1)
• 2 недели технической поддержки после релиза

Типичный пайплайн проекта

1. Анализ задачи — замеряем latency, privacy, size, поддерживаемые устройства.
2. Прототипирование модели — в Python, оценка accuracy на целевых данных.
3. Конвертация и квантизация — под CoreML/TFLite с валидацией.
4. Интеграция в приложение — модель оборачивается в сервисный слой (легко подменять CoreML → TFLite → облако).
5. Тестирование — на реальных девайсах, замер FPS, RAM, батареи.
6. Деплой — через TestFlight / Firebase App Distribution, мониторинг метрик.

Сроки: интеграция готовой CoreML/TFLite модели — 1–2 недели, разработка кастомной модели с мобильной оптимизацией — от 6 недель, on-device LLM чат с персонализацией — 4–8 недель.

Почему мы беремся за сложные кейсы?

10+ лет опыта в мобильной разработке, 50+ внедрённых AI/ML решений, гарантия совместимости с актуальными версиями iOS и Android. Все проекты проходят code review и нагрузочное тестирование. В стоимость уже входит подготовка документации для модерации и обучение вашей команды.

Свяжитесь с нами — мы поможем выбрать архитектуру и внедрить ML в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).