On-Device ML: обучение и инференс на устройстве без облака

Почему on-device ML не доходит до внедрения

Модель выходит из лаборатории с хорошими метриками, и на этом проект чаще всего встаёт. Инференс на устройстве проверяли на одном эталонном экземпляре, где памяти и вычислителя хватает с запасом. Реальный парк — это десятки моделей устройств разного класса: то, что уверенно проходит на эталоне, на половине парка либо не запускается, либо теряет качество.

Первое узкое место — ограничения памяти. Веса, промежуточные тензоры и сам интерфейс приложения делят один бюджет, поэтому локальный вывод модели вытесняет соседние процессы или вытесняется сам. Сжатие весов и снижение разрядности помогают, но каждое такое решение забирает точность, и её приходится подтверждать заново на реальных данных, а не на лабораторной выборке.

Второе — задержка отклика. На устройстве модель работает не одна: она конкурирует за вычислитель и делит бюджет с основным приложением, а под нагрузкой отклик растёт непредсказуемо. Пользователь видит «подвисает», команда — невыполненное требование по времени реакции, хотя на стенде всё укладывалось с запасом.

Третье — разнородность парка вместе с работой без сети. Одна и та же сборка ведёт себя по-разному на разных моделях устройств, а обновить модель там, где связи не бывает неделями, нельзя: не приходит ни телеметрия о деградации, ни откат при неудачной замене весов. Поддержка расползается, а автономность превращается в слепую зону.

Ни одна из этих проблем не снимается одним приёмом: нужен бюджет ресурсов под каждый класс устройств, замеры качества под реальной нагрузкой и схема обновления с откатом. Ниже разбираем, как это закрывается на практике.

Что даёт локальный вывод модели на устройстве

Локальный инференс означает, что веса модели лежат внутри приложения, а вычисление идёт на самом устройстве — нейропроцессоре, графическом ядре или центральном процессоре. Модель один раз компилируется под целевую платформу и квантуется: вес артефакта сокращается в разы, а точность на типовых задачах остаётся приемлемой.

Отклик перестаёт зависеть от канала связи. Небольшая модель отвечает за десятки миллисекунд, и это время одинаково при хорошем и плохом сигнале — доля отказов из-за связи уходит в ноль, интерфейс ведёт себя предсказуемо. Работа офлайн становится не отдельным режимом, а обычным состоянием: склад, выезд за город, подвал без покрытия.

Разгрузка серверов — вторая половина эффекта. Распознавание, классификация и извлечение признаков считаются на клиенте, а серверная часть держит синхронизацию, доставку обновлений модели и агрегацию обезличенной статистики. Её мощность растёт заметно медленнее числа пользователей.

Приватность данных на устройстве — следствие архитектуры, а не обещание: кадры, аудио и текст остаются в памяти приложения и не уходят по сети. Меньше передачи — меньше поверхность утечки и меньше обязательств по хранению чужих персональных данных.

Разные ускорители закрывает TensorFlow Lite: один интерфейс вывода на нескольких платформах, поэтому смена модели или устройства не требует переписывать слой инференса.

Варианты запуска ML-модели: сравнение подходов

Запуск модели на устройстве — это не один сценарий, а три разных режима с разной ценой поддержки. Выбор между ними определяется тем, где лежат данные, как часто меняются веса и есть ли на устройстве запас по памяти и питанию.

На практике режимы комбинируют: сжатая модель закрывает базовый инференс, а редкие тяжёлые случаи уходят в гибридную схему. Общее промежуточное представление вроде ONNX позволяет переносить одну и ту же модель между исполняющими средами, не переобучая её под каждую платформу заново.

Критерий выбора считается по двум числам: размер парка устройств и частота обновления весов. Пока модель стабильна, достаточно готового варианта; как только появляется регулярное дообучение или жёсткие ограничения по памяти, адаптация и гибридная схема окупаются за счёт меньшего числа отказов на устройствах.

Этапы внедрения: от аудита сценариев до передачи

