Железо под нейросетевую видеоаналитику: камера, сервер, edge 

«Сервер видеоаналитики» ищут как товар с ценником, но это ответ на четыре вопроса, заданные в правильном порядке: что нужно видеть, с какой детализацией, как часто и где это считать. Интегратор, который начинает разговор со стойки и лицензий, отвечает на четвертый вопрос, не задав первых трех — так в смете появляется сервер за миллионы под задачу, которую закрыл бы миникомпьютер у камеры.

Ниже — расчет железа с правильного конца: от пикселей на объекте до модели вычислителя, с формулами, которые пересчитываются под ваш объект за вечер. Где обрабатывать поток — на месте или в облаке — вопрос архитектуры, он разобран в статье edge против облака; здесь считаем само железо. Что мы предлагаем как услуга — на странице видеоаналитики для бизнеса.

Порядок расчета: от задачи к вычислителю

Сайзинг видеоаналитики идет по цепочке. Задача диктует пиксельную плотность на объекте — плотность и сцена диктуют камеру и объектив — задача же диктует кадровую частоту анализа — камеры, помноженные на частоту, дают бюджет инференса — бюджет выбирает вычислитель: CPU, GPU-сервер или edge-бокс. Каждый шаг — арифметика на калькуляторе. Кто начинает с конца, покупает вычислитель наугад.

IP-камера для видеоаналитики: решает пиксельная плотность

Нейросети нужен объект из достаточного числа пикселей. Мерить удобно пиксельной плотностью — сколько пикселей кадра приходится на метр сцены на рабочей дистанции. В видеонаблюдении для этого есть отраслевая шкала DORI (стандарт EN 62676-4): обнаружение — 25 пикселей на метр, наблюдение — 62,5, распознавание — 125, идентификация — 250.

Для нейросетевой детекции наши рабочие ориентиры совпадают со шкалой: заметить человека в зоне — от 25–30 px/м днем и с запасом ночью; уверенно отличать каску, спецодежду и жилет — от 60–80 px/м, потому что модель оценивает голову и то, что на ней, а голова с каской — сантиметров тридцать, шестая часть роста; номера и лица — территория 125–250 px/м, и это уже другие задачи с другой юридикой.

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

Читается так: камера 4 Мп с объективом на 90 градусов уверенно держит контроль СИЗ до 15–20 метров, а просто присутствие человека — до 40. Дальше — либо узкий объектив на конкретную зону, либо 8 Мп, либо вторая камера. Типовой провальный проект контроля СИЗ выглядит так: каску пытаются разглядеть с 30 метров камерой 2 Мп — по таблице это 32 px/м, голова с каской — 8–9 пикселей, детектору просто не из чего работать.

Что еще написать в спецификации камеры

• Матрица важнее мегапикселей. 8 Мп на матрице 1/2.8 дюйма — это мелкий пиксель, который ночью тонет в шуме, и детектор кормится кашей. Для круглосуточной работы честнее 4 Мп на матрице от 1/1.8 дюйма, чем рекордные мегапиксели на крошечной.
• Аппаратный WDR от 120 дБ — если в кадре ворота, окна или сварка: без него контровый свет выжигает пиксели, и нейросети достается пересвет вместо сцены. Программная коррекция эту физику не чинит.
• ИК-подсветка по дистанции зоны, без экономии: ночная детекция живет на ней.
• Два потока и H.265. Основной — в архив, легкий субпоток — на анализ. Как это разгружает сеть и декодер, разобрано в статье про подключение ИИ к RTSP-потоку.
• Фиксированный объектив для зон анализа. PTZ — рабочий инструмент живого оператора, но детекторные зоны привязаны к кадру: крутанули камеру — аналитика ослепла. Поворотные камеры в проекте видеоаналитики живут отдельной строкой, без зон.
• RTSP или ONVIF. Единственное жесткое требование к существующему парку: отдает стандартный поток — подходит. Менять камеры ради аналитики почти никогда не нужно.

Кадровая частота: почему 25 fps не нужны

Камера отдает 25 кадров в секунду, но анализировать все — сжигать вычислитель впустую. Частота анализа выбирается по скорости события. Человек без каски находится в зоне минуты — хватает 3–5 кадров в секунду. Машина на КПП при 20 км/ч проходит шесть метров в секунду — 5–10 кадров, чтобы трек не рвался. Быстрая механика конвейера — уже территория машинного зрения с другим железом и другой оптикой.

