Конвертація моделі в TFLite: що ламається на виході
Конвертація моделі в TFLite — це не «зберегти в іншому форматі», а перескладання графа під мобільний інференс.
Частина операторів не має еквівалента в рантаймі, і замість зрозумілої помилки ви отримуєте або падіння на конкретній моделі пристрою, або тиху підміну прискореного шляху на повільний запасний.
Непідтримувані операції проявляються по-різному: конвертер повідомляє про них прямо або видає попередження й збирає модель, яка обчислюється, але неправильно.
Кастомні шари, динамічні розміри входів, операції над розрідженими структурами доводиться переписувати під підтримуваний набір.
Окрема історія — квантизація. Цілочисельне представлення ваг стискає модель і прискорює вивід, але без репрезентативного набору калібрування точність падає нерівномірно: середня метрика тримається, а на рідкісних класах деградація у рази. Тому падіння точності шукають не за загальною цифрою, а за зрізами даних.
Розбіжність результатів на пристрої додають делегати: апаратні прискорювачі змінюють порядок обчислень і округлення, і вивід перестає збігатися з еталоном. Потрібні тести на паритет за кожним виходом і явні допуски, а не перевірка одного демонстраційного прикладу.
Ззовні це виглядає як зростання часу відгуку в частини користувачів і падіння на конкретних пристроях: прискорений шлях відкочується на процесор, вмикається троттлінг, не вистачає пам’яті. Далі розбираємо, як кожен із цих класів збоїв закривається на етапі конвертації.
Що дає оптимізація під конкретний пристрій
Модель, навчена на серверних прискорювачах, на телефоні поводиться інакше: відгук вимірюється секундами, артефакт не вміщається в розумний розмір застосунку, частина операцій на бюджетних пристроях зазнає відмови.
Конвертація моделі в TensorFlow Lite переводить граф у формат, який виконується на пристрої, а оптимізація під конкретну платформу робить його придатним для роботи.
Квантизація у 8-бітні цілі — основний важіль: ваги й активації калібруються на реальних прикладах, повноточними залишаються лише шари, де просідання якості помітне метриці.
Обсяг займаної пам’яті скорочується в 3–4 рази, а приріст швидкості вищий на слабких процесорах — там, де він і потрібен. Оприлюднені спільнотою заміри дають той самий порядок величин: артефакт — із сотень до десятків мегабайт, відгук — із секунд до десятих часток.
Виконання шарів на графічному або нейронному блоці прискорює прогін, але одна непідтримувана операція повертає ділянку графа на центральний процесор — відгук починає стрибати.
Тому склад операцій перевіряють заздалегідь, а запасний шлях тестують на кожному цільовому сімействі пристроїв.
Уся обробка відбувається локально: немає запитів до сервера, немає відмов через канал зв’язку, дані не залишають пристрій. Для медицини, фінансів і промислових сценаріїв це знімає більшу частину питань про персональні дані.
Частку відмов вважаємо за слабким парком, а не за флагманом: бюджетні моделі, нагрів, нестача пам’яті. До оптимізації невдалі прогони там сягають 10–15%, після — одиниці відсотків за тієї самої якості відповіді.
Порівняння режимів: квантизація, делегати, стиснення
Режими оптимізації не замінюють один одного: квантизація змінює формат ваг і активацій, делегати перекладають обчислення на прискорювач пристрою, відсікання ваг прибирає надлишкові зв’язки в самій мережі.
Комбінувати їх можна й часто потрібно, але порядок важливий — спочатку відсікання з дообученням, потім квантизація, а делегат вибирається на етапі збирання під конкретний парк пристроїв.
Нижче — варіанти, між якими реально обирають під час конвертації моделі в TFLite, з обмеженнями кожного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| float16-квантизація ваг | Потрібен менший розмір за майже нульової втрати якості | Скорочує лише вагу: на процесорі час виводу майже не змінюється, виграш проявляється на графічному прискорювачі |
| Динамічна цілочисельна квантизація | Багато згорткових шарів, репрезентативного набору даних немає | Ваги стискаються, активації обчислюються в плаваючій точці — виграш за часом частковий |
| Повна цілочисельна квантизація з калібруванням | Парк пристроїв однорідний, важливі мінімальна вага й передбачуваний час | Потрібен репрезентативний набір даних, рідкісні класи втрачають точність, частина операторів випадає з прискореного шляху |
| Делегат під графічний прискорювач | Модель зібрана з підтримуваних операторів, критична затримка | Оператори поза списком повертаються на процесор, зростає споживання пам’яті |
| Делегат під нейромодуль | Пристрої одного сімейства з виділеним прискорювачем | Прив’язка до моделі пристрою, частина шарів усе одно йде на процесор |
| Відсікання ваг з дообученням | Мережа явно надлишкова, потрібен запас за пам’яттю | Без підтримки розріджених ядер на пристрої виграш не проявляється |
Вибір підтверджуємо замірами на цільовому парку: час виводу, частка операторів на прискорювачі та якість на відкладеній вибірці.
Порядок робіт: аудит, схема, налаштування, перевірка
Порядок етапів не випадковий: кожен наступний крок спирається на заміри попереднього. Якщо одразу увімкнути квантизацію, не зафіксувавши базову лінію, втрата точності виявиться вже в продакшені — на пристроях користувачів, а не на стенді.
Тому починаємо з аудиту, а закінчуємо передачею, щоб будь-яку зміну можна було перевірити й відкотити.
- Аудит поточного стану. Розбираємо архітектуру моделі, вхідні й вихідні тензори, знаходимо вузькі місця — попередню обробку кадрів, постобробку, сам вивід. Фіксуємо базові метрики на цільовому пристрої: час виводу, споживання пам’яті, поведінку під тривалим навантаженням.
- Схема конвеєра збирання. Визначаємо, звідки беруться ваги, як відтворюється експорт, де зберігаються артефакти та їхні версії. Після цього конвертація моделі в TFLite стає повторюваною командою, а не ручною операцією на ноутбуці розробника.
- Налаштування режиму оптимізації. Підбираємо тип квантизації — від вагової до повної цілочисельної — і делегати під конкретні прискорювачі. Вибір обґрунтовуємо заміром: де виграш за швидкістю перекриває втрату точності, а де ні.
- Збирання та правки. Прогоняємо модель через конвертер, замінюємо несумісні оператори, налаштовуємо параметри представлення. Контролюємо два числа: розмір артефакту й якість на валідаційній вибірці.
- Перевірка на пристроях. Тестуємо на реальному парку — різні покоління чіпів, обсяг пам’яті, версії системи. Дивимося найгірший випадок, а не середній: холодний старт, нагрів, нестача пам’яті.
- Передача робіт. Віддаємо налаштований конвеєр, регламент випуску нової версії, скрипти замірів і звіт із числами до та після. Команда замовника далі повторює цикл самостійно.
Артефакти проєкту: конфігурації, схеми, регламенти
Ми передаємо проєкт так, щоб його можна було зібрати й перевірити без нас: відтворювана конвертація моделі в TFLite — це не один скрипт, а набір файлів, за якими будь-який інженер отримає той самий артефакт. Нижче — що саме залишається в замовника в репозиторії та в документації.
- Конфігурації збирання — параметри конвертації (вхідні форми, тип квантизації, перелік операцій з відкатом на резервну реалізацію) винесені у файли, а не зберігаються в голові інженера.
- Схема конвеєра: де навчаються ваги, де виконується конвертація, де проганяються перевірки на реальному пристрої та в який момент артефакт публікується.
- Правила версіонування — зв’язка версії датасету, ваг і сконвертованого артефакту, щоб відкат на будь-яку попередню збірку був однозначним.
- Регламент перевірок: тести на розбіжність виходів до та після квантизації, час виводу й споживання пам’яті на еталонному наборі пристроїв.
- Матриця прискорювачів — які задіяні, на яких моделях пристроїв і версіях системи перевірені та як поводиться модель за їх відсутності.
- Документація: як зібрати артефакт з нуля, як відкотитися на попередню версію та які обмеження є в поточної конфігурації.
- Звіт порівняння — таблиця за точністю й часом виводу до та після стиснення на фіксованому наборі вхідних даних.
Кейс: як скоротили розмір моделі та прибрали затримки
Замовник прийшов із моделлю розпізнавання, яка впевнено працювала на флагманських телефонах і розвалювалася на решті парку. Артефакт не вміщався в бюджет пам’яті, частина операцій ішла на повільний шлях обчислень, і відгук на слабких апаратах розтягувався.
Заміри до старту: у 9% пристроїв обробка кадру не вкладалася у відведене вікно, у 4% застосунок падав на ініціалізації.
Що зробили
Зібрали стенд із пристроїв різних поколінь і зафіксували базові метрики за кожним — без цього оптимізація перетворюється на вгадування.
Модель перезібрали у формат TensorFlow Lite з квантизацією, відкаліброваною на реальних даних замовника, а не на синтетиці: ваги привели до цілочисельного вигляду, а ділянки, чутливі до точності, залишили без змін.
Під кожен клас чіпсетів підібрали апаратний прискорювач, частину операторів винесли в попередню обробку, важкі гілки графа розділили на два проходи з проміжним кешем.
Що стало
Розмір артефакту зменшився вчетверо, час відгуку на слабких пристроях — утричі. Частка апаратів, що не вкладаються у вікно обробки, упала з 9% до 0,6%, а падіння на ініціалізації зникли як клас відмов.
Точність після стиснення просіла в межах одного відсотка — це підтверджує прогін на відкладеній вибірці перед кожним релізом.
Перевірка йде на парку з кількох десятків моделей пристроїв: якщо нова збірка деградує за затримкою або пам’яттю, вона не доходить до публікації.
Чим делегат відрізняється від квантизації і що вибрати
Делегат і квантизація вирішують різні задачі, і плутанина між ними призводить до того, що прискорення шукають не там, де воно є. Делегат — це спосіб виконання: частина графа операцій переходить із центрального процесора на графічний прискорювач або нейромодуль пристрою.
Квантизація — це спосіб представлення: ваги й активації зберігаються в цілочисельному форматі замість плаваючого, завдяки чому артефакт важить у рази менше, а арифметика обчислюється швидше.
Звідси й порядок застосування. Квантизація виконується на етапі конвертації моделі в TFLite — це властивість готового файлу, зафіксована до збирання застосунку. Делегат підключається на етапі запуску, в ініціалізації інтерпретатора, і на вміст файлу не впливає.
Тому спочатку визначається цільова точність і формат ваг, а вже потім підбирається виконавець під цей формат.
Поєднуються вони далеко не завжди автоматично. Не кожен делегат підтримує весь набір цілочисельних операцій: непідтримувані вузли повертаються на центральний процесор, граф рветься на фрагменти, і пересилання проміжних тензорів між прискорювачем і процесором з’їдає виграш. Ознака проблеми — прискорення менше очікуваного й зростання енергоспоживання на довгих сесіях.
Критерій вибору простий. Якщо обмеження — розмір застосунку й обсяг пам’яті, починаємо з квантизації. Якщо модель вкладається в пам’ять, але не тримає затримку, пробуємо делегат.
Якщо на пристрої є нейромодуль і потрібна мінімальна затримка, ставляться обидва режими — але з контролем частки операцій, що реально перейшли на прискорювач, і розбіжності виходів з еталонним результатом.
Сумніви щодо точності, розміру й сумісності
Інженерні сумніви навколо конвертації моделі в TensorFlow Lite майже завжди ті самі: наскільки просяде точність після квантизації, що робити з операціями, яких немає в рантаймі, і як оновлювати мережу, не випускаючи нову збірку застосунку. Нижче — прямі відповіді за кожним пунктом.
Наскільки просяде точність?
Залежить від режиму. Квантизація ваг дає частки відсотка за цільовою метрикою, повна восьмибітна схема — відчутніше, особливо на детекції дрібних об’єктів. Тому порівнюємо пари «до/після» на відкладеній вибірці та калібрувальному наборі з реальних даних.
Що робити з непідтримуваними операціями?
Три шляхи: замінити вузол на підтримуваний аналог, зібрати кастомний оператор або залишити сегмент на резервному виконавці. Вибір — за тим, скільки часу виводу додає обхід і наскільки стабільно він працює на різних чіпсетах.
Чи можна оновлювати модель без випуску застосунку?
Так, якщо мережа й інтерфейс розведені: ваги лежать окремим артефактом, застосунок підтягує актуальну версію й відкочується на попередню за деградації метрик. Нова збірка потрібна лише за зміни структури входів-виходів.
Як перевіряєте сумісність пристроїв?
Збираємо матрицю цільових пристроїв і проганяємо збірку на кожному: різні чіпсети, прискорення через графічний або нейронний блок, відкат на резервний шлях. Старт і поведінка під навантаженням показують розбіжності між пристроями краще за середній замір.
Обговоримо задачу: що потрібно для старту робіт
Щоб оцінка спиралася на факти, а не на припущення, нам достатньо кількох вступних. Чим точніше описано сценарій, тим швидше ми назвемо етапи, терміни та ризики.
- Постановка задачі — де працює модель: на пристрої користувача чи зі зверненням до сервера, хто користувач і яка відповідь вважається правильною.
- Вихідні дані — що надходить на вхід: кадри з камери, зображення, аудіо або текст. Достатньо 10-20 прикладів реальних даних, включно зі складними випадками.
- Поточний конвеєр — на чому навчена модель, у якому форматі збережена, чи були спроби конвертації в TFLite і на якому кроці вони зупинялися.
- Список пристроїв — моделі телефонів, гілки операційних систем, частка слабких апаратів в аудиторії: від цього залежать квантизація й делегати.
- Метрики якості — що не можна втратити: точність, повнота, затримка відповіді, витрата батареї. Заміри на поточній версії помітно прискорюють роботу.
- Обмеження проєкту — допустимий розмір застосунку, доступна пам’ять, вимоги до приватності, необхідність роботи без мережі.
- Терміни етапів — прив’язані дати: запуск, показ замовнику, сезонний пік. Вони задають порядок робіт.
За цими вступними ми готуємо оцінку й план: розбивку за етапами, склад робіт, точки перевірки результату та ризики. Опишіть задачу у вільній формі — повернемося з оцінкою та планом, а дані, яких не вистачає, винесемо окремим етапом.
