CABiNet (ICRA 2021) vs YOLO26-sem on UAVid: accuracy, compute, and GPU latency [P]

Disclosure up front: I'm the original first author of CABiNet (ICRA 2021), so I'm not a neutral party. Everything below is reproducible from the repo.

CABiNet is a dual-branch CNN for real-time semantic segmentation: a high-res spatial branch, a lightweight context branch (global aggregation + local distribution) over a MobileNetV3 backbone, fused with a small FFM. Published 2021, then it went quiet.

I came back this year, rebuilt the repo (PyTorch 2.x, Hydra, AMP, EMA, poly-LR, OHEM loss, CI + tests), and used it to ask one question on UAVid, the aerial dataset the original paper targeted: how does a purpose-built 2021 efficient architecture compare to a 2026 general multi-task model with a dedicated semantic-segmentation variant?

Both models run off the same converted dataset and splits, the same ENet inverse-log class weighting (cls_pw=0.5), EMA weights for eval, and the same evaluation protocol: single-scale, no test-time augmentation. What is not matched:

| Axis | CABiNet | YOLO26-sem | Potential advantage | | --- | --- | --- | --- | | Initialization | ImageNet-pretrained MobileNetV3 backbone; seg layers random | full net pretrained on Cityscapes + ADE20K | potentially favors YOLO | | Epoch budget | 5000 (early stop, patience 100) | 500 (early stop, patience 50) | potentially favors CABiNet | | Optimizer / schedule | SGD + poly decay, decoder LR ×10 | SGD + cosine | different | | Loss | OHEM-CE + aux deep supervision | CE + Dice + aux | different | | Extra augmentation | none | mosaic 0.8, copy-paste 0.15 | potentially favors YOLO |

So this is not an architecture-only ablation. It's a controlled benchmark: the data representation, class weighting and evaluation are standardized, while each model keeps a model-specific training recipe. None of the rows above is an isolated experiment, so I haven't measured how much any single one is worth.

| Model | mIoU (%) | Params (M) | FLOPs (G) | FP16 latency* | FP16 FPS | | --- | --- | --- | --- | --- | --- | | CABiNet (MobileNetV3-L) | 67.14 | 9.17 | 54.8 | 4.44 ms | 225 | | CABiNet (MobileNetV3-S) | 65.25 | 5.36 | 44.1 | 3.09 ms | 324 | | YOLO26x-sem | 64.41 | 40.16 | 430.9 | 13.09 ms | 76 | | YOLO26l-sem | 63.28 | 17.87 | 192.4 | 7.54 ms | 133 | | YOLO26m-sem | 61.98 | 14.32 | 152.3 | 5.71 ms | 175 | | YOLO26s-sem | 61.69 | 6.50 | 44.4 | 2.52 ms | 396 | | YOLO26n-sem | 58.17 | 1.63 | 11.4 | 2.23 ms | 449 | *\*RTX 4070 SUPER, batch 1, pure model forward pass (no pre/post), 200 iters after 30 warmup, measured by me. Params are architecture-only; FLOPs are analytic forward-pass at 1024² (thop for CABiNet, Ultralytics profiler for YOLO26; both report FLOPs = 2×MACs).*

The dashed line is the accuracy/latency Pareto frontier: YOLO26n and YOLO26s sit on it as legitimate lower-latency points, while YOLO26m/l/x are dominated, each being both slower and less accurate than at least one CABiNet variant. CABiNet occupies the higher-accuracy end of the frontier.

- Near-iso-compute: CABiNet-S vs YOLO26s. ~44 GFLOPs each (44.1 vs 44.4), CABiNet-S has slightly fewer params (5.36M vs 6.50M), and they're within 0.6 ms on this GPU, yet CABiNet-S is +3.6 mIoU (65.25 vs 61.69). YOLO26s is still the faster model, so this is a clean accuracy/latency trade, not a universal win.

- Higher-accuracy end: CABiNet-L vs YOLO26x. CABiNet-L is +2.7 mIoU and ~3× lower forward latency (4.44 vs 13.09 ms). It's not that CABiNet is the fastest model (YOLO26n/s are faster); it's that it reaches higher accuracy without moving into the latency/compute regime of YOLO26m/l/x.

- Not universally better. On VDD and AeroScapes (same matched eval), YOLO26 s-and-up pull ahead of CABiNet-Large, which lands mid-pack there. Numbers and configs in the repo.

MobileNetV3's depthwise convs are FLOP-cheap but not GPU-latency-cheap, which is why the frontier looks the way it does. The story is accuracy per millisecond at the higher-accuracy end, not " smallest and fastest. "

Where the +2.7 mIoU comes from. Per-class IoU on the UAVid test split, matched single-scale:

| Class | CABiNet-L | YOLO26x-sem | Δ | | --- | --- | --- | --- | | Human | 28.3 | 21.1 | +7.2 | | Static Car | 57.2 | 51.3 | +5.9 | | Moving Car | 71.9 | 66.8 | +5.1 | | Tree | 80.3 | 78.2 | +2.1 | | Vegetation | 64.1 | 63.3 | +0.8 | | Road | 80.3 | 79.8 | +0.5 | | Clutter | 67.8 | 67.3 | +0.5 | | Building | 87.1 | 87.4 | −0.2 |

The gap is almost entirely the small / thin classes: people and vehicles. On the big region classes the two are within half a point, and YOLO26x is marginally ahead on Building.

Two UAVid test frames, both single-scale; columns are input · YOLO26x-sem · CABiNet-L · ground truth. Row 2 shows a failure mode behind the Static-Car number: YOLO26x collapses the parking-lot structure into one Static-Car/Clutter mass and bleeds Building into the lot, while CABiNet-L tracks the ground truth more closely. These two frames were chosen to illustrate the per-class differences above, not as a representative random sample.

- UAVid only (see point 3 above). The VDD / AeroScapes numbers and configs are in the repo; I'm leading with UAVid because that's where the result is clean, not hiding the rest.

- Single training run per config: no seed sweep, no variance estimate. The observed ~2.7 mIoU CABiNet-L vs YOLO26x gap is large relative to the smaller differences in this table, but I haven't established statistical significance. I wouldn't over-read anything under ~1 point.

- Latency is a clean-room forward pass on one consumer GPU. No TensorRT/ONNX, no Jetson, no full-frame sliding-window cost (UAVid source frames are 4K; CABiNet tiles, YOLO resizes, so end-to-end numbers would differ). Read these as model-level GPU measurements, not deployment throughput.

- The initialization is asymmetric: YOLO26-sem starts from Cityscapes + ADE20K pretraining, CABiNet only from an ImageNet-pretrained backbone. This likely gives YOLO26 a transfer learning advantage on aerial data, though its magnitude isn't measured here. CABiNet reaching higher UAVid accuracy from the less domain-specific start is part of what makes the result interesting, but it stays a confound.

- Weights (CABiNet-L/S + all YOLO26-sem sizes) on Hugging Face, with model cards + metrics

- Live demo (UAVid): run any checkpoint on your own aerial image at https://huggingface.co/spaces/dronefreak/uavid-aerial-segmentation

The criticism I'd most like: is standardizing the data representation, class weighting and evaluation, while letting each model keep its native training recipe, a useful way to compare architectures from different lineages? If not, what would you standardize or change instead?