OpenVINO выбрала AUTO: первые ответы ещё могут идти с CPU
AUTO может обслужить первые запросы на CPU, пока готовится GPU. Памятка помогает заметить переключение и отдельно оценить старт, устойчивую скорость и точность.
AUTO в OpenVINO может начать выполнять запросы на CPU, пока модель готовится для выбранного ускорителя. Это штатный способ сократить ожидание первого ответа. Но короткий замер сразу после запуска способен смешать работу двух устройств — и запутать вывод о скорости или точности модели.
Что известно
В документации AUTO описан startup fallback: CPU помогает на старте, затем работа передаётся подходящему устройству. Механизм зависит от настроек и кеша; для моделей с операциями, сохраняющими состояние, стартовая помощь CPU отключается. Поэтому одинаковое имя AUTO ещё не доказывает одинаковый путь исполнения.
Не путайте стартовую помощь с постоянным распределением запросов по нескольким устройствам. Это разные сценарии. Здесь проверяем именно переход от начала процесса к устойчивому режиму, сохраняя остальные настройки.
Что это меняет
Представьте сервис классификации изображений, который часто перезапускается. Пользователь первым запросом проверяет доступность, а разработчик затем меряет серию изображений. Первый ответ и последующие могут прийти с разных устройств. Вывод «GPU медленная» по одной общей средней будет преждевременным.
Для проверки возьмите одну модель и фиксированный набор входов. Запишите версии среды, выбранные устройства и состояние кеша. Отдельно измерьте время от старта процесса до первого готового ответа, затем задержки после прогрева. Это предложенный протокол сравнения, а не обещание конкретного выигрыша.
Свойство execution_devices позволяет спросить текущие целевые устройства у скомпилированной модели. Снимите его значение на старте и после серии запросов. Если маршрут непонятен, временно включите DEBUG-лог AUTO. В Python документация показывает config={log.level: log.Level.DEBUG}; лог помогает увидеть выбор устройства и ошибки загрузки. После диагностики повторите замер без подробного логирования, чтобы не смешивать его накладные расходы с рабочим режимом.
Что ещё неясно
Сколько времени займёт подготовка именно вашей модели, документация не предсказывает. В benchmark_app отчёт отделяет компиляцию, первый инференс и статистику последующих запусков. Проверяйте также режим измерения: подготовка входов может не входить в цикл. Скорость этого цикла не равна полной задержке сервиса.
Для проверки точности зафиксируйте одно целевое устройство. Документация не рекомендует оценивать её через AUTO: CPU и GPU могут давать немного разные результаты, а их доля в короткой серии меняется. Если нужен именно AUTO без стартовой помощи CPU, предусмотрен enable_startup_fallback=False; сначала проверьте поддержку настройки в своей версии.
Выбирайте по двум отдельным требованиям: насколько быстро нужен первый ответ и как сервис работает после подготовки. Один усреднённый замер не отвечает на оба вопроса.
Комментарии
Войдите, чтобы оставить комментарий
Пока нет комментариев. Начните обсуждение.