GPU-сервер для видеоаналитики: Как рассчитать нагрузку по потокам камер

GPU-сервер для видеоаналитики нельзя корректно подобрать только по количеству камер. Две системы на 100 камер могут создавать совершенно разную нагрузку: в одной нейросеть анализирует почти каждый кадр, в другой — только несколько кадров в секунду, а после детектора дополнительно работают трекер и другие модели.

Поэтому расчёт лучше вести по всей цепочке обработки:

Для каждого этапа определяют требуемую производительность, а затем проверяют полный конвейер при допустимой задержке. Итоговое число камер ограничивает тот этап, который первым перестаёт справляться с потоком данных.

Почему количество камер не определяет необходимую GPU

Формулировки вроде «нужен сервер на 50 камер» недостаточно.

Даже при одинаковом числе камер могут различаться:

Поэтому нельзя составить универсальную таблицу:

50 камер — одна GPU, 100 камер — две GPU.

Без кодека, FPS анализа, моделей и требований по задержке такое сравнение почти ничего не говорит о реальной нагрузке.

То же относится к опубликованной производительности GPU. Даже официальный результат в кадрах в секунду нельзя автоматически делить на FPS камеры и получать допустимое число потоков. Имеют значение конкретная нейросеть, её входное разрешение, точность вычислений, трекер и настройки всего конвейера.

Какие данные собрать перед расчётом сервера

Камеры сначала стоит разделить на группы с одинаковыми параметрами.

Например:

Для каждой группы желательно зафиксировать:

• количество камер;

• кодек и профиль;

• разрешение;

• фактический FPS;

• битрейт;

• способ получения потока, например RTSP;

• требуемую частоту нейросетевого анализа.

Одной записи «100 камер 1080p» недостаточно.

Например, H.264 и H.265 нельзя считать одинаковой нагрузкой на декодирование. Производительность аппаратного видеодекодера зависит от кодека, поколения и конкретной GPU. NVIDIA публикует характеристики NVDEC отдельно для разных архитектур и форматов: NVDEC Application Note.

Отдельно описывают нейросетевую часть:

• основную модель и её версию;

• входное разрешение модели;

• точность вычислений;

• требуемый FPS анализа;

• использование трекера;

• дополнительные классификаторы, OCR и другие модели;

• максимально допустимую задержку.

FPS камеры и FPS нейросети — не одно и то же

Одна из главных ошибок при расчёте сервера — считать, что нейросеть обязательно должна обработать каждый кадр исходного видеопотока.

Предположим, система получает видео со 100 камер по 25 кадров в секунду.

Количество входящих кадров:

100 × 25 = 2500 кадров/с.

Но это ещё не означает, что основной детектор должен анализировать 2500 кадров каждую секунду.

Если для задачи достаточно анализировать 5 кадров в секунду с каждой камеры:

100 × 5 = 500 кадров/с.

Через основную модель должно пройти уже 500, а не 2500 кадров в секунду.

Разница — в пять раз при том же числе камер.

Поэтому в расчёте полезно держать как минимум три отдельные величины:

В NVIDIA DeepStream основная модель может запускаться не на каждом входящем пакете кадров. Параметр interval позволяет пропускать последовательные пакеты между запусками нейросетевой обработки: Gst-nvinfer.

Но не стоит превращать конкретное значение interval в универсальную формулу фактического FPS. На результат влияют частота источников, формирование пакетов, пропуски кадров и поведение живых потоков.

Фактический FPS анализа лучше измерять на рабочем конвейере.

Декодирование нужно считать отдельно от нейросети

До того как кадр попадёт в нейросеть, сжатое видео необходимо декодировать.

На NVIDIA GPU для этого используется специализированный аппаратный декодер NVDEC. Его производительность нельзя выводить из количества CUDA-ядер, Tensor Cores или общей вычислительной производительности модели.

Поэтому для одной конфигурации существуют как минимум две разные проверки:

1. хватает ли производительности декодирования для всех входящих потоков;

2. хватает ли производительности GPU для требуемой нейросетевой обработки.

Это важное разделение.

GPU может иметь достаточный запас для основной модели, но не справляться с нужным количеством потоков заданного кодека и разрешения. Возможна и обратная ситуация: декодирование имеет запас, а ограничением становится нейросеть.

NVIDIA приводит ориентировочные показатели NVDEC отдельно по архитектурам и кодекам. У некоторых GPU несколько блоков декодирования, что позволяет увеличить суммарную производительность при параллельной работе нескольких сессий. При этом один видеопоток не получает автоматически суммарную производительность всех NVDEC.

