Конвертація ML-моделі в ONNX — оптимізація для деплою

Чому конвертація моделі в ONNX ламає виведення

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

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

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

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

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

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

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

Що змінюється після переведення моделі в єдиний формат

Переведення моделі в єдиний формат розриває зв'язку «сервіс виведення — бібліотека навчання». Граф обчислень ONNX описує лише те, що потрібно для прогону: оператори, форми входів, ваги.

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

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

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

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

Частка відмов при оновленні падає: зникає розсинхронізація версій бібліотеки та середовища, яка раніше спливала лише на бойовому контурі.

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

Режими перенесення та формати: порівняння підходів

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

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

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

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

Етапи роботи: від аудиту графа до передачі

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

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

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

3. Схема перенесення моделі. Фіксуємо, що переноситься як є, що замінюється еквівалентним оператором, а що йде в код додатку. Узгоджуємо точність розрахунків і допустиму розбіжність виходів.

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

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

6. Передача рішення команді. Віддаємо артефакти, скрипти перезбирання, опис схеми перенесення та регламент додавання нових моделей, навчаємо ваших інженерів. Залишаємося на зв'язку на період перших релізів.

Що залишається у вас після завершення робіт

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

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

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

Кейс: прискорили виведення моделі без перенавчання

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

Реліз займав дні, а поведінка моделі на одному й тому ж запиті відрізнялася від вузла до вузла — відтворити помилку поза продакшеном вдавалося не завжди.

Що змінили

Навчену модель вивантажили в єдиний граф ONNX — відкритий формат, який однаково виконується на будь-якій платформі і не тягне за собою стек навчання.

Входи та виходи зафіксували явно, прибрали шари, прив'язані до конкретної бібліотеки, і зібрали один артефакт замість чотирьох збірок.

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

Що стало

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

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

Що робити, якщо модель вже зібрана в іншому форматі

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

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

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

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

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

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

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

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

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

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

Технічні сумніви навколо ONNX і відповіді інженерів

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

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

Що робити з шарами, яких немає в стандартному наборі?

Такі операції мапимо вручну: частина розкладається на еквівалентну комбінацію підтримуваних, для решти пишемо власний оператор. Якщо шар зав'язаний на рідкісну бібліотеку, оцінюємо, переписати його чи залишити окремим блоком.

Чи доведеться перенавчати модель?

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

Як переконатися, що виходи збігаються?

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

Чи можна повернутися до вихідного формату?

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

Обговоримо вашу задачу перенесення моделі

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

• Архітектура та призначення: що на вході та виході, форми даних, чи є динамічні осі та розгалуження графа.
• Вага моделі та бібліотека, в якій її навчали — від цього залежить, чи знадобиться проміжне представлення при конвертації в ONNX.
• Цільове середовище: процесор або прискорювач, операційна система, середовище виконання та набір обчислювальних операторів.
• Вимоги до часу відгуку та кількості одночасних запитів на одному екземплярі — за ними вибираємо точність обчислень і глибину оптимізації графа.
• Ланцюжок попередньої та постобробки: нормалізація, приведення розмірів, декодування виходів — його теж переносимо і перевіряємо окремо.
• Тестовий набір входів з еталонними відповідями: 50–100 прикладів достатньо, щоб порівняти якість до та після перенесення.
• Обмеження щодо доступів: розгортаємо у відкритій хмарі або в закритому сегменті без виходу назовні.

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

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