A YOLO model publishes an mAP of, say, 0.91 on its benchmark set, and the temptation is to read that number as a promise about your line. It is not. That number describes how a specific network performed on a specific dataset under specific evaluation rules — none of which are your defect set, your camera, or your conveyor. The gap between the benchmark and the line is not noise. It lives inside the inference stage, and if you treat inference as a solved detail, that gap will surface as false rejects, missed defects, or a pipeline that cannot keep up with the belt. So the useful question is not “which YOLO variant has the highest mAP?” It is “what does YOLO inference actually do at runtime, and how does each thing it does interact with my line?” Answer that, and the published accuracy stops being a headline and becomes something you can reason about, tune, and size hardware against. How does YOLO inference actually work? YOLO — “You Only Look Once” — is a single-pass detector. Unlike the older two-stage family (region proposal, then classification), YOLO runs one forward pass through a convolutional backbone and prediction head, and emits a dense grid of candidate boxes in a single shot. Each candidate carries a class prediction and an objectness/confidence score. That single-pass design is the reason YOLO is the default for line-rate inspection: it trades some of the localisation precision of a region-proposal network for a latency profile that fits a moving conveyor. But the forward pass is only the first of three things that happen at inference time, and the other two decide what you actually see. After the network produces its raw grid of candidates, two post-processing steps run: Confidence thresholding discards every candidate whose score falls below a cutoff you set. Raise it and you suppress marginal detections; lower it and you keep more, including noise. Non-max suppression (NMS) collapses overlapping boxes that describe the same object into one, keeping the highest-scoring box and removing its neighbours based on an IoU (intersection-over-union) overlap threshold. Here is the part teams miss: these two thresholds are not model weights. They are runtime knobs, set by you, and they move the operating point of the exact same trained network. Two teams can deploy an identical YOLO checkpoint and get materially different false-positive rates purely from how they set confidence and NMS. The trained model defines a range of possible behaviours; the inference configuration selects the one you run in production. This is why we treat inference behaviour as a first-class engineering concern rather than a detail downstream of training — the same idea underpins how an image detection model works in industrial inspection, where the runtime stage does the operational work. What do confidence thresholds and non-max suppression control on a production line? On a line, “accuracy” is not one number — it is a trade-off between two failure modes with very different costs. A false positive flags a good part as defective; on a high-volume line each one either triggers a needless reject or pulls an operator to a manual re-check. A false negative lets a real defect through to the customer. The relative cost of these two is a business decision, not a modelling one, and confidence thresholding is the primary lever that sets where you sit between them. Raising the confidence threshold cuts false positives but eventually starts dropping genuine defects that the model scored with low confidence — often the subtle, borderline defects that matter most. Lowering it recovers those defects at the cost of more spurious flags. NMS interacts with this: if your IoU overlap threshold is too aggressive, two genuinely adjacent defects (say two nicks close together on a stamped part) can be merged into one detection, and you undercount. Too permissive, and a single defect fragments into several boxes, inflating your apparent defect count. The correct framing is to tune these against a measured false-positive ceiling — the maximum spurious-reject rate the line can absorb without hurting throughput or operator trust — rather than shipping library defaults. In our experience across industrial CV engagements, the default 0.25 confidence and 0.45 NMS IoU that ship with most YOLO implementations are almost never the right operating point for a specific defect set; they are reasonable starting values for a generic benchmark, which your line is not. (This is an observed pattern from deployment work, not a benchmarked constant.) Why does a YOLO model’s published mAP rarely match detection rates on your own defect set? Mean average precision is computed by sweeping the confidence threshold across its whole range and integrating precision against recall over the benchmark’s object classes. It is a summary of the model’s behaviour across all operating points on that dataset. Your line runs at exactly one operating point, on your defect classes, under your lighting. Three things break the transfer: Domain shift. The benchmark’s images are not your parts under your factory lighting, with your camera’s resolution and your motion blur at belt speed. A model that separates classes cleanly on COCO-style data can lose margin on low-contrast surface defects it never trained to distinguish. Class imbalance and rarity. mAP averages over classes. If your critical defect is rare and visually subtle, strong average precision can coexist with weak precision on the one class you care about most. The headline number hides it. Single-operating-point reality. mAP integrates over thresholds you will never run. Your production detection rate is precision and recall at your chosen confidence, not the area under the curve. This is exactly why the metric deserves its own careful reading — what mean average precision means for inspection accuracy on the line differs from what it means on a leaderboard, and what mAP@50 means for defect detection is a narrower, more line-relevant reading than the full curve. The practical move is to re-measure on your own labelled defect set at your intended operating point, then decide whether the model needs retuning or fine-tuning YOLO for your manufacturing-line defect detection — and to be clear-eyed about which of those two the gap actually calls for. How does inference latency relate to conveyor speed and line cycle time? Detection quality is only half the constraint. The other half is timing, and it is unforgiving: if a part is in front of the camera for 40 ms and your end-to-end inference takes 55 ms, you are dropping frames regardless of how good the model is. The relevant number is per-frame inference latency measured end to end — capture, preprocessing (resize, normalise, transfer to device), the forward pass, and the post-processing (thresholding plus NMS) — against the line’s cycle time and the field-of-view dwell of each part. A worked example makes the arithmetic concrete. The figures below are illustrative to show the method, not measured values from any specific deployment: Line parameter Illustrative value What it constrains Conveyor speed 0.5 m/s How long each part is in frame Part pitch (spacing) 100 mm Parts per second entering the field of view Parts per second ~5 parts/s Minimum detection rate required Camera frame rate 30 fps Frames available per part Required frames per part 2–3 Redundancy against motion blur / partial views End-to-end latency budget ~33 ms/frame 1 / frame rate If sustained end-to-end inference fits inside roughly 33 ms per frame at 30 fps, the pipeline keeps up. If it does not, you have three levers: reduce input resolution (which can cost accuracy on small defects), choose a lighter YOLO variant, or add hardware. The single most common mistake we see is budgeting only the forward-pass time — which a runtime like TensorRT reports cleanly — while ignoring preprocessing and NMS, which can dominate at high candidate counts. NMS in particular scales with the number of surviving boxes; a low confidence threshold that keeps thousands of candidates can make post-processing, not the network, your bottleneck. The real-time object detection on the production line picture only closes when you account for the whole chain. What hardware does sustained YOLO inference throughput require? The word that matters here is sustained. A GPU’s transient peak — the number you get from a single warm inference in a benchmark loop — tells you very little about what happens when the same device runs continuously for a shift, sharing a PCIe bus, feeding a preprocessing pipeline, and thermally throttling under a real duty cycle. What you size against is sustained throughput at your operating point, with your resolution, your batch size (often 1 for latency-bound single-camera lines), and your post-processing load included. In configurations we have worked with, an optimised inference stack matters as much as the raw device: exporting a YOLO checkpoint to ONNX and running it under NVIDIA TensorRT with the appropriate precision (FP16, or INT8 where the defect set tolerates the quantisation loss) typically shifts the achievable per-frame latency substantially compared with an unoptimised PyTorch forward pass. That is an engineering intervention on the software stack, not a hardware upgrade. Batch strategy, CUDA stream overlap between capture and compute, and where NMS runs (on-device versus CPU) all move the sustained number. Sizing hardware from a spec sheet’s TOPS figure, without measuring the whole pipeline at load, is how teams end up over-provisioned on paper and under-provisioned in the cell. How do you tune inference for a false-positive ceiling without sacrificing recall? This is where the pieces come together, and it is a procedure, not a setting. The goal is to find the confidence and NMS configuration that holds false positives under your line’s ceiling while keeping defect recall as high as that ceiling allows. Use this checklist against your own labelled data, not a benchmark: Fix the ceiling first. Decide the maximum false-positive rate the line can absorb — measured in spurious rejects per hour or per thousand parts — as a business input. Measure on your defect set. Run inference over a representative, labelled sample from your line at production resolution and lighting. Do not use the training benchmark. Sweep confidence, plot precision–recall. For each threshold, record precision and recall per defect class, not just averaged. Watch the class you care about most. Set NMS by defect geometry. Choose the IoU overlap threshold from how close genuine distinct defects appear on your parts — tight for well-separated defects, looser where adjacent defects must stay separate. Pick the operating point at the ceiling. Select the highest-recall configuration whose measured false-positive rate stays under the ceiling from step 1. Re-measure latency at that configuration. A low confidence threshold that maximises recall may inflate candidate counts and blow the per-frame latency budget through NMS. Confirm timing holds. These are the same three metrics a feasibility audit calibrates before a pilot ever fires: detection rate on the buyer’s defect set at target throughput, false-positive rate at that throughput, and inference latency per frame against cycle time. The tuning is not a one-time chore — the thresholds you land on become reliability artefacts the pilot carries into hardening, and they belong in the computer vision inspection capability record, not in someone’s notebook. FAQ How should you think about YOLO inference in practice? YOLO is a single-pass detector: one forward pass through the network produces a dense grid of candidate boxes, each with a class and a confidence score. Two runtime steps follow — confidence thresholding to discard low-scoring candidates, and non-max suppression to collapse overlapping boxes for the same object. In practice, the same trained model can behave very differently in production depending on how those two runtime knobs are set. What do confidence thresholds and non-max suppression control, and how do they affect false positives on a production line? Confidence thresholding sets the cutoff below which detections are discarded, directly trading false positives against missed defects; NMS controls how overlapping boxes for one object are merged, using an IoU threshold. Raising confidence cuts spurious rejects but can drop subtle real defects, while NMS set too aggressively can merge two adjacent defects into one. Both should be tuned against a measured false-positive ceiling rather than shipped at library defaults. How does inference latency per frame relate to conveyor speed and line cycle time? Each part is in front of the camera for a fixed dwell time set by conveyor speed and part pitch, and the camera delivers a fixed number of frames during that window. End-to-end per-frame inference — capture, preprocessing, forward pass, and post-processing — must fit inside the per-frame budget (for example, roughly 33 ms at 30 fps) or the pipeline drops frames. Budgeting only the forward pass and ignoring preprocessing and NMS is the most common timing mistake. Why does a YOLO model’s published mAP rarely match detection rates on your own defect set? mAP integrates precision against recall across all confidence thresholds on the benchmark’s dataset, whereas your line runs at one operating point on your defect classes under your lighting. Domain shift, class rarity of critical defects, and the single-operating-point reality of production all break the transfer. The reliable move is to re-measure on your own labelled defect set at your intended operating point. What hardware does sustained YOLO inference throughput require for industrial inspection? Size against sustained throughput at your operating point — your resolution, batch size, and post-processing load, running continuously under a real duty cycle — not a device’s transient peak or a spec-sheet TOPS figure. An optimised software stack (ONNX export, TensorRT with FP16 or INT8) often shifts achievable latency as much as a hardware change. The whole pipeline must be measured at load before provisioning. How do you tune inference for a specific false-positive ceiling without sacrificing defect recall? Fix the false-positive ceiling as a business input, then measure precision and recall per defect class on your own labelled data across a confidence sweep, set NMS by defect geometry, and select the highest-recall configuration that stays under the ceiling. Finally, re-check per-frame latency at that configuration, because a recall-maximising low threshold can inflate candidate counts and blow the timing budget through NMS. The result is a measured operating point, not a default. Understanding inference this way is what lets a team ask the honest feasibility question: at my throughput, on my defect set, what detection and false-positive rates are actually achievable — and is the gap a tuning problem or a fundamentally harder one? That is the mechanism a GPU performance and vision-pipeline feasibility assessment is built to quantify per defect class, and it is where the benchmark’s headline mAP finally gives way to numbers you can commit to.