Это главный рычаг экономии на сервере: разница между «анализируем 25» и «анализируем 5» — пятикратная разница в бюджете инференса при том же качестве детекции. Лишние кадры дропаются на входе — это штатный режим любой взрослой системы, никакого компромисса в нем нет.

Сколько камер тянет одна GPU

Бюджет считается в инференсах в секунду: число камер умножить на частоту анализа. Двадцать четыре камеры по 5 кадров — 120 инференсов в секунду. Компактная детекционная модель, квантованная в INT8, на GPU среднего класса — уровня T4, A2000, RTX 4060 — выдает с батчингом две-три сотни инференсов в секунду, так что 20–30 камер такой пайплайн несет с запасом на пики. Вторая статья бюджета — декодирование потоков, но аппаратный декодер современных карт держит десятки субпотоков и упирается заметно позже инференса.

Практические ориентиры для прикидки, все — про компактные модели в INT8 и анализ на 5 кадрах в секунду:

Цифра для edge-бокса взята из измерений: бенчмарк восьми RTSP-потоков на Jetson с разными моделями мы публиковали отдельно — что реально тянет edge-бокс. Важная оговорка ко всей таблице: она про детекцию объектов. Тяжелые задачи — сегментация, распознавание действий, плотный трекинг толпы — режут эти цифры в разы, и это выясняется на пилоте, а не после закупки.

Когда хватает CPU — и когда это ловушка

Честный ответ: CPU хватает чаще, чем принято думать, и реже, чем хочется финдиректору. Одна-две камеры, компактная модель, анализ раз в секунду, задача из разряда «посчитать посетителей» — обычный офисный процессор справится, и ставить GPU туда — переплата. Но у CPU-пути три скрытых порога: декодирование видео ест те же ядра, что и нейросеть; запас на пиковую нагрузку отсутствует; каждый следующий детектор — минус камера. Проект, который стартовал «на CPU обойдемся», к третьему модулю утыкается в потолок и переезжает на GPU целиком — с простоем и повторной настройкой. Правило, которое мы применяем к себе: от четырех-пяти камер или при любой задаче про безопасность людей — сразу ускоритель.

Edge-бокс против сервера в стойке

Edge-вычислитель у камеры выигрывает там, где камеры разбросаны: удаленные КПП, площадки без серверной, объекты со слабым каналом. Считать на месте и слать наружу события — килобайты вместо мегабит. Классы железа: Jetson-модули, промышленные боксы с NPU — специализированные нейроускорители дают десятки TOPS на единицы ватт, и когда такая экономика окупается, мы разбирали в статье про NPU против GPU на edge.

Две вещи, которые в спецификации edge-железа забывают чаще всего: тепло и корпус. Бокс, который в лаборатории держит заявленные кадры, на солнце и в пыли уходит в троттлинг и молча роняет частоту анализа — этот сценарий мы разбирали на собственном постмортеме теплового троттлинга. Пассивное охлаждение с запасом, промышленный диапазон температур, крепление и питание по месту — это не опции, а часть спецификации.

Сервер видеоаналитики: что в нем кроме GPU

Остальная конфигурация сервера видеоаналитики скромна: восемь ядер CPU на захват и оркестрацию, 32 гигабайта памяти, NVMe под систему и журнал. Два решения, которые стоит принять до закупки. Первое — виртуализация: запускать аналитику в гипервизоре можно, но проброс GPU и аппаратного декодера в виртуалку — постоянный источник тонких проблем с драйверами и производительностью; выделенная железка с Linux и Docker проще в жизни и дешевле в поддержке, чем слот в корпоративном кластере. Второе — резервирование: видеоаналитика в большинстве задач переживает перезагрузку сервера спокойнее, чем учетная система, поэтому кластер высокой доступности ей обычно не нужен — достаточно автозапуска сервисов и мониторинга. Исключение — сценарии, где алерт завязан на физическую безопасность в реальном времени: там резерв считается отдельно.

Сеть и питание: скучная арифметика, которая роняет проекты

