Мы занимаемся объектовой видеоаналитикой. В контексте статьи — это детекция и распознавание объектов. Например, номеров транспортных средств, марок и моделей. Для этого используются сверхточные нейронные сети. В нашем случае две топологии — Darknet19 и UNET. Процесс исполнения нейронных сетей называется инференсом. Источник данных — это видеокамеры. С них поступает видеопоток RTSP Full HD 15 FPS H.264 на устройство для инференса. Это может быть устройство "на краю", микрокомпьютер, например, FriendlyARM Nano Pi M4 или UP Board, сама камера или сервер. Выбор конкретного устройства для инференса зависит от множества факторов. Как минимум — характеристик потока, размера канала (если с камеры отправлять видеопоток в ДЦ), типа камеры. Когда мы говорим о ФВФ (фото-видеофиксации), часто, канал уже есть и с множества камер гонится видеопоток на один сервер для инференса. Мы используем Intel NUC8i5BEK в форм-факторе 1U. В одном корпусе собрано 8 NUC. Таким образом мы получаем на один сервер 8 процессоров Intel Core i5, 32 физических ядра и 8 GPU Iris Plus 655. За счёт наличия CPU и GPU, часть сетей выполняется на процессоре, а часть на GPU (в нашем случае речь о детекции и распознавании номеров и марок/моделей). Результат инференса — события (мета и фото). Устройств для инференса, обычно, множество из-за уже сложившейся инфраструктуры. С этого множества нужно собирать события и это оказалось очень удобно делать напрямую с СХД. В нашем случае — QNAP.
Вроде, ответ был выше: «край», «последняя миля» в контексте — устройства, расположенные в непосредственной близости от источника данных, рядом с камерой. На схеме уточнили для наглядности:
При тестировании решения и софта, СХД укомплектовали дисками по 1 Тб. Некорректно сформулировали мысль, поправим. В продакшн требуются диски максимального объема (с максимальной плотностью их установка в рамках СХД).
Конфигурация была приведена ниже: QNAP TVS-871T, Intel Core(TM) i5-4590S CPU 3.00GHz, Version 4.4.1.1086 (2019/10/10), Linux-kernel 4.14.24-qnap, под system-docker Version:17.09.1-ce, API version: 1.32, OS/Arch: linux/amd64. Смысл в том, что требовалась агрегация с множества устройств инференса (исполнения нейронных сетей) для организации общей точки доступа и хранения больших объемов данных (событий, в нашем случае). Интеграция в QNAP через Docker-контейнеры оказалась быстрой, удобной и эффективной.
Нет, не так. Для инференса (исполнения нейронных сетей) применяется три типа устройств: сервера в ДЦ в стойках на Intel NUC8i5BEK в форм-факторе 1U, сервера на Intel VCA2 на платформе Supermicro 1U, камеры с установленным в них ПО (Axis, Vivotek и др.), микрокомпьютеры наружной установки (в нашем варианте это или ARM на базе FriendlyARM Nano Pi M4, или х86 UP Board Intel Atom X5). Далее, с множества устройств (например, 2 сервера, 15 камер, 30 микрокомпьютеров) требуется агрегация и хранение данных. Для этого мы выбрали СХД от QNAP.
Да, простите. "Край", "последняя миля" в контексте — устройства, расположенные в непосредственной близости от источника данных, рядом с камерой. Инференс — исполнение нейронной сети. В нашем случае — детекция транспортных средств (включая траекторный анализ), распознавание номеров, классификация марок и моделей ТС. Дополним статью.
Немного не так. Суть статьи в запуске агрегатора событий "с края" и с множества серверов, а также в хранении этих событий с единой точкой доступа к ним. Сейчас в подобных системах не применяется подход, когда события собираются самим СХД и СХД выступает точкой доступа. Мы применили, это удобно, поделились опытом. Конкретно наш случай — это сбор данных после инференса (события о нарушениях ПДД или в рамках проводимых ОРМ/ОРД). Контейнеры в данном случае — способ реализации. Технические детали — это то, как конфигурировался контейнер, используемое оборудование и сам подход. Если что-то не раскрыли, укажите, пожалуйста, дополним статью.
На исследования в области систем параллельного выполнения задач уже потрачено много ресурсов. Но реально распараллеливать получается только узкий круг задач. Зачастую накладные расходы на распараллеливание перекрывают преимущества многоядерности. Та же самая оркестровка может требовать большее количество вычислительных мощностей, чем результат от ее применения.
FPGA с нужным количеством входов и заранее определенным алгоритмом всегда будет выгоднее, чем многопроцессорные системы. Плюс исполнение на FPGA детерминировано по времени, что позволяет работать в реальном времени, что крайне актуально для видеоаналитики.
Ускоритель ИИ (обучение или инференс). Тот же самый Mustang F100, о котором писали выше. Их нельзя сравнивать по частоте. Тактовая частота и скорость исполнения инструкций — это совершенно разные вещи. Смысл в том, что на ПЛИС'е может быть набор собственных инструкций, которые выполняют конкретно твой код (который на процессоре общего назначения может потребовать несколько миллиардов тактов). На обычном CPU это будет набор типовых инструкций, а на ПЛИС'е — конкретно необходимая в данном месте операция.
Так, все операции с уровнями нейронных сетей (тензорных вычислений) строятся на BLAS. Для CUDA — cuBLAS, Intel — MKL и т.д. FPGA позволяет реализовать большую часть библиотечных операций на аппаратном уровне, вместо того, чтобы загружать процессор общего назначения математическими преобразованиями.
Все-таки непонятен глубинный смысл идеи портирования ИИ и нейросетей, в частности, на архитектуру Эльбруса. Есть более современные архитектуры и типы устройств, которые далеко продвинулись в области машинного обучения и инференса. Последний идеально работает на стиках NCS2, есть Google Coral, UP Board AI на Myriad X, FPGA и многое другое. Возможно, правильным было бы направление не адаптации современных решений под устаревшую архитектуру, а разработка архитектуры под современные решения.
Если уж сильно хочется, можно повторить тензорный процессор на ПЛИС'ах. Будет свой ускоритель ИИ на отечественной аппаратной базе. Опять же есть Tesnorflow, который замечательно компилируется в OpenCL и отлично исполняется на ПЛИС'ах (например, Mustang F100 и подобные).
ASIC'и и системы с водяным охлаждением (подключаемые к системам отопления). Они, в принципе, есть. У нас другие устройств — сервера для стоек и безвентиляторные промышленные ПК для наружной эксплуатации.
Включили. Мы поставляем сервер в комплекте с софтом по детекции и распознаванию объектов (марки, модели ТС и номера) или предустановленной ОС Linux. Для дальнейшей работой с группой устройств, вы можете использовать связку Docker, Docker Swarm, Ansible для максимально гибкой и быстрой настройки.
Весь сервер потребляет не более 450 Вт. БП — 500 Вт и оснащен системой активного охлаждения, выведенной на заднюю панель сервера. Он, в принципе, не может настолько нагреться, чтобы выйти за рамки рабочего диапазона. В продакшн версии сервера с активным охлаждением — 2 БП по 600 Вт Supermicro с системой активного охлаждения, которая не требует дополнительного (стоечного) продува.
Они кардинально разные. 3011 — температурный диапазон до 40 градусов, 4011 — до 70 градусов. В варианте с пассивным охлаждением в рамках закрытого серверного корпуса это важно. Разница в стоимости 3011/4011 — около 1000 руб. Внутренняя пропускная способность 4011 — 40 Гбит/сек.
Да, верно. Он переходит в тротлинг, т.е. понижает частоту и отключает часть ядер при перегреве. Но это отразится и на быстродействии в том числе. При тестировании устройств (как в серверном исполнении, так и в корпусах наружного применения) мы проверяем устройства на отсутствие тротлинга в процессе эксплуатации, а с работающих устройств собирается статистика (Zabbix, Chronograf), что также позволяет отслеживать тротлинг и температуру по сенсорам.
Полная статистика есть по 4-ому поколению Нюков в корпусах наружного исполнения с климатикой. Там около 10% с 2015 года. По 8-ому поколению за 6 месяцев тестовой эксплуатации нет ни одного вышедшего из строя (48 штук работает исправно).
Мы занимаемся объектовой видеоаналитикой. В контексте статьи — это детекция и распознавание объектов. Например, номеров транспортных средств, марок и моделей. Для этого используются сверхточные нейронные сети. В нашем случае две топологии — Darknet19 и UNET. Процесс исполнения нейронных сетей называется инференсом. Источник данных — это видеокамеры. С них поступает видеопоток RTSP Full HD 15 FPS H.264 на устройство для инференса. Это может быть устройство "на краю", микрокомпьютер, например, FriendlyARM Nano Pi M4 или UP Board, сама камера или сервер. Выбор конкретного устройства для инференса зависит от множества факторов. Как минимум — характеристик потока, размера канала (если с камеры отправлять видеопоток в ДЦ), типа камеры. Когда мы говорим о ФВФ (фото-видеофиксации), часто, канал уже есть и с множества камер гонится видеопоток на один сервер для инференса. Мы используем Intel NUC8i5BEK в форм-факторе 1U. В одном корпусе собрано 8 NUC. Таким образом мы получаем на один сервер 8 процессоров Intel Core i5, 32 физических ядра и 8 GPU Iris Plus 655. За счёт наличия CPU и GPU, часть сетей выполняется на процессоре, а часть на GPU (в нашем случае речь о детекции и распознавании номеров и марок/моделей). Результат инференса — события (мета и фото). Устройств для инференса, обычно, множество из-за уже сложившейся инфраструктуры. С этого множества нужно собирать события и это оказалось очень удобно делать напрямую с СХД. В нашем случае — QNAP.
При тестировании решения и софта, СХД укомплектовали дисками по 1 Тб. Некорректно сформулировали мысль, поправим. В продакшн требуются диски максимального объема (с максимальной плотностью их установка в рамках СХД).
Конфигурация была приведена ниже: QNAP TVS-871T, Intel Core(TM) i5-4590S CPU 3.00GHz, Version 4.4.1.1086 (2019/10/10), Linux-kernel 4.14.24-qnap, под system-docker Version:17.09.1-ce, API version: 1.32, OS/Arch: linux/amd64. Смысл в том, что требовалась агрегация с множества устройств инференса (исполнения нейронных сетей) для организации общей точки доступа и хранения больших объемов данных (событий, в нашем случае). Интеграция в QNAP через Docker-контейнеры оказалась быстрой, удобной и эффективной.
Нет, не так. Для инференса (исполнения нейронных сетей) применяется три типа устройств: сервера в ДЦ в стойках на Intel NUC8i5BEK в форм-факторе 1U, сервера на Intel VCA2 на платформе Supermicro 1U, камеры с установленным в них ПО (Axis, Vivotek и др.), микрокомпьютеры наружной установки (в нашем варианте это или ARM на базе FriendlyARM Nano Pi M4, или х86 UP Board Intel Atom X5). Далее, с множества устройств (например, 2 сервера, 15 камер, 30 микрокомпьютеров) требуется агрегация и хранение данных. Для этого мы выбрали СХД от QNAP.
Да, простите. "Край", "последняя миля" в контексте — устройства, расположенные в непосредственной близости от источника данных, рядом с камерой. Инференс — исполнение нейронной сети. В нашем случае — детекция транспортных средств (включая траекторный анализ), распознавание номеров, классификация марок и моделей ТС. Дополним статью.
Немного не так. Суть статьи в запуске агрегатора событий "с края" и с множества серверов, а также в хранении этих событий с единой точкой доступа к ним. Сейчас в подобных системах не применяется подход, когда события собираются самим СХД и СХД выступает точкой доступа. Мы применили, это удобно, поделились опытом. Конкретно наш случай — это сбор данных после инференса (события о нарушениях ПДД или в рамках проводимых ОРМ/ОРД). Контейнеры в данном случае — способ реализации. Технические детали — это то, как конфигурировался контейнер, используемое оборудование и сам подход. Если что-то не раскрыли, укажите, пожалуйста, дополним статью.
Со скриншотами — да, обновим.
FPGA с нужным количеством входов и заранее определенным алгоритмом всегда будет выгоднее, чем многопроцессорные системы. Плюс исполнение на FPGA детерминировано по времени, что позволяет работать в реальном времени, что крайне актуально для видеоаналитики.
Так, все операции с уровнями нейронных сетей (тензорных вычислений) строятся на BLAS. Для CUDA — cuBLAS, Intel — MKL и т.д. FPGA позволяет реализовать большую часть библиотечных операций на аппаратном уровне, вместо того, чтобы загружать процессор общего назначения математическими преобразованиями.
Если уж сильно хочется, можно повторить тензорный процессор на ПЛИС'ах. Будет свой ускоритель ИИ на отечественной аппаратной базе. Опять же есть Tesnorflow, который замечательно компилируется в OpenCL и отлично исполняется на ПЛИС'ах (например, Mustang F100 и подобные).
Полная статистика есть по 4-ому поколению Нюков в корпусах наружного исполнения с климатикой. Там около 10% с 2015 года. По 8-ому поколению за 6 месяцев тестовой эксплуатации нет ни одного вышедшего из строя (48 штук работает исправно).