Разработка и внедрение Edge AI / TinyML на микроконтроллерах

Edge AI разработка: где ломаются проекты на устройствах

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

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

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

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

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

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

Автономная работа без сети — второй эффект, который заказчик замечает сразу. Устройство продолжает считать свой сценарий, когда канал недоступен: в подвале, в поле, на подвижной технике, на изолированном участке. Класс отказов «обрыв связи — функция встала» уходит из архитектуры, а не маскируется повторами запросов и буферизацией.

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

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

Подходы к внедрению: сравнение вариантов

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

Сравнение подходов к Edge AI начинается с замера: сколько классов нужно различать, как быстро меняется обстановка и допустимо ли отправлять данные на сервер. По этим ответам выбирается схема вывода.

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

Этапы разработки и внедрения на объекте

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

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

Комплект поставки: модели, схемы и регламенты

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

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

Кейс: контроль качества на производственной линии

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

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

Главный эффект — ушёл класс отказов «обнаружили, когда партия уже собрана». Пороги откалиброваны под освещение и скорость конкретного цеха, поэтому ложных срабатываний стало меньше, а линия перестала зависеть от связи наружу: при обрыве канала контроль продолжается.

— Раньше о проблеме мы узнавали от отдела контроля, теперь — от самой линии, — главный инженер «Светлогорский машиностроительный завод».

Когда вывод на устройстве проигрывает серверу

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

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

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

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

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

Вопросы, которые задают перед стартом

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

Точность на приёмке ниже ожидаемой — что дальше?

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

Как обновлять модели на уже установленных устройствах?

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

Кто размечает датасет?

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

Что входит в сопровождение после передачи?

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

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

Точная оценка проекта для микроконтроллеров получается только из вводных по конкретному объекту: универсальные прикидки здесь дают разброс в разы. Чтобы обсудить задачу предметно и не угадывать, достаточно прислать следующее.

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

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

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