Бокс вычислений для 32 камер

Когда слышишь ?бокс вычислений для 32 камер?, первое, что приходит в голову — мощный сервер в стойке, который тянет кучу потоков. Многие заказчики так и думают, гонятся за терафлопсами, а потом упираются в проблемы синхронизации, задержек в шине или банального перегрева в тесном шкафу. На деле, ключевое здесь — не пиковая производительность чипа, а архитектура обмена данными и предобработки видео перед тем, как оно попадает в нейросеть. Если на этапе захвата кадров с 32 источников возникает бутылочное горло, все эти вычисления можно смело отправлять в утиль.

От термина к реальной задаче

В нашей практике под боксом вычислений обычно подразумевается законченное аппаратно-программное решение, которое должно принимать, обрабатывать и анализировать в реальном времени потоки с фиксированного числа камер. Цифра 32 — не случайна, это часто порог, после которого классические решения на базе ПК с платами захвата начинают сыпаться. Нужен специализированный контроллер.

Мы, в ООО Шэньчжэнь Энтаймс Технолоджи, как раз и занимаемся проектированием таких решений — от модулей до готовых продуктов. Сайт https://www.nnntimes.ru описывает нашу деятельность, но в нем нет главного: каких шишек мы набили, пытаясь собрать стабильную систему на 32 канала. Одна из ключевых сложностей — обеспечить детерминированную задержку. Не просто ?быстро?, а предсказуемо. Для промышленного зрения или автономной техники это критично.

Помню один проект для логистического хаба. Задача — распознавание маркировок на коробках с конвейеров, которые снимают 32 камеры. Клиент изначально хотел взять 8 мощных GPU-серверов и распределить камеры. Звучало логично, пока не посчитали стоимость энергии, охлаждения и, главное, задержку из-за передачи данных по сети между серверами для агрегации результатов. В итоге пришли к кастомному боксу вычислений на базе двух наших центральных контроллеров с аппаратными энкодерами и выделенным чипом для препроцессинга.

Архитектурные ловушки и ?подводные камни?

Главный миф — что можно взять любой промышленный компьютер с солидным процессором и PCIe-слотами, воткнуть туда 8 плат захвата по 4 канала и все заработает. На бумаге — да. На практике — драйвера разных плат начинают конфликтовать за прерывания, буферы памяти переполняются из-за несогласованных таймингов, и система падает в самый неподходящий момент. Нужна единая система управления вводом-выводом.

Поэтому наш подход в ООО Шэньчжэнь Энтаймс Технолоджи смещен в сторону интеграции на уровне модулей интеллектуальных вычислений. Мы проектируем платы, где контроллер камер, ISP (Image Signal Processor) и интерфейсы для нейроускорителя тесно связаны, часто через внутреннюю шину с гарантированной пропускной способностью. Это снижает нагрузку на центральный CPU и дает ту самую предсказуемость.

Еще один нюанс — тепловыделение. 32 потока видео, даже в сжатом виде, плюс работа нейросетей — это сотни ватт. В тесном боксе это проблема. Приходится идти на компромиссы: иногда эффективнее поставить два бокса вычислений по 16 каналов, разнеся их физически, чем один монстр с титанической системой охлаждения, которая шумит как взлетающий истребитель.

Программная часть: где кроется дьявол

Железо — это только половина дела. Без продуманного ПО и SDK даже самый совершенный бокс вычислений для 32 камер превращается в дорогую безделушку. Наша команда потратила немало времени, чтобы создать middleware, которое абстрагирует работу с мультипотоковым захватом. Заказчик не должен вручную настраивать каждый канал, синхронизировать временные метки и распределять ресурсы между инстансами алгоритмов.

Мы предоставляем API, где разработчик приложения видит виртуальный ?пул? камер, а система сама занимается балансировкой нагрузки на вычислительные ядра. Это особенно важно, когда на разных камерах работают разные модели ИИ: где-то детекция лиц, где-то чтение номеров, где-то анализ тепловизора. Все это должно крутиться на одном устройстве без взаимных помех.

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

Кейс из практики: система контроля на производстве

Реальный пример — внедрение на заводе по производству электронных компонентов. Нужно было контролировать пайку на 32 автоматизированных линиях. Камеры снимали платы под разными углами, задача — обнаруживать отсутствие компонентов, перекосы, качество паяных соединений. Точность — выше 99.5%, время обработки кадра — не более 50 мс.

Сначала пробовали собрать систему на базе GPU от NVIDIA. Столкнулись с проблемой — драйвера не могли стабильно обслуживать 32 камеры высокого разрешения через GigE Vision. Потоки ?сыпались?. Перешли на собственную разработку — центральный контроллер интеллектуальных вычислений серии EC-9000, где часть препроцессинга (коррекция освещения, стабилизация изображения) делается на аппаратном уровне FPGA, разгружая основной нейроускоритель.

Итог: система работает уже больше года. Заказчик отметил снижение брака на участке на 15%. Но главное для нас — полученные данные по стабильности. Наработка на отказ превысила расчетную. Это подтвердило правильность выбранной архитектуры с акцентом на надежность ввода данных, а не на голую вычислительную мощь.

Взгляд в будущее и выводы

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

Наша компания, ООО Шэньчжэнь Энтаймс Технолоджи, уже экспериментирует с такими гибридными решениями в области робототехники и беспилотных аппаратов. Проектирование отраслевых продуктов требует гибкости. Старый добрый бокс вычислений для 32 камер в классическом понимании, возможно, постепенно уйдет в нишу высоконагруженных стационарных систем, типа городского видеонаблюдения.

Так что, если резюмировать мой опыт: гнаться за большой цифрой ?32? без понимания полного конвейера данных — бессмысленно. Нужно считать латентность, планировать тепловой режим, продумывать отказоустойчивость каждого звена. И тогда даже такая, казалось бы, рутинная вещь, как коробка с процессорами, становится ключевым элементом в успешном внедрении ИИ. Именно на этом стыке аппаратуры и софта мы и работаем, о чем можно подробнее узнать на нашем сайте.