OpenVINO обрабатывает больше запросов — но один ответ может не стать быстрее

Режим THROUGHPUT в OpenVINO помогает обслуживать много параллельных запросов. Это не обещание сократить ожидание каждого ответа: для одиночного запроса предусмотрен LATENCY. Выбор стоит начинать с нагрузки приложения, затем сравнивать оба режима на одной модели и устройстве.

Что известно о двух целях

В документации performance hints подсказка задаёт цель, а плагин устройства подбирает низкоуровневые настройки с учётом модели. Для THROUGHPUT это может включать число потоков исполнения, а на GPU — выбор размера пакета и автоматическое объединение запросов, где оно поддерживается.

Цена тоже есть: модель может загружаться дольше и занимать больше памяти. Установка подсказки не создаёт параллельную работу внутри вашего приложения. Если оно отправляет следующий запрос только после завершения предыдущего, возможности режима высокой пропускной способности могут остаться неиспользованными.

Сравните на одном устройстве

Для первого замера используйте benchmark_app. Подставьте путь к подготовленной поддерживаемой модели и доступное устройство; здесь приведён пример для CPU:

benchmark_app -m model.xml -d CPU -hint latency
benchmark_app -m model.xml -d CPU -hint tput

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

При переносе режима в приложение запросите optimal_number_of_infer_requests у скомпилированной модели. Документация рекомендует запускать соответствующее число запросов параллельно, чтобы использовать устройство эффективно. Если реальный источник даёт меньше независимой работы, настройку нужно согласовать с этим ограничением; для него существует дополнительная подсказка num_requests.

Что это меняет для приложения

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

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

Что ещё нужно проверить

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

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