Модель не вміщується в мікроконтролер: де ламається 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 хвилин з інженером, який вестиме проєкт, без переказів через посередників.
Після нього повертаємося з письмовим планом робіт: склад етапів, схема моделі та її обмеження, вимоги до даних і розмітки, порядок перевірки на пристрої та перелік ризиків. Опишіть задачу — повернемося з оцінкою та планом.
