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

Почему конвертация модели в ONNX ломает вывод

Обученная модель живёт внутри одной среды, а выводу нужен переносимый артефакт, который одинаково считается на сервере, во встраиваемом окружении и в браузере. Конвертация модели в ONNX — это не пересохранение файла, а пересборка вычислительного графа под чужой набор операторов. Поэтому перенос модели в единый формат почти всегда вскрывает расхождения, которые внутри исходной среды были не видны.

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

Второй — неподдерживаемые слои модели и ошибка при экспорте графа. Кастомные слои и зависящие от данных ветвления трассировка не переносит: она фиксирует один путь исполнения и молча теряет остальные. Тот же эффект даёт выбор набора операторов — оператор из новой ветки в старом наборе отсутствует, и экспортёр либо падает, либо подменяет его приближением.

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

Что меняется после перевода модели в единый формат

Перевод модели в единый формат разрывает связку «сервис вывода — библиотека обучения». Граф вычислений ONNX описывает только то, что нужно для прогона: операторы, формы входов, веса. Из контейнера уходит тяжёлая среда обучения, поэтому время холодного старта модели сокращается с десятков секунд до единиц — реплика успевает подняться до прихода трафика, а не после.

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

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

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

Ограничение честное: не все операторы конвертируются один в один. Для кастомных слоёв мы пишем реализацию под целевую среду исполнения, а численный результат сверяем с исходной моделью на эталонном наборе входов — расхождение выше допуска блокирует релиз. Эта сверка и даёт ту стабильность релиза модели, которую видно в метриках.

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

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

Выбор делаем от условий эксплуатации, а не от моды на формат: сначала фиксируем, где модель будет работать и какие метрики качества терять нельзя, затем считаем допустимую нагрузку. На практике гибридный режим даёт ускорение в два-три раза на пиках, сохраняя точность базовой ветки для остального трафика.

Этапы работы: от аудита графа до передачи

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

1. Инвентаризация моделей. Собираем то, что выходит в продуктив: на чём обучали, входы и выходы, частоту переобучения, требования к задержке отклика. Отмечаем, что переносим первым, а что может подождать.

2. Аудит вычислительного графа. Разбираем граф по узлам: нестандартные слои, динамические оси, постобработка внутри самой модели. Всё, что не имеет прямого аналога в целевом формате, помечаем — это и есть объём доработок.

3. Схема переноса модели. Фиксируем, что переносится как есть, что заменяется эквивалентным оператором, а что уходит в код приложения. Согласуем точность расчётов и допустимое расхождение выходов.

4. Сборка артефактов модели. Готовим граф, конфигурацию входов и выходов, словари и правила предобработки, версионируем их вместе с весами. Пересборка воспроизводима одной командой, без ручных правок.

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

6. Передача решения команде. Отдаём артефакты, скрипты пересборки, описание схемы переноса и регламент добавления новых моделей, обучаем ваших инженеров. Остаёмся на связи на период первых релизов.

Что остаётся у вас после завершения работ

Работы заканчиваются не показом демонстрации, а состоянием репозитория, в который можно вернуться через полгода и повторить перенос без нас. Ниже — что именно остаётся у вас и какую задачу закрывает каждая единица.

• Конфигурации сборки модели — параметры экспорта, перечень поддерживаемых операторов, зафиксированные размерности входов. Повторная сборка из этих файлов даёт тот же артефакт, а не «примерно похожий».
• Схема предобработки данных — порядок нормализации, приведение типов, обработка пропусков и крайних значений. Она описывает, как сырой запрос превращается во вход модели, и совпадает с тем, что реально проверялось при переносе.
• Политики доступа к моделям — роли на публикацию и чтение артефактов в хранилище, правила выдачи ключей на стороне исполнения. Отзыв доступа не требует пересборки модели.
• Регламент повторного переноса — пошаговый маршрут для обновлённой версии: от фиксации весов до прогона проверок. Инженер вашей команды проходит его самостоятельно.
• Тестовые наборы для проверки — эталонные входы с ожидаемыми выходами и допустимым расхождением. Они же служат основанием для приёмки и для разбора регрессий в будущем.
• Отчёт о сверке — расхождение по метрикам между исходной и перенесённой моделью на контрольной выборке, с указанием слоёв, где допуск превышен.

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

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

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

Что изменили

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

Что стало

Теперь на всех узлах лежит один и тот же файл модели — развёртывание свелось к доставке артефакта и перезапуску сервиса, откат на предыдущую версию занимает минуты. Медианный отклик сократился примерно вдвое, хвост задержек на тяжёлых запросах — на треть. Доля отказов по таймауту упала с шести процентов до одного, при этом точность ответов осталась на прежнем уровне: модель та же, изменился только способ её исполнения.

Что делать, если модель уже собрана в другом формате

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

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

Дальше снимают эталонные ответы: исходную модель прогоняют на контрольном наборе примеров и сохраняют выходы. Это единственная база для сравнения, и получить её можно только до конвертации — после неё отличить ошибку переноса от старой ошибки модели уже не получится.

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

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

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

Технические сомнения вокруг ONNX и ответы инженеров

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

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

Что делать со слоями, которых нет в стандартном наборе?

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

Придётся ли переобучать модель?

Нет. Перенос не меняет веса и не требует новых данных — иначе сдвинулось бы качество и понадобилась повторная валидация. Переобучение нужно только если вы сами меняете архитектуру под требования устройства.

Как убедиться, что выходы совпадают?

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

Можно ли вернуться к исходному формату?

Да, обратный перенос возможен. Но мы не полагаемся на него: исходные веса, конфигурацию обучения и скрипт экспорта храним в репозитории модели, поэтому откат занимает минуты, а не превращается в восстановление по памяти.

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

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

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

По этим данным мы смотрим, где хватит штатных операторов, а где придётся писать свои, и собираем план работ по переносу: этапы, точки промежуточной проверки, состав команды на задачу — инженер по машинному обучению, специалист по среде исполнения, тестировщик. Вернёмся с оценкой по каждому этапу, сроками переноса модели и перечнем рисков, влияющих на дату запуска. Опишите задачу и приложите то, что есть, — вернёмся с планом и уточняющими вопросами.