Поэтому для проверки декодирования нужны:

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

• кодек и профиль;

• разрешение;

• FPS;

• количество одновременных потоков.

Как рассчитать нагрузку основной нейросети

Для группы одинаковых камер и одной основной модели, работающей по полным кадрам, предварительное требование можно рассчитать просто:

Требуемый FPS основной модели = количество камер × FPS анализа на камеру.

Например:

80 камер × 8 кадров/с = 640 кадров/с.

То есть через основную модель должны устойчиво проходить не менее 640 кадров каждую секунду при заданной конфигурации.

Это уже намного полезнее, чем формулировка «сервер на 80 камер».

Но сравнивать полученное значение нужно с результатом для максимально близких условий:

Важно не путать разрешение камеры и разрешение, которое получает нейросеть.

Камера может передавать поток 1920×1080, а перед нейросетевой обработкой кадр масштабируется, например, до 640×640. В DeepStream преобразование размера и формата может выполняться перед передачей данных TensorRT: Gst-nvinfer.

Поэтому оба разрешения нужно записывать отдельно.

Что меняется, если моделей несколько

Видеоаналитика редко ограничивается одной нейросетью.

Например, конвейер может выглядеть так:

детектор → трекер → классификатор → OCR.

Основной детектор обрабатывает кадры.

Трекер — модуль отслеживания объектов — связывает обнаруженный объект между последовательными кадрами.

Дополнительные модели могут получать уже не целый кадр, а отдельные найденные объекты.

Из-за этого их нагрузка определяется иначе.

Предположим, детектор ищет автомобили, а дополнительная модель определяет тип транспортного средства. На пустой парковке дополнительных запросов будет немного. В час пик — значительно больше, хотя количество камер и FPS останутся прежними.

При этом обрабатывать каждый объект на каждом кадре тоже необязательно.

DeepStream позволяет:

• запускать дополнительную модель только для определённых классов;

• ограничивать объекты по размеру;

• задавать повторную частоту обработки;

• вместе с трекером кешировать результаты классификации для уже известных объектов.

Подробнее это описано в документации Gst-nvinfer.

Поэтому формула:

не является универсальным способом расчёта дополнительных моделей.

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

Причём проверять стоит не только среднюю сцену.

Если видеоаналитика работает на проходной, парковке или производстве, для тестирования нужен и характерный пиковый режим: начало смены, час пик, массовый проход людей или максимальная загрузка наблюдаемой зоны.

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

Высокий FPS ещё не означает, что система удовлетворяет задаче.

Предположим, две конфигурации успевают обработать необходимые 500 кадров в секунду.

У первой результат появляется через 100 мс.

У второй — через 2 секунды.

Для статистической аналитики эта разница может быть допустимой. Для контроля доступа или тревожного события — критичной.

На задержку влияет в том числе пакетная обработка.

Несколько кадров можно объединять в пакет — batch — чтобы эффективнее использовать GPU. Но системе требуется время на формирование такого пакета.

В DeepStream компонент nvstreammux формирует пакеты из нескольких источников и отправляет их после заполнения либо после наступления заданного тайм-аута: Gst-nvstreammux.

Из этого следует важное правило:

Поэтому техническое требование лучше формулировать не только как:

анализировать не менее 10 кадров в секунду на камеру,

но и как:

результат должен появляться не позднее чем через X миллисекунд.

Серверную конфигурацию нужно проверять одновременно по обоим условиям.

Калькулятор нагрузки сервера видеоаналитики

Для предварительного расчёта можно использовать следующий рабочий лист.

Шаг 1. Исходные видеопотоки

Количество исходных кадров:

Количество камер × FPS камеры

Например:

64 камеры × 25 FPS = 1600 кадров/с.

Это нагрузка исходного видеопотока, а не требуемая производительность нейросети.

Шаг 2. Декодирование

Если все 64 камеры по 25 FPS необходимо полностью декодировать:

Даже если нейросеть анализирует только часть из них.

Шаг 3. Основная модель

Если основной модели достаточно 5 кадров в секунду с каждой из 64 камер:

64 × 5 = 320 кадров/с.

Значит полный рабочий конвейер должен обеспечивать не менее 320 кадров/с через эту модель при соблюдении требования по задержке.

Шаг 4. Трекер и дополнительные модели

