Getting Started Cameras & Video Detection & Recording Automation & Events Actions Integration & Connectivity Network & Discovery AI & Remote Control MQTT Modbus ZeroMQ System & Administration Use Cases Troubleshooting About & Legal
Home / Documentation / YOLO Worker
Knowledge base

YOLO Worker

Yolo Worker loads a YOLO object-detection model and exposes it as a reusable image classifier for Banalytics tasks. Use it when one or more cameras need real-time object classification through the same model, backend, and worker pool.

Keep model loading separate from detection tasks

The worker owns the OpenCV DNN networks, model files, computation backend, and pool size. YoloDetectionTask instances borrow network instances from this pool, so several detection tasks can share the same loaded model.

DNN

Model pool

Creates 1-10 independent YOLO network instances and tracks wait time, processing time, throughput, and total processed count.

CV

OpenCV backend

Uses the selected OpenCV DNN backend and target, such as CPU, CUDA, OpenCL, or OpenVINO when available in the runtime.

CLS

Class registry

Reads class names from config.names so detection tasks can offer an exact target-class selector.

Choose worker count for the real workload

CPU

Single camera on CPU

Start with workers=1, a tiny model, and a CPU backend/target pair. This is the safest baseline for low-power hosts where capture, motion detection, recording, and YOLO share the same CPU.

POOL

Several detection tasks sharing one model

Point multiple YoloDetectionTask instances to the same worker when they use the same model. Increase workers only when wait time grows and the host still has free CPU/GPU and memory.

GPU

Accelerated inference

Select CUDA, OpenCL, or OpenVINO only when the installed OpenCV/Bytedeco runtime, drivers, and hardware expose that pair. Test one worker first because extra GPU workers can increase VRAM pressure.

THRU

Throughput-first deployment

Use more workers when several cameras submit inference concurrently and the selected backend can run them in parallel. If processing time rises sharply after adding workers, the device is saturated.

Pick the model family and file layout that match latency and accuracy

Tiny models
Use tiny variants when near-real-time reaction matters more than detecting small, distant, or difficult objects.
Full models
Use larger YOLO models when accuracy matters more than latency and the host can absorb the cost.
ONNX layout
Use a model folder with model.onnx and config.names. ONNX is preferred automatically when present.
Darknet layout
Use config.cfg, config.weights, and config.names for Darknet model packages.
Dedicated workers: create separate Yolo Worker instances for different model families or class lists, then point each detection task to the worker that matches its scenario.

Configuration parameters

ParameterRequiredDescriptionDefault
Workers
YesNumber of parallel YOLO inference instances in the pool. Allowed range is 1-10.1
Model
YesModel name from the yolo model registry, for example a YOLOv4 or tiny variant.Registry default
Computation configuration
YesColon-separated OpenCV DNN backend and target pair, for example DNN_BACKEND_OPENCV:DNN_TARGET_CPU.CPU pair

Tune using worker statistics

WAIT

Wait time means queue pressure

If requests spend time waiting for a free network, the pool is too small, the model is too slow, or detection tasks submit work too often.

PROC

Processing time means inference cost

If processing time increases when workers are added, the CPU, GPU, memory bandwidth, or VRAM is likely over-subscribed.

MEM

Each worker loads a network

Increasing workers can multiply native memory or GPU memory usage because every pool instance owns its own OpenCV DNN network.

RST

Restart after model changes

Changing workers, subModelName, or computationConfig requires restart because the network pool must be rebuilt.

Compatibility note: a backend/target pair being listed does not guarantee good performance for every model. Some combinations can fail or fall back depending on OpenCV build, drivers, hardware support, and model operators.

Related classification pages

Related tasks and pages