Чому модель на OpenVINO втрачає швидкість після перенесення
Модель навчена, метрики на валідації тримаються, а після перенесення моделі на пристрій інференс просідає в рази.
Причина майже ніколи не в самій мережі: вузьке місце під час інференсу — це розрив між графом, який показував стенд, і тим, на що він перетворюється після конвертації в проміжне представлення OpenVINO та збірки під конкретний прискорювач.
Перше, що з'їдає час, — оператори, які пристрій не бере на себе. Плагін ріже граф на фрагменти, непідтримувані шари обчислює центральний процесор, і між частинами починаються перегони тензорів в обидва боки.
Одна така вставка на початку мережі обнуляє виграш від прискорених шарів: час іде на копіювання, а завантаження прискорювача падає до десятків відсотків.
Друге — динамічні розміри входу та попередня обробка. Якщо форма тензора змінюється від кадру до кадру, граф перезбирається на кожній новій формі, кеш зібраних моделей не спрацьовує, і перші виклики після рестарту йдуть помітно повільніше.
Поруч живе ресайз із нормалізацією: вони залишаються на CPU, і прискорювач простоює в очікуванні готового тензора.
Третє — пам'ять. Зайві копії вхідних буферів, відсутність спільного доступу до пам'яті між застосунком і прискорювачем, один запит за раз і непідібране число потоків дають зростання споживання та просідання за паралельних запитів. Окремо б'є квантування «на око»: перерахунки у float між шарами повертають частину графа на CPU.
Тому порядок тут зворотний до звичного: спочатку профілювання за шарами та замір частки кожної ділянки, потім режими продуктивності, попередня обробка, кеш і калібрування. Розбираємо, де саме втрачається час і як це закривається.
Вимірювані ефекти оптимізації: пропускна здатність і затримка
Ефект оптимізації видно лише на відтворюваному стенді: той самий потік запитів, зафіксований набір вхідних даних, замір до й після змін.
Тому порівнюємо не «стало швидше», а конкретні показники — пропускну здатність одного пристрою, затримку реакції на медіані та на хвості розподілу, пікові та сталі витрати пам'яті моделі.
Прискорення інференсу моделі дає прямий приріст пропускної здатності: той самий пристрій обслуговує в рази більше запитів за одиницю часу, бо конвертація моделі в проміжне представлення OpenVINO прибирає зайві перекладання даних, а квантування знижує розрядність ваг без помітної втрати якості. Звільнений ресурс іде на паралельні потоки замість упору в одне ядро.
Зниження затримок помітне не стільки за середнім значенням, скільки за хвостом: зникають рідкісні викиди, через які відповідь не встигала у відведене вікно.
Це змінює клас відмов — під піком навантаження система тримає темп, а не скочується в таймаути, повтори запитів і ручні перезапуски.
Витрати пам'яті моделі падають разом із розрядністю ваг, тому на прискорювачі міститься більше інстансів, а сервіс перестає впиратися в ліміт і випадати через нестачу пам'яті.
Стабільність під навантаженням перевіряємо довгим прогоном: споживання виходить на плато і не зростає годинами, черга запитів не роз'їжджається.
Результат фіксуємо звітом із замірами до й після: графіки затримки, пропускна здатність за заданого числа потоків, споживання пам'яті на довгому прогоні. За ними видно, який запас залишився на зростання трафіку без заміни обладнання.
Варіанти роботи з OpenVINO: конвертація та режими розгортання
У OpenVINO ці шляхи не замінюють один одного: конвертація моделі, квантування ваг, режими розгортання на різних прискорювачах і робота у вихідному середовищі без конвертації. Нижче — те, що ми реально порівнюємо на проєктах, з обмеженнями кожного варіанта.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Конвертація в проміжне представлення | Запуск на процесорі або вбудованій графіці; модель навчена поза цільовим середовищем | Нестандартні шари описуємо вручну, частина операцій переноситься неточно |
| Квантування ваг після навчання | Потрібні менший розмір артефакту й менша затримка; втрата десятих часток відсотка допустима | Просідання на рідкісних класах, потрібен контрольний набір для приймання |
| Квантування з донавчанням | Точність критична і після простого стиснення не тримається | Довше: потрібен доступ до навчальної вибірки та прогін донавчання |
| Розкладка за кількома прискорювачами | Профіль навантаження неоднорідний: частину шарів вигідніше на іншому пристрої | Налаштовується під конкретну платформу, перенесення на інше залізо потребує перевірки |
| Без конвертації, у вихідному середовищі | Строки не дозволяють міграцію, модель відлагоджена там само, де навчалася | Втрачається виграш від оптимізації під цільове залізо |
Кандидатів відбираємо замірами: знімаємо профіль навантаження на репрезентативній вибірці, проганяємо два-три варіанти в лоб і фіксуємо затримку, розмір артефакту та метрику якості в документації — щоб рішення переперевірялося під час зміни заліза.
Як ми впроваджуємо оптимізацію: етапи інженерної роботи
Порядок робіт вибудовуємо так, щоб кожен крок давав вимірюваний результат і точку відкату. Починаємо з аудиту моделі та схеми її запуску в продукті — без цього оптимізація перетворюється на вгадування, а якість доводиться переперевіряти вже на бойовому контурі.
Порядок етапів
- Аудит моделі та схеми запуску. Розбираємо граф, знаходимо оператори, які не лягають на цільове залізо, і дивимося, як модель викликається зараз. На виході — список вузьких місць і план робіт.
- Конвертація та звірка. Переводимо модель у формат OpenVINO і порівнюємо виходи з вихідною версією на контрольній вибірці. Розходження вище допуску розбираємо одразу, а не після запуску.
- Налаштування виконання. Підбираємо точність розрахунків, число потоків і режим інференсу під конкретне залізо — серверний процесор, вбудовану або дискретну графіку. Прибираємо зайві копіювання даних між етапами.
- Квантування з контролем якості. Переводимо ваги в цілочисельну точність і стежимо за деградацією на класах, де модель помилялася й раніше. Прискорення не має сенсу, якщо зростає частка хибних спрацювань.
- Тестування на реальних даних. Проганяємо вибірку з бойового трафіку: порівнюємо якість, час відгуку й споживання ресурсів до і після. Окремо дивимося пікове навантаження, а не середні значення.
- Передача рішення. Віддаємо конфігурації, скрипти збірки та інструкцію з повторної конвертації, навчаємо команду. Далі оновлення версій моделі проходить без нас.
На кожному кроці залишається слід: видно, що і наскільки прискорилося й куди відкотитися, якщо нова версія моделі поведеться інакше.
Що залишається у вас: конфігурації, схеми та регламенти
Матеріальний результат — це не «ми налаштували й пішли», а комплект, за яким ваші інженери піднімуть і змінять систему без нас. Нижче — що саме передається за підсумками роботи.
- Файли конфігурації середовища: залежності рантайму, змінні, параметри потоків виконання та профілі під різні класи вузлів — із зазначенням, що змінюється під час переходу на інший сервер.
- Схеми запуску та інтеграцій: потік даних від джерела до інференсу, точки входу, черги, таймаути й місця, де найчастіше виникає вузьке місце.
- Скрипти конвертації та квантування моделі у формат OpenVINO із зафіксованим калібрувальним набором — повторний прогін дає той самий артефакт.
- Регламент оновлення моделі: приймання нової версії, прогін на зрізі реального трафіку, умови відкату на попередню збірку та критерії, за яких відкат запускається автоматично.
- Інструкція з повторної збірки: від вихідних ваг до готового артефакту, з перевіркою збігу виходів на контрольному наборі.
- Регресійний набір: збережений зріз даних і порогові значення метрик, за якими порівнюються версії.
- Політики доступу: ролі, розподіл прав на вивантаження ваг і на зміну конфігурації, де зберігаються артефакти й хто їх читає.
- Журнал припущень і відомих обмежень — щоб наступний крок не починався з повторного дослідження того самого.
Кожен пункт перевіряється на прийманні: ми запускаємо систему за переданою інструкцією в чистому середовищі, і якщо щось не відтворюється — дописуємо документацію, а не пояснюємо словами.
Кейс: як прибрали затримки на пристроях після оптимізації
Що було до оптимізації
До нас прийшла команда з робочим пілотом на парку пристроїв без виділених прискорювачів: модель розпізнавання видавала коректний результат, але відгук зростав лінійно з числом одночасних потоків.
На одному пристрої реакція вкладалася в норму, на восьми — черга запитів накопичувалася швидше, ніж система встигала їх розбирати, і під піковим навантаженням частина кадрів просто губилася.
Частка помилок розпізнавання трималася близько 6%, а на сплеску сягала 12% — оператори переперевіряли вивід вручну, і сенс автоматизації розчинявся.
Що змінили
Спочатку перенесли прогін моделі в Intel OpenVINO: граф конвертували в проміжне представлення й зібрали під конкретну апаратну конфігурацію, замість того щоб щоразу розбирати вихідний формат.
Потім пройшли квантування ваг — якість перевіряли на відкладеній вибірці, а не «на око», підібравши поріг спрацювання так, щоб просідання точності залишилося в допустимих межах.
Окремо переписали попередню обробку: прибрали зайві копії кадру, винесли нормалізацію в загальний крок і перейшли з поштучної обробки на пакетну. Це дало запас продуктивності ще до того, як ми торкнулися самої моделі.
Що стало
Затримка реакції скоротилася вчетверо, потік оброблених кадрів зріс утричі на тому самому парку пристроїв — докуповувати прискорювачі не довелося. Частка помилок розпізнавання впала з 6% до 2%, а на піку — з 12% до 4%.
За триразового сплеску навантаження черга більше не зростає: система тримає відгук у межах норми, а оператор підключається лише до пограничних випадків.
Що робити, якщо конвертація ламає точність моделі?
Розходження майже ніколи не виникає «в усій моделі» — воно локалізується в кількох шарах. Перший крок — прогнати той самий вхід через вихідну та сконвертовану модель, зняти виходи проміжних шарів і порівняти. Так видно, де накопичується помилка: на вході, після злиття операцій чи вже на останніх шарах.
Найчастіше точність просідає на квантуванні активацій — калібрувальний набір зібрано не на тому розподілі даних. Перевірка якості моделі починається з нього: набір має повторювати реальні входи, включно з рідкісними класами та крайніми значеннями.
Якщо його зібрали «на око», діапазони активацій зрізаються, і модель втрачає впевненість на пограничних прикладах.
Далі — чутливі шари: їх залишають у повній точності, квантують лише решту частину графа. Це дозволяє виконати повторну конвертацію без перенавчання — ваги не чіпаються, змінюється набір налаштувань збірки та список винятків.
Допустиме відхилення фіксуємо до початку робіт: наприклад, метрика на валідаційному наборі не гірша за вихідну на обумовлену частку. Тоді приймання не перетворюється на спір, а кожна перезбірка супроводжується регресійним прогоном і звітом про розходження за шарами.
У Intel OpenVINO є штатні засоби порівняння виходів і статистики за шарами — ми вбудовуємо їх у конвеєр збірки, щоб втрата точності ловилася на етапі конвертації, а не в робочому середовищі.
Технічні питання, які задають до старту проєкту
Перед стартом інженерна команда замовника перевіряє не загальні слова, а конкретику: що саме змінюється в їхньому контурі, які вузли зачіпаються і як відкотитися, якщо щось піде не так. Нижче — питання, які спливають найчастіше, з відповідями по суті.
Модель уже навчена — її доведеться перенавчати?
Ні. Ми працюємо з готовими вагами: переводимо граф у проміжне представлення OpenVINO, підбираємо вхідні розміри й калібруємо. Навчання й розмітка залишаються на вашій стороні, доступ до датасету не потрібен — достатньо репрезентативної вибірки для контролю якості.
Квантування ламає точність?
8-бітне квантування майже завжди змінює метрики — питання в тому, наскільки. Заміряємо якість на валідаційному наборі до і після, тримаємо узгоджений поріг деградації, а чутливі шари залишаємо в 16 бітах.
Якщо поріг не проходить — переходимо на змішаний режим, а не «дожимаємо» прискорення на шкоду результату.
Чи працюватиме на вже встановленому парку?
Граф збирається під конкретні покоління процесорів і вбудованої графіки; на старих вузлах залишається коректний відкат на центральний процесор, і застосунок не падає.
Перед розкаткою проганяємо той самий набір входів на кожному типі пристроїв і звіряємо виходи — розходження видно до введення в експлуатацію.
Як оновлювати моделі на пристроях і чим вимірювати результат?
Експортуємо версіонований артефакт, попередню збірку тримаємо поруч: оновлення й повернення до попередньої версії займають хвилини й не потребують перевстановлення середовища.
Затримку на один запит і пропускну здатність знімаємо до і після — рішення видно в цифрах, а не на словах.
Обговоримо вашу задачу: що потрібно від вас і від нас
Щоб оцінка проєкту оптимізації під OpenVINO спиралася на вимірювання, а не на припущення, потрібен мінімальний набір даних про модель і середовище її роботи. Нижче — що просимо у вас і що повернемо у відповідь.
Що потрібно для старту
- Модель у вихідному вигляді: ваги та опис архітектури з фреймворку навчання — від цього залежить обсяг проміжного перетворення.
- Цільове залізо: клас прискорювача й операційна система, де працюватиме інференс.
- Метрика якості та допустиме просідання після стиснення ваг.
- Режим роботи: час відгуку, число паралельних потоків, обмеження за пам'яттю.
- Еталонний набір із кількох сотень реальних прикладів для звірки відповідей до і після.
- Обмеження контуру: доступи, політика безпеки, чи можна вивантажувати ваги за межі інфраструктури.
Що повернемо
- План за етапами: конвертація в проміжне представлення, підбір точності квантування, звірка, збірка та розгортання.
- Протокол звірки з розходженням за кожним виходом моделі та калібрувальний набір до нього.
- Оцінку строків і складу робіт із критеріями приймання на кожному етапі.
- Перелік ризиків: операції, які цільовий плагін не підтримає і доведеться залишити на процесорі.
Опишіть задачу й передайте модель з еталонним набором — повернемося з оцінкою та планом робіт. Якщо частина даних недоступна, зафіксуємо це як ризик і врахуємо в розрахунках.
