Ask most teams what a computer vision consultant does and you get some version of the same answer: they pick a model. That framing is where edge projects go wrong before a single line of inference code runs. On the edge, the model is the last decision, not the first — and treating it as the first is why so many pilots miss either their latency target or their accuracy target on the first field test. The real work of a consultant, when the deployment target is a camera on a wall or a box bolted to a machine, is characterising the trade-off envelope: what accuracy is acceptable for a given latency budget, on a specific piece of silicon, under real power and thermal limits. That envelope exists whether or not anyone maps it. Skipping the mapping doesn’t make the constraints go away — it just moves the discovery to production, where fixing it costs a rework cycle instead of a whiteboard session. What does a CV consultant do before selecting a model? Before any model gets shortlisted, a grounded consultant is doing something that looks nothing like ML work. They are mapping the deployment context. Where does the device sit? What is the ambient temperature range, and does that cap sustained clock speed? Is there a power budget — a PoE camera and a fanless gateway have very different envelopes than a mains-powered edge server. What is the input pipeline: is the camera already producing a decoded RGB frame, or is there an H.265 decode step whose cost belongs in the latency budget too? Then come the failure modes the system must survive. A defect-inspection line that stops when the model is uncertain behaves very differently from a retail people-counter that can drop a frame. Naming those failure modes early is what determines the accuracy floor — the point below which the system is not merely worse but actually unsafe or useless for its job. That floor is a business decision dressed as a technical one, and pinning it down is consulting work, not modelling work. Only after that context is on the table does model selection make sense. By then the shortlist is small, because most models are already ruled out by the envelope. A model that needs 8 GB of activation memory is off the table for a device with 4 GB, regardless of its accuracy. This is the coupling the naive view misses: compression technique, hardware target, and network architecture are one decision, not three. Pick a heavy architecture and you have implicitly committed to aggressive quantisation and a beefier target; pick a small target and you have constrained the architecture. Teams that treat these as three separate procurement steps end up with a stack that individually looks fine and collectively misses its numbers. How does a consultant characterise the latency / accuracy / power trade-off? The characterisation is empirical, not theoretical. You cannot read latency off a spec sheet, because the number that matters is sustained inference under the real input rate and the real thermal envelope — not a burst figure measured on a cold device (an observed pattern across edge engagements, not a published benchmark). The way we approach it is to fix two of the three axes and sweep the third. A worked example makes the mechanics concrete. Suppose the requirement is people-counting at a store entrance with a sub-100ms per-frame budget and a tolerated accuracy floor of, say, 92% detection recall on the classes that matter. Assume a fanless NVIDIA Jetson-class device and a 1080p camera feed. Fix hardware and accuracy target; sweep model + precision. Run the candidate detector in FP16, then INT8 via TensorRT, and measure sustained latency at the real frame rate after the device has warmed up. If FP16 lands at ~130ms and INT8 at ~70ms, INT8 is the only option that fits — provided its recall stays above the floor after calibration. Fix hardware and latency; sweep accuracy. If INT8 drops recall below 92%, the questions become: does 4-bit or 8-bit quantisation with proper calibration recover it, or does the architecture itself need to change to a lighter backbone? Fix model and accuracy; sweep hardware. If nothing on the target device fits the latency budget at the required accuracy, the honest answer is that the hardware is wrong — not that the model needs one more round of tuning. These figures are illustrative of the method; the real numbers come from measuring your own model on your own device. The point is that the envelope is discovered by measurement, and the consultant’s job is to run that measurement before committing, not to promise a number and hope. This is closely related to how real-time object detection throughput actually behaves under load, where the gap between a benchmark FPS and a sustained production FPS is often the whole story. Choosing between edge targets: Jetson, Coral, or Intel NCS The target question is where a lot of engagements start, usually phrased as “which edge device should we buy.” It’s the wrong first question — the device falls out of the envelope — but once the envelope is mapped, the comparison becomes tractable. The three families most teams weigh differ less on raw throughput than on what kind of model they run well. Edge target selection rubric Consideration NVIDIA Jetson (Orin/Nano class) Google Coral (Edge TPU) Intel Neural Compute Stick / Movidius Best-fit workload Larger detectors, mixed CV+other, custom CUDA ops Fixed INT8 classification/detection at low power USB add-on to an existing x86/ARM host Software path TensorRT, full CUDA stack, most flexibility TensorFlow Lite, INT8-only, compiled for the TPU OpenVINO toolkit Precision constraint FP16/INT8, flexible INT8 mandatory — model must quantise cleanly INT8/FP16 via OpenVINO Power envelope Higher (needs thermal design) Very low, fanless Low, host-dependent Where it bites Cost and thermal design Models that don’t quantise to INT8 lose too much accuracy Host bottlenecks and USB bandwidth The rubric is not a ranking. Coral is superb when your model quantises cleanly to INT8 and you need minimal power; it is a poor fit when the accuracy floor demands FP16 or an operator the Edge TPU compiler doesn’t support. Jetson buys flexibility and headroom at the cost of power and thermal design. The Intel path suits retrofitting inference onto hardware that already exists. A consultant’s value here is matching the target to the envelope you already mapped, not to a spec-sheet FPS number. If your model won’t quantise to INT8 without falling through the accuracy floor, no amount of Coral’s efficiency helps you. When to recommend on-device, hybrid, or cloud-fallback architecture The architecture decision — where inference physically runs — is the one with the largest cost and reliability consequences, and it is genuinely conditional. There is no default answer. Pure on-device makes sense when latency is hard-real-time, connectivity is unreliable, or data cannot leave the site for privacy reasons. A hybrid split — run a cheap detector on-device to gate, escalate uncertain or high-value frames to a cloud model — makes sense when the on-device model can handle the common case but the tail of hard cases justifies a heavier second stage. Cloud-fallback with local buffering fits when connectivity is usually good but occasionally drops, and the application can tolerate the added round-trip on most frames. The decision turns on three variables: the latency budget, the connectivity reliability, and where the data is allowed to live. Get those on the table and the architecture usually picks itself. This is also where deployment discipline matters more than model accuracy. A model that runs beautifully in the lab and falls over on a flaky 4G link at a remote site has failed, regardless of its mAP. The portability and reliability principles that keep edge CV pipelines deployable are part of the same conversation — a consultant who ignores them ships something that benchmarks well and operates badly. Our approach treats deployment context as a first-class input to architecture, not a downstream integration detail. What deliverables should you expect from a consulting engagement? A grounded engagement produces artifacts you can defend to your own leadership, not a model file and a shrug. Concretely, expect a characterised trade-off envelope (measured latency at your accuracy floor on the candidate hardware), a defensible architecture recommendation with the reasoning behind on-device versus hybrid versus cloud, and a named risk register of the failure modes the system must survive. An engagement of this kind typically opens with a production readiness assessment of which edge deployment is one dimension — the same framing we bring to scoping machine vision engagements from recognition problem to production. You can see how this fits our broader computer vision practice and the way we scope these engagements. FAQ How should you think about a computer vision consultant in practice? In practice, a computer vision consultant maps the deployment context — hardware, power, thermal limits, input pipeline, and failure modes — before choosing a model. On edge projects the model is the last decision, not the first, because most models are ruled out by the envelope before accuracy even enters the conversation. The output is a defensible set of choices, not just a trained model handed back. What does a CV consultant do before selecting a model for edge deployment? They characterise the deployment context: where the device sits, its power and thermal envelope, the input pipeline (including any decode cost), and the failure modes the system must survive. Naming those failure modes fixes the accuracy floor — the point below which the system is useless for its job. Only then does model selection make sense, against a shortlist already narrowed by those constraints. How does a consultant characterise the latency / accuracy / power trade-off for a specific deployment? Empirically, by fixing two of the three axes and sweeping the third — measuring sustained inference on the real device at the real frame rate after warm-up, not a burst figure from a cold start. If INT8 fits the latency budget but drops accuracy below the floor, the questions become whether better calibration recovers it or whether the architecture or hardware has to change. The envelope is discovered by measurement, not read off a spec sheet. How does a consultant choose between edge targets like Jetson, Coral, or Intel NCS for a given constraint set? The target falls out of the mapped envelope, not from a spec-sheet FPS number. Jetson buys flexibility and headroom with CUDA and TensorRT at the cost of power and thermal design; Coral is excellent at very low power when the model quantises cleanly to INT8; the Intel/OpenVINO path suits retrofitting inference onto existing x86 or ARM hosts. If a model won’t hold its accuracy floor after INT8 quantisation, Coral’s efficiency doesn’t help. When does a consultant recommend an on-device, hybrid, or cloud-fallback architecture? The choice turns on three variables: the latency budget, connectivity reliability, and where the data is allowed to live. Pure on-device fits hard-real-time, unreliable connectivity, or privacy-bound data; a hybrid split gates common cases locally and escalates hard ones to the cloud; cloud-fallback with local buffering fits when connectivity is usually good but occasionally drops. Once those three variables are on the table, the architecture usually picks itself. What deliverables should I expect from a computer vision consulting engagement? Expect a characterised trade-off envelope — measured latency at your accuracy floor on candidate hardware — plus a defensible architecture recommendation and a named risk register of the failure modes the system must survive. These are artifacts you can defend to leadership, not a model file. The engagement typically opens with a production readiness assessment of which edge deployment is one dimension. How do I tell a grounded CV consultant apart from a generic AI vendor? A grounded consultant asks about your power budget, thermal envelope, input pipeline, and failure modes before recommending a model; a generic vendor leads with a model or a device. Watch for whether they treat compression, hardware target, and architecture as one coupled decision or three isolated ones — the coupling is where edge systems succeed or fail. If the first deliverable is a model rather than a measured envelope, you’re buying a demo, not a deployment. The sharper question to hold onto, before you sign anything, is this: does the person scoping your edge deployment start from the model, or from the envelope that decides whether any model can fit? That difference is the whole job.
