Оптимизация AI на Intel OpenVINO: конвертация, квантование, деплой

Почему модель на OpenVINO теряет скорость после переноса

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

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

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

Третье — память. Лишние копии входных буферов, отсутствие общего доступа к памяти между приложением и ускорителем, один запрос за раз и неподобранное число потоков дают рост потребления и просадку при параллельных запросах. Отдельно бьёт квантование «на глаз»: пересчёты в float между слоями возвращают часть графа на CPU.

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

Измеримые эффекты оптимизации: пропускная способность и задержка

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

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

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

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

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

Варианты работы с OpenVINO: конвертация и режимы развёртывания

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

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

Как мы внедряем оптимизацию: этапы инженерной работы

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

Порядок этапов

1. Аудит модели и схемы запуска. Разбираем граф, находим операторы, которые не ложатся на целевое железо, и смотрим, как модель вызывается сейчас. На выходе — список узких мест и план работ.
2. Конвертация и сверка. Переводим модель в формат OpenVINO и сравниваем выходы с исходной версией на контрольной выборке. Расхождение выше допуска разбираем сразу, а не после запуска.
3. Настройка выполнения. Подбираем точность расчётов, число потоков и режим вывода под конкретное железо — серверный процессор, встроенную или дискретную графику. Убираем лишние копирования данных между этапами.
4. Квантование с контролем качества. Переводим веса в целочисленную точность и следим за деградацией на классах, где модель ошибалась и раньше. Ускорение не имеет смысла, если растёт доля ложных срабатываний.
5. Тестирование на реальных данных. Прогоняем выборку из боевого трафика: сравниваем качество, время отклика и потребление ресурсов до и после. Отдельно смотрим пиковую нагрузку, а не средние значения.
6. Передача решения. Отдаём конфигурации, скрипты сборки и инструкцию по повторной конвертации, обучаем команду. Дальше обновление версий модели проходит без нас.

На каждом шаге остаётся след: видно, что и насколько ускорилось и куда откатиться, если новая версия модели поведёт себя иначе.

Что остаётся у вас: конфигурации, схемы и регламенты

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

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

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

Кейс: как убрали задержки на устройствах после оптимизации

Что было до оптимизации

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

Что изменили

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

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

Что стало

Задержка реакции сократилась вчетверо, поток обработанных кадров вырос втрое на том же парке устройств — докупать ускорители не пришлось. Доля ошибок распознавания упала с 6% до 2%, а на пике — с 12% до 4%. При трёхкратном всплеске нагрузки очередь больше не растёт: система держит отклик в пределах нормы, а оператор подключается только к пограничным случаям.

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

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

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

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

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

В Intel OpenVINO есть штатные средства сравнения выходов и статистики по слоям — мы встраиваем их в конвейер сборки, чтобы потеря точности ловилась на этапе конвертации, а не в рабочей среде.

Технические вопросы, которые задают до старта проекта

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

Квантование ломает точность?

8-битное квантование почти всегда меняет метрики — вопрос в том, насколько. Замеряем качество на валидационном наборе до и после, держим согласованный порог деградации, а чувствительные слои оставляем в 16 битах. Если порог не проходит — переходим на смешанный режим, а не «дожимаем» ускорение в ущерб результату.

Заработает ли на уже установленном парке?

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

Как обновлять модели на устройствах и чем измерять результат?

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

Обсудим вашу задачу: что нужно от вас и от нас

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

Что нужно для старта

• Модель в исходном виде: веса и описание архитектуры из фреймворка обучения — от этого зависит объём промежуточного преобразования.
• Целевое железо: класс ускорителя и операционная система, где будет работать вывод.
• Метрика качества и допустимая просадка после сжатия весов.
• Режим работы: время отклика, число параллельных потоков, ограничения по памяти.
• Эталонный набор из нескольких сотен реальных примеров для сверки ответов до и после.
• Ограничения контура: доступы, политика безопасности, можно ли выгружать веса за пределы инфраструктуры.

Что вернём

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

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