Оптимізація та розгортання ШІ-моделей на NVIDIA Jetson

Розгортання AI на Jetson: де ламається продуктивність

Розгортання AI на Jetson майже завжди починається однаково: модель навчена, на стенді метрики збігаються, точність влаштовує — а на пристрої вона не тримає потік. Перші секунди все виглядає робочим, потім з'являються провали за кадрами, і час відгуку зростає від запиту до запиту.

Причина зазвичай не в самій мережі, а в її оточенні. На NVIDIA Jetson пам'ять спільна для ваг моделі, буферів входу та підсистеми виводу: коли її не вистачає, починається витіснення даних, і затримка перестає бути передбачуваною.

Далі вмикається тепловий контур — під тривалим навантаженням відбувається зниження частоти, і та сама операція виконується в рази довше, хоча код не змінювався.

Друге джерело відмов — нерівномірний вхід. Камери й датчики віддають дані пачками, пік за потоком не збігається із середнім, а робота моделі на пристрої планується під середній темп.

На піках черга зростає, на спадах прискорювач простоює; вузьке місце в конвеєрі обробки майже завжди опиняється на препроцесингу, приведенні форматів або синхронізації буферів, а не в шарах мережі.

Ціна такої картини — не «повільно», а нестабільно. Пристрій упевнено проходить приймальні перевірки й розвалюється в найнавантаженішу годину, коли потік максимальний і корпус уже прогрітий.

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

Що дає оптимізація моделі під конкретний пристрій

Оптимізація моделі під пристрій — це не стиснення файлу заради економії місця, а перебудова обчислень під конкретний прискорювач.

Ми профілюємо кожен шар на NVIDIA Jetson і окремо вимірюємо підготовку вхідних даних: на практиці вузьке місце опиняється не в самій мережі, а в збиранні кадру та копіюванні буферів.

Квантування та змішана точність дають основну частину виграшу. Шари, стійкі до зниження розрядності, переводимо в цілочисельні обчислення, чутливі залишаємо в плаваючій точності.

Перед викочуванням проганяємо калібрувальний набір на реальних даних замовника й звіряємо метрики якості до та після — розходження має вкладатися в обумовлений допуск.

Далі змінюються дві речі. Час відгуку стає стійким: зникають рідкісні «хвости», коли модель упиралася в обмеження за пам'яттю і частина роботи йшла на повільний шлях.

Пропускна здатність потоку зростає — той самий пристрій обробляє більше кадрів або запитів за одиницю часу, і частина навантаження закривається без розширення парку заліза.

Тепловий режим — наслідок тих самих змін. Неоптимізована модель тримає прискорювач на межі, той знижує робочу частоту й втрачає продуктивність: відгук «пливе», з'являються пропущені кадри та черги на вході.

Після оптимізації піки коротші, середнє завантаження передбачуване, а перегрів, деградація під навантаженням і раптові перезапуски сервісу просто не настають.

Розгортання моделей на Jetson: порівняння підходів

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

На модулі все впирається в пам'ять: ваги моделі, буфери кадрів і системні служби живуть в одному пулі, тому те, що на сервері вирішується додаванням ресурсу, тут вирішується перезбиранням конвеєра й урізанням входу.

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

Гібридну схему закладають заздалегідь — перемикач режимів дешевше додати на старті, ніж переписувати конвеєр під навантаженням.

Етапи впровадження: від аудиту моделі до передачі

Перенесення моделі із серверного прискорювача на вбудовану платформу рідко зводиться до запуску готового файлу.

Спочатку потрібно зрозуміти, які шари дають основну затримку, чи вкладається мережа в пам'ять разом із відеопотоком і чи не впирається система в тепловий бюджет корпусу. Нижче — послідовність, за якою ми ведемо проєкт на NVIDIA Jetson: від аудиту до передачі вашій команді.

1. Аудит моделі. Проганяємо поточну мережу на цільовій платі й знімаємо профіль за шарами, шукаємо вузькі місця — операції, які не підтримуються апаратно й переїжджають на центральний процесор. На виході — карта втрат часу й рішення: квантування, заміна окремих шарів або зміна архітектури.

