To hit 30 fps on a camera stream, would you channel-prune your trained detector or train a narrower one?

## Frame the question properly The constraint is fixed: frames arrive at 30 per second and the detector must keep up, one frame at a time. The question is which route to a model that fits gives the best detection quality for the engineering budget you have. There are three routes — prune the trained detector and fine-tune, train a narrower architecture from scratch, or train a smaller model with distillation from the big one — and the interviewer wants your decision procedure, not a slogan. ## What pruning actually buys Structured pruning gives you two things: a **width configuration** discovered from a trained model, and a **warm start** in the surviving weights. The important research result to know is that for structured pruning, retraining the resulting narrow architecture from random initialization with a full training schedule frequently matches, and sometimes beats, fine-tuning the inherited weights. The implication is that most of the value sits in the discovered shape. Pruning is best understood as a fast architecture search that uses importance scores instead of a search loop — which is a genuinely useful thing, and cheaper than any explicit search. That reframing kills the usual bad argument ("the inherited weights carry knowledge we must not throw away") and replaces it with a concrete question: do I have the compute and the data to train the narrow shape properly, or not? ## The factors that decide it **Do you still have the data and recipe?** Frequently the trained detector is inherited, the dataset is partially unavailable, and nobody has the augmentation and schedule that produced it. Then from-scratch training is not on the table, and pruning with a modest recovery set is the pragmatic answer. Say this out loud in an interview; it is the most common real-world constraint. **How large is the gap?** A 1.3x speed-up is a shallow cut; prune, fine-tune briefly, ship. A 5x or 10x gap is a different exercise: at those ratios a pruned backbone is a mutilated version of a design that was never meant to be that narrow, whereas a compact architecture designed for the regime — or a smaller model distilled from the big one — starts from a healthier point. **Where is the time actually going?** Measure before you choose. If the frame budget is being eaten by the input pipeline, resizing, decoding, letterboxing or post-processing such as non-maximum suppression, then narrowing the backbone buys almost nothing and the whole compression project is misdirected. Likewise, if the layers are memory-bandwidth bound, removing multiplies changes little. Width cuts, depth cuts (removing whole residual blocks, which also removes the fixed per-layer overhead) and input-resolution cuts are three different levers with different conversion rates into wall-clock, and resolution is often the most brutal-but-effective one for detectors. **What is the accuracy floor?** Fix it *before* pruning, in the metric the product actually cares about, and check it after recovery training. Detectors degrade unevenly: mean average precision can hold while small-object recall — often the thing the camera deployment exists for — falls off a cliff. Report the breakdown, not just the headline number. **What does each option cost to maintain?** A pruned artifact is a derived thing. Every time the base detector is retrained on new data, someone must re-run the pruning, the recovery training and the device timings. A single narrow architecture, trained by the normal pipeline, is one model with one recipe. Over a year of retraining cycles, that maintenance difference often dominates the one-off accuracy difference — and it is exactly the tradeoff a lead is expected to own. ## A defensible default Profile on the target device first and confirm the model, not the pipeline, is the bottleneck. Prune and fine-tune as the first attempt, because it is cheap and it tells you which widths the task actually needs. If it clears the frame budget within the accuracy floor, ship it. If it does not, use the discovered widths as the specification for a proper from-scratch run, add distillation from the unpruned detector, and consider taking part of the budget from depth or input resolution rather than from width alone. Whatever you ship, quote latency measured on the deployment device at batch size one and accuracy measured after recovery training.