Інтеграція 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 тижнів. Вартість розраховується індивідуально після аналізу моделі та вимог до продуктивності.

Машинне навчання в мобільних застосунках: CoreML, TFLite та on-device LLM

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

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

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

TensorFlow Lite — крос-платформна альтернатива для Android та Flutter відповідно до специфікації Google. На 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 токенів/секунду.

Інтеграція 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, логує запити, захищає ключ.

Що входить у роботу (результати)

• Навчена та квантизована модель під цільовий пристрій (документація за метриками)
• 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 у ваш застосунок під ключ. Замовте аудит наявного рішення — безкоштовно оцінимо потенціал економії серверних витрат. Отримайте консультацію експерта — напишіть нам сьогодні.