· via dev.to (home feed)
Same-GPU benchmark of nine object-detection models upends published latency rankings
A developer ran nine object-detection models on one V100 under identical settings and found every model slower than its published figure, the speed ranking reordered, and licences varying by package.

A controlled comparison on a single GPU
A developer writing on dev.to has published a side-by-side comparison of nine object-detection models, all executed on one NVIDIA Tesla V100-PCIE-32GB under identical measurement conditions. The lineup covers YOLOv8m, YOLOv9m, YOLO11n, YOLO11m, YOLO26m, Faster R-CNN R50, Mask R-CNN R50, RF-DETR-B and RT-DETR-L. The motivation, according to the post, is that published latency figures depend heavily on the GPU, precision, batch size, framework and optimisations used during testing, which makes numbers taken from different project pages hard to compare directly.
How the test was run
Every model was run through plain PyTorch, with no TensorRT, no FP16 quantisation and no batching. Each model was loaded via its native ecosystem — Ultralytics, torchvision, Hugging Face Transformers or the RF-DETR package — and kept its own preprocessing and input-resizing pipeline untouched. Timing was done per scene with explicit CUDA synchronisation, and the reported figure is the median across 48 scenes. Those scenes mix ordinary images with harder conditions such as fog, motion blur, low light, snow, glare, thermal imagery and aerial viewpoints.
One caveat is stated up front: this is not an accuracy benchmark. The scenes lack human-verified ground-truth annotations, so no mAP scores are calculated. The comparison instead focuses on inference latency, visual detections, confidence scores and licensing.
Every model was slower than its published number
Across the board, measured latencies exceeded the published ones, by factors ranging from 1.6x to 11.6x.
| Model | Published | Measured | Gap |
|---|---|---|---|
| YOLO11n | 1.5 ms | 17.4 ms | 11.6x |
| RF-DETR-B | 6.0 ms | 69.1 ms | 11.5x |
| RT-DETR-L | 9.3 ms | 66.2 ms | 7.1x |
| YOLOv8m | 4.8 ms | 16.2 ms | 3.4x |
| Faster R-CNN R50 | 45.0 ms | 73.3 ms | 1.6x |
The author is careful to note that this does not mean the published benchmarks are wrong; they were presumably produced with different hardware, input sizes, precision settings or measurement methods. The point is that the figures only mean something relative to each other when the testing conditions match.
The ranking reordered
The more consequential result is that the ordering itself changed. Using published figures, the fastest model was YOLO11n, followed by YOLO26m and YOLOv8m. Measured under the same conditions, YOLOv8m took first place, YOLO11n slipped to second, and RF-DETR-B fell from fifth to seventh. Faster R-CNN R50 and Mask R-CNN R50 stayed at the bottom of the table, but their relative penalty shrank considerably, since the lighter models slowed down the most.
Licensing varied more than expected
The second finding the author highlights concerns licences. Five of the nine models — the Ultralytics family of YOLOv8m, YOLOv9m, YOLO11n, YOLO11m and YOLO26m — carry AGPL-3.0. The torchvision pair, Faster R-CNN R50 and Mask R-CNN R50, are BSD-3-Clause. RF-DETR-B and RT-DETR-L are generally Apache-2.0, but with a catch: the actual terms can depend on the specific distribution or package. RT-DETR's original Baidu release is Apache-2.0, while other implementations may differ. The practical conclusion offered is to verify the licence of the specific implementation, package and weights you intend to ship, rather than trusting the architecture name alone.
The author has also built an interactive viewer that shows bounding boxes, confidence scores, measured latency and licence information for each model across the 48 scenes, with a free demo available and segmentation and pose-estimation comparisons planned next.
Why it matters
For teams selecting a detection model for production, the benchmark makes three practical points. First, published latency numbers are not portable: differences in hardware, precision and optimisation can shift measured speed by an order of magnitude. Second, rankings are unstable across conditions — a model that wins on its own project page may not win on your GPU, so shortlists should be re-measured on target hardware with a consistent method. Third, licence terms belong in the selection criteria from the start: an AGPL-3.0 model that is fastest on paper may be unusable in a closed-source commercial product regardless of speed, while a permissively licensed alternative may cost only a few milliseconds.
- #object-detection
- #benchmarks
- #computer-vision
- #deep-learning
- #gpu