• Битрейт. Камера 4 Мп в H.265 — порядка 4–6 Мбит/с основной поток плюс 1–2 Мбит/с субпоток. Дюжина камер — 60–90 Мбит/с: гигабитной сети хватает с многократным запасом, если видео не гоняется через полздания к серверу по цепочке из трех неуправляемых свитчей.
• PoE-бюджет. Камера с ИК ест 8–13 Вт, с обогревом кожуха — до 20–25. Коммутатор выбирается по суммарному бюджету с запасом процентов тридцать, иначе зимой камеры начнут перезагружаться по кругу, а виноватой назначат нейросеть.
• Отдельный VLAN для камер — гигиена, которая заодно успокаивает безопасника: видеосеть не смотрит в интернет.
• ИБП на 10–15 минут — чтобы штатно пережить моргание питания и не собирать битые файловые системы по всем узлам.

Диски: аналитике не нужен ваш архив

Видеоаналитика пишет журнал событий и кадры-доказательства — это сотни мегабайт в день на объект, любой NVMe на терабайт закрывает вопрос с годовым запасом. Видеоархив — отдельная система с отдельной экономикой: NVR или VMS как писали круглосуточный поток, так и пишут, аналитика забирает те же RTSP-потоки параллельно и в архивную математику не вмешивается. Смешивать эти два бюджета в одной смете — классический способ продать вам стойку дисков под задачу, которой они не нужны.

Пять граблей закупки железа под видеоаналитику

1. Анализ по основному потоку. Субпоток не настроили — аналитика жует полновесный мейн-стрим, аппаратный декодер кончается втрое раньше расчетного, и сервер «не тянет» уже на половине заявленных камер.
2. Камеры без синхронизации времени. Часы дюжины камер без NTP расползаются на минуты — таймстемпы событий врут, и разбор инцидента «кто проехал первым» превращается в угадайку.
3. «Аппаратная видеоаналитика» в камере как замена всему. Детекторы, зашитые в прошивку, работают в границах прошивки: дообучить их под вашу спецодежду и вашу сцену нельзя. Где встроенная аналитика уместна, а где кончается — разобрано в сравнении коробочной видеоаналитики и кастомной модели.
4. Wi-Fi-камеры на производстве. Металл, помехи, перекрытия — трек рвется, детектор мигает, диагностика съедает недели. Кабель.
5. Сервер «с запасом» до расчета. Симметричная грабля всем остальным: стойка с четырьмя топовыми картами под двенадцать камер контроля касок. Сначала арифметика из этой статьи, потом счет.

Шесть вопросов поставщику про железо

Задайте их любому, кто присылает вам спецификацию под видеоаналитику, — интегратору, вендору коробки, нам. По ответам видно, считал человек или копировал прошлое КП.

1. Какая модель детекции и в каком формате будет работать — и сколько инференсов в секунду она дает именно на предложенном железе?
2. Из какого расчета пиксельной плотности выбраны камеры и объективы для каждой зоны? Просите цифры по дистанциям, как в таблице выше.
3. Какая частота анализа заложена на камеру и что произойдет с бюджетом при добавлении следующего детектора?
4. Что с тепловым режимом летом: замерялась ли производительность под нагрузкой при рабочей температуре площадки?
5. Где проходит граница ответственности за ложные срабатывания ночью — камера, свет или модель, и кто ее доказывает?
6. Какой запас по вычислителю остается после запуска всех заявленных задач? Меньше тридцати процентов — спецификация без будущего.

Готовая спецификация: объект на 12 камер, СИЗ и транспорт

Типовая конфигурация под задачу «каски и спецодежда в цеху плюс учет машин на КПП» — как ориентир для бюджета и разговора с интегратором.

Эта конфигурация несет оба модуля на всех двенадцати камерах с запасом на пики и на будущий третий модуль — арифметика из раздела про GPU сходится с двукратным резервом.

Что дальше

Если хочется проверить расчет на своем объекте — пришлите план расстановки камер и задачи по зонам, вернем спецификацию железа бесплатно: для готовых модулей MoranaVision она входит в коммерческое предложение вместе с требованиями к серверу, а дальше агент ставится в Docker одной командой и первые одну-две недели работает в теневом режиме, показывая реальную точность на вашем свете до боевого запуска. Железо при этом остается вашим и покупается по вашей закупке — мы зарабатываем на подписке, поэтому продавать вам лишнюю стойку нам неинтересно.