Analítica de video (YOLO): consumo de recursos¶
El trigger Analítica de video (YOLO) analiza las cámaras en el servicio
automation-vision-worker. Esta página resume cuánto consume y cómo calcular el servidor que hace falta.
Son aproximaciones. Los valores se midieron en un entorno concreto (ver Cómo se midió) y pueden variar ±30–50 % según el procesador, la escena y la carga simultánea. Usalos para dimensionar, y confirmá luego con el estado en vivo de las cámaras en el editor del nodo (FPS reales y tiempo de análisis).
Resumen rápido¶
- Lo que más pesa es la inferencia del modelo. Su costo crece con el tamaño del modelo y con los FPS que configurás.
- Cada modelo se carga una sola vez en memoria, aunque lo usen muchas cámaras.
- Cada cámara suma un decodificador de video (~55 MB de RAM y muy poca CPU en el sub-stream).
- Bajar de 5 a 2 FPS reduce el consumo de CPU del modelo a menos de la mitad.
Consumo por modelo¶
Latencia de una imagen (preparación + inferencia + resultado) y memoria que agrega el modelo una vez cargado.
| Modelo | Entrada | Archivo | RAM del modelo | Latencia (1 núcleo) | Latencia (4 núcleos) | Núcleos por cámara a 5 FPS | Cámaras por núcleo a 5 FPS |
|---|---|---|---|---|---|---|---|
| YOLOX Nano | 416 px | 3.7 MB | ~35 MB | ~24 ms | ~12 ms | ~0.14 | ~7 |
| YOLOX Tiny | 416 px | 20 MB | ~80 MB | ~80 ms | ~38 ms | ~0.43 | ~2 |
| D-FINE Nano | 640 px | 15 MB | ~130 MB | ~150 ms | ~76 ms | ~0.77 | ~1.3 |
| YOLOX S | 640 px | 36 MB | ~180 MB | ~315 ms | ~123 ms | ~1.6 | 0.6 |
| D-FINE S | 640 px | 42 MB | ~255 MB | ~425 ms | ~200 ms | ~2.1 | 0.5 |
| RT-DETRv2 R18 | 640 px | 81 MB | ~335 MB | ~710 ms | ~350 ms | ~3.6 | 0.3 |
| YOLOX M | 640 px | 101 MB | ~340 MB | ~760 ms | ~390 ms | ~3.8 | 0.25 |
Cómo leer la tabla:
- Latencia (1 núcleo) es el costo real de CPU por imagen. Núcleos por cámara = latencia × FPS ÷ 1000, más el decodificador.
- Latencia (4 núcleos) es lo que tarda en analizarse una imagen cuando el modelo usa 4 hilos. Mejora el tiempo de respuesta de una cámara, pero no la cantidad total de cámaras: la CPU total consumida es la misma o algo mayor.
- Cámaras por núcleo se refiere a núcleos físicos. Los hilos de Hyper-Threading suman poco en inferencia.
- Los modelos de 640 px y los transformers (D-FINE, RT-DETR) en CPU sirven para pocas cámaras o FPS bajos. Para muchas cámaras con esos modelos, conviene una GPU.
¿Qué modelo elegir?¶
| Necesidad | Modelo recomendado |
|---|---|
| Muchas cámaras en un servidor modesto, objetos cercanos (pasillos, puertas, cajas) | YOLOX Nano |
| Uso general en CPU (perímetros, estacionamientos medianos) | YOLOX Tiny |
| Multitudes (menos cajas duplicadas) en CPU, pocas cámaras | D-FINE Nano |
| Objetos chicos o lejanos (perímetros grandes, autos a distancia) | YOLOX S o D-FINE S, con GPU si son varias cámaras |
| Máxima precisión | RT-DETRv2 o YOLOX M, con GPU |
Consumo por cámara (además del modelo)¶
| Concepto | CPU | RAM |
|---|---|---|
| Decodificar el sub-stream (640×360, 15 fps) | ~2 % de un núcleo | ~55 MB |
| Decodificar el main a 720p (15 fps) | ~8 % de un núcleo | ~60 MB |
| Decodificar el main a 1080p (15 fps) | ~10 % de un núcleo | ~70 MB |
| Conexión WebRTC, seguimiento de objetos y reglas | < 1 % | ~5 MB |
Recomendación: usá el sub-stream. El modelo trabaja a 416–640 px, así que el stream principal solo aporta cuando los objetos son muy chicos.
Consumo fijo del servicio¶
| Concepto | Valor aproximado |
|---|---|
| Proceso del worker con el motor de inferencia cargado | ~35–60 MB |
| Imagen Docker (sin modelos) | ~750 MB en disco |
| Modelos instalados | Su tamaño de archivo (3.7 a 101 MB cada uno) |
| Foto anotada por evento | 70–150 KB. Se guardan 7 días por defecto (VISION_SNAPSHOT_RETENTION_HOURS) |
Ejemplo de disco para fotos: 500 eventos por día × 100 KB × 7 días ≈ 350 MB.
Cómo calcular el servidor¶
CPU (núcleos físicos)
núcleos ≈ Σ por cámara [ latencia_1_núcleo_ms × FPS ÷ 1000 + 0.02 ] × 1.3
El 1.3 es un margen: con todos los núcleos ocupados, el procesador baja su frecuencia de turbo.
RAM
RAM ≈ 60 MB + Σ modelos en uso (RAM del modelo) + cámaras × 60 MB (+30 % de margen)
Ejemplos¶
| Escenario | Cálculo de CPU | Núcleos | RAM |
|---|---|---|---|
| 16 cámaras, YOLOX Nano, 5 FPS | 16 × (24×5/1000 + 0.02) × 1.3 | ~3 | ~1.3 GB |
| 8 cámaras, YOLOX Tiny, 5 FPS | 8 × (80×5/1000 + 0.02) × 1.3 | ~4.5 | ~0.8 GB |
| 8 cámaras, YOLOX Tiny, 2 FPS (permanencia/aforo) | 8 × (80×2/1000 + 0.02) × 1.3 | ~2 | ~0.8 GB |
| 4 cámaras, YOLOX S, 2 FPS (perímetro lejano) | 4 × (315×2/1000 + 0.02) × 1.3 | ~3.4 | ~0.6 GB |
| 2 cámaras, D-FINE S, 5 FPS | 2 × (425×5/1000 + 0.02) × 1.3 | ~5.6 | ~0.6 GB |
Variables que regulan el consumo¶
| Variable | Por defecto | Efecto |
|---|---|---|
| FPS del trigger | 5 | Lineal sobre la CPU del modelo |
VISION_MAX_INFER |
mitad de los núcleos | Inferencias en paralelo. Más paralelismo = más cámaras atendidas, si hay CPU libre |
VISION_THREADS |
min(4, núcleos) | Hilos por inferencia. Conviene que VISION_MAX_INFER × VISION_THREADS no supere los núcleos físicos |
VISION_MAX_STREAMS |
32 | Tope de cámaras simultáneas. Las que exceden no se analizan (queda registrado en el log) |
VISION_FRAME_WIDTH |
640 | Ancho al que se decodifica la imagen. Subirlo solo ayuda con modelos de 640 px y objetos chicos |
Señales de que el servidor no da abasto: los FPS reales del estado de la cámara quedan por debajo de los configurados, o el tiempo de análisis sube mucho por encima de la tabla. En ese caso, bajá FPS, usá un modelo más chico, desactivá cámaras o asigná más CPU o una GPU.
GPU¶
Existe una imagen con soporte NVIDIA (Dockerfile.vision.gpu, CUDA 12 + cuDNN 9, VISION_EP=cuda). No hay
mediciones en GPU todavía. Como referencia general, con onnxruntime + CUDA los modelos de 640 px suelen
analizar una imagen en pocas decenas de milisegundos, lo que permite decenas de cámaras por GPU. Medilo en el
equipo real antes de comprometer una capacidad.
Cómo se midió¶
- Equipo: Intel Core i9-11900H (8 núcleos / 16 hilos, portátil), contenedor Linux (Docker Desktop, WSL2).
- Software: onnxruntime 1.29 (CPU, el mismo que trae la imagen del worker); ffmpeg 4.4 de Ubuntu 22.04.
- Imagen de prueba: foto de calle reescalada a 640 px de ancho, como la decodifica el worker. Se tomó la mediana de 40 corridas, después de 3 de calentamiento.
- Memoria: RSS del proceso antes y después de cargar el modelo y analizar (un proceso por modelo).
- Decodificador: ffmpeg con los mismos argumentos que usa el worker, sobre H264 de 30 s a 15 fps.
- Reproducible: el test
TestBenchmarkCatalogdel repositoriomodule.automation(backend/pkg/vision/infer/bench_test.go).
Un servidor con procesadores Xeon o EPYC de menor frecuencia puede ser hasta un 30–50 % más lento por núcleo, aunque tenga muchos más núcleos.