Что такое инференс нейронные сети
Как мы сделали акселератор инференса нейронных сетей для ЦОД с 64 чипами Intel Movidius
Некоторое время назад мы искали оптимальное аппаратное и программное обеспечение для исполнения нейронных сетей в ЦОД и «на краю» (edge computing). В рамках нашего исследования мы протестировали множество устройств, от процессоров до встроенной графики iGPU и GPGPU различных производителей. С результатами исследования можно ознакомиться по ссылке.
В рамках этого исследования нас заинтересовал VPU Intel Movidius (MyriadX). При вычислениях «на краю» и использовании фреймворка Intel OpenVINO он позволял нам увеличивать число потоков или каналов путем дооснащения существующих устройств без какой-либо модификации аппаратной и программной базы. По умолчанию мы использовали встроенную графику, например, Intel HD или Iris Plus 655, но если FPS и число потоков необходимо было увеличивать, то промышленные ПК можно было дооснастить VPU. Это давало возможность сохранить единообразие множества устройств при изменяемом числе потоков. В качестве примера можно привести транспортную отрасль и подсчет пассажиров на борту автобусов. Автобусы бывают с 2, 3 и 4 дверьми. И если для двух дверей достаточно встроенной графики, то для четырех необходимо увеличение FPS, что достигалось расширением готового решения при помощи VPU формата M.2.
Вот так выглядело наше устройство для исполнения нейронных сетей «на краю» с Intel Movidius:
ComBox Outdoor Box Squared
Сегодня для инференса «на краю» интерес представляют решения от компании AAEON, в частности VPC-3350S, VPC-3350AI:
AAEON VPC-3350S
С использованием Movidius в IoT все было более или менее понятно, но нас заинтересовала хотя бы теоретическая возможность масштабирования и применения этих компактных энергоэффективных чипов в ЦОД в виде ускорителей инференса PCIe формата.
После предварительной оценки рынка мы провели поиск имеющихся решений в формате PCIe. Все найденные на тот момент устройства содержали 4 или 8 Movidius на одну плату. Например, решения от AAEON:
AAEON AI CORE XP4/ XP8
плотность чипов Movidius не менее 64 штук на каждую плату
наличие возможности изменения числа VPU на плате
минимально возможное энергопотребление
форм-фактор PCIe x4/x8
работа конечного устройства под управлением фреймворка Intel OpenVINO без каких-либо значимых доработок
исполнение под использование в серверных платформах
Концепт не заставил себя долго ждать:
ComBox x64 Movidius Blade Board 
ComBox x64 Movidius Blade Board
Результатом проектирования платы получилось устройство PCIe с размещенными на несущей плате кастомными разъемами для подключения дочерних плат с нанесенными на них VPU. Таким образом конечную плату можно использовать с числом VPU до 64 штук, кратно 8. На каждый разъем отведена 1 линия PCIe, а в рамках каждой дочерней платы устройства подключены через USB хаб.
Первые образцы прототипа:
ComBox x64 Movidius Blade Board
Дочерние платы (по 8 Movidius на каждой):
x8 Movidius blades for ComBox x64 Movidius board
Для тестирования и отладки мы использовали платформу Supermicro SYS-1029TRT и рекомендуем ее по следующим причинам:
хорошее соотношения цена/качество
форм-фактора 1U (занимает 1 место в стойке)
наличие 4 портов PCIe x8/x16
Про 1U отдельно отмечу, что при высоком энергопотреблении платформы и установленных ускорителей это не важно из-за наличия лимитов энергопотребления на шкаф, в целом. Но так как мы говорим о чипах, изначально предназначенных для использования в IoT, вся плата отличается низким энергопотреблением, что позволяет повышать плотность количества серверов в стойках.
Supermicro SYS-1029TRT с установленной платой ComBox x64 Movidius Blade Board
На картинке выше у нас установлено 4 дочерних платы с 32 Movidius, что отображается на обратной стороне ускорителя 4 зелеными диодами.
Вид готового изделия:
ComBox x64 Movidius Blade Board
И первые промышленные образцы платы:
Каких итогов мы добились:
Максимальная плотность VPU Movidius на одной плате в мире.
Энергопотребление платы не более 120 Вт при полной загрузке.
Возможность использовать произвольное число дочерних плат и устанавливать по 8, 16, 24 и т.д. VPU в рамках одной несущей платы.
Возможность запуска инференса под управлением фреймворка Intel OpenVINO с использованием MDL и HDDL плагинов.
Следующие планируемые шаги:
Выпуск несущих плат с интегрируемым аппаратным ключом Senselock для защиты моделей нейронных сетей в процессе их исполнения.
Предоставление облачных мощностей для инференса в аренду на базе ComBox x64 Movidius Blade board.
Оценка эффективности инференса нейронных сетей
Развитие рынка нейронных сетей подразумевает под собой удешевление стоимости железа при постоянном росте производительности. Обычно нейронная сеть проходит три жизненных этапа: обучение, деплой и инференс. Если про обучение и деплой материала в сети предостаточно, то инференс — нераскрытая тема, в которой стоит разобраться.
Инференс
Инференсом называется непрерывная работа какой-либо нейронной сети на конечном устройстве. Инференс выполняется для совершенно разных нейронных сетей, например — для распознавания марок, моделей транспортных средств, лиц, голосов, анализа текстовых материалов и много другого. То есть, это процесс исполнения сети, когда она уже готова к проведению полезной работы.
Для инференса используются процессоры общего назначения CPU, графические процессоры GPU, некоторые другие вычислительные единицы.
Инференс на CPU
В случае использования CPU, инференс выполняется на логических ядрах процессора, число которых равно числу физических ядер или, при использовании технологии Hyper-threading, увеличено вдвое. Решения на современных многоядерных процессорах достаточно дороги, а использование CPU на больших (глубоких) нейросетях неэффективно из-за ограниченного объема кэша процессора и необходимости организации обмена данными с ОЗУ, что существенно влияет на скорость работы. Кроме того, ограничения на производительность накладываются самой архитектурой — в процессе инференса решаются простые задачи сравнения, которые легко переносятся на параллельные вычисления, но количество параллельных потоков обработки всегда будет ограничено количеством логических ядер CPU.
Инференс на GPU
Оценка производительности инференса
Инференс — процесс несложный, в некоторой степени даже примитивный, однако рост сложности нейронной сети приводит к нелинейному росту необходимых для инференса ресурсов. В результате вполне реально упереться в потолок вычислительной производительности системы или канала передачи данных. Из этой проблемы очевидными видятся два выхода — отправлять данные на обработку к серьезным вычислительным мощностям, если канал передачи данных позволяет, или выполнять его на месте, увеличивая локальную производительность. Но и в первом и во втором случае возникает проблема оценки производительности устройств, осуществляющих инференс. Ведь будет очень странным, если нейросеть работает, но для ее работы требуется система стоимостью много мертвых американских президентов.
Производители устройств всегда нацелены на увеличение продаж. Методики тестирования, которые они предлагают, бывают очень своеобразными, как и выводы которые делаются на базе таких тестов. Например, пытались сравнить количество логических ядер разных устройств, заявляя, что количество ядер имеет решающее значение, хотя понятно, что сравнивать десяток Intel 80486 даже с одним Intel i5 мягко говоря неэтично. Пытались сравнить количество обрабатываемых потоков, гордо заявляя, что решение может обрабатывать 100 каналов, тактично замалчивая, что эти потоки – 240p. Каждый измерял в своих попугаях, и каждый из этих попугаев c точки зрения производителя был более правильный и более производительный.
Очевидно, что для практического применения такие методики непригодны. Мы — компания Combox Technology, как разработчики оборудования, нуждались в сравнительных характеристиках, которые позволяли бы объективно оценивать конечную стоимость эксплуатации системы. Мы попытались привязать эффективность к стоимости — той характеристике, которая прямо связана с клиентом. Было проведено исследование скорости сетей различных топологий на различных видах устройств (процессоры и видеокарты) с привязкой к стоимости. Вы можете ознакомиться с ним по ссылке. Основные метрики, которые нас интересовали — это цена за FPS (frame per second) и скорость (relative FPS).
Результаты получились очень интересные. Именно их мы использовали при разработке наших устройств для инференса. Максимальную скорость инференса при оптимальной стоимости FPS можно получить на одноплатном компьютере (SBC) Intel NUC8i5BEK, поскольку на них в полной мере раскрывается потенциал совместного инферена на CPU и GPU. Именно по этой причине мы использовали это устройство в наших устройствах SBC NUC Server. Для другого устройства OutdoorBox NUC используется Intel NUC4i5MYHE.
Эти решения создавались как раз для того, чтобы решить боль, описанную в начале статьи — максимальная эффективность с максимальной объективностью оценки.
Что же получилось в результате?
OutdoorBox NUC — высокопроизводительное решение для инференса на краю, которое используется при необходимости сократить трафик, решать локальные задачи при минимальной стоимости внедрения и эксплуатации. Устройство выполнено во всепогодном исполнении IP66, обладает низким энергопотреблением (30Вт) и обладает великолепной производительностью при низкой стоимости. Одно устройство способно одновременно эффективно работать с 10 потоками FullHD 15fps.
Для корпоративного сегмента при потребностях в высоких вычислительных мощностях мы разработали SBC NUC Server, которое объединяет в одном корпусе до 8 устройств NUC8i5BEK и обеспечивает обработку до 80 потоков FullHD 15fps.
Очевидно, что такие решения разрабатываются не из-за простого интереса к экспериментам. Мы разрабатываем, обучаем и эксплуатируем нейронные сети, например, для целей распознавания марок и моделей транспортных средств, номерных знаков. Для классификации объектов мы используем нейронную сеть на топологии YOLO (You Only Look Once), которая построена на ее упрощенной оптимизированной модели DarkNet19, использующую 19 слоев, взамен оригинальных 25, и нейронную сеть на топологии UNET для детектирования. Решение используется в коммерческом продукте EDGE с MMR (Make and Model Recognition) и LPR (Licence Plate Recognition), который активно эксплуатируется по всему миру – в национальной полиции Колумбии, Мексики, Белоруссии, Грузии, Болгарии, таможенных терминалах Украины, Азербайджана, системах городского видеонаблюдения Аргентины, Омана, Казахстана. Эффект от внедрения SBC NUC Server был очень существенным и осязаемым – в отличие от GPU-серверов на базе Tesla T4, используемых ранее, стоимостью 1 200 000 рублей, наше решение дешевле на 500 000 рублей, энергопотребление вместо 2 кВт на единицу теперь составляет всего 500 Вт. При этом экономится место в стойках – GPU-сервера обычно имеют формат 2U-4U, в отличие от 1U в нашем случае. Что очень важно – мы получили унифицированное решение на стандартной элементной базе, что позволяет в случае необходимости перепрофилировать устройство под другие задачи, кроме инференса (кластерные решения, web-сервер и пр.)
А потребитель теперь может быть уверен в объективности предлагаемых оценок — эффективность измеряется в деньгах — самых универсальных попугаях.
Как запихать нейронку в кофеварку
Мир машинного обучения продолжает стремительно развиваться. Всего за год технология может стать мейнстримом, и разительно измениться, придя в повседневность.
За прошедший год-полтора, одной из таких технологий, стали фреймворки выполнения моделей машинного обучения. Не то, что их не было. Но, за этот год, те которые были — стали сильно проще, удобнее, мощнее.
В статье я попробую осветить всё что повылезало за последнее время. Чтобы вы, решив использовать нейронную сеть в очередном калькуляторе, знали куда смотреть.
Перед началом статьи нужно сразу сказать несколько дисклеймеров:
Часть 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 разных мини-рассказа на соседние темы.