Модель не влезает в микроконтроллер: где ломается TinyML-проект
Обученная модель уверенно работает на сервере, а после портирования обученной модели на микроконтроллер начинает выдавать мусор или вообще не собирается — это самая частая точка отказа. Причина не в качестве обучения, а в том, что ограничения микроконтроллера заданы железом: оперативная память измеряется сотнями килобайт, её делят веса и код, аппаратной поддержки операций с плавающей точкой часто нет. Модель не помещается в память устройства — и вместо вывода модели на устройстве начинается переписывание архитектуры.
Второй разлом — разрядность. Веса в 32-битном формате занимают вчетверо больше места, чем нужно, а целочисленная арифметика на таких чипах идёт быстрее. Квантование до 8 бит сокращает размер в разы, но требует калибровки на реальных данных: без неё точность проседает именно на редких классах, ради которых проект и затевался.
Третий — среда исполнения. Слой, который спокойно живёт в обучающей среде, может просто отсутствовать на устройстве: нет нужной операции, нет поддержки динамических форм тензора, нет конкретного активационного слоя. Тогда граф пересобирают из того набора операторов, который устройство действительно умеет исполнять, и проверяют расхождение выходов с исходной моделью.
TinyML на микроконтроллере ломается не в обучении, а на стыке архитектуры, формата весов и среды исполнения. Ниже разбираем, как это закрывается на практике.
Что меняется, когда вывод модели уходит на само устройство
Когда модель исполняется на самом устройстве, обработка перестаёт зависеть от канала связи: датчик сам снимает сигнал, считает результат и отдаёт наружу только вывод. Задержка отклика перестаёт «плавать» — она определяется локальным циклом опроса и остаётся одинаковой при перегрузке сети, слабом сигнале и в момент, когда шлюз недоступен.
Автономная работа датчика — следствие того же решения. Устройство продолжает измерять и классифицировать, пока связи нет, а в сеть уходит сжатая сводка после её восстановления. Объём передаваемых данных падает кратно: вместо непрерывного потока сырых отсчётов передаются события и агрегаты за интервал, и канал перестаёт быть узким местом.
Отказоустойчивость без сети перестаёт быть отдельной задачей. Уходит целый класс отказов на стороне канала передачи — обрывы, потеря пакетов, переполнение буфера приёмника, — потому что критичная часть вычисления выполнена на месте и уже не может быть потеряна при транспортировке.
Проверяем эффект измеримо: какая доля выводов модели считается на устройстве, сколько устройство живёт автономно без связи, во сколько раз сократился трафик, как ведёт себя отклик при деградации канала и восстанавливается ли накопленное после возврата в сеть.
Именно на этих метриках строится решение по TinyML — от выбора модели до её упаковки под память и энергобюджет конкретного устройства.
TinyML, классические алгоритмы или облако: что выбрать
Выбор между TinyML и облаком определяется не модой, а тремя ограничениями микроконтроллера: объём оперативной памяти, энергобюджет автономного питания и допустимая задержка реакции. Сначала считаем эти границы, и только потом решаем, где вообще может жить модель.
Второй вопрос — что именно решает задачу. Пороговые алгоритмы на признаках дешевле и предсказуемее любой нейросети, но ломаются, когда классы перекрываются. Если без обучаемой модели не обойтись, её сжимают — квантование весов, отсечение малозначимых связей, упрощение архитектуры — и заново измеряют точность на своих данных, а не по чужим замерам.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Пороговые алгоритмы на устройстве | Признак хорошо описывается правилом: порог вибрации, амплитуда, счётчик событий. Нужны предсказуемость и минимальное потребление | Не работает при перекрывающихся классах и дрейфе сигнала; каждое новое условие — ручная настройка |
| Сжатая модель на устройстве (TinyML) | Распознавание образов и аномалий по датчикам офлайн, реакция критична по времени | Жёсткий потолок по размеру модели и точности; обновление модели означает перепрошивку парка устройств |
| Вывод в облаке | Нужна максимальная точность, модели часто обновляются, связь и питание стабильны | Задержка канала, зависимость от связи, передача сырых данных и требования к приватности |
| Гибридная схема вывода | На устройстве грубая фильтрация событий, в облако уходит только отобранное | Сложнее в отладке: две версии модели, синхронизация логики и разрывов связи |
Выбор фиксируется замером на пилотной партии: доля пропусков, число ложных срабатываний, время реакции, потребление за сутки. Гибрид чаще выигрывает там, где точность нужна высокая, а канал рвётся, — но сопровождение дороже.
Этапы разработки модели под микроконтроллер
В TinyML ограничения по памяти и питанию устройства задаются в начале проекта, а не проверяются в конце. Поэтому этапы разработки TinyML идут от аудита задачи к передаче проекта, и каждый шаг закрывается проверкой на реальном контроллере.
- Аудит задачи и данных. Смотрим, какие величины снимаются с датчиков, с какой частотой и что уже накоплено в логах. Фиксируем метрики приёмки, допустимое время отклика и объём памяти, доступный модели на устройстве.
- Схема решения и сбор данных с датчиков. Определяем состав каналов и разметку, затем собираем данные на реальных экземплярах изделия, а не только на макете, — так в выборку попадают шум, дрейф и особенности монтажа.
- Подготовка признаков и прототип. Считаем признаки, выбираем архитектуру под доступную память и обучаем модель с запасом по точности — ей предстоит выдержать сжатие.
- Обучение и сжатие модели. Прореживаем веса, переводим вычисления в целочисленный вид, при необходимости применяем дистилляцию. После каждого шага сверяем точность с исходной: критичные классы сигналов не должны деградировать.
- Проверка на устройстве. Прогоняем модель на целевом контроллере, замеряем время отклика и потребление, проверяем поведение на граничных и зашумлённых сигналах.
- Передача проекта. Отдаём воспроизводимый процесс обучения, датасет с описанием разметки, прошивку и отчёты по метрикам. Обучаем вашу команду дообучать модель на новых данных и выпускать обновления самостоятельно.
Артефакты проекта: модель, прошивка, документация
Проект в TinyML считается сданным не тогда, когда модель показала нужную точность на нашем стенде, а когда она устойчиво работает на устройстве заказчика и её можно сопровождать без нас. Поэтому в комплект входит всё, что нужно для повторной сборки, проверки и обновления — от скриптов обучения до регламентов.
- Исходный код обучения: подготовка набора данных, обучение, квантизация и конвертация в формат, который принимает компилятор микроконтроллера.
- Прошивка микроконтроллера: готовая сборка под конкретную плату — с назначенными выводами, частотой опроса датчика и режимом энергосбережения.
- Карта размещения по памяти: сколько занимают веса, промежуточные тензоры и буферы, какой запас остаётся под логику приложения и будущие правки.
- Тестовый набор и эталонные ответы: прогон на нём показывает, что модель не потеряла точность при переносе с сервера на устройство.
- Документация на модель: назначение, входные и выходные сигналы, допустимые диапазоны, условия, при которых качество падает, ожидаемые метрики.
- Регламент обновления: как переобучить на новых данных, пометить версию, выкатить её на парк устройств и вернуться к предыдущей прошивке.
- Схема сборки и прошивки: зависимости, команды и порядок шагов, которые ваш инженер воспроизводит у себя без нашей помощи.
Отдельно проговариваем, что из этого критично для вашего парка: где хранится эталонный набор, кто владеет правом на переобучение, как фиксируются изменения модели между релизами. Такой комплект снимает зависимость от одного исполнителя — сопровождение и развитие решения остаются внутри вашей команды.
Практика: модель для датчика вибрации на TinyML
До проекта датчики вибрации отправляли сырой поток измерений на сервер: канал был занят почти постоянно, а решение об остановке принимал человек по графику осмотров. Рост амплитуды на характерных частотах заметить успевали не всегда — подшипниковые узлы выходили из строя между регламентными проверками.
Что изменили
После внедрения TinyML инженерная часть выглядела так: собрали записи рабочих и аварийных режимов, разметили их по стадиям износа и обучили компактную модель, которая считает признаки прямо на микроконтроллере. Вывод идёт на TensorFlow Lite for Microcontrollers, веса квантованы, модель вместе с буфером отсчётов занимает малую долю памяти — внешняя память и замена железа не потребовались.
Метрики до и после
Объём передаваемых данных упал на два порядка: наверх уходят события с окном отсчётов, а не непрерывный поток, канал свободен под служебный обмен. Точность модели на устройстве — 0,94 при доле ложных тревог ниже 3%, поэтому предсказание отказа оборудования срабатывает на ранней стадии износа, когда есть запас на плановую замену узла.
Оставшиеся пропуски относятся к отказам с медленным развитием — модель не успевает увидеть динамику в коротком окне, и это закрывается увеличением окна анализа, а не ростом самой модели. Обновление прошивки с новыми весами идёт по воздуху, парк переводится поэтапно.
Что делать, если обученная модель не влезает в устройство?
В TinyML-проектах обученная модель не влезает в устройство — это не тупик, а точка, где начинается инженерная работа. Сначала считаем бюджет памяти: сколько занимают веса, сколько — промежуточные тензоры и рабочие буферы под вывод. Часто выясняется, что веса помещаются, а не хватает памяти под активации, — и тогда решение одно, а не другое.
Первый шаг — упрощение архитектуры: уменьшаем число каналов и слоёв, тяжёлые свёртки заменяем раздельными, убираем ветви, дающие доли процента качества. Это сжатие модели без потери смысла задачи: точность проседает на единицы процентов, а объём падает в разы.
Второй шаг — квантование весов в целочисленное представление. Калибруем параметры на реальных данных с датчиков, а не на синтетике: иначе расхождение между стендом и полем съест всю экономию. Модель становится меньше и быстрее, при этом исходная версия сохраняется — откат возможен на любом этапе.
Если и этого мало — переобучение под устройство. Меняем вход, разбиваем задачу на каскад простых моделей, переносим знание из большой сети в компактную. Обучение идёт с оглядкой на целевое железо: проверяем не только метрику качества, но и время вывода с пиковой памятью.
И только в конце — выбор микроконтроллера другого класса: больше памяти, аппаратный ускоритель или внешний модуль. Это самый долгий путь — смена партии, повторная калибровка, проверки в поле, — поэтому его держим последним вариантом, а не первым.
Сомнения инженерных команд: отвечаем по существу
Разработку TinyML обычно тормозят не модели, а вопросы, на которые команда не получила внятного ответа до старта. Ниже — те, что звучат на разборе чаще всего: они и определяют, дойдёт решение до серии или останется на стенде.
Насколько упадёт точность после сжатия?
Квантование и прореживание почти всегда снимают часть метрики — планируем контролируемый допуск, а не нулевые потери. Допуск фиксируем отдельно по каждому значимому классу: редкий класс проседает сильнее средней точности и именно он определяет пригодность.
Как обновлять модель на уже развёрнутых устройствах?
Закладываем два канала: полная замена прошивки и обновление только весов, когда модель отвязана от логики — второй дешевле по трафику и риску. Обязательны два раздела памяти под версии, проверка целостности и автооткат, если самопроверка после обновления не прошла.
Данных для обучения мало — с чего начинать?
Идём через перенос из облака: обучаем большую модель на доступных данных и передаём знание компактной, дополняя синтетикой и аугментацией сигналов. Остаток разметки добираем активно — устройство отдаёт только неоднозначные срабатывания, их размечаем точечно.
Как заметить деградацию модели в поле?
По телеметрии: уверенность модели, доля отказов от решения и расхождение распределения входных сигналов с обучающей выборкой. При выходе за порог устройство копит данные, а стенд с опорным образцом прогоняет регрессию — сдвиг условий виден раньше, чем начнёт расти ошибка.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценить проект по TinyML, готовое техническое задание не нужно — достаточно описания задачи и условий эксплуатации. Мы разбираем вводные, уточняем ограничения по памяти и энергопотреблению устройства и возвращаемся с планом работ: этапами, сроками и тем, что потребуется от вашей стороны.
Для первичного разбора полезно прислать входные данные:
- описание задачи: что устройство должно распознавать или предсказывать и как часто — постоянно или по событию;
- данные: записи с датчиков, размеченные фрагменты или сырые логи с реального устройства;
- платформу: микроконтроллер, объём памяти и допустимое энергопотребление, если они уже выбраны;
- ограничения: задержка отклика, автономность, требования к обновлению модели на устройстве;
- что уже сделано: прототипы, обученные модели, замеры точности;
- критерии приёмки: по какой метрике вы поймёте, что решение работает, и на каких данных её проверить;
- сроки: есть ли дата, к которой нужен рабочий прототип.
Обсуждение — один разговор на 40–60 минут с инженером, который будет вести проект, без пересказов через посредников. После него возвращаемся с письменным планом работ: состав этапов, схема модели и её ограничения, требования к данным и разметке, порядок проверки на устройстве и перечень рисков. Опишите задачу — вернёмся с оценкой и планом.
