A tracker flickers IDs on a distant vehicle and the first instinct is to blame the tracker. Nine times out of ten, in the pipelines we have debugged, the tracker never had a stable detection to work with. The object was too small in a downscaled frame, YOLO returned a low-confidence box on some frames and nothing on others, and the association logic had no consistent evidence to hold an ID. The fault lived one stage upstream, in the detector. SAHI — Slicing Aided Hyper Inference — is the intervention that addresses this directly. Instead of running YOLO once over a downscaled full frame, SAHI tiles the high-resolution image into overlapping slices, runs the detector on each slice at close to native scale, and merges the results back into a single full-frame prediction with non-maximum suppression. Small objects that would have collapsed below the confidence threshold at full-frame resolution get a fair chance because the detector sees them at a sensible pixel size. That is the whole idea, and the rest of this article is about why it works, what it costs, and how to prove it helped the thing you actually care about. Why small objects fall below the confidence threshold Detectors do not fail on small objects because the objects are hard to recognise in principle. They fail because of what happens to those objects before inference. A 4K feed pushed through a YOLO model with a 640-pixel input is downscaled by roughly a factor of six on each axis. An object that occupied 40 pixels in the source frame is now a 6- or 7-pixel smudge. The convolutional backbone has almost no signal to work with, and the confidence score the detector emits drops accordingly — often below whatever threshold the pipeline uses to accept a detection. This is not a tuning problem you can solve by lowering the threshold. Drop the threshold far enough to catch the smudge and you flood the pipeline with false positives on everything else. The information loss happened at the resize step, and no amount of post-hoc thresholding recovers it. The signal is gone before the network sees it. The naive framing treats this as acceptable collateral — distant objects get missed, that is the nature of the feed — and then, when tracking degrades, attributes the degradation to the tracker. That misattribution is the expensive part. Teams spend weeks tuning association gates, Kalman filter parameters, and re-identification embeddings to fix a symptom whose cause is that the detector never produced a stable box to associate. The tracker is doing exactly what it was told to do with the evidence it was given. How SAHI slicing works, step by step SAHI reframes the resolution problem as a geometry problem. Rather than shrink the frame to fit the detector, it cuts the frame into pieces that already fit. Slice. The full frame is divided into a grid of overlapping tiles — for example, 640×640 slices with a 20% overlap ratio. Each tile is close to the detector’s native input size, so objects inside it are near their original pixel scale. Infer per slice. YOLO runs on each slice independently. A distant object that was a 6-pixel smudge in the downscaled full frame is now a 40-pixel object inside its slice, well within the range the model was trained on. Translate coordinates. Each slice’s detections carry slice-local coordinates. SAHI maps them back into the full-frame coordinate system by adding the slice’s offset. Merge. Objects that straddle a slice boundary get detected in two or more overlapping tiles. Non-maximum suppression (or the greedy NMM variant SAHI supports) collapses these duplicates into a single box using intersection-over-union to decide which detections describe the same object. The overlap ratio matters more than people expect. Without overlap, an object sitting on a slice seam is bisected and may be detected as two partial objects, or missed entirely because neither half looks like a complete instance. Overlap guarantees that every object appears whole in at least one slice. That guarantee is exactly what the merge step then has to de-duplicate — which is why NMS is not an afterthought here but a structural requirement of the approach. Where does NMS come into merging sliced detections? NMS is doing two distinct jobs in a SAHI pipeline, and it helps to keep them separate. Within a single slice, YOLO already applies NMS to suppress overlapping proposals for the same object — that is standard detector behaviour. The SAHI-specific job happens after coordinate translation, across slices: the same physical object detected in two overlapping tiles produces two full-frame boxes with high mutual IoU, and the cross-slice merge step suppresses the weaker one. If you skip or misconfigure this cross-slice merge, small-object recall looks great but your box count roughly doubles along every slice seam, and a downstream tracker will treat those seam duplicates as separate tracks. What SAHI actually costs The recall gain is not free, and the cost is the whole reason SAHI has to be a deliberate decision rather than a default wrapper call. Running the detector on nine slices instead of one frame is, to a first approximation, nine forward passes instead of one. In configurations we have profiled, the per-frame latency scales close to linearly with slice count once you account for batching and overlap overhead — a 3×3 slice grid lands in the neighbourhood of an order of magnitude more detector compute per frame than a single pass. This is an observed pattern across the pipelines we have instrumented, not a fixed benchmark; the exact multiplier depends on your GPU, batch strategy, and how tightly the slices pack. Both sides of this trade are instrumentable, which is what makes the decision tractable. Slice count and overlap are knobs; per-frame latency and small-object recall are measurements. You are not guessing whether the extra compute is worth it — you are reading it off a plot. The engineering discipline here is the same one that governs real-time detection throughput budgets: decide the latency budget first, then find the slice configuration that maximises recall inside it. Decision table: when to reach for SAHI Situation Reach for SAHI? Better first move High-res feed, objects of interest are tiny relative to frame Yes — this is the design case — Objects already occupy a healthy fraction of the frame No Single-pass YOLO is fine; slicing adds latency for no recall gain Recall is fine but boxes are loose No Tune the detector or its input resolution, not slicing You can raise the camera’s effective resolution on the object cheaply (optical zoom, closer mount) Usually not Fix the optics — it costs no inference latency Small-object recall matters and you have latency headroom Yes Sweep slice count against your latency budget Hard real-time budget already saturated by a single pass Not yet Reduce model size or upgrade compute before adding slice overhead The row that teams skip is the optics one. If a distant object is small because the camera is poorly placed or under-resolved, the cheapest fix is upstream of any model. SAHI is the right lever when the resolution is genuinely there in the frame and the detector is throwing it away at the resize step — not when the resolution was never captured. How improving detection upstream quiets the tracker Here is the payoff the CCU framing insists on: SAHI is a detector-side intervention with a tracking-side effect, and the two stages are independently observable. A tracker maintains an object’s identity by associating each frame’s detections with existing tracks. When the detector produces a stable, above-threshold box on a small object frame after frame, association is easy and the ID holds. When the detector produces a box on frame 1, nothing on frames 2 and 3, and a low-confidence box on frame 4, the track’s motion model coasts through the gaps, drifts, and eventually the association gate rejects the reappearing detection as a new object — a classic ID switch, or, if the gap is short but frequent, track fragmentation. Recovering small-object recall attacks that mechanism at its root. More consistent detections mean fewer gaps for the motion model to coast through, which means fewer opportunities for the association logic to lose the thread. This is why we push teams to treat detection and tracking as distinct, independently observable stages rather than a monolithic “tracking system.” You can measure detection recall on small targets with the detector alone, in isolation, before the tracker ever runs. If recall on the class you care about was 0.4 single-pass and 0.7 sliced, you have quantified the lever independently of whatever the tracker does with it. How do I know SAHI improved tracking, not just detection counts? This is where teams get burned. Slicing inflates detection counts — that is what it is supposed to do — and it is tempting to read a higher detection count as success and stop there. But a higher detection count that includes seam duplicates, or that helps object classes you do not care about, or that arrives too late to fit the latency budget, has not necessarily improved anything downstream. The detection count is an intermediate metric; the tracking outcome is the real one. Measure the end-to-end result with tracking metrics, not detection metrics: MOTA (Multiple Object Tracking Accuracy) captures misses, false positives, and ID switches in one number. If SAHI recovered real small-object detections and the tracker held their IDs, MOTA moves up. IDF1 weights identity preservation specifically. It is the metric that most directly reflects whether the ID-switch problem you set out to fix actually got fixed. ID switches and fragmentation counts are the direct symptoms; watch them fall on the specific object class SAHI was meant to help. Run the comparison as a controlled swap — same footage, same tracker configuration, single-pass detector versus SAHI-sliced detector — and read MOTA and IDF1 on both. If detection recall on small objects went up but IDF1 did not move, either the merge step is producing seam duplicates the tracker is choking on, or the missed detections were never the true cause of the ID switches. Both are useful findings, and both are invisible if you only count boxes. The general discipline of choosing the right detection and tracking metric for the question you are asking is worth internalising before you run any of this — it is the difference between reading detection metrics that describe your actual failure and reading ones that merely look like they improved. FAQ How should you think about sahi yolo in practice? SAHI (Slicing Aided Hyper Inference) tiles a high-resolution frame into overlapping slices, runs YOLO on each slice at close to native scale, translates each slice’s boxes back into full-frame coordinates, and merges the results with non-maximum suppression. In practice it means small or distant objects that would collapse below the confidence threshold in a downscaled full-frame pass are detected because the detector sees them at a workable pixel size. It is a detector-stage lever, applied before any tracking happens. What problem does SAHI solve that a single-pass YOLO inference misses — and why do small objects fall below the confidence threshold? A single-pass YOLO downscales the whole frame to the model’s input size, so a small object loses most of its pixels at the resize step and the backbone has almost no signal to work with. The detector’s confidence on that object drops below the acceptance threshold, and lowering the threshold to catch it only floods the pipeline with false positives. SALI solves this by running the detector on native-scale slices instead of a shrunken whole frame, so the object arrives at inference at a size the model was trained on. How do slice size and overlap affect detection recall versus per-frame inference latency? More slices means more objects seen at native scale, so recall rises — but each slice is roughly a separate forward pass, so per-frame latency scales close to linearly with slice count in the configurations we have profiled. Overlap protects objects sitting on slice seams from being bisected or missed, at the cost of extra duplicate detections the merge step must resolve. Both recall and latency are instrumentable, so slice count and overlap are chosen by sweeping against a latency budget, not by guessing. How does merging sliced detections back into a full-frame result work, and where does NMS come into it? Each slice’s detections are in slice-local coordinates; SAHI adds the slice offset to translate them into the full-frame coordinate system. Objects that straddle a slice boundary get detected in multiple overlapping tiles, producing duplicate full-frame boxes with high mutual IoU. Non-maximum suppression across slices collapses those duplicates into one box — this cross-slice merge is separate from the per-slice NMS YOLO already runs, and skipping it doubles box counts along every seam. How does improving small-object detection upstream reduce ID switches and track fragmentation in the tracking stage? A tracker holds an object’s identity by associating consistent detections frame to frame; gaps force the motion model to coast, drift, and eventually reject the reappearing object as new — an ID switch or fragmentation. Recovering small-object recall fills those gaps, giving the association logic stable evidence to hold the track. Because detection and tracking are independently observable stages, you can measure the recall gain on the detector alone before the tracker ever runs. When is SAHI worth its latency cost, and when should you fix the detector or resolution instead? SAHI is worth it when the resolution genuinely exists in the frame but the detector throws it away at the resize step, small-object recall matters, and you have latency headroom. It is the wrong move when objects already fill a healthy fraction of the frame, when the fix is cheaper optics (closer mount or optical zoom), or when a single pass already saturates a hard real-time budget. In those cases, fix the detector, the input resolution, or the camera placement first — none of those add per-frame inference latency. How do I measure whether SAHI actually improved end-to-end tracking results rather than just detection counts? Run a controlled swap on the same footage with the same tracker — single-pass detector versus SAHI-sliced detector — and read tracking metrics, not detection counts. MOTA captures misses, false positives, and ID switches together; IDF1 reflects identity preservation specifically; watch ID-switch and fragmentation counts fall on the target class. If detection recall rose but IDF1 did not move, the merge step is producing seam duplicates or the missed detections were never the real cause of the switches. What a defensible choice looks like here SAHI is one of the cleaner examples of a principle we return to often: the cheapest way to fix a downstream symptom is frequently to instrument the stage above it. Before adding slice overhead to a pipeline, the honest question is not “will SAHI help?” but “is the detection stage independently observable and tunable, and does the missed-small-object problem actually live there?” Our computer vision engineering practice is built around answering that kind of attribution question before committing compute to a fix — because a slicing configuration chosen against a measured latency budget and confirmed against IDF1 is engineering, while a blind wrapper call bolted onto a pipeline is just hope with more GPU hours attached. The open question worth sitting with: if slicing recovers the recall but IDF1 still refuses to move, is your tracker’s association gate too tight for the newly recovered detections, or were those detections never the thing breaking your IDs in the first place? You cannot answer that by counting boxes — only by keeping detection and tracking as two stages you can measure apart.