Порядок работ здесь — не бюрократия, а способ не переделывать модель дважды. On-device ML ограничен памятью, теплом и временем автономной работы, поэтому решение, собранное под усреднённое устройство, разваливается на живом парке. Поэтому идём от сценариев к железу: каждый следующий этап опирается на замеры предыдущего.

1. Аудит парка устройств и сценариев. Собираем модели, версии системы, доступную память и то, где пользователь не готов ждать. На выходе — список сценариев, которые устройство реально потянет.
2. Схема вывода. Решаем, что считается на самом устройстве, а что уходит на сервер: тяжёлая модель раз в сутки или компактная на каждое действие. Отдельно фиксируем, какие данные вообще не покидают устройство.
3. Сборка и оптимизация модели. Сжатие весов, дообучение под задачу, кэш промежуточных результатов. Цель — уложиться в память с запасом, а не впритык.
4. Тестирование на реальном парке. Прогрев, долгая сессия, нагрев, разряд, поведение при нехватке памяти. Смотрим долю неудачных выводов и хвосты задержек, а не среднее.
5. Передача решения. Код, схема вывода, регламент обновления модели на устройствах, метрики для мониторинга.
6. Обучение команды заказчика. Разбираем с инженерами, как переобучить модель, как откатить обновление и что смотреть в логах, — дальше решение живёт без нас.

Пропуск любого этапа возвращается откатами на живом парке.

Что остаётся у команды: конфигурации, схемы, регламенты

Решение на устройстве работает без облака, поэтому вся логика — сборка модели, доступ к данным, порядок обновлений — передаётся команде артефактами, а не устными договорённостями. Ниже полный комплект, который остаётся у вас после сдачи.

• Конфигурации сборки модели — файлы, из которых сборка воспроизводится с нуля: параметры квантования под целевые классы устройств, состав выгружаемых слоёв, контрольные суммы весов.
• Схема интеграции — где модель вызывается в приложении: точки входа, работа в фоне, ограничения по памяти и питанию, поведение при нехватке ресурсов.
• Политики доступа к данным — что остаётся на устройстве и не покидает его, что и в каком виде уходит в телеметрию, правила обезличивания, шифрование локального хранилища.
• Регламент обновления модели — как новая версия доезжает до устройств: выкат на малую долю аудитории, критерии остановки, откат на предыдущую сборку без переустановки приложения.
• Документация на решение — архитектурная схема, состав зависимостей, ограничения по памяти и тепловому режиму, перечень сценариев отказа и того, что видит пользователь.
• Набор приёмочных проверок — прогон на реальном парке устройств: качество ответа, время отклика, деградация при разряде и слабом сигнале.

Комплект рассчитан на самостоятельное развитие: заменить модель, добавить сценарий или изменить политику хранения можно силами вашей команды, не возвращаясь к нам за каждым изменением.

Кейс: распознавание на складе без связи с облаком

Складской контур — это ангары, стеллажные зоны и холодильные камеры, где устойчивого канала связи просто нет. Распознавание работало на серверной стороне: кадр уходил по сети, ответ возвращался с задержкой, а при обрыве оператор оставался без подсказки и до конца смены работал вслепую. Расхождения в учёте накапливались к отгрузке — их находили уже при инвентаризации.

Мы перенесли модель на сами терминалы: инференс выполняется локально через TensorFlow Lite, кадр не покидает устройство. Облако оставили только для синхронизации справочников и накопления обезличенной статистики — ночной обмен пакетами вместо постоянного потока. Сеть перестала быть в критическом пути: сканирование, распознавание и подсказки работают без неё, накопленные записи уходят на сервер, как только канал появляется.

Что изменилось в метриках

• Отклик: вместо секунд ожидания и очередей в час пик — локальный ответ, не зависящий от загрузки сети.
• Доступность: 100% рабочих сценариев выполняются без связи, раньше — только часть, остальное ждало канала.
• Класс отказов «сервер не ответил» ушёл из эксплуатационной сводки; остались физические — загрязнённая оптика, износ расходников.
• Точность распознавания после дообучения на реальных снимках склада: с ~92% до ~97% на эталонной выборке.
• Расхождения в учёте к закрытию смены сократились в разы — сверка идёт на месте, а не постфактум.

