Оптимизация ML-модели (квантизация) для мобильного устройства

Мы сталкивались с задачей: модель детекции объектов занимает 100 МБ и работает 200 мс на устройстве пользователя. После квантизации — 25 МБ и 50 мс. Но иногда точность падает непредсказуемо. Делимся опытом: как выбирать метод, анализировать слои и верифицировать результат. Ниже — проверенные подходы для iOS и Android с кодом и конкретными метриками.

Квантизация — перевод весов модели из float32 в формат с меньшей разрядностью: float16, int8, int4. Модель ResNet-50 весит 98 МБ в FP32. После int8 квантизации — 25 МБ. Скорость инференса на мобильном CPU вырастает в 2–4× за счёт уменьшения объёма данных и использования целочисленных инструкций ARM NEON/SVE. Но простая квантизация часто роняет точность сильнее, чем хотелось бы. Правильная квантизация — это подбор метода, анализ чувствительных слоёв и верификация деградации.

Мы в сфере мобильной оптимизации более 5 лет, реализовали 15+ проектов по квантизации для клиентов из e-commerce, fintech и IoT. Гарантируем сохранение точности в рамках оговоренных допусков. Закажите оптимизацию модели — получите консультацию по вашему проекту.

Как выбрать метод квантизации?

Post-Training Quantization (PTQ) — квантизуем уже обученную модель без дообучения. Два варианта:

• Dynamic quantization — веса в int8, активации вычисляются в float32 в рантайме. Простая, не требует калибровочных данных. Хорошо работает для RNN/Transformer (BERT, LLM). Для CNN даёт меньший прирост.
• Static quantization — и веса, и активации в int8. Требует calibration dataset (100–500 репрезентативных примеров). Быстрее dynamic, но нужна калибровка.

Quantization-Aware Training (QAT) — модель дообучается с «симулированной» квантизацией. Веса адаптируются к пониженной точности. Лучшее качество, но требует доступа к обучающему датасету и GPU-времени.

# PyTorch: static PTQ через torch.quantization
import torch
from torch.quantization import quantize_static, get_default_qconfig

model.eval()
model.qconfig = get_default_qconfig('fbgemm')  # x86; для ARM — 'qnnpack'
torch.quantization.prepare(model, inplace=True)

# Calibration: прогоняем calibration dataset
with torch.no_grad():
    for batch in calibration_loader:
        model(batch)

torch.quantization.convert(model, inplace=True)
# Теперь model содержит квантизованные слои

Для мобильного Android (ARM) — qconfig = 'qnnpack', не 'fbgemm'. Это меняет порядок квантизованных операций под QNNPACK backend, который использует ARM NEON инструкции.

TFLite квантизация: full integer

# Конвертация с full int8 (активации + веса)
converter = tf.lite.TFLiteConverter.from_saved_model(saved_model_dir)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8

# Calibration generator — критично для точности static quantization
def representative_dataset():
    for sample in calibration_data[:500]:
        yield [sample.astype(np.float32)]

converter.representative_dataset = representative_dataset
tflite_model = converter.convert()

Full int8 модель работает на NNAPI и Hexagon DSP — там, где FP16 не поддерживается. На Snapdragon 778G через Hexagon — 5–8× быстрее CPU при правильной INT8 квантизации.

Core ML квантизация на iOS

import coremltools as ct
from coremltools.optimize.coreml import (
    OptimizationConfig,
    OpLinearQuantizerConfig,
    linearly_quantize_weights
)

# Загружаем уже конвертированную Core ML модель
mlmodel = ct.models.MLModel("model_fp32.mlpackage")

# Конфигурация: 8-bit линейная квантизация весов
config = OptimizationConfig(
    global_config=OpLinearQuantizerConfig(
        mode="linear_symmetric",
        dtype=np.int8,
        granularity="per_channel"  # per_channel точнее per_tensor для CNN
    )
)

compressed_model = linearly_quantize_weights(mlmodel, config)
compressed_model.save("model_int8.mlpackage")

per_channel квантизация — отдельный scale factor для каждого выходного канала свёрточного слоя. Значительно точнее per_tensor (один scale на весь слой), но чуть медленнее. Для CNN обычно оправдано.

Что делать, если точность падает?

Не все слои одинаково переносят квантизацию. Первый и последний слои сети, а также слои attention в трансформерах — часто самые чувствительные. Инструмент: per-layer sensitivity analysis.

# Проверяем деградацию точности при квантизации каждого слоя по отдельности
from torch.quantization.quantize_fx import prepare_fx, convert_fx

baseline_accuracy = evaluate(float_model, test_loader)

for layer_name in get_all_quantizable_layers(model):
    # Квантизуем только этот слой
    single_layer_model = quantize_single_layer(model, layer_name)
    layer_accuracy = evaluate(single_layer_model, test_loader)
    sensitivity = baseline_accuracy - layer_accuracy
    print(f"{layer_name}: sensitivity={sensitivity:.4f}")

Слои с высокой чувствительностью оставляем в FP32 — это mixed precision quantization. Остальные переводим в INT8. 5–10% «тяжёлых» слоёв остаются в FP32, модель теряет только 20–30% объёма вместо 75%, но точность сохраняется.

Как проверить, что квантизация выполнена корректно?

После квантизации обязательно:

1. Точность на тестовом датасете — сравниваем top-1/top-5 accuracy с оригиналом. Допустимая деградация: FP16 — <0.5%, INT8 — <2%. Если больше — переходим к QAT или mixed precision.

2. Числовая погрешность — на одинаковых входах сравниваем выходы float и quantized модели. MSE < 0.01 обычно приемлемо.

3. Скорость на реальных устройствах — не на симуляторе. Xcode Instruments → Core ML Profiler для iOS, adb shell am instrument + TFLite Benchmark Tool для Android.

4. Краш-тест — разные входы, edge cases (чёрное изображение, очень яркое, нестандартный aspect ratio). INT8 модели иногда overflow на экстремальных входах.

Практический кейс из нашей практики

Для одного из клиентов мы оптимизировали модель детекции объектов YOLOv8n. В FP32 — 6.3 МБ, 45 мс на iPhone 13. После Core ML INT8 квантизации — 1.8 МБ, 12 мс. mAP упал с 37.3 до 36.1 — в пределах допустимого для задачи. На Snapdragon 8 Gen 1 через TFLite INT8 + NNAPI — 8 мс. Экономия на облачных вычислениях при инференсе — до 4×.

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

• Аудит исходной модели и выбор метода (PTQ/QAT, INT8/FP16).
• Подготовка калибровочного датасета и настройка calibration.
• Анализ чувствительных слоёв и настройка mixed precision.
• Полная квантизация с верификацией точности.
• Замеры скорости на целевых устройствах (iOS/Android).
• Отчёт по деградации и рекомендации.
• Интеграция квантизованной модели в ваш пайплайн.

Согласно PyTorch documentation, PTQ может уменьшить размер модели до 4 раз. Для детального изучения также рекомендуем TensorFlow Lite post-training quantization.

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

PTQ для одной модели с верификацией — 1–2 недели. QAT с полным циклом дообучения и тестированием — 3–6 недель в зависимости от размера датасета. Квантизация снижает затраты на хранение модели до 75%.

Свяжитесь с нами, чтобы оценить ваш проект. Мы поможем подобрать оптимальный метод и гарантируем результат.

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 в месяц).