At 0.3 seconds per unit, a factory vision system running 11,520 units per day per line generates about 38,400 inference requests in a single eight-hour shift. That number is manageable on the factory floor. Sent to the cloud, it becomes a stream of continuous network dependency — and every millisecond of round-trip latency is time the part has already moved down the conveyor before the rejection signal arrives.
The edge-vs-cloud question for factory vision is not primarily a cost question. It is a latency, bandwidth, and regulatory question. Each has its own math, and each math produces a different answer depending on your line speed, camera count, and data jurisdiction. This post runs the numbers and provides a working decision table. Buyers evaluating HyperQ AI Vision for in-line production inspection will find the deployment architecture discussion directly applicable; the principles apply to any vision inference system.
Why latency is an architecture decision, not a configuration setting
Rejection signals need to reach the actuator — the reject gate, the robot-arm divert, the conveyor stop — before the part passes the divert point. How much time that leaves depends on two things: the distance from the inspection station to the divert mechanism, and the conveyor speed.
On an automotive components line running at 11,520 units per day across a single eight-hour shift, the inter-part spacing runs roughly 2.5 seconds. A cloud round-trip on a well-provisioned corporate WAN runs 80–120ms, which leaves 2.4 seconds of headroom. That sounds comfortable until the WAN degrades during a peak production burst, or IT applies quality-of-service throttling to non-priority traffic, or the cloud inference queue backs up when multiple lines submit simultaneously.
The inspection system does not know about QoS policies. It sends the image, waits for the response, and fires the actuator signal when the response arrives. If the response arrives 200ms late, the part has already cleared the divert point. The miss is not flagged as a latency event. It appears in your escape rate.
On lines running 0.3 seconds per unit — roughly 12,000 parts per hour on a precision machining or electronics assembly line — that tolerance collapses. A cloud round-trip that adds 80ms introduces latency equivalent to roughly one part position at that speed. Statistically, a percentage of rejection signals will arrive after the divert window has closed, particularly during production surges.
Edge inference runs the model locally. The inference request travels zero meters to a cloud endpoint. The response travels zero meters back. The only variable is the GPU or NPU processing time, which for a trained defect model runs in the 20–50ms range on modern edge hardware. That latency is deterministic and immune to network variability. It does not degrade during production peaks.
This is not an argument that cloud inference is always wrong for factory vision. It is an argument that the decision requires a latency budget calculation before an architecture is chosen, not after deployment has already begun.
One controls engineer working on an automotive components line described the failure mode this way: "The latency looked fine on the WAN test because we ran the test at 10 a.m. on a Tuesday. The shift change at 6 p.m. dropped the WAN to 40% capacity for about 25 minutes. During that window we had approximately 500 parts go through the divert zone with no rejection signal." The system was not producing errors. It was producing silent misses. The gap between test-environment latency and production-environment latency is consistently larger than the project team expects, for exactly this reason.
The bandwidth calculation most factory IT teams skip
A single 5-megapixel industrial camera operating at 15 frames per second generates approximately 75 megapixels per second of raw image data. Compressed to JPEG for transmission, that becomes roughly 30–60Mbps of sustained data per camera.
At 10 cameras per line, a cloud-inference architecture requires 300–600Mbps of sustained uplink bandwidth from the factory to the inference endpoint. That bandwidth must be consistent. Average-consistency is not sufficient. A factory Ethernet uplink that delivers 500Mbps average but drops to 200Mbps during shift changes will cause inspection backlogs during the busiest production windows. Backlogs mean queued frames, which mean delayed rejection signals, which compounds the latency problem described above.
Most factories provision 1Gbps uplinks for ERP, SCADA, MES, and video surveillance combined. A cloud vision deployment competing for that same pipe will either degrade existing systems or require a dedicated circuit. A dedicated 1Gbps uplink for vision inference alone changes the infrastructure cost calculation significantly — often enough to reverse the hardware-savings argument for cloud.
Edge inference sidesteps this. Image data stays on the factory floor. The edge device sends a small JSON payload — classification result, confidence score, part identifier, timestamp, operator override flag — to the MES. That payload runs kilobytes per inference, not megabytes. The uplink requirement for quality record traffic is trivially small against any modern factory network.
The tradeoff is model update logistics. Edge devices need periodic model updates when defect catalogues change, when a new product variant enters production, or when retraining has produced an improved model version. A model update file runs hundreds of megabytes as a one-time transfer. Scheduled overnight pushes over the existing factory WAN handle this without difficulty. The key distinction is burst vs sustained: model updates are infrequent bursts; cloud image upload is continuous sustained load.
Data residency and PDPA cross-border transfer
Malaysia's Personal Data Protection Act 2010 and Singapore's PDPA 2012 both impose obligations on cross-border transfer of personal data. For most vision inspection data — images of metal stampings, surface defects, barcode labels — there is no personal data and PDPA cross-border provisions do not apply directly.
The complicating case is when the same camera estate handles both product inspection and personnel monitoring. A facility that uses HyperQ AI Safety for contractor gate verification or PPE compliance checks alongside HyperQ AI Vision for product inspection has a mixed data stream: some frames contain identifiable individuals, some contain only product. If that stream is routed through a cloud inference endpoint hosted in a jurisdiction without equivalent data protection standards, the cross-border transfer obligation attaches to the personal data frames.
Sending personal data to an inference endpoint in a non-adequate jurisdiction requires either explicit consent from data subjects — impractical for factory floor monitoring — or reliance on adequacy mechanisms the MY/SG frameworks define. Neither is operationally straightforward for real-time production monitoring where workers are not in a position to give per-session consent.
Edge inference removes the question. If inference happens on-premises, personal data never crosses a jurisdictional boundary. The image is processed, the classification is produced, and only the structured result is logged. Nothing personally identifiable leaves the factory network.
For purely industrial inspection with no personal data content, cloud inference remains legally straightforward under both MY and SG frameworks. The residency question becomes relevant specifically when the same camera estate serves dual purposes — which, in practice, it increasingly does as AI deployments expand from QC to EHS within the same facility.
A facilities engineer at a MY precision parts facility described the dual-use expansion pattern this way: the facility started with product inspection only, no personal data, no PDPA consideration. When contractor gate verification was added to the same camera management platform six months later, no one revisited the data flow architecture. The cross-border transfer obligation appeared on a later legal review, not because anyone made a bad decision, but because the scope of what the cameras were doing had grown without a corresponding review of where the data was going. The audit exposure came from addition, not from the original deployment.
Practical decision table: edge vs cloud for factory vision
| Factor | Edge inference preferred | Cloud inference viable |
|---|---|---|
| Inspection cycle time | Under 2 seconds per unit | Over 5 seconds per unit |
| Camera count per line | More than 4 cameras | 1–3 cameras |
| WAN reliability | Congested or variable | Consistent 500Mbps+ dedicated uplink |
| Data classification | Includes personal data or regulated batch data | Product imagery only, no personal data |
| Regulatory context | MY/SG PDPA cross-border constraint present | No jurisdictional transfer restriction |
| Deployment includes worker monitoring | Yes | No |
| Production continuity requirement | Inspection must run during WAN outage | WAN outage acceptable for production |
| Model update frequency | Monthly or less | Weekly or more |
No single factor is determinative. A facility with a high-reliability dedicated WAN, no personal data, and low inspection cycle times can run cloud inference for cosmetics checks without difficulty. A safety-and-quality combined deployment on a shared CCTV estate with a congested uplink needs edge inference regardless of the per-frame economics.
The hybrid pattern: edge inference with cloud aggregation
The architecture most production deployments converge on separates real-time inference from analytics and governance.
Edge inference handles the real-time rejection decision. The edge device runs the active inspection model and produces all rejection signals. Results — not images — are forwarded over the factory LAN to a local or cloud-hosted analytics layer that aggregates trend data across lines, flags model drift, and queues retraining jobs when defect distribution shifts. When a new model version is validated, it is pushed to the edge device during a scheduled maintenance window, with the previous version retained for rollback.
This separation keeps the critical path — image capture, inference, rejection signal — independent of WAN availability. A network outage does not stop the inspection. It creates a reporting lag in the trend layer. Reporting lags are manageable; production stoppages because the cloud endpoint is unreachable are not.
In deployments covering both product inspection and safety monitoring across the same camera estate, the hybrid architecture also simplifies data handling. Product inspection results and safety event records flow to separate logical record systems with separate retention policies, both fed from the same edge inference pipeline. The data governance overhead is lower when personal data never leaves the premises.
The vision data pipeline post covers the record side of this in more detail — what structured results should contain, how they link to batch and lot records, and what retention is needed for ISO 9001 and 13485 compliance.
Frequently asked questions
Can cloud inference handle real-time rejection on a fast line? It can if the round-trip latency is deterministically below the latency budget for that line's conveyor speed and divert geometry. Most factories cannot guarantee that determinism on a shared WAN. Dedicated low-latency cloud connectivity (direct peering, private circuits) can close the gap but adds cost and complexity. For lines running under 2 seconds per unit, the determinism requirement is the main obstacle, not the average latency.
What edge hardware does a vision system require? The hardware depends on camera count, resolution, and model complexity. A single-camera station with a 5MP camera running a trained defect classification model typically needs a GPU-equipped industrial PC with 8–16GB GPU VRAM. Multi-camera stations scale roughly linearly. HyperQ AI Vision runs on standard industrial x86 hardware without proprietary compute requirements; no purpose-built hardware lock-in applies.
Does edge inference mean losing access to central dashboards? No. Edge inference handles the real-time rejection decision; classification results forward to the central analytics layer as structured records. Trend dashboards, defect heatmaps, and retraining queues are maintained centrally. The edge device is the inference engine, not the data warehouse.
What happens to inspection if the edge device fails? Edge device failure stops the inspection at that station. For production lines where inspection is a quality gate — where a non-pass product cannot proceed — this triggers a production hold. For advisory inspection where operators review flags but the line continues, production can run without inspection until the device is restored. Redundant edge devices are an option for lines where inspection downtime has significant direct cost.
How is model version control managed across multiple edge devices? HyperQ AI Vision uses a central model registry. Each edge device reports its active model version and last update timestamp. When a new model version passes validation, the registry schedules a push to designated devices during a maintenance window. Device-level rollback to the previous version is supported and is the default response to a newly deployed model that produces an elevated false-positive rate.
Does cloud inference reduce the hardware cost? Cloud inference eliminates the edge hardware purchase but introduces ongoing per-frame inference API cost, bandwidth cost for image upload, and the latency risk described above. For low-volume, low-frequency inspection tasks — incoming inspection of small lots at a receiving dock, for instance — cloud inference can be cost-effective. For in-line production inspection at volume, the per-frame cost compounds quickly against the fixed edge hardware cost, and the latency risk is real. The right architecture depends on the inspection cycle and volume, not on a generic cost comparison.
Send your camera specifications, line speeds, and current network topology, and we will return a deployment architecture recommendation — edge, hybrid, or cloud — with latency calculations matched to your specific inspection cycle. Two weeks turnaround, no contract until the architecture specification meets your production requirements.
Send your line specifications and get a deployment architecture recommendation