Устойчивость к обрывам связи

Отдельно проверили восстановление: терминал переживает потерю сети, перезапуск и разряд без потери накопленных операций — очередь поднимается из локального журнала. Перестраивать склад под покрытие не пришлось: вычислительный узел теперь само устройство.

Чем локальный вывод отличается от дообучения в облаке?

Граница проходит не по тому, где считается результат, а по тому, где меняются веса модели. Локальный вывод — это зафиксированная модель на устройстве: отклик за доли секунды, работа без сети, но опыт эксплуатации она не накапливает. Дообучение на сервере — обратный случай: веса пересобираются по агрегированным данным, зато каждое обновление нужно доставить на парк устройств и проверить совместимость.

Ключевой вопрос — где хранить данные обучения. Персональные данные (голос, изображения, переписка) разумнее не вывозить с устройства: тогда дообучение идёт федеративно, наружу уходят только обновления весов, а не сырые записи. Если данные обезличены, серверный контур даёт больше — общий опыт всех устройств сразу.

На практике чаще выигрывает гибридный сценарий: базовая модель на устройстве держит быстрый отклик и офлайн, сервер дообучает персонализацию и раздаёт обновления по расписанию с возможностью отката на предыдущую версию. Выбор схемы вывода мы фиксируем до начала работ: от него зависит объём кода на клиенте и то, какие данные покидают устройство.

Технические сомнения перед стартом работы

Вопросы на этом этапе обычно про инженерию, а не про саму идею. Ниже — как закрываются типовые сомнения: ресурсы парка, обновление модели без переустановки, разброс качества вывода, дообучение на малых данных и встраивание в готовое приложение.

Модель обновляется без новой версии приложения?

Веса выносим в изменяемый артефакт, а не вшиваем в сборку: модуль встраивается в готовое приложение и сверяет манифест версии при запуске. Обновление подтягивается в фоне, переключение идёт после проверки контрольной суммы, а предыдущий артефакт остаётся точкой отката.

Почему на разных устройствах ответы расходятся?

Разные ускорители и форматы сжатия дают разброс точности. Прогоняем единый набор тестовых сцен по матрице устройств и смотрим не только совпадение ответов, но и стабильность на повторах; ветку, которая не укладывается в допуск, убираем из матрицы поддержки.

Данных для дообучения мало — есть ли смысл?

Есть, если обучать не всю модель: основную часть замораживаем, а поверх базовой модели дообучаем небольшой адаптер на скромном размеченном наборе. Когда данных нет совсем, начинаем со сбора — разметка спорных случаев даёт материал для следующей итерации.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы вернуться с оценкой сроков и схемой работ, а не с общими словами, нужен ваш ввод по нескольким пунктам. Ниже — что описать со стороны заказчика: этого достаточно, чтобы мы собрали план и сразу определили, как будем проверять результат.

• Задача и данные: какой сигнал на входе (изображение, звук, текст, показания датчиков), объём выборки, есть ли требование не выносить данные за пределы устройства.
• Целевой парк: классы и модели устройств, доля старых версий, режим работы — одиночные запросы или поток, запас по памяти и энергии.
• Качество: метрика, по которой считаем решение рабочим, допустимая доля ошибок и сценарии, где ошибка критична.
• Работа без сети: нужен ли полностью офлайн-режим, как модель обновляется на устройстве и как откатывается к предыдущей версии.
• Интеграция: с чем стыкуется on-device ML — камера, микрофон, приложение, бортовая система, какие доступы и разрешения уже есть.
• Критерии приёмки: набор сценариев для прогона на согласованном парке и то, что считаем пройденным этапом.
• Пилот на ограниченном парке: сколько устройств выделяете, за какой срок собираем замеры и по каким признакам решаем масштабировать.

Дальше мы возвращаемся с планом работ: подготовка и разметка данных, подбор модели под ограничения конкретного устройства, проверка на реальном парке, схема обновления и замер результата по согласованным критериям.

Опишите задачу в свободной форме — вернёмся с оценкой и планом.