Инференс модели что это
Как запихать нейронку в кофеварку
Мир машинного обучения продолжает стремительно развиваться. Всего за год технология может стать мейнстримом, и разительно измениться, придя в повседневность.
За прошедший год-полтора, одной из таких технологий, стали фреймворки выполнения моделей машинного обучения. Не то, что их не было. Но, за этот год, те которые были — стали сильно проще, удобнее, мощнее.
В статье я попробую осветить всё что повылезало за последнее время. Чтобы вы, решив использовать нейронную сеть в очередном калькуляторе, знали куда смотреть.
Перед началом статьи нужно сразу сказать несколько дисклеймеров:
Часть 1. “Что такое инференс”
Мир нейронных сетей можно разбить на две части:
Чаще всего для обучения используются Nvidia GPU (да, есть TPU от Google, или Intel Xe, но скорее это редкость). Так что софт для обучения должен хорошо поддерживать одну платформу.
Нужно ли обучение при использовании нейронной сети в проде? Очень редко. Да, у нас было несколько проектов с автоматическим дообучением. Но лучше этого избегать. Это сложно и нестабильно.
Да и если нужно, то проще утащить на внешний сервак и там дообучить.
Как следствие — можно отбросить 90% математики и обвеса, использовать только выполнение. Это и называется “инференс”. Он быстрее, чем обучение. Требует сильно меньше математики.
Но вот засада. Не тащить же для инференса GPU. Инференс может быть и на десктопах, и на мобильниках, и на серверах, и в браузере.
В чём его сложность?
Нейронные сети едят много производительности — нужно либо специальное железо и его поддержка, либо максимальная утилизация существующего, чтобы хоть как-то достать производительность.
А железо очень-очень разное. Например в телефонах Android может существовать с десяток различных вычислителей, каждый из которых имеет свою архитектуру. А значит ваш модуль должен быть универсален для большинства.
Часть 2. Железо
Железо в ML бывает очень разное. Его хотя бы примерное описание на текущий момент будет требовать десятка статей. Могу вам посоветовать очень крутую статью от 3Dvideo про технологии аппаратного ускорения нейронных сетей. И свою статью про то как устроены embedding системы в последнее время.
И то и то уже немного неактуально, ведь всё быстро-быстро меняется;)
Для упрощения понимания статьи, или для тех кто не хочет углубляться я накидал упрощённую схему которой мы будем оперировать (кликабельно):
Тут мы видим несколько направлений инференса:
Есть фреймворки которые теряют в разветвленности, но неплохо работают там где работают. Есть которые используют максимально популярные устройства, но не работают на других. Опять же, если показать это ооочень примерно, то выйдет как-то так:
Поговорим подробнее, скорее слева на право.
Специализированное железо: Gyrfalcon, Khadas, Hikvision, и.т.д.
Всё это добро я решил выделить в одну группу. Фреймворком это назвать сложно. Обычно это специализированный софт который может перенести нейронку на железо, чтобы она выполнялась там оптимально. При этом железяка у производителей зачастую одна или две.
Отличительной особенностью таких платформ является:
Более подробно рассказывать про эту часть наверное нет смысла.
Специализированное железо но от крупных фирм
Крупные производители железа обычно имеют много разного железа, но всё оно программируется в рамках одного фреймворка. Это открытые фреймворки, которые можно спокойно скачать и использовать.
Они позволяют портировать нейронку и использовать её максимально эффективно. В большинстве случаев поддерживаются все современные архитектуры, а если не поддерживаются, то есть другие способы их использовать или добавить.
Поговорим про них подробнее:
Nvidia — TensorRT
Наверное это самая классика, и не надо рассказывать почему. Больше 90% ресёрча использует именно видюхи NVIDIA. Инференс часто на них же => все стараются выжать максимум, а для этого нужны TensorRT — специальный фреймворк который максимально утилизирует мощь видеокарты для нейронных сетей.
Более того, если вы пишите на CUDA — то можете в рамках одного обработчика обрабатывать данные. Самый классический пример — NMS. Например, когда-то давно мы переписывали кусок одного детектора поз на CUDA чтобы не гонять данные на процессор. И это очень ускоряло его работу.
Нужно понимать, что NVIDIA целит в три области, и везде TensorRT используется:
Мне кажется, что если вы делаете инференс на Nvidia, то у вас просто нет альтернатив — надо использовать TensorRT. Всё остальное приведёт к падению производительности.
Triton Inference Server
Но, так как мы говорим про инференс, то нужно упомянуть Triton Inference Server. Это не совсем TensorRT (хотя TensorRT подразумевается как оптимальный для него фреймворк). Triton может использовать TensorFlow, PyTorch, Caffe. Он сам ограничивает память и настраивает любой из упомянутых фреймворков, управляя выполняющимися сетями.
Triton сам решает какие модели загружать-выгружать из памяти, сам решает какой batch использовать. Может использовать не только TensorRT модели, но и модели *.pd, *.pth, ONNX, и.т.д., (ведь далеко не все можно сконвертировать в tensorrt). Triton может раскладывать по нескольким GPU. И прочее и прочее.
Мы использовали его в продакшне в нескольких проектах — и остались ужасно довольны. Максимальная утилизация GPU с минимумом проблем.
Но… Он не сможет выполнить модель где-то за пределами Nvidia
Intel — OpenVino
Intel представлен на рынке:
Мне нравиться OpenVino так как он достаточно стабилен, прост, и имеет инференс почти везде. Я писал на Хабре статью в которой рассказывал опыт одного хоббийного проекта под Intel. Там я отлаживал на десктопах, а тестировал на RPi с мовидиусом. И все было норм.
В целом, все 2-3 проекта которые мы делали в своей практике под OpenVino, прошли примерно так же. Минимум сложностей, удобный инференс, заказчик доволен.
Open Vino интегрирован в OpenCV про который мы ещё поговорим. OpenCV тоже от Intel, но я бы рассматривал его как отдельный фреймворк/способ инференса и подхода к данным.
Отдельно я бы хотел отметить один забавный момент. Аренда GPU сервера для того чтобы развернуть модель в онлайне будет стоить где-то от 10к. рублей, где-то до 100к. рублей, в зависимости от используемых видюх.
Аренда сервака с I5 на каком-нибудь клауде зачастую возможна за 500-1000 рублей в месяц.
Разница в производительности между TensorRT и ONNX на сравнимых по цене процах может быть в 2-20 раз (зависит от сети). Как следствие — часто можно неплохо сэкономить перенеся онлайн инференс на ONNX.
Google — Edge
Google очень неоднозначная фирма сама по себе. Мало того, что Google имеет свой стек аппаратуры для инференса нейронных сетей. Ещё у Google целый стек различных фреймворков про которые мы поговорим позже. Запутанный и местами бажный. Но в целом это:
Минусом Edge является то, что из коробки поддерживаются не все модели, гарантирована поддержка лишь нескольких (coral.ai/models/). А конвертация достаточно усложнена (TF → TF Lite → Edge TPU):
Конвертация в Cloud TPU чуть проще, но и там есть свои особенности. Я не буду более подробно рассказывать про особенности этого фреймворка. Скажу лишь что каждый раз когда с ним сталкивался — оставались неприятные впечатления, так что не стали тащить его нигде в прод.
Универсализация с хорошей аппаратной поддержкой
Мы переходим в область подходов, которые достаточно оптимально используют железо, но будут требовать немного разный код на разных платформах (нельзя же на Android всё сделать на Python).
Тут я бы упорядочил как-то так (опять же, очень условно):
Пройдем по этому списку.
OpenCV
OpenCV это легендарный фреймворк ComputerVision появившийся более 15 лет назад. За свои 12 лет занятий ComputerVision я запускал его на Arm году в 2010, на BlackFin примерно тогда же, на мобильниках, на серверах, на RPi, на Jetson, и много-много где. У него есть классные биндинги на Python, Java, JavaScript, когда-то я вовсю использовал его на C#.
OpenCV более чем живой и сейчас. И нейронные сети активно просачиваются туда с самого их появления.
Мне кажется, что на сегодня у OpenCV есть несколько глобальных минусов:
По нашим тестам в OpenCV нейронные сети на CUDA выполняются медленнее чем в TensorRT всего на 5-10%, что отлично.
Это делает OpenCV весьма ценным фреймворком для серверных решений, где нужно выжимать максимум из имеющегося ускорителя, какой бы он не был.
Так же OpenCV очень неплохо поддерживает различные CPU на ARM-устройствах. На том же RPi он использует NEON.
Tensorflow lite
Чуть ближе к мобильному миру лежит TensorFlow lite. Он может исполнять нейронные сети как и на обычном GPU мобильного устройства, так и на возможных сопроцессорах, если производитель телефона соблюдает какой-то набор стандартов. Для мобильников возможные варианты выглядят примерно так:
В большинстве случаев вы автоматически можете проверить максимальный уровень ускорения и запустить именно на нём. Детальной карты того какие вендоры предоставляют какую поддержку железа я не нашёл. Но я видел несколько примеров которые начались поддерживаться. Например под Snapdragon мы когда-то портировали сети, а потом TFLite начал его поддерживать.
Чуть более подробно о том что насколько даёт прирост можно посмотреть, например, тут. Также, стоит упомянуть, что изначально поддержка GPU шла за счёт OpenGL, но в последнее время Google добавила и OpenCL, чем почти в 2 раза ускорила выполнение сетей.
Но прелесть TFlite не только в том что он работает под мобильниками. Он ещё достаточно неплох для части embedded устройств. Например, он достаточно эффективно работает под RaspberryPI. На последнем DataFest ребята из X5 рассказывали что они используют эту конструкцию в продакшне.
Так же, TFlite, за счёт XNNPACK неплохо работает на процессорах (но не так эффективно как OpenVino на Intel). Это даёт возможность использовать TFLite как способ инферить модели на десктопах. Хоть и без поддержки GPU. Зато без тонны лишних зависимостей.
ONNX runtime
В какой-то момент в гонку ворвался Microsoft, который решил зайти со стороны. Сначала они выпустили универсальный формат сохранения нейронных сетей, который сейчас достаточно популярен, — ONNX.
И, когда уже форматом многие начали пользоваться, — решили сделать свой рантайм для него.
Если честно, то я даже не знаю половину того что представлено в списке. )
Выглядит всё идеально (а ещё всё поддерживается на Python, Java, C, C++, C# и.т.д.)…
Но пока что мне не довелось использовать ONNX-runtime на практике, кроме ONNX.js, о котором будет ниже. Так что не могу гарантировать что всё работает идеально. В интернетах слишком мало примеров того как всё работает. И знакомых которые бы на этом разворачивали продакшн полноценный тоже не знаю (максимум тестировали но не решили развернуть).
Но в гайдах уверяется что даже для Raspberry PI и Jetson есть поддержка.
Про поддержку ios явно ничего не сказано. Но местами «ios» встречается по коду. А кто-то билдит.
PyTorch
Одна из проблем использования OpenCV, TFlite, ONNX Runtime: “А почему мне надо обучать в одном фреймворке, а использовать в другом?”. И авторы PyTorch тоже задают себе такой вопрос. Так что, прямо из коробки, предоставляют способ использования PyTorch на мобильниках:
Скажу честно, я не тестировал скорости инференса. Но по опросу знакомых — в целом все считают это медленным вариантом. По крайней мере инференс PyTorch на процессорах и GPU — тоже не самый быстрый. Хотя, опять же, XNNPACK используют.
Но, данный вариант вполне удобен для разработки и пуша в продакшн (нет лишних конвертаций, и.т.д.). Мне кажется, что иногда это хороший вариант (например когда нет требований на очень высокую производительность).
TensorFlow
Кроме использования TFlite можно использовать и оригинальный TF, для развертывания на embedded устройствах и десктопах. При этом TF имеет достаточно высокую степень конфигурируемости. Но, на мой взгляд, это достаточно мертвый вариант в будущем.
Китайское вторжение
Теперь мы переходим к двум вариантам, которые не тестировал почти никто из моих знакомых. Но которые выглядят весьма перспективно.
Первый из них — MNN, вариант от alibaba.
Авторы уверяют, что MNN — самый легковесный из фреймворков, который обеспечивает инференс на большом числе устройств, при использовании GPU или CPU. При этом поддерживает большой спектр моделей.
Второй вариант интереснее, это ncnn от Tencent. Согласно документации библиотека работает на большом числе устройств. Реализована на c++:
На неё даже Yolov4 спортировано. И в целом, AlexeyAB очень позитивно отзывался.
Но, опять же, у меня достаточно мало информации о практическом применении. Сам не использовал, в проектах которые видел/консультировал — никто не использовал.
При этом можно отметить, что не так много нативных решений одновременно поддерживают и телефоны и nvidia.
JS — Tensorflow.JS, ONNX.js
Я бы объединил эти две категории в общий раздел, хотя, конечно, у TensorFlow.js и ONNX.js есть много различий. TensorFlow чуть лучше поддерживает оптимизацию. ONNX чуть быстрее. LSTM не присутствует в ONNX. И прочее и прочее.
В чем особенность этого класса инференс фреймворков? В том, что они выполняются только на CPU, или на GPU. По сути через WebGL или через WebAssembly. Это наборы инструкций, которые доступны через браузерный JS.
Как плюс — имеем офигенную универсальность такого подхода. Написав один раз код на JS — можно исполнять его на любом устройстве. Если есть GPU — на нём. Если только CPU — на нём.
Основной минус — тоже понятен. Никакой поддержки за пределами CPU или GPU (ускорители/сопроцессоры). Невозможно использовать эффективные способы утилизации CPU и GPU (те же OpenVino или TensorRT).
Правда, под Node.js, TF.js умеет в TPU:
При этом этот вариант явно оптимальный, если вам нужно использовать простые модели, имея кроссплатформенность.
Мы использовали в проектах оба инференса, всё работало хорошо. Но, конечно, производительность немного жалко.
Как небольшое резюме
Выводы сложно делать. Я не смог придумать какого-то однозначного алгоритма который бы помогал выбрать платформу на которой нужно разворачивать ML решение в зависимости от бизнес требований, аппаратуры и сложности сетей.
А так… Тема объёмная. Ведь чтобы достаточно подробно рассмотреть TensorFlow lite со всеми плюсами и минусами — надо написать две таких статьи. А для полного обзора OpenCV и десяти не хватит. Но сил написать столько нет.
С другой стороны, я надеюсь, написанное поможет кому-то хоть немного структурировать логику при выборе платформы для инференса.
А если у вас есть и другие идеи как выбирать — пишите!
В последнее время делаю много мелких статей/видеороликов. Так как это не формат Хабра — то публикую их в блоге или на ютубе. Подборка всего есть в телеге и вк.
На Хабре обычно публикую, когда рассказ становится уже более самозамкнутым, иногда собрав 2-3 разных мини-рассказа на соседние темы.
Приемы повышения производительности инференса глубоких моделей с DL Workbench. Часть 1 — введение и установка
Если у вас есть проект с интенсивной обработкой данных глубокими моделями (или еще нет, но вы собираетесь его создать), то вам будет полезно познакомиться с приемами по повышению их производительности и уменьшению затрат на покупку / аренду вычислительных мощностей. Тем более, что многие из приемов сейчас выполняются буквально за несколько кликов мышкой, но при этом позволяют повысить производительность на порядок. В этом посте мы рассмотрим, какие оптимизации бывают, установим Docker на Windows 10 и запустим DL Workbench, измерим производительность инференса без оптимизации и с применением оных.
Введение
Перед тем, как погружаться в ускорение глубоких моделей, сначала нужно посмотреть на общую схему жизни любой глубокой модели в каком-либо проекте. В течение «жизни» глубокой модели есть этапы обучения модели и многократного вывода (инференса). Кстати, благодаря четкому разделению на тренировку и инференс модели в ее жизненном цикле, появились специализированные фреймворки только для инференса, как например ONNX runtime или OpenVINO.
Стадии жизни модели глубокого обучения
Обучение модели производится один или несколько раз, и затраты на железо / электричество на ее обучение не являются фатальными (если, конечно, вы не обучаете GPT-3, для обучения которой OpenAI могла потратить до 4,6 миллиона долларов). А вот при многократном инференсе модели даже небольшие улучшения могут дать хорошую экономию бюджета. Причем для использования некоторых оптимизаций нужно приложить минимальные усилия.
Приемы оптимизации можно разделить на следующие группы:
Внедрение новых, более быстро исполняемых слоев при разработке модели. Группа объединяет приемы, которые закладываются во все модели на этапе конструирования модели. Простейший пример — использование простой и быстрой функции активации ReLU в сверточных глубоких моделях. Такие оптимизации будут за рамками данной статьи.
Оптимизация модели через модификацию некоторых слоев. К таким оптимизациям можно отнести использование слияния линейных операций (Linear Operations Fusing) модели для моделей ResNet. Такие операции применяются автоматически и незаметно при конвертации модели в OpenVINO, но про них полезно знать.
Увеличение степени параллельного исполнения через увеличение числа операций, которые можно выполнить одновременно. Сюда мы отнесем подходы с увеличением размера пачки одновременно обрабатываемых изображений (батча) и запуск на обработку нескольких изображений параллельно и независимо.
Использование типов данных меньшей точности для увеличения производительности. Сюда в первую очередь относится квантизация моделей — ускорение модели и возможное снижение ее точности за счет использования типа данных INT8. Кроме того, есть возможность сразу тренировать глубокие модели с использованием типов данных меньшей точности, но данный метод пока не очень популярен.
После небольшого теоретического экскурса можно переходить к практике. Мы рассмотрим примеры оптимизации инференса, которые мы можем «пощупать» в фрейморке DL Workbench от разработчиков OpenVINO. Intel Distribution of OpenVINO Toolkit — это набор инструментов для оптимизации и высокопроизводительного инференса глубоких моделей. В OpenVINO можно сконвертировать, оптимизировать и запустить модели в форматах Caffe, TensorFlow, MXNet, ONNX (а через формат ONNX мы можем загружать модели из всех остальных фреймворков). Для более детального знакомства с OpenVINO можно посмотреть вот эту презентацию на русском, либо посмотреть оригинальную документацию (но на английском). DL Workbench — это графический интерфейс для более удобного и наглядного взаимодействия с инструментами оптимизации.
Для кого создавался DL Workbench и какие его главные функции
Установка DL Workbench
Чтобы начать работать с DL Workbench, нужно его установить, но сначала нужно установить Docker. Если вы еще не пользуетесь Docker в Windows 10, то в его установке на Windows есть дополнительные шаги.
Установить WSL 2 по умолчанию (пишут, что команду нужно выполнять в PowerShell):
Скачать и установить докер.
После установки докера запуск DL Workbench сводится к двум командам. Скачать его через docker pull и запустить через docker run.
Работа в DL WorkBench
После запуска DL Workbench в браузере открывается приветственная страница, в которой нам предложат создать конфигурацию теста, состоящего из модели, устройства для инференса и датасета.
Приветственное окно DL WorkBench
Импортируем модель из Open Model Zoo и конвертируем в IR
В то время, когда модель конвертировалась в IR формат, уже были применены некоторые структурные оптимизации по слиянию слоев. Например, для моделей ResNet, которые часто являются основой для трансфер лернинг и, таким образом, задействованы в большом количестве моделей из самых разных областей, производится операция слияния слоев (Linear operation Fusing), что уже дает хорошее ускорение по инференсу моделей по сравнению с фреймворками для обучения моделей. На рисунке ниже можно посмотреть, как OpenVINO оптимизирует структурный блок модели ResNet-50. Вместо 12 слоев в оригинальном фреймворке 8 в оптимизированном представлении, картинка со страницы Model Optimizer.
Более подробно про оптимизации модели во время конвертации можно прочитать на странице Model Optimizer. Там описано какие еще применяются оптимизации слоев внутри модели при конвертации.
С внутренними оптимизациями модели пока все, возвращаемся к DL Workbench и смотрим на оптимизации не самой модели, а ее инференса. Для этого нужно загрузить датасет или сгенерировать фейковый набор данных из шума, чтобы запускать тесты производительности. Во второй части статьи мы рассмотрим, как загрузить реальный датасет, когда он нам понадобится для квантизации моделей.
Генерируем датасет из шума для бенчмаркинга
Первые результаты производительности MobileNet-v2 на i5-10600
Во всех фреймворках поддерживается увеличение производительности за счет увеличения размера пачки. Размер пачки подбирается в зависимости от количества ядер экспериментально. В DL Workbench мы можем выполнить эксперименты по подбору оптимального размера пачки. Как правило, размер пачки в несколько раз превышает число физических ядер при инференсе на CPU, в нашем случае на графике ниже будет видно, что оптимальным значением является 8 картинок в пачке, при дальнейшем увеличении производительность уменьшается. По сравнению с 326 fps при размере пачки 1, 410 fps при размере пачки 8 составляют увеличение производительности на 25%, уже неплохо.
График производительности с различными размерами пачки
Deep Learning Inference Benchmark — измеряем скорость работы моделей глубокого обучения
Перед разработчиками встает задача определения производительности железа в задаче исполнения глубоких моделей. Например, хочется решить проблему анализа пола-возраста покупателей, которые заходят в магазин, чтобы в зависимости от этого менять оформление магазина или наполнение товаром. Вы уже знаете какие модели хотите использовать в вашем ПО, но до конца не понятно как выбрать железо. Можно выбрать самый топ и переплачивать как за простаивающие мощности, так и за электроэнергию. Можно взять самый дешевый i3 и потом вдруг окажется, что он может вывезти каскад из нескольких глубоких моделей на 8 камерах. А может быть камера всего одна, и для решения задачи достаточно Raspberry Pi с Movidius Neural Compute Stick? Поэтому хочется иметь инструмент для оценки скорости работы вашего инференса на разном железе, причем еще до начала обучения.
В целом можно выделить три направления работы с глубокими моделями:
Общую схему решения задач с использованием глубокого обучения можно представить следующим образом:
Из лекции курса по современным методам и технологиям глубокого обучения в компьютерном зрении
Как правило, требования по скорости заложены еще на этапе постановки задачи, и хочется еще до начала обучения или дообучения узнать «уложится» или нет предполагаемая модель в доступные для инференса ресурсы. И для решения этой задачи был создан DLI benchmark.
DLI benchmark
В рамках лаборатории ITLab студентами ННГУ им. Н.И.Лобачевского был разработан открытый фреймворк DLI (https://github.com/itlab-vision/dl-benchmark), который позволяет запустить измерение производительности большого количества разных моделей на доступном железе.
Основные требования, которые были заложены на этапе разработки:
Архитектура фреймворка
Схема со страницы проекта
Алгоритм работы DLI-benchmark:
Типы экспериментов
При обработке картинок по одной вычислительное устройство очень часто недогружено. Можно подать два изображения одной пачкой (batch=2), тогда они обработаются быстрее чем два изображения по отдельности. При увеличении размера пачки производительность сначала начнет расти, а потом падать, и определить лучший размер пачки весьма полезно.
В современных фреймворках поддерживается асинхронный режим работы, когда не нужно дожидаться конца обработки предыдущего изображения, можно новую картинку начать обрабатывать сразу после поступления. При использовании асинхронного API в OpenVINO можно создавать реквесты по 1 картинке независимо и при этом получать по прежнему высокую производительность и при этом низкие задержки. Возможность получать высокую производительность, сохраняя при этом низкие задержки, открывает новые возможности для инференса глубоких моделей на многосокетных высокопроизводительных системах.
Метрики производительности
В случае когда мы можем подавать несколько картинок независимо друг от друга (асинхронный запуск на обработку), мы используем другие метрики производительности.
Анализ результатов
В ходе экспериментов мы попробовали бенчмарк на различном оборудовании: CPU i7-7700K, i5-8600K, i3-7100, i7-8700, i3-8100, GPU Intel HD Graphics 630, Intel Neural Compute Stick 2.
Пока опубликовали результаты только для фреймворка OpenVINO. Докеры бенчмарка с Caffe, TensofFlow и PyTorch в разработке.
Для демонстрации примеров работы возьмем модель ResNet-152 — это очень объемная модель, которая решает задачу классификации ImageNet.
На графике ниже представлена время обработки одной пачки картинок в различных режимах. На данном графике по оси X отложено количество потоков процессора, которые были использованы для обработки изображений, а по оси Y — среднее время обработки (или задержка, latency) одной пачки изображений. На этом графике мы видим, что при удвоении использованных потоков скорость обработки увеличивается примерно в два раза — это означает отличную параллеллизацию в обработке изображений. Что важно, параллелизация показывает хорошие результаты и для большой пачки картинок, и для одиночной картинки.
Чтобы посчитать FPS (сколько в среднем картинок в секунду обработает процессор в каждом режиме работы) нужно количество картинок в пачке разделить на время обработки одной пачки. Эти данные мы приведем в таблице ниже.
Взглянув на эти цифры, мы видим, что если мы будем использовать все 6 ядер процессора, что при обработке картинок пачками по 8 штук производительность возрастает на 20% из-за более плотной упаковки вычислений. Но в прикладном ПО не слишком хочется писать дополнительные функции, чтобы собирать картинки в пачки, да и задержки тогда возрастают…
В этом случае нам на помощь приходит асинхронный запуск нескольких картинок на обработку! OpenVINO поддерживает возможность не собирать из картинок большую пачку, а подавать картинки независимо друг от друга не дожидаясь завершения обработки предыдущей. В данном режиме вы задаете в программе количество «стримов» (это не поток процессора; это сущность, которая захватывает один или несколько потоков процессора и обрабатывает в себе картинку), и можете независимо запускать на обработку картинки по мере поступления.
С использованием OpenVINO в асинхронном режиме с размером пачки в 1 картинку мы почти достигаем производительности, полученной в синхронном режиме с размером пачки 8, при этом почти не меняя код запуска моделей.