Three YOLO26 variants — s / n / l — share the exact same deployment chain
(6-class, reg_max=1, int8, march=bayes-e) and the same reg-aware
post-processing. All three bins are committed here; YOLO26s is the default.
All were compiled with identical calibration (max-percentile 0.99995, 20 imgs,
per-tensor) — see ../docs/REPORT_NOTES.md for why max-int8 beat KL / mix.
| model | bin filename | size | MD5 | merged-val mAP50 / mAP50-95 | MOT17 best HOTA | board latency |
|---|---|---|---|---|---|---|
| YOLO26s (default) | best_bpu_bayese_640x640_nv12.bin |
10.75 MB | b438704015efbf46cb392ef9a69afa70 |
0.626 / 0.397 | botsort 53.60 | ~19.4 ms ✅ |
| YOLO26n | yolo26n_bpu_bayese_640x640_nv12.bin |
3.35 MB | a5bcf086 |
0.555 / 0.346 | hybridsort 50.49 | pending |
| YOLO26l | yolo26l_bpu_bayese_640x640_nv12.bin |
26.74 MB | 770c491a |
0.688 / 0.443 | botsort 60.84 | pending |
| field | value |
|---|---|
| input | 1×3×640×640, NV12 at runtime, RGB / data_scale 1/255 |
| classes | 6: person bicycle car motorcycle truck bus |
| reg_max | 1 (direct LTRB box decode — not DFL16) |
| outputs | 6 NHWC tensors: 3 strides × (cls, box) |
| calibration | max-percentile 0.99995, 20 imgs, per-tensor |
YOLO26l gives the strongest detection/tracking but is 2.5× the s bin; expect higher board latency than the s ~19 ms (large model, more BPU ops). n/l use the identical calibration set and config as s — no recipe change, just scale. Board latency for n/l is not yet measured (the X5 was unavailable); only the compile + remote GPU eval is done. Trained on BDD100K + CrowdHuman + MOT17 (rare classes oversampled).
Because reg_max=1, the box output is a 4-dim direct LTRB distance, not a
16-bin DFL distribution. The Python wrapper (ultralytics_yolo_det.py) and the
C++ detector (cpp/yolo_detector.hpp) both branch on reg: reg==1 decodes
via decode_ltrb_boxes, otherwise the DFL16 path is used (back-compatible with
YOLO11). Running a DFL decode on a reg=1 model collapses every box to zero.
| model | bin filename | size | sha256 | input | embedding | board latency |
|---|---|---|---|---|---|---|
| MobileNetV4 joint person+vehicle ReID | mnv4_reid_256x256_nv12.bin |
1.77 MB | 3b05f90760c8a6a862378dbf5e52c10662afce58e0b2567a59ef7696bdb2226a |
256×256 NV12 | 256-d float32 | ~0.35 ms/crop |
| field | value |
|---|---|
| backbone | MobileNetV4 Conv-Small (int8 internal) |
| output | embeddings [1,256] float32 (no dequant needed) |
| BPU nodes | 52 nodes / 0 CPU / single subgraph |
| trained on | BDD100K + CrowdHuman + MOT17 (person+vehicle joint, shared PID space) |
| best mAP | 89.28% / R1 95.88% (epoch 110) |
| intended classes | person(0), car(2), truck(4), bus(5) → ReID features |
| excluded classes | bicycle(1), motorcycle(3) → pure-motion (zero embedding) |
| class routing | v1: single joint model; bicycle/motorcycle get zero embeddings |
The model is committed to this directory (
models/mnv4_reid_256x256_nv12.bin, 1.77 MB) and whitelisted in../.gitignoreso the repo ships with ReID out-of-the-box. The input size (256×256) and embedding dimension (256) are probed at runtime from the.bin— they are not hard-coded in the tracker code. Board latency is ~3.5 ms/crop end-to-end (1.08 ms BPU-only); full speed numbers in../docs/REID_MNV4_BOARD_BENCH.md.
yolo26s_kl_int8_*.bin and yolo26s_mix_int8_*.bin (KL-divergence and
per-layer mix calibration) were evaluated and measured worse than max-int8
on the board (bicycle/motorcycle dropped by KL; car/person −10% by mix despite
higher output cosine). They are git-ignored; keep only the max-int8 bins here.