Computer vision at 1.5 milliseconds

Small-object detection punishes shortcuts. Targets occupy few pixels, class boundaries can be visually subtle, and a model that looks convincing on a hand-picked image can fail quietly across lighting, scale, or background changes. Deployment adds a second constraint: the useful model must fit the latency and hardware envelope of the real system.

The project covered 25 classes and 43,088 annotated objects. That dataset was not merely a prelude to training. Label inspection, class balance, difficult negatives, augmentation, and split design were treated as parts of the model.

Python, PyTorch, and OpenCV formed a repeatable training and evaluation pipeline. More than thirty iterations per model varied one meaningful factor at a time: input treatment, augmentation, architecture settings, optimization, and post-processing. Results were compared through per-class behaviour and failure images, not only a single aggregate score.

This ablation-style discipline made negative results useful. A change that helped a large or frequent class while erasing a rare small class was visible. The training record became a chain of evidence rather than a folder of checkpoints with memorable filenames.

The selected model was exported through ONNX and checked for numerical and preprocessing parity before optimization. TensorRT then provided the engine-building layer for the target GPU. Precision was an engineering choice, not a checkbox: FP16 delivered the required acceleration while preserving the measured accuracy profile.

INT8 was also evaluated. Its additional compression was not accepted simply because it was faster on paper; the observed accuracy loss made the trade unsuitable. That decision is central to the report: optimization is the search for the best system outcome, not the smallest benchmark number.

The published inference measurement fell from 127.8 milliseconds to 1.5 milliseconds on the deployment path while holding the chosen accuracy target. Timings were separated from loading and warm-up so that the number described inference rather than convenient surrounding work.

Latency was observed as a distribution, with the execution environment and precision recorded beside it. A result without its conditions is an anecdote; a result with a repeatable harness can guide the next design decision.

The lasting skill was not one API. It was learning to keep data quality, model behaviour, export correctness, hardware constraints, and honest measurement in the same mental model. The detector only became a product component when all five agreed.

A fast wrong answer is still wrong. A correct answer that misses its deadline is not deployed.