Актуально на май 2026 года. Сервер для видеоаналитики нельзя подбирать по принципу «поставим мощную видеокарту». В production узкими местами становятся декодирование RTSP, PCIe, CPU, RAM, NVMe, сеть, охлаждение, драйверы, мониторинг и запас под будущие модели.

Smart Video проектирует ИИ-сервер для машинного зрения как промышленную платформу: камеры, инференс, хранение событий, мониторинг, интеграция с MES/SCADA/СКУД и развитие в сторону локальных LLM, RAG и ИИ-агентов через AI Platforms.

Что изменилось к 2026 году

NVIDIA развивает сразу несколько классов решений. Для enterprise-инференса доступны H200 с 141 GB HBM3e и высокой пропускной способностью памяти, DGX B200 как плотная Blackwell-платформа для крупных AI Factory, а RTX PRO 6000 Blackwell Server Edition дает 96 GB GDDR7, современные NVENC/NVDEC и серверный форм-фактор для смешанных нагрузок: computer vision, видео, графика, LLM-инференс.

AMD Instinct MI300X остается сильным вариантом для задач, где важна большая HBM-память: 192 GB на ускоритель и высокая пропускная способность. При подборе железа мы опираемся и на инженерную практику Аквис-Сервис: питание, стойка, охлаждение и эксплуатация важны не меньше модели. На edge-уровне NVIDIA Jetson Thor показывает, куда движется физический AI: больше локального inference рядом с оборудованием и робототехникой.

Но для видеоаналитики голая производительность TFLOPS не отвечает на главный вопрос: сколько камер система стабильно обработает 24/7 при заданной задержке.

Как считать нагрузку

Нужно отдельно считать четыре потока работы:

1. Прием видео: RTSP/GigE Vision/USB, битрейт, потери пакетов, буферизация.

2. Декодирование: H.264/H.265, число NVDEC, нагрузка CPU, batch кадров.

3. Инференс: размер модели, FPS анализа, разрешение, batch, precision, TensorRT/Triton.

4. Постобработка и интеграция: трекинг, OCR, правила зон, запись JPEG/видео, MQTT/OPC UA/REST.

Например, 64 камеры 1080p по 25 FPS не означают, что нужно анализировать все кадры. Для контроля СИЗ часто достаточно 5-10 FPS на камеру. Для быстрого конвейера может требоваться каждый кадр, аппаратный trigger и жесткая задержка до исполнительного механизма. Это принципиально разные серверы.

Типовые классы конфигураций

Edge-узел на участке: 4-16 камер, простая детекция, локальный журнал, интеграция с одной линией. Здесь важны компактность, пылезащита, питание, удаленный мониторинг и запас по температуре.

Площадочный сервер: 16-64 камеры, несколько моделей, DeepStream/Triton, общий журнал событий, Grafana/Prometheus, интеграция с СКУД или SCADA. Часто оптимальны серверные RTX-карты или несколько GPU с нормальным корпусом и продувом.

Центральная AI-платформа: десятки и сотни потоков, архив, RAG, LLM-ассистенты, аналитика по документам и событиям. Здесь уже уместны H200/B200/MI300X-классы, кластеризация и отдельный MLOps-контур.

Почему декодирование важно не меньше GPU

Видеопоток сначала нужно принять и декодировать. Если сервер не справляется с NVDEC или CPU-декодированием, GPU может простаивать, а задержка будет расти. Поэтому мы проверяем число аппаратных декодеров, поддержку кодеков, пропускную способность сети, схему хранения и реальные потоки камер, а не только synthetic benchmark модели.

NVIDIA Triton полезен для стандартизации inference-сервиса: разные модели, dynamic batching, метрики, Kubernetes/MLOps-интеграция. DeepStream удобен для GPU-ускоренной видеоаналитики и pipeline-обработки потоков. TensorRT-LLM и vLLM относятся уже к LLM-нагрузкам, которые появляются рядом с видеоаналитикой: поиск по событиям, ассистенты инженера, RAG по регламентам.

Тепловой режим и надежность