Здесь универсальной формулы обычно недостаточно. Нагрузка зависит от содержания сцены и логики самого приложения.

Шаг 5. Проверка полного конвейера

Если хотя бы один обязательный этап не проходит требование, заявлять подтверждённую поддержку заданного числа камер рано.

Как найти узкое место видеоаналитики

Если система не достигает требуемой производительности, начинать диагностику можно с наблюдаемого симптома.

Эта таблица указывает направление проверки, но не доказывает конкретную причину автоматически.

Почему одного тестового файла недостаточно

Предварительное тестирование на записанном видео полезно: оно даёт воспроизводимый вход и позволяет проверить модель без влияния большинства сетевых факторов.

Но рабочая система обычно получает живые потоки.

При RTSP появляются дополнительные условия:

• неравномерное поступление пакетов;

• сетевой jitter;

• задержки;

• потеря или запоздание данных;

• переподключение камер.

Поэтому сервер, стабильно работающий с локальным MP4-файлом, не обязательно покажет тот же результат с реальными камерами.

Для проверки можно использовать последовательность:

1. проверить саму модель;

2. проверить полный конвейер на репрезентативном записанном видео;

3. подключить реальные или эквивалентные рабочим RTSP-потоки;

4. довести число одновременных камер до проектного;

5. проверить пиковую сцену;

6. проверить устойчивость в достаточно продолжительном тесте.

Во время такого испытания важно смотреть не только на общий средний FPS.

Нужно фиксировать:

• FPS по отдельным потокам;

• задержку получения результата;

• пропущенные и опоздавшие кадры;

• загрузку этапов конвейера;

• длительность теста.

Как учитывать битрейт и видеоархив

Битрейт нужен прежде всего для расчёта входящего сетевого трафика и объёма хранения.

Например, если 100 камер передают в среднем по 8 Мбит/с:

100 × 8 = 800 Мбит/с.

Это приблизительная полезная нагрузка сжатого видео. Фактический трафик сети будет несколько выше из-за служебных данных протоколов.

Но из битрейта нельзя определить производительность нейросети.

Поток 8 Мбит/с ничего не говорит о том, сколько кадров в секунду способен обработать конкретный детектор.

Если на том же сервере планируется хранить видеоархив, дисковую подсистему нужно рассчитать отдельно с учётом:

• суммарного битрейта;

• срока хранения;

• режима записи;

• резервирования;

• необходимой скорости чтения и записи.

Для расчёта GPU эти параметры не заменяют показатели нейросетевой нагрузки.

Даст ли вторая GPU вдвое больше камер

Не обязательно.

Часть этапов действительно можно распределить между несколькими GPU. Но итоговый прирост зависит от архитектуры приложения и от того, где находилось исходное ограничение.

Если система упирается в производительность основной модели, дополнительная GPU может существенно увеличить ресурс.

Если ограничением являются декодирование, получение RTSP-потоков, процессор или другой этап, установка второй GPU для нейросетевых вычислений может дать гораздо меньший эффект.

Поэтому нельзя считать:

две GPU = вдвое больше камер.

Какие данные нужны для подбора GPU-сервера

Перед выбором конкретной серверной конфигурации полезно заполнить одну таблицу.

После этого вопрос:

Какую GPU поставить на 100 камер?

можно заменить на технически корректный:

Какая конфигурация обеспечит заданное декодирование, FPS нейросетевого анализа и задержку для наших потоков и моделей?

Именно такую задачу уже можно проверять расчётом и тестом.

Главное

Количество камер — не характеристика производительности GPU.

При расчёте сервера для видеоаналитики нужно отдельно определить:

• сколько видеопотоков приходит на сервер;

• сколько кадров нужно декодировать;

• сколько кадров действительно анализирует основная нейросеть;

• какую нагрузку создают трекер и дополнительные модели;

• какая задержка допустима для проекта;

• выдерживает ли вся цепочка реальные потоки без недопустимых очередей и пропусков.

Например, 100 камер по 25 FPS могут давать 2500 исходных кадров в секунду, но при анализе 5 FPS на камеру основной модели требуется уже 500 кадров в секунду.

Декодирование при этом может оставаться рассчитанным на полный исходный поток.

Поэтому количество камер становится не исходной характеристикой GPU, а результатом расчёта всей системы.

Окончательно его подтверждают на реальных или репрезентативных потоках при той же модели, кодеке, FPS анализа и требованиях по задержке, которые будут использоваться в рабочей системе.