A wide-angle CCTV camera catches a face at the far end of a corridor. It is maybe 22 pixels tall. Your YOLO detector, running on the full frame downscaled to 640×640, never sees it — and because face detection is the first stage of the recognition pipeline, nothing downstream ever gets a chance. No alignment, no embedding, no match. The subject was in frame the whole time. The system just wasn’t looking at the right resolution. This is the failure that Slicing-Aided Hyper Inference (SAHI) is built to address. Instead of feeding the detector one downscaled copy of the frame, SAHI tiles the image into overlapping slices, runs the detector on each slice at closer to native pixel density, and merges the per-slice detections back into a single frame-level result. Objects that were too small to survive downscaling get a second chance at a scale the model was actually trained to see. The core trade-off is blunt: whole-frame inference is fast and blind to small targets; sliced inference sees them at a multiplied compute cost. Understanding where that line sits — and when paying the multiplier is worth it — is the difference between a recognition system that quietly drops distant subjects and one that doesn’t. How does SAHI YOLO actually work? SAHI is a wrapper around a detector, not a detector itself. It works with YOLO variants, RT-DETR, and other bounding-box models through a common inference interface. The mechanism has three stages. First, slicing: the input frame is divided into a grid of tiles — say 512×512 or 640×640 — with a configurable overlap between adjacent tiles. Overlap exists so that an object straddling a slice boundary still appears whole in at least one tile. Second, per-slice inference: the detector runs independently on each tile. A face that was 22 pixels tall in a 1920×1080 frame is still 22 pixels tall inside its slice, but now the slice is only 640 pixels wide instead of 1920 — so the effective resolution presented to the model is roughly three times higher. The detector sees the face at a scale much closer to its training distribution. Third, merging: detections from all slices are mapped back to full-frame coordinates and de-duplicated. Because overlap means the same object can be found in two adjacent tiles, a merge step — usually a form of non-maximum suppression (NMS) or the greedy NMM variant SAHI ships — collapses duplicate boxes into one. Optionally, SAHI also runs a full-frame pass alongside the sliced passes and merges that in too. This matters because slicing helps small objects but can hurt large ones: a person standing close to the camera might be split across four tiles, and no single tile contains the whole body. The full-frame pass keeps large-object recall intact while the slices recover the small ones. This is the same slicing logic we discuss in the context of slicing inference for small-object detection before tracking, applied here specifically to the face-detection stage. Why whole-frame YOLO misses small or distant faces The root cause is resolution, and it is structural rather than a bug you can tune away with a confidence threshold. A YOLO model has a fixed input size — commonly 640×640. When you hand it a 1920×1080 frame, the frame is downscaled to fit. A 22-pixel face in the original becomes roughly a 7-pixel face after downscaling. At 7 pixels, the discriminative features a face detector relies on — eye spacing, nose bridge, the contrast pattern of a face — are essentially gone. The detector isn’t choosing to ignore the face; the information that would let it fire has been destroyed by the resize. This is why lowering the confidence threshold rarely fixes small-face recall. There is nothing to threshold on. The activation was never strong because the input signal was never there. Turning the threshold down instead floods the output with false positives from texture and noise, which then poison every downstream stage. SAHI sidesteps the problem by never destroying the signal in the first place. Each slice preserves near-native pixel density, so the small face arrives at the detector at a size it can actually resolve. In configurations we’ve tested on wide-angle footage, this is the single largest lever on small-object recall — larger than swapping detector architectures — because it fixes the input, not the model (observed pattern across TechnoLynx CV engagements; not a published benchmark). If you want the mechanics of how the underlying detector produces boxes and scores in the first place, our explainer on how object detection with YOLO works covers the anchor-and-score pipeline that SAHI wraps. What does SAHI’s slicing actually cost? The compute story is the honest counterweight to the recall story. Slicing does not come free, and the cost is predictable enough to budget. The inference-cost multiplier is roughly slices per frame × per-slice latency, plus the merge overhead. If a 1920×1080 frame is cut into a 3×2 grid with overlap, you are running the detector six times (seven, if you add the full-frame pass) instead of once. Per-slice latency is not identical to full-frame latency — each slice is smaller — but the batched total is substantially higher than a single 640×640 forward pass. Here is a worked example with explicit assumptions: Worked example — slicing cost on a 1080p stream Assumptions: 1920×1080 input, 640×640 slices, 0.2 overlap ratio, one full-frame pass added, per-slice inference ≈ 8 ms on the target GPU (illustrative figure, not a benchmark). Grid: roughly 3 columns × 2 rows = 6 slices, +1 full-frame pass = 7 forward passes Naive per-frame compute: 7 × 8 ms ≈ 56 ms (~18 FPS ceiling before merge/overhead) Whole-frame baseline: 1 × ~12 ms ≈ 12 ms (~80 FPS) Net: roughly a 4–5× latency increase to recover sub-30px targets The exact numbers depend entirely on your hardware, batch strategy, and grid — treat the ratio, not the milliseconds, as the transferable lesson. The multiplier is why SAHI is a deployment decision, not a default. On a real-time 30 FPS stream where the payoff is detecting a distant face at all, a 4–5× cost may be entirely justified — a missed detection has infinite recall cost. On a stream where every object is already large and close, slicing burns compute for no recall gain. Understanding what throughput really costs in real-time object detection is the prerequisite to deciding whether your latency budget can absorb the multiplier. When does the slicing trade-off pay off? Use this rubric to decide before you commit engineering time. Condition Whole-frame YOLO SAHI slicing Targets consistently > ~50px in frame ✅ Sufficient ❌ Wasted compute Small or distant targets (< ~30px) matter ❌ Silent misses ✅ Recovers them Wide-angle / high-resolution source (CCTV, drone) ❌ Downscaling destroys signal ✅ Preserves pixel density Hard real-time latency budget, no headroom ✅ Fits ⚠️ Only with aggressive grid tuning Batch / offline processing, recall-critical ⚠️ Under-detects ✅ Best-fit Crowd scenes with dense small faces ❌ Missed subjects ✅ Major recall lift The pattern is consistent: SAHI earns its cost when your source resolution is high, your targets are small relative to the frame, and recall matters more than raw throughput. When those conditions don’t hold, slicing is a liability. How slice size, overlap, and merge settings change results Three parameters do most of the work, and they interact. Slice size sets the effective resolution multiplier. Smaller slices push more pixels toward each object but generate more tiles (higher cost) and risk cutting large objects into fragments none of which is recognizable. A slice size near the detector’s native input (e.g. 640 for a 640-trained YOLO) keeps each tile at the resolution the model expects. Overlap ratio governs boundary safety. A 0.2 overlap means each tile shares 20% of its edge with neighbours, so an object on a seam appears whole in at least one tile. Too little overlap and boundary objects get split and missed; too much and you inflate the slice count and produce more duplicate detections to merge. Merge / NMS settings decide how duplicates collapse. Because overlap deliberately creates redundant detections, the IoU threshold in the merge step controls whether two boxes of the same face fuse into one or survive as a double-count. Set it too strict and you get duplicate faces feeding the pipeline as two subjects; too loose and you can suppress genuinely adjacent objects in a crowd. This is the same precision-recall balancing act covered in our object detection metrics explainer — SAHI just adds a second place where IoU thresholds bite. There is no universal setting. The right grid is a function of your camera geometry, target size distribution, and latency budget, and it is worth measuring on your own footage rather than inheriting a tutorial default. Where SAHI fits in the recognition pipeline A facial recognition pipeline runs in stages: detection → alignment → embedding → matching. Each stage assumes the previous one succeeded. Alignment can only align a face the detector found. The embedding network only produces a vector for a face that was aligned. Matching only compares embeddings that exist. SAHI operates entirely at the detection stage — the first one. This placement is the whole point. A failure at detection is not recoverable downstream; there is no clever matching threshold that recovers a face the detector never emitted a box for. Teams that treat detection as a solved problem and pour tuning effort into the embedding or matching stages are optimizing links in a chain whose first link already broke. When we run a facial-recognition pipeline audit and small-face recall is the failure mode, SAHI is one of the first detection-stage levers we evaluate — precisely because it changes recall at the top, where every later stage inherits the consequences. This is also the connective tissue to hardware accelerators for facial recognition: the slicing multiplier is exactly the workload that determines whether your accelerator budget holds under sliced inference. The full pipeline picture lives on our computer vision practice page. SAHI versus a higher-resolution model or a dedicated small-object detector SAHI is not the only way to recover small objects, and it is not always the best. Raising the model input resolution — training or running YOLO at 1280×1280 instead of 640×640 — preserves more of the small-object signal without tiling. It avoids the merge complexity entirely and keeps large objects whole. But input resolution scales compute quadratically, and beyond a point the model still can’t resolve a truly tiny face; you hit a ceiling that slicing pushes past. A dedicated small-object detector or a model architecture with finer feature-map strides can be more efficient than slicing for a known, fixed target size. The cost is that you are now maintaining and retraining a specialized model, and it may not generalize across the range of object sizes SAHI handles with one wrapper. SAHI’s advantage is that it is a deployment-time wrapper on an existing detector — no retraining, works across architectures, and handles a wide size range in one configuration. Its disadvantage is the per-frame compute multiplier and merge tuning. If your target size is fixed and known, a higher-resolution model or specialized detector may be cleaner; if target sizes vary and you need a fast route to recall on an already-deployed detector, SAHI usually wins. For teams choosing the detector underneath, our RT-DETR vs YOLO comparison is the upstream decision that SAHI sits on top of. Does slicing behave differently across cloud, on-device, and edge? Yes, and the deployment setting often decides whether SAHI is viable at all. In the cloud, the slicing multiplier is a cost line, not a hard wall — you can throw more GPU at seven forward passes per frame, batching slices to keep the accelerator busy. The constraint is dollars per stream, not feasibility. On-device (a workstation or a beefy edge box with a discrete GPU), the multiplier competes directly with your latency budget. A 4–5× cost that was invisible in the cloud can drop you below real-time. Aggressive grid tuning — fewer, larger slices; skipping the full-frame pass when large objects are rare — becomes necessary rather than optional. On a genuinely constrained edge device (an embedded NPU or a low-power SoC), running the detector seven times per frame may simply not fit the frame budget. Here the honest answer is often not SAHI — a higher-resolution model tuned to the exact hardware, or region-of-interest cropping driven by a cheap motion-detection stage, can recover small objects without the full slicing multiplier. The right choice is a deployment-specific engineering trade-off, and it is exactly the kind of question a computer vision consultant scopes when weighing edge deployment trade-offs. FAQ How should you think about SAHI YOLO in practice? SAHI wraps a YOLO (or other) detector: it tiles the frame into overlapping slices, runs the detector on each slice at near-native pixel density, and merges the per-slice detections back into one frame-level result using an NMS-style step. In practice it recovers small or distant objects that would be destroyed by downscaling the whole frame to the model’s input size. Why does whole-frame YOLO miss small or distant faces, and how does slicing-aided inference recover them? A 1080p frame downscaled to 640×640 shrinks a 22-pixel face to roughly 7 pixels, destroying the features a detector needs — lowering the confidence threshold can’t recover information that isn’t there. Slicing preserves near-native resolution inside each tile, so the small face arrives at a scale the model was trained to resolve, restoring the signal rather than tuning the model. What is the latency and compute cost of SAHI’s slicing, and when does the trade-off pay off? The cost is roughly slices-per-frame × per-slice latency plus merge overhead — often a 4–5× latency increase over whole-frame inference for a typical 1080p grid. It pays off when the source is high-resolution, targets are small relative to the frame, and recall matters more than throughput; it is wasted compute when every object is already large and close. How do slice size, overlap ratio, and merge (NMS) settings affect detection recall and false positives? Smaller slices raise effective resolution but multiply cost and can fragment large objects; overlap protects objects on tile seams but inflates slice count and duplicates. The merge IoU threshold decides whether redundant detections of the same face fuse into one or survive as double-counts — too strict double-counts subjects, too loose suppresses genuinely adjacent objects in crowds. Where does SAHI fit relative to the face detection stage of the recognition pipeline? SAHI operates entirely at the detection stage, the first step before alignment, embedding, and matching. Because every later stage assumes detection succeeded, a face the detector never boxed is unrecoverable downstream — which is why detection-stage recall is the right place to intervene when small faces are being missed. When should you use SAHI versus a higher-resolution model input or a dedicated small-object detector? Use SAHI when you need fast recall gains on an already-deployed detector across a range of object sizes, with no retraining. Prefer a higher-resolution model input or a dedicated small-object detector when the target size is fixed and known and you want to avoid the per-frame slicing multiplier and merge tuning. How does slicing-aided inference behave differently across cloud, on-device, and edge deployment settings? In the cloud the multiplier is a cost line you can absorb by batching slices across more GPU. On-device it competes directly with the latency budget and usually needs aggressive grid tuning. On constrained edge hardware seven passes per frame may not fit at all, making a hardware-tuned higher-resolution model or ROI cropping the better route. Slicing changes where the pipeline can fail — it moves the small-object failure from the detection stage, where it was silent and terminal, into a compute-budget decision you can measure and defend. The open question for any specific deployment is not whether SAHI recovers small faces, but whether your latency envelope can hold the multiplier that recovery costs — and answering that means measuring recall and per-frame latency on your own footage, not inheriting a tutorial’s grid.