Частая ошибка — собрать сервер как рабочую станцию. В стойке это быстро превращается в throttling, нестабильность драйверов и трудное обслуживание. Для production нужны:

  • серверный корпус с рассчитанным airflow;
  • GPU с подходящим охлаждением под стойку;
  • запас по питанию и пиковым нагрузкам;
  • ECC-память там, где это оправдано;
  • NVMe под журнал и кэш;
  • out-of-band management;
  • мониторинг GPU, CPU, RAM, температуры, дисков, сетевых потерь и FPS по камерам.

Метрики приемки сервера

Мы проверяем не только «модель запустилась», а длительный профиль:

  • FPS inference по каждой камере;
  • end-to-end latency;
  • загрузка GPU/CPU/NVDEC;
  • температура и отсутствие throttling;
  • потеря кадров и reconnect RTSP;
  • время восстановления после сбоя камеры;
  • запас мощности под новую модель;
  • работа мониторинга и тревог.

Как Smart Video подбирает сервер

Мы начинаем с матрицы камер: разрешение, FPS, кодек, битрейт, сценарий, требуемая задержка. Затем выбираем модели и считаем pipeline. После этого подбираем GPU, CPU, RAM, NVMe, сеть, корпус и мониторинг.

Если заказчику нужна не только видеоаналитика, но и локальные LLM, RAG, ИИ-агенты или корпоративный поиск по документам, мы проектируем платформу вместе с AI Platforms. Для оценки нагрузки полезно начинать с конкретного сценария: контроль качества, СИЗ или распознавание лиц. Так сервер не становится тупиковой покупкой: он развивается от детекции дефектов и СИЗ к полной локальной ИИ-инфраструктуре предприятия.

Почему расчет «камеры × FPS» почти всегда ошибочен

На бумаге кажется, что 32 камеры по 25 FPS — это 800 кадров в секунду. На практике система может анализировать 5 FPS для СИЗ, каждый кадр для быстрого конвейера и отдельные trigger-кадры для контроля качества. Поэтому расчет начинается не с числа камер, а с матрицы сценариев.

Для каждой камеры мы фиксируем:

  • разрешение и кодек;
  • битрейт и стабильность RTSP;
  • FPS анализа, а не только FPS потока;
  • тип модели: detection, segmentation, OCR, face recognition, tracking;
  • размер входа модели;
  • требования к задержке;
  • нужно ли хранить видео, кадры событий или только метаданные;
  • нужны ли LLM/RAG-нагрузки на той же платформе.

Одна камера контроля качества на быстрой линии может быть тяжелее десяти обзорных камер СИЗ, если она требует высокого разрешения, trigger, segmentation и задержку меньше 100 мс. И наоборот: 50 камер архива могут почти не грузить GPU, если аналитика запускается только по событию.

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

Видеокарта не получает «готовые картинки из воздуха». Поток надо принять, декодировать, иногда изменить размер, положить в batch, обработать моделью, выполнить постобработку и записать событие. Если NVDEC или CPU не успевают, GPU может быть загружен всего на 40%, а задержка будет расти.

Для серверов видеоаналитики мы отдельно считаем:

  • число аппаратных декодеров и поддерживаемые кодеки;
  • запас сетевого интерфейса: 1/10/25 GbE;
  • CPU для RTSP, Python/C++ сервисов, брокеров и БД;
  • RAM под буферы и параллельные pipeline;
  • NVMe под события, кэш, временные фрагменты видео;
  • RAID/backup, если хранится доказательная база;
  • мониторинг температуры, питания, SMART, FPS и очередей.

RTX PRO 6000 Blackwell Server Edition интересна для смешанных задач: много видеопотоков, CV, мультимодальные модели, локальные ассистенты. H200/B200 и MI300X уместны там, где много LLM/RAG или крупных моделей, но для обычной видеоаналитики их нужно обосновывать. Иногда две серверные RTX-карты с хорошим NVDEC и правильным корпусом дадут более разумный TCO.

Пример расчета конфигурации

