Розробка real-time детекції об'єктів: до 280 FPS на TensorRT

Коли на об'єкті 16 камер відеоспостереження, а система видає 15 FPS — це не real-time. Пайплайн, описаний нижче, тримає 30+ FPS на кожній камері при загальному навантаженні до 32 потоків 1080p. Гарантуємо затримку (latency) менше 10 мс завдяки апаратному декодуванню NVDEC та GPU-процесингу. У нашій практиці — 20+ проєктів з детекції об'єктів. Оптимізація пайплайну дозволяє знизити витрати на GPU-інфраструктуру в 2–3 рази. Зв'яжіться з нами для попередньої оцінки вашого проєкту — це безплатно та займе не більше години.

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

Завдання потребує балансу між точністю, швидкістю та навантаженням на залізо. Наївний підхід — ганяти кожен кадр через нейромережу — впирається в ліміт GPU: сучасні архітектури (YOLOv8, RT-DETR) вимагають 10–30 мс на інференс. Без оптимізації затримка легко перевищує 50 мс, що критично для робототехніки або систем безпеки. Рішення лежить у трьох площинах: вибір легкої моделі (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 ) 

Пропуск кадрів — детектуємо не кожен кадр. При 30 FPS відео детекція на кожному 3-му кадрі (10 детекцій/сек) + трекінг для проміжних кадрів. Сприйнятна якість зберігається.

Динамічне пакетування — групуємо кадри з декількох камер в батч для одного 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

Що дає використання 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

Як ми оптимізуємо затримку?

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

Додатково використовуємо pipeline parallelism: захоплення, попередня обробка та інференс виконуються конкурентно на різних потоках GPU. Це дозволяє утилізувати GPU на 95%+.

Як ми впроваджуємо рішення: покроковий процес

1. Аналіз вимог — визначення числа камер, класів об'єктів, допустимої затримки.
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.

Вартість розраховується індивідуально та залежить від масштабу і складності. Зв'яжіться з нами для отримання консультації та попереднього розрахунку. Економія на GPU-інфраструктурі може досягати 2–3 разів.