2. Схема конвеєра обробки. Розкладаємо потік на етапи: захоплення кадрів, передобробка, інференс, післяобробка, віддача результату. Фіксуємо, що йде паралельно, які буфери перевикористовуються й де дані копіюються зайвий раз — найчастіше саме там і ховається просідання.

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

4. Налаштування розгортання. Збираємо образ системи, автозапуск сервісу, оновлення й відкат до попередньої версії. Окремо опрацьовуємо режими енергозбереження та тепловий профіль пристрою.

5. Тести під навантаженням. Ганяємо тривалий прогін із реальною кількістю потоків: стежимо за витоками пам'яті, падінням пропускної здатності, температурою. Перевіряємо поведінку при обриві камери або каналу зв'язку.

6. Передача в експлуатацію. Віддаємо прошивку, конфігурації, скрипти збирання, набір метрик і регламент обслуговування. Навчаємо вашу команду й фіксуємо, за якими ознаками розпізнавати деградацію моделі до того, як вона стане відмовою.

Комплект документації та конфігурацій після впровадження

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

Ми тримаємо документацію в тому самому репозиторії, що й саме розгортання AI на Jetson, — тоді при оновленні моделі опис і фактичний стан стенда не розходяться.

• Схема розгортання: склад вузлів, мережеві сегменти, точки підключення камер і датчиків, порядок холодного старту.
• Конфігурації середовища виконання: параметри відеопотоку, пороги спрацювання, виділені ресурси, профілі енергоспоживання.
• Розмежування прав доступу: ролі оператора, інженера й адміністратора — окремі права на моделі, конфігурації та журнали.
• Регламент оновлення моделі: хто ініціює, за якими метриками приймається нова версія, перевірка на стенді до викочування.
• Політика відкату: зберігання минулих версій ваг і конфігурацій, час повернення в робочий стан, умови автоперемикання.
• Інструкції для експлуатації: типові операції, розбір журналів, дії при перегріві, втраті зв'язку й падінні якості розпізнавання.
• Паспорт моделі: вибірка навчання, класи, точність на контрольних даних і межі застосовності.

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

Кейс: як зросла пропускна здатність на пристрої

До нас прийшли з бойовим завданням: одна бортова платформа NVIDIA Jetson обслуговує кілька відеопотоків і віддає результат у реальному часі. На стенді пристрій упевнено тримав шість потоків, але вже на восьмому частка втрачених кадрів сягала 12%.

Причина виявилася не в моделі: передобробка йшла на центральному процесорі, кожен кадр двічі копіювався між пам'яттю прискорювача й системною, а кілька сесій виводу конкурували за один контекст.

Що переробили в конвеєрі

Розбір показав, що вузьке місце — транспорт даних навколо моделі, а не сама мережа.

Передобробку перенесли на апаратні блоки кодування, проміжні копії прибрали, сесії звели до спільного контексту, а чергу кадрів обмежили явною політикою скидання: при перевантаженні відкидається найстаріший кадр, тому затримка не зростає лавиноподібно.

Профіль живлення зафіксували, щоб тактова частота не плавала під навантаженням і метрики залишалися відтворюваними.

Метрики до та після

Усунений клас відмов — перезапуск сервісу виводу на піку: раніше пристрій скидав увесь потік і піднімався заново, тепер деградує передбачувано, відкидаючи найменш важливі потоки. Такий розбір конвеєра дає запас, за якого додавання камер не потребує заміни заліза.

Чим відрізняється оптимізація на сервері від роботи на пристрої

Різниця починається з обмежувача. Оптимізація на сервері впирається в пропускну здатність пам'яті та вартість обчислень: запас за живленням дозволяє нарощувати розмір пакета й паралелізм.

На вбудованій платформі на кшталт NVIDIA Jetson обмежувач інший — тепловий пакет і спільна пам'ять, яку ділять процесор, прискорювач і відеовхід.

