CloudSignal AI

Blog

Real-time detection in the attention era: YOLO grows up

By Ashwin Rajendraprasad Computer Vision

For the better part of a decade, real-time object detection meant one thing: a convolutional YOLO. Transformers were the accurate-but-slow option you didn’t reach for when frames were on the clock. YOLOv12, an attention-centric detector from Tian et al. (arXiv:2502.12524), challenges that split by making attention fast enough to hold a real-time budget. Here’s what actually changed, and the less glamorous stuff (versions, licensing) that decides whether you should care.

The 33-millisecond budget

Start with the constraint that defines “real-time,” because it’s a product decision before it’s a research one. To hold 30 frames per second you have about 33 milliseconds per frame. That budget is camera-to-decision, everything included: capture, preprocessing, the forward pass, post-processing, and whatever your application does with the result. The model’s inference time is only a slice of it.

That framing is why detector choice is rarely about the top of a leaderboard. A model that’s two points more accurate but blows the frame budget on your target hardware ships nothing. Everything below should be read against that clock.

Why attention was too slow, and the two ideas that fixed it

Attention is the mechanism behind the transformer: every location in the image can, in principle, attend to every other location. That global view is exactly what makes attention powerful. Naively, it’s also what makes it expensive. Full self-attention scales quadratically with the number of image locations, which is fine for a language model’s tokens and brutal for a dense grid of image features on a latency budget. That cost is why real-time detection stayed convolutional for so long.

YOLOv12’s contribution, per the paper (arXiv:2502.12524, February 2025, accepted to NeurIPS 2025), is making an attention-centric design run at real-time YOLO speeds. Two ideas carry it. The first is an efficient area attention mechanism, which, as the name suggests, limits attention to local areas rather than the whole image, cutting the quadratic cost while keeping most of the benefit. The second is a redesigned feature-aggregation network (a residual efficient layer-aggregation design) that keeps the network fast to run at depth. The takeaway isn’t the mechanism names; it’s that “attention is too slow for real-time” is no longer a safe assumption.

The version soup

Here’s the part that genuinely confuses teams, and it has nothing to do with architecture. “YOLO” is not a single product from a single group, and the number after it is not a clean version sequence.

Different research groups publish different YOLOs. Ultralytics maintains several of the most widely used ones: YOLOv8, YOLO11, and the confusingly named “YOLO26,” which is Ultralytics’ own model despite the jump in numbering. Other numbered releases (v9, v10, v12, v13) come from separate teams entirely. A higher number does not mean “a newer version of the same thing,” and it does not automatically mean “better for you.” It means a different group published a detector and attached the YOLO name to it.

Practically, this means you cannot shop for a detector by version number. You have to look at who published it, what it was measured on, what the license is, and whether it’s maintained.

In practice we keep a simple mental index: for each candidate, note the publishing group, the license, the last meaningful update, and the hardware its reported numbers were measured on. Four fields, and they tell you more about whether a detector will survive production than its rank on any chart. The version number tells you almost nothing on its own.

Which brings us to the thing that actually bites products.

The licensing reality check

Accuracy is what gets discussed; licensing is what causes the emergency meeting three weeks before launch. Ultralytics’ widely used YOLO models (YOLOv8, YOLO11, YOLO26) are distributed under AGPL-3.0, a strong copyleft license. The releases from other teams are mostly copyleft too. YOLOv12 itself ships under AGPL-3.0 in its own repository, as do YOLOv10 and YOLOv13; YOLOv9 is GPL-3.0. Read the specific LICENSE file for whatever you’re evaluating, but go in expecting copyleft rather than hoping for permissive.

AGPL is not a trap in itself; it’s a well-understood license with clear obligations. The trap is not reading it. AGPL’s network-use provision can reach further than teams expect for a hosted product, and “we’ll swap the license later” is not a plan. Before a detector goes anywhere near production, know its exact license and whether it fits your product and distribution model. For a lot of commercial deployments this single question narrows the field faster than any benchmark. The point is to decide deliberately, not to discover the terms in an audit.

When to upgrade, and when your current detector is fine

The newest detector is not automatically your next detector. Upgrade when you have a concrete reason: your current model misses the latency budget on real hardware, misses classes you now need, or charges an accuracy tax you can measure and that matters to the product. “There’s a higher number out” is not a reason.

If your existing detector clears its budget on your worst target device, holds its accuracy on your real data, and carries a license you can live with, the highest-value move is usually to leave it alone and spend the effort on data and evaluation instead. A retrained older architecture on better data routinely beats a drop-in newer one on default weights. And every upgrade carries a cost beyond the swap (re-validation, re-calibration, a fresh set of failure modes to learn), which is real even when the new model is genuinely better.

Choosing a detector for a deployment, not a leaderboard

The practitioner’s version of this whole discussion is short. Pick the detector that clears your latency budget on the device you actually ship, holds accuracy on data that looks like your data, and carries a license you can live with. Attention-centric designs like YOLOv12 are a real advance (they widen the accuracy you can afford inside a frame budget), but the winning choice is still the one that fits your constraints, not the one at the top of a chart drawn on hardware you don’t own.

If your team is picking a detector by leaderboard instead of by constraints, that’s exactly the conversation an architecture review exists to have. And if you haven’t yet chosen a backbone for the tasks feeding that detector, see our earlier note on self-supervised backbones.

Sources / further reading

Written by Ashwin Rajendraprasad for CloudSignal AI.