Допустим, площадка хочет:

  • 24 камеры СИЗ 1080p, анализ 5 FPS;
  • 6 камер распознавания лиц на проходах;
  • 4 камеры контроля качества с trigger и 12 MP кадрами;
  • хранение JPEG событий 90 дней;
  • локальный RAG по регламентам и журналам инцидентов.

Это уже не «одна мощная видеокарта». Нужен сервер, где отдельно проверены: декодирование 24 потоков, latency для 4 trigger-камер, отдельный сервис биометрии, журнал событий, база метаданных, RAG-сервис и мониторинг. Если все посадить в один docker-compose без ограничений ресурсов, ночью при переиндексации документов может просесть видеоаналитика. Поэтому production-схема требует resource limits, очередей, health checks и разделения критичных контуров.

Edge или центральный сервер

  • Edge на участке. Подходит, когда нужна низкая задержка и линия должна работать автономно. Главный риск — сложнее обновлять и сопровождать парк устройств.
  • Центральный сервер. Подходит для большого числа камер, единого журнала и централизованного сопровождения. Главный риск — сеть становится критичным звеном.
  • Гибридная схема. Хороша, когда trigger-события и безопасность работают локально, а аналитика, архив и отчеты централизованы. Главный риск — нужно заранее проектировать синхронизацию и правила отказа.

Для критичных производственных сигналов мы часто выбираем гибрид: быстрый локальный inference на участке, а журнал, отчеты, дообучение и RAG — на центральной платформе. Так линия не зависит от перегруженного канала, а ИТ не получает десятки неуправляемых коробок.

Мониторинг как часть поставки

Без мониторинга сервер работает «пока кто-то не пожалуется». Для промышленной эксплуатации этого мало. Мы выводим:

  • FPS по каждой камере;
  • очередь кадров и задержку;
  • загрузку GPU, CPU, NVDEC, RAM;
  • температуру GPU, CPU, дисков;
  • падения RTSP и время reconnect;
  • число событий по классам;
  • долю кадров, отброшенных по качеству;
  • версию модели и дату обновления;
  • ошибки интеграции с MES/SCADA/СКУД.

Этот мониторинг нужен не только ИТ. Главному инженеру важно видеть, что система не деградировала после переноса камеры или загрязнения объектива. Руководителю ОТК важно видеть, как меняется число дефектов по партиям. Службе охраны труда — где повторяются нарушения.

Как не купить сервер в тупик

ИИ-инфраструктура меняется быстрее, чем жизненный цикл промышленного оборудования. Поэтому в 2026 году сервер надо покупать с запасом не только по GPU, но и по архитектуре: контейнеризация, понятный MLOps, обновление моделей, возможность добавить RAG/LLM, резервное копирование, журналирование. Здесь Smart Video и AI Platforms работают вместе: видеоаналитика дает события, AI Platforms превращает их в поиск, отчеты, ассистентов и корпоративные знания.

Приемка сервера под нагрузкой

Мы считаем сервер принятым только после длительного прогона. Минимальный тест:

1. 24-72 часа реальных RTSP/GigE потоков.

2. Проверка reconnect камер.

3. Пиковая нагрузка: все модели включены одновременно.

4. Имитация отказа диска/сети/камеры, если это входит в SLA.

5. Проверка обновления модели без потери журнала.

6. Проверка метрик и алертов.

7. Отчет: фактическая задержка, FPS, загрузка, температура, запас.

Такой тест быстро показывает, где слабое место: GPU, декодирование, сеть, диск, Python-сервис, база или интеграция.

Источники

  • NVIDIA: RTX PRO 6000 Blackwell Server Edition specifications
  • NVIDIA: H200 Tensor Core GPU, 141 GB HBM3e and 4.8 TB/s memory bandwidth
  • NVIDIA Docs: Triton Inference Server
  • NVIDIA Docs: TensorRT-LLM
  • NVIDIA Docs: DeepStream SDK
  • AMD Instinct MI300X documentation: 192 GB HBM3 per accelerator
  • AMD Instinct Customer Acceptance Guide: MI300X system acceptance
  • AI Platforms: локальные LLM, RAG, ИИ-агенты и ИИ-серверы