Звідси й відмінності підходів. Розмір пакета, що прискорює сервер, на пристрої веде до нагріву й падіння пропускної здатності за кілька хвилин.

Оптимізація на пристрої — це про пам'ять і тепло: динамічні форми тензорів і повна точність з'їдають пам'ять, якої не вистачає відеопотоку, а копіювання буферів між процесором і прискорювачем стає основною витратою часу.

Перенесення моделі починається з профілювання: спочатку знаходимо, де втрачається час — передобробка, вивід моделі або копіювання. Далі квантування, злиття шарів, статичні форми й відмова від проміжних буферів. Орієнтир — кратне скорочення затримки на кадр при контрольованому просіданні точності.

Вибір режиму роботи диктують вимоги: потрібен відгук за частки секунди й закритий контур — вивід моделі залишається на пристрої, а на сервер ідуть навчання й зведена аналітика. Гібрид знімає суперечність між якістю моделі та передбачуваністю відгуку.

Часті технічні сумніви перед стартом робіт

Перші питання на оцінці майже завжди одні й ті самі: чи не втратимо точність після стиснення моделі, як оновлювати її на пристрої без виїзду інженера й що станеться при перегріві корпусу. Нижче — короткі відповіді, щоб зняти ці сумніви до старту робіт.

Як оновлювати модель, якщо пристрій стоїть на віддаленому об'єкті?

Оновлення йде мережею: версія артефакту фіксується, на пристрій він приїжджає цілком або дельтою, перед підміною звіряється контрольна сума. Попередня збірка залишається на носії — відкат займає хвилини й не потребує фізичного доступу. Спочатку розкочуємо на одному вузлі, звіряємо метрики, потім на решті парку.

Що буде при перегріві в закритому корпусі?

Це реальне обмеження, а не теорія. Ми закладаємо тепловий профіль: режим живлення, граничні частоти, пасивний відвід, а в прошивку — телеметрію температури й частот. При наближенні до порогу навантаження знижується ступенями, аж до полегшеної моделі, замість аварійного вимкнення.

Як ви знаходите вузьке місце в обробці?

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

Обговоримо задачу: з чого почати розгортання

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

Тому старт ми будуємо як короткий збір вхідних даних — від нього залежить і схема виводу моделі, і те, які оптимізації взагалі мають сенс.

Щоб повернутися з оцінкою та планом, а не з здогадами, потрібно від замовника:

• Модель і ваги: вихідний формат (ONNX, чекпоінт із навчального фреймворку), допустиме просідання точності після квантування, еталонні приклади входів і очікуваних виходів.
• Цільовий пристрій: конкретний модуль Jetson, його пам'ять і носій, версія JetPack, а також корпус, живлення й тепловий бюджет — від них залежить вибір режиму продуктивності.
• Джерело даних: тип сенсора, параметри потоку, кількість одночасних каналів, допустимий час від кадру до результату.
• Сценарій експлуатації: автономна робота або мережа, хто і як оновлює модель на пристрої, чи потрібні віддалений доступ і журналювання.
• Обмеження: енергоспоживання, вібрація, діапазон температур, робота без перезапуску добами.
• Критерії приймання: що вважаємо успіхом — частка правильних спрацювань, стабільна пропускна здатність, відсутність деградації при тривалому навантаженні.

Перший етап — пілот на одному пристрої: збираємо образ, конвертуємо модель у TensorRT, знімаємо профіль затримки й точності, перевіряємо поведінку під навантаженням і в найгіршому тепловому режимі.

За підсумками пілоту повертаємося з оцінкою та планом робіт: склад команди (інженер із прискорення моделей, розробник вбудованих рішень, тестувальник), обсяг етапів, точки відкату й ризики.

Тривалість першого етапу — від кількох днів до двох тижнів, точний строк називаємо після розбору вхідних даних.

Опишіть задачу й надішліть вхідні дані зі списку — повернемося з оцінкою та планом робіт.