Разработка real-time детекции объектов: до 280 FPS на TensorRT

Детекция объектов в реальном времени: решаем проблему latency

Направления AI-разработки

Часто задаваемые вопросы

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1460
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1314
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1013
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1275
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    727
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1019

Детекция объектов в реальном времени: решаем проблему latency

Отметим: когда на объекте 16 камер видеонаблюдения, а система выдаёт 15 FPS — это не real-time. Пайплайн, описанный ниже, держит 30+ FPS на каждой камере при общей нагрузке до 32 потоков 1080p. Гарантируем latency менее 10 ms за счёт аппаратного декодирования NVDEC и GPU-процессинга. В нашей практике — 20+ проектов по детекции объектов. Оптимизация пайплайна позволяет снизить затраты на GPU-инфраструктуру в 2–3 раза. Свяжитесь с нами для предварительной оценки вашего проекта — это бесплатно и займёт не более часа.

Почему real-time детекция — сложная техническая задача?

Задача требует баланса между точностью, скоростью и нагрузкой на железо. Наивный подход — гонять каждый кадр через нейросеть — упирается в предел GPU: современные архитектуры (YOLOv8, RT-DETR) требуют 10–30 ms на инференс. Без оптимизации latency легко переваливает за 50 ms, что критично для роботики или систем безопасности. Решение лежит в трёх плоскостях: выбор лёгкой модели (YOLOv8n/m), аппаратное ускорение (TensorRT, NVDEC) и снятие повторяющейся нагрузки через скиппинг кадров.

Архитектура системы

Camera → Frame Capture → Preprocessing → Inference → Postprocessing → Output ↓ ↓ Frame Skipping TensorRT/ONNX Runtime Resize/Normalize GPU batching 

Для RTSP/IP-камер используем GStreamer или FFmpeg для захвата потока с аппаратным декодированием (NVDEC на NVIDIA):

import cv2 # Hardware-accelerated RTSP capture cap = cv2.VideoCapture( 'rtsp://camera_ip/stream?' 'pipeline=' 'rtspsrc location=rtsp://camera_ip/stream !' 'rtph264depay ! h264parse ! nvh264dec !' # NVDEC 'videoconvert ! appsink', cv2.CAP_GSTREAMER ) 

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

Как мы достигаем 280+ FPS на одной камере?

Оптимизация через TensorRT — стандарт индустрии, подтверждённый NVIDIA TensorRT Developer Guide. Конвертация YOLOv8 в engine FP16 даёт ускорение в 2–5x по сравнению с нативным PyTorch. Также применяется динамическое батчирование: кадры от нескольких камер группируются в один батч, что повышает загрузку GPU.

from ultralytics import YOLO model = YOLO('yolov8n.pt') # Export to TensorRT FP16 model.export( format='engine', half=True, # FP16 precision batch=1, # or batch=4 for batching device=0, workspace=4 # GB for optimization ) 

Frame skipping — детектируем не каждый кадр. При 30 FPS видео детекция на каждом 3-м кадре (10 детекций/сек) + трекинг для промежуточных кадров. Воспринимаемое качество сохраняется.

Dynamic batching — группируем кадры с нескольких камер в батч для одного GPU-прохода:

class MultiCameraInference: def __init__(self, model_path, num_cameras=8): self.model = load_trt_model(model_path) self.batch_size = num_cameras def process_batch(self, frames: list[np.ndarray]) -> list[list]: # Preprocessing batch batch = preprocess_batch(frames) # [N, 3, H, W] # Single GPU inference for all cameras results = self.model.infer(batch) return postprocess_batch(results) 

TensorRT в 3–4 раза быстрее нативного PyTorch. Подробнее — в документации TensorRT.

Сравнение: TensorRT против PyTorch

Параметр PyTorch FP32 TensorRT FP16 Ускорение
YOLOv8n (640x640) 12 ms 4 ms 3x
YOLOv8m (640x640) 28 ms 8 ms 3.5x
YOLOv8l (640x640) 55 ms 14 ms 4x

Что даёт использование TensorRT для многокамерных систем?

Для мониторинга с 8–32 камерами: один A100/H100 GPU обрабатывает до 32 потоков 1080p@30fps с YOLOv8n. Архитектура: shared inference server (Triton) + отдельные процессы захвата для каждой камеры. Экономия на GPU-инфраструктуре — до 3 раз по сравнению с наивной реализацией.

Пропускная способность:

  • NVIDIA T4 (16GB): 8–12 камер 1080p с YOLOv8m
  • NVIDIA A100: 24–32 камеры 1080p с YOLOv8l

Как мы оптимизируем latency?

Pipeline latency = capture + decode + preprocess + inference + postprocess + display

Этап Типичное время Оптимизированное
Захват кадра 5 ms 2 ms (NVDEC)
Препроцессинг 8 ms 1 ms (GPU preproc)
Инференс YOLOv8n 12 ms 4 ms (TRT FP16)
Постпроцессинг + NMS 5 ms 2 ms
Итого 30 ms 9 ms

Дополнительно используем pipeline parallelism: захват, препроцессинг и инференс выполняются конкурентно на разных потоках GPU. Это позволяет утилизировать GPU на 95%+.

Как мы внедряем решение: пошаговый процесс

  1. Анализ требований — определение числа камер, классов объектов, допустимой latency.
  2. Сбор и разметка данных — если нужны кастомные классы, готовим датасет (1000+ кадров).
  3. Обучение и квантование — выбираем YOLOv8n/m, обучаем на GPU, оптимизируем до FP16/INT8.
  4. Интеграция с инфраструктурой — настройка Triton Inference Server, RTSP-захват, деплой в Docker.
  5. Мониторинг и поддержка — дашборды Grafana, alerting, обновление модели.

Объём работ и поставка

  • Архитектура: протокол захвата, постобработка, трекинг.
  • Модель: выбор YOLO, датасет, обучение, квантование до FP16/INT8.
  • Инференс-сервер: настройка Triton или TorchServe с батчированием.
  • Деплой: Docker-образ с CUDA 12.x, Helm-чарт для Kubernetes.
  • Документация: API, метрики, инструкции оператора.
  • Обучение: 2–4 часа workshop для вашего персонала.

Деплой и мониторинг

Docker-контейнер с CUDA 12.x + TensorRT. Метрики: FPS per camera, inference latency, GPU utilization, detection count per class per minute. Alerting через Prometheus + Grafana.

Масштаб системы Срок
1–4 камеры, базовая детекция 2–3 недели
8–32 камеры, кастомные классы 4–7 недель
50+ камер, распределённая архитектура 8–14 недель

Стоимость рассчитывается индивидуально и зависит от масштаба и сложности. Свяжитесь с нами для получения консультации и предварительного расчёта. Экономия на GPU-инфраструктуре может достигать 2–3 раз.