Разработка машинного обучения (Core ML) в iOS-приложении
Конвертируете модель из Python-среды в мобильный продакшн — и сразу сталкиваетесь с несовместимостью форматов, латентностью инференса и отсутствием механизма обновления без релиза в App Store. Core ML решает эти проблемы нативно, но только если его правильно встроить в архитектуру приложения.
Где чаще всего теряют время при интеграции Core ML
Самая распространённая ошибка — конвертация модели без учёта целевого железа. coremltools позволяет указать minimum_deployment_target и тип compute unit: cpuOnly, cpuAndGPU, cpuAndNeuralEngine. Если не указать cpuAndNeuralEngine для A12+, модель не попадёт на Neural Engine и будет работать на CPU, что в 5–10 раз медленнее для свёрточных сетей.
Второй момент — входной формат. Core ML ожидает CVPixelBuffer с конкретным kCVPixelFormatType. Если приложение получает UIImage с камеры через AVCapturePhotoOutput, нужна промежуточная конвертация через CIImage → CVPixelBuffer. Делать это на main thread — верный путь к dropped frames. Вся цепочка захвата и инференса должна идти через DispatchQueue с QoS .userInteractive или через Vision framework, который сам управляет буферами.
Vision + CoreML — правильная комбинация для большинства задач: VNCoreMLRequest берёт на себя масштабирование, нормализацию и управление буфером. Но если нужна последовательность инференсов на видеопотоке, лучше использовать VNSequenceRequestHandler — он кэширует состояние между кадрами.
Как мы интегрируем Core ML
Начинаем с аудита исходной модели: формат (ONNX, TensorFlow SavedModel, PyTorch TorchScript), размер весов, количество операций. Для конвертации используем coremltools 7.x, для количественных моделей — ct.optimize.coreml с LinearQuantizer или PalettizationConfig. Квантизация в 8-bit снижает размер модели в 4 раза без заметной потери точности на большинстве классификаторов.
Пример из практики: финтех-клиент хотел детекцию подделки документов на устройстве. Исходная TFLite-модель (MobileNetV3, 12 MB) давала 280 ms на iPhone 12. После конвертации в .mlpackage с computeUnits = .cpuAndNeuralEngine и Float16-компрессией — 34 ms на том же устройстве. Дополнительно завернули инференс в MLModelConfiguration с allowLowPrecisionAccumulationOnGPU = true.
Для обновления моделей без релиза настраиваем загрузку через CloudKit или собственный S3-совместимый storage. MLModel(contentsOf:) принимает локальный URL — модель скачивается в фоне, верифицируется по SHA-256, подменяется атомарно через FileManager.replaceItem. Старая версия хранится как fallback.
Архитектурно весь ML-слой изолируем в отдельный модуль (Swift Package) с протоколом MLInferenceService. Это позволяет подменять реализацию в тестах и переиспользовать между несколькими таргетами.
Что входит в работу
- Аудит исходной модели и выбор пути конвертации
- Конвертация в
.mlmodel/.mlpackageчерезcoremltools - Оптимизация: квантизация, прунинг, выбор compute units
- Интеграция через
Visionили прямойMLModelAPI - Механизм OTA-обновления моделей (CloudKit / S3)
- Unit-тесты инференса с эталонными входами/выходами
- Профилирование через Xcode Instruments (Core ML Instrument)
Сроки
Интеграция готовой сконвертированной модели в существующее приложение — от 3 до 5 рабочих дней. Если нужна конвертация, оптимизация и настройка OTA-обновления с нуля — 1–2 недели. Стоимость рассчитывается индивидуально после анализа требований и исходной модели.