Как выбрать сервер для видеонаблюдения с AI-аналитикой: камеры, FPS, storage, GPU

Сервер для видеонаблюдения с AI-аналитикой нужно выбирать не по одному только числу камер, а по полной нагрузке: разрешению, частоте кадров, битрейту, сроку хранения архива, режиму записи, RAID, скорости дисков, сети, декодированию видео и количеству потоков, которые реально анализирует нейросеть. Для небольшого объекта может хватить одного сервера с дисковым массивом и умеренным запасом по процессору. Для среднего объекта уже важны 10 Гбит/с, RAID 6, отдельные диски под систему и архив, а также GPU. Для крупной системы лучше разделять запись, хранение и видеоаналитику по разным серверам.

Почему нельзя выбирать сервер только по количеству камер

Фраза «нужен сервер на 50 камер» почти ничего не говорит о реальной конфигурации. Пятьдесят камер могут быть простыми 2 Мп устройствами в офисных коридорах, которые пишут 10 кадров в секунду. А могут быть 8 Мп камерами на парковке, где нужен высокий FPS, ночная съемка, распознавание номеров, людей и транспорта. В первом случае нагрузка будет умеренной. Во втором — серверу потребуются быстрые сетевые порты, большой дисковый массив и отдельная видеокарта для аналитики.

Количество камер — это только начало расчета. После него нужно понять, какой поток дает каждая камера, сколько суток хранится архив, работает ли запись постоянно или по событию, сколько операторов смотрят видео одновременно и какие задачи выполняет AI-аналитика. Если этого не сделать, сервер может оказаться формально «подходящим», но на практике начнет терять кадры, медленно открывать архив или задерживать события.

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

Что делает сервер видеонаблюдения

Сервер видеонаблюдения — это не просто место, куда складываются видеофайлы. В зависимости от проекта он может выполнять сразу несколько ролей: принимать потоки с IP-камер, записывать архив, показывать живое видео, отдавать записи из архива, хранить события, обрабатывать тревоги, передавать данные в систему контроля доступа, кассовую систему, охранную сигнализацию или внутренние бизнес-сервисы.

Если используется VMS или NVR-платформа, то есть программная система управления видеонаблюдением или сетевой видеорегистратор, сервер также обслуживает пользователей, лицензии, базу событий, настройки камер, журналы, карты объекта, правила доступа и интеграции. У таких платформ есть собственные требования к операционной системе, процессору, памяти, сети и хранилищу, поэтому перед покупкой сервера нужно сверять не только параметры камер, но и требования конкретного программного обеспечения. Например, Milestone отдельно публикует системные требования для XProtect, и это хороший пример того, почему нельзя выбирать железо без учета VMS-платформы.

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

Камеры, разрешение, FPS, кодек и битрейт

Базовый расчет начинается с камер. Для каждой группы камер нужно знать разрешение, частоту кадров, кодек и битрейт. Разрешение показывает детализацию кадра: 2 Мп, 4 Мп, 8 Мп и выше. FPS — это количество кадров в секунду. Кодек (например H.264 или H.265) отвечает за сжатие видео. Битрейт показывает, сколько данных камера передает в секунду.

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

FPS нельзя выбирать по принципу «чем больше, тем лучше». Для общего контроля склада или коридора часто достаточно 10–15 кадров в секунду. Для кассы, въезда, шлагбаума, контроля производственной зоны или распознавания номеров может потребоваться больше. Чем выше FPS, тем больше поток, архив и нагрузка на декодирование. Если AI-аналитика работает по каждому кадру, растет и нагрузка на GPU.

H.265 обычно позволяет уменьшить объем архива по сравнению с H.264, но при этом может быть тяжелее для декодирования. Это важно для проектов, где сервер не только пишет поток, но и анализирует его. Экономия на дисках может обернуться ростом нагрузки на процессор или видеокарту.

Как посчитать архив

Архив считается от битрейта, количества камер и срока хранения. В простом виде формула выглядит так:

Объем архива = битрейт одной камеры × количество камер × время записи в сутки × срок хранения

В реальном проекте к этому добавляют запас на файловую систему, служебные данные, RAID, рост битрейта, будущие камеры и ошибки первоначальной оценки. Производители инструментов для проектирования систем видеонаблюдения используют ту же базовую логику: расчет строится вокруг параметров камер, пропускной способности и срока хранения. Например, Axis Site Designer позволяет оценивать хранилище и полосу пропускания при проектировании системы, а Seagate предлагает калькулятор архива на основе параметров видеонаблюдения.

Возьмем пример: 40 камер, средний поток 4 Мбит/с на камеру, запись 24 часа в сутки, хранение 30 дней. Суммарный входящий поток будет 160 Мбит/с. За сутки такая система создаст примерно 1,7 ТБ «сырого» видео. За 30 дней получится около 52 ТБ до учета RAID и запаса.

Но покупать ровно 52 ТБ нельзя. Если используется RAID 6, часть емкости уйдет на отказоустойчивость. Еще часть уйдет на файловую систему и служебные данные. Кроме того, поток может быть выше в ночное время, в плохую погоду или при большом движении в кадре. Поэтому для такого проекта полезная емкость массива должна быть заметно больше расчетного минимума. Часто разумно закладывать запас 20–30%, а для растущих объектов — больше.

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

Как AI-аналитика меняет требования к серверу

Обычная запись архива и AI-аналитика нагружают сервер по-разному. При записи основная нагрузка ложится на сеть и диски. При аналитике сервер должен получить поток, декодировать его, подготовить кадры, передать их нейросети, обработать результат и сохранить событие. NVIDIA в документации DeepStream рассматривает производительность видеоаналитики как цепочку из захвата потока, декодирования, предобработки, обработки нейросетью и последующей обработки результата.

Это значит, что вопрос «какая видеокарта нужна» нельзя решать отдельно от камер. Нужно знать, сколько потоков анализируется одновременно, в каком разрешении, с каким FPS и какой тип аналитики используется. Распознавание человека в кадре, подсчет посетителей, поиск автомобиля, контроль каски, распознавание лица и распознавание номера — разные задачи. Они могут использовать разные модели и давать разную нагрузку.

AI-аналитика не обязана работать на всех камерах. Часто достаточно анализировать входы, кассы, въезды, периметр, опасные зоны и участки с повышенным риском. Камеры общего обзора можно просто записывать. Это сильно снижает требования к GPU.

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

Когда нужен GPU

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

Выбирать GPU только по объему видеопамяти неправильно. Важны производительность в нужной модели аналитики, поддержка декодирования, энергопотребление, охлаждение, длина карты, количество доступных линий PCIe и совместимость с сервером. В обычный стоечный сервер не всегда можно поставить любую мощную видеокарту: она может не поместиться по габаритам, не пройти по теплопакету или потребовать питание, которого нет в выбранной конфигурации.

Для небольшого объекта с 10–20 камерами GPU может не понадобиться, особенно если аналитика выполняется на самих камерах или включается только по событиям. Для среднего объекта с 30–80 камерами и анализом части потоков обычно уже стоит рассматривать отдельный GPU. Для крупного объекта лучше заранее проектировать масштабирование: несколько GPU, отдельный сервер аналитики или разделение системы на серверы записи и серверы обработки.

Важно проверить, поддерживает ли выбранная VMS или аналитическая платформа конкретную видеокарту. Иногда железо мощное, но программное обеспечение не умеет использовать его полностью. В таком случае часть бюджета будет потрачена впустую.

Декодирование видео — скрытая нагрузка

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

H.265 помогает экономить место на дисках, но может требовать больше ресурсов при обработке. Поэтому выбор кодека — это не только вопрос архива. Это еще и вопрос того, где и как будет выполняться декодирование. NVIDIA Video Codec SDK описывает аппаратные возможности декодирования и кодирования видео на GPU, включая работу с H.264 и H.265, поэтому для проектов с большим числом потоков стоит проверять не только «нейросетевую» часть GPU, но и видеокодеки.

Типичная ошибка выглядит так: компания покупает GPU для AI-аналитики, но не проверяет, сколько потоков он сможет декодировать в нужном разрешении и кодеке. В итоге нейросеть еще имеет запас, а вся система уже ограничена подготовкой кадров. Поэтому расчет должен учитывать весь путь видео, а не только момент обработки нейросетью.

Как выбрать дисковую подсистему

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

Хорошая практика — разделять системные диски и архив. Операционная система, VMS, база событий и служебные данные Вполне могут находиться на отдельных SSD. А вот видеоархив лучше размещать на отдельном массиве HDD, если главная задача — большой объем. SSD или NVMe-диски полезны для системы, базы, кэша, метаданных и быстрых операций, но не всегда нужны для самого архива. Если сервер пишет сотни терабайт видео, узким местом часто становится не задержка, а емкость и надежность.

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

Количество дисковых отсеков нужно считать заранее. Если сегодня требуется 80 ТБ полезной емкости, а через год появятся новые камеры и срок хранения увеличится, сервер на 4 диска быстро станет тупиком. Лучше сразу выбирать корпус с запасом по отсекам или проектировать внешнее хранилище.

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

RAID и полезная емкость

RAID нужен не для того, чтобы «сделать резервную копию», а чтобы сервер продолжал работать при отказе одного или нескольких дисков. Это важная разница. RAID не спасает от удаления данных, ошибки администратора, повреждения архива, вируса, пожара или кражи сервера. Для особо важных событий нужно отдельно продумывать резервное копирование или выгрузку фрагментов во внешнее хранилище.

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

При расчете архива важно учитывать не номинальную, а полезную емкость. Например, восемь дисков по 16 ТБ дают 128 ТБ «на бумаге». В RAID 6 полезный объём будет меньше, потому что емкость двух дисков уходит на отказоустойчивость. После этого нужно учесть файловую систему, служебные данные и запас. Поэтому сервер с «128 ТБ дисков» не равен серверу со 128 ТБ доступного архива.

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

Сеть: где появляется узкое место

Сервер видеонаблюдения постоянно принимает поток от камер. Если 100 камер дают в среднем по 6 Мбит/с, входящий поток уже составляет около 600 Мбит/с. На первый взгляд это меньше 1 Гбит/с, но для реальной системы запас слишком мал. Нужно учитывать пики, служебный трафик, просмотр операторами, выгрузку архива, резервное копирование, обновления и удаленный доступ.

Один гигабитный порт может быстро стать ограничением. Для средних систем лучше рассматривать 10 Гбит/с или несколько сетевых портов с правильным разделением трафика. Для крупных объектов может понадобиться 10/25 Гбит/с и отдельная сеть для камер.

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

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

Процессор и память

Процессор отвечает за работу операционной системы, VMS, сетевого стека, базы событий, пользователей, правил, экспорта архива и части обработки видео. Даже если AI-аналитика выполняется на GPU, слабый процессор может ограничить всю систему. Он будет управлять потоками, готовить данные, обслуживать диски и сеть.

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

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

Как считать сервер по типу объекта

Для небольшого объекта с 8–20 камерами, разрешением 2–4 Мп, частотой 10–15 кадров в секунду и архивом на 7–14 дней часто достаточно одного сервера. Разумная конфигурация: SSD под систему и VMS, отдельный HDD-массив под архив, RAID 5 или RAID 6 в зависимости от объема и критичности, запас по памяти и нормальное охлаждение. GPU может не понадобиться, если аналитика выполняется на камерах или включается только для простых событий.

Для среднего объекта с 30–80 камерами расчет становится жестче. Здесь уже важно считать общий поток, полезную емкость RAID и нагрузку от операторов. Если часть камер анализируется нейросетью, стоит рассматривать GPU среднего уровня. Желательны 10 Гбит/с, RAID 6, отдельные системные SSD, достаточное число дисковых отсеков и запас по памяти. В таких проектах сервер «в минимальной комплектации» часто оказывается ошибкой.

Для крупного объекта со 100+ камерами лучше не пытаться уместить все в один сервер. Запись, хранение, управление и AI-аналитику часто выгоднее разделить. Один или несколько серверов принимают и пишут потоки, отдельный узел выполняет аналитику, а хранилище масштабируется независимо. Такой подход дороже на старте, но проще в обслуживании и надежнее при росте системы.

Что часто забывают при выборе

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

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

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

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

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

Резервные блоки питания, нормальное охлаждение и мониторинг состояния дисков — не роскошь для системы 24/7. Видеонаблюдение обычно вспоминают именно тогда, когда что-то произошло. Если в этот момент архив недоступен из-за отказа диска или перегрева сервера, экономия на инфраструктуре теряет смысл.

Вопросы перед покупкой сервера

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

Список вопросов должен быть таким:

• сколько камер используется сейчас;
• сколько камер может появиться через 1–3 года;
• какое разрешение у камер;
• какой FPS нужен для каждой зоны;
• какой кодек используется: H.264 или H.265;
• какой средний и пиковый битрейт у камер;
• запись идет постоянно или по событию;
• сколько дней нужно хранить архив;
• сколько операторов смотрят видео одновременно;
• есть ли видеостена;
• какие камеры требуют AI-аналитики;
• какие задачи аналитики нужны: люди, лица, номера, транспорт, каски, периметр, очереди;
• нужна ли обработка в реальном времени;
• где будет выполняться аналитика: в камере, на сервере или на отдельном узле;
• какая VMS или NVR-платформа используется;
• какие системные требования у этого ПО;
• какой RAID нужен;
• какие события нужно дополнительно копировать или сохранять отдельно;
• сколько времени система может быть недоступна при аварии.

Если на эти вопросы нет ответов, сервер лучше не покупать. Сначала нужно провести обследование, снять параметры с камер или хотя бы смоделировать несколько сценариев.

Типовые ошибки

• Считать только количество камер. Это самый быстрый путь к неправильной конфигурации. Камеры отличаются разрешением, частотой кадров, кодеком, битрейтом и сценой.
• Выбирать диски только по объему. Для видеонаблюдения важны постоянная запись, ресурс, скорость восстановления массива, число отсеков и полезная емкость после RAID.
• Забывать про декодирование. Сервер может легко писать поток, но начать тормозить при просмотре, экспорте или аналитике.
• Покупать GPU без проверки совместимости. Видеокарта должна поддерживаться программным обеспечением, помещаться в сервер, получать достаточно питания и нормально охлаждаться.
• Хранить операционную систему, базу VMS и архив на одном массиве. При высокой нагрузке это усложняет обслуживание и может ухудшать стабильность.
• Не учитывать рост системы. Камеры почти всегда добавляются: новый склад, новая парковка, дополнительные кассы, периметр, производственная зона. Сервер без запаса быстро становится ограничением.
• Экономить на сети. Один гигабитный порт выглядит достаточным только до тех пор, пока не появятся пиковые потоки, несколько операторов и удаленная выгрузка архива.
• Не тестировать реальный поток. Табличные расчеты полезны, но лучше проверить систему на настоящих камерах, с реальными настройками и сценами.

Как выбрать итоговую конфигурацию

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

Затем рассчитывается архив. Нужно определить срок хранения, перевести битрейт в объем данных, добавить запас и пересчитать емкость с учетом RAID. На этом этапе часто выясняется, что дисков нужно больше, чем ожидалось.

После этого выбирается дисковая схема. Системные SSD отдельно, видеоархив отдельно. Для небольших массивов можно рассматривать простые схемы, для значимых архивов чаще подходит RAID 6, для высокой скорости и быстрого восстановления — RAID 10. Важно считать полезную емкость, а не сумму всех дисков.

Дальше рассчитывается AI-аналитика. Нужно определить, какие камеры анализируются, в каком разрешении, с каким FPS и какой тип нейросетевой обработки используется. Если аналитика нужна только на части камер, не стоит закладывать GPU так, будто анализируется весь объект.

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

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

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

Что выбрать в итоге

Для небольшого видеонаблюдения с несколькими десятками камер обычно достаточно одного сервера с отдельным системным SSD, HDD-массивом под архив, разумным RAID и запасом по памяти. GPU нужен только если аналитика выполняется на сервере и не ограничивается простыми событиями.

Для среднего объекта сервер нужно выбирать уже как полноценную платформу: дисковые отсеки с запасом, RAID 6, 10 Гбит/с, отдельный GPU для аналитики, достаточный объем памяти и проверенная совместимость с VMS. Здесь опасно покупать минимальную конфигурацию, потому что запас быстро съедят новые камеры, операторы и дополнительные сценарии аналитики.

Для крупной системы лучше разделять роли. Запись, хранение, управление и AI-аналитика могут жить на разных узлах. Это упрощает масштабирование и снижает риск, что одна перегруженная подсистема остановит весь проект.

Правильный сервер для видеонаблюдения с AI-аналитикой выбирается не по названию задачи и не по числу камер в коммерческом предложении. Его считают от потока данных, архива, дисков, сети, декодирования и реальных сценариев аналитики. Такой подход позволяет не переплатить за лишнее, но и не получить систему, которая формально куплена «под AI», а на практике не выдерживает рабочую нагрузку.