Optical Inspection for Edge Devices
Vision models running on the hardware at the machine, benchmarked on the actual device rather than a datasheet, within the thermal, power and latency budget the environment really allows.
Edge deployment is where computer vision projects meet physics. A model that runs comfortably on a workstation may not fit in the memory available beside the conveyor, may throttle after twenty minutes in an enclosure, and may need to produce a verdict before the part has moved past the reject gate.
Edge computer vision is the deployment of vision models on hardware at or near the camera rather than in a data centre: selecting and benchmarking the device, compressing the model to fit within memory and power budgets while measuring the accuracy cost, and operating a fleet of devices with monitoring, updates and rollback.
Why deployment moves to the edge
- Latency. A reject decision has to be made before the part passes the actuator. A network round trip does not fit inside that window.
- Bandwidth. Streaming many camera feeds continuously is expensive and frequently impossible on an industrial or remote connection.
- Availability. The line must keep running when the network does not.
- Privacy. Processing images locally and transmitting only results removes an entire category of data protection argument.
- Cost at scale. Beyond a certain number of cameras, dedicated local compute is cheaper than continuous cloud inference.
The trade is engineering effort. Edge deployment is harder to build, harder to update and harder to debug, and those costs are real and ongoing rather than one-off.
How we deliver edge vision
Benchmark on the actual device, early
Vendor throughput figures are measured under conditions you will not have: a different model, a different precision, no other processes, and no enclosure. We benchmark your candidate model on the real hardware in the first fortnight, with sustained load rather than a burst, because the second number is usually much lower than the first.
Compress with the accuracy cost measured
Quantisation, pruning and architecture selection, each evaluated on your validation set rather than assumed to be lossless. Eight-bit quantisation is frequently near-free and sometimes is not, and the only way to know which case you are in is to measure on your own data.
Budget for heat and power
Sustained inference generates heat, and heat causes throttling. A device that hits its target throughput for ninety seconds and half of it thereafter is a support ticket waiting to happen. We measure sustained performance in the enclosure, at the ambient temperature the site actually reaches in summer.
Define the failure behaviour
What the line does when the device fails, when the camera fails, and when the network is down. Fail-safe or fail-open is a business decision, made and documented in advance, with a watchdog that restarts predictably and an alert that reaches someone.
Treat the fleet as infrastructure
Signed model and firmware updates, staged rollout across devices, automatic rollback on failure, and remote monitoring of throughput, temperature and error rates. Updating fifty devices by hand is workable exactly once, and this is the part most commonly under-built.
Keep a sample of images for retraining
A sampling policy that retains a small share of images, particularly the uncertain and rejected ones, so the model can be improved without instrumenting the whole fleet to stream everything. Without this the deployment is frozen at its launch accuracy.
Buy the next size up
Device selection made at the exact limit of the current model's requirements leaves no room for the improved model in six months. The cost difference between adequate and comfortable hardware is almost always smaller than a fleet replacement, and this is the single most common regret in edge deployments.
Choosing the hardware class
| Class | Typical use | Main constraint |
|---|---|---|
| Smart camera with built-in inference | Single fixed inspection point | Very limited model size and flexibility |
| Embedded accelerator module | Line-side inspection, several cameras | Thermal budget and memory |
| Industrial PC with GPU | Multiple cameras, heavier models | Space, power and cost per site |
| Mobile or battery device | Field and handheld inspection | Power draw and thermal above all |
| Gateway aggregating several cameras | Retail, logistics, multi-view sites | Combined throughput across streams |
We recommend a class after benchmarking rather than before, because the requirement that decides it is usually sustained throughput at your resolution rather than anything on a specification sheet.
How the engagement runs
Hardware is benchmarked with your model under sustained load before anything is committed.
Device benchmarking
Candidate model run on candidate hardware under sustained load, with thermal and power measured in a representative enclosure.
Model compression
Quantisation and architecture selection with accuracy measured at each step on your validation set.
Device software
Capture, inference, output integration, watchdog, failure behaviour and local buffering built and tested.
Fleet management
Signed updates, staged rollout, rollback, remote monitoring and the image sampling policy.
Site pilot and handover
Deployment to a pilot site under real conditions, then rollout runbook and handover to your engineering team.
What you receive
Devices that hold their throughput in July, and a fleet you can update without visiting.
Hardware recommendation
Benchmarked on your model under sustained load, with thermal and power measurements.
Optimised model
Compressed for the device with the accuracy cost of each step measured on your data.
Device software
Capture, inference, integration, watchdog and defined failure behaviour, deployed as versioned images.
Fleet management
Signed staged updates with automatic rollback and remote configuration.
Remote monitoring
Throughput, latency, temperature, error rate and drift per device, with alerting.
Sampling policy
Retention of uncertain and rejected images for retraining, within bandwidth and privacy limits.
Is this the right engagement?
Worth being direct. Optical Inspection for Edge Devices is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Latency, bandwidth, availability or privacy rules out cloud inference.
- You will deploy to more than a handful of devices and need to update them remotely.
- Target hardware can be made available for benchmarking early.
- Site conditions including temperature and power are known or measurable.
- Someone will own the fleet operationally after handover.
Choose something else if
- A single site with good connectivity, where cloud inference is simpler and cheaper.
- The model genuinely cannot be compressed to fit any acceptable device.
- No access to representative hardware or sites before deployment.
- Nobody will maintain devices in the field.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How do we choose edge hardware for computer vision?
By benchmarking your actual model on candidate devices under sustained load, in a representative enclosure, at the ambient temperature your site reaches in summer. Datasheet throughput is measured under conditions you will not have, and the sustained figure is usually considerably lower.
How much accuracy do we lose from quantisation?
Often very little, sometimes more than expected, and the only way to know is to measure on your own validation set at each compression step. We report the accuracy cost of every optimisation rather than treating compression as free.
What happens when a device fails?
Whatever you decide in advance. Fail-safe or fail-open is a business decision we document, with a watchdog that restarts predictably, local buffering where output can be delayed, and an alert that reaches a person. The important part is that it is designed rather than discovered.
How do we update models across a fleet?
Signed updates rolled out in stages with automatic rollback on failure, and remote monitoring of throughput and errors per device. Updating by hand works exactly once, which is why fleet management is part of the build rather than an afterthought.
Can we improve the model after deployment?
Only if you keep the data. We define a sampling policy that retains a small share of images, weighted towards uncertain and rejected cases, within bandwidth and privacy limits. Without it the deployment stays frozen at its launch accuracy.
Often paired with this
Most clients combine two or three engagements from the Computer Vision pillar. These are the ones that most often run immediately before or after.
Visual Quality Inspection and Defect Detection
Defect detection engineered from the imaging up, tuned to escape rate and false reject cost on your line.
Read more →Object Detection and Image Classification
Detection and classification models trained on your own images, with honest labelling and cost-weighted thresholds.
Read more →Video Analytics and Surveillance AI
Video analytics tuned against alert fatigue, with tracking across cameras and privacy designed in from the start.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.