Edge AI vs cloud AI for machine vision systems

Your new inspection needs a neural network, and the architecture decision lands before the camera choice: does the model run on the camera, on a controller at the line, or in the cloud? This comparison gives you the numbers that settle it — the latency a cloud round trip adds, the bandwidth raw frames consume, and the cycle time your machine actually allows. You will leave with a decision rule for real-time inspection, monitoring and training workloads, and the hardware tier that fits each side: smart cameras, vision controllers and AI inference terminals, with the cloud reserved for the workloads it serves best.

Where should AI in a vision system run: edge or cloud?

Run inference at the edge — on the camera or a vision controller beside the line — whenever its result drives a machine action, and keep the cloud for training, analytics and monitoring: a raw 5 MP frame needs 0.5 s to upload on an 80 Mb/s uplink, while an on-device decision finishes inside 40 ms.

The trade rests on three costs. Latency is physics: bytes crossing a wide-area link take time that no protocol tuning removes. Bandwidth is a recurring bill: raw inspection frames fill most of a GigE per camera, while the uplink to the internet is far narrower than the factory LAN. Privacy and retention are policy: frames that show people or unreleased product often cannot leave the building at all. Edge moves compute to the data; cloud moves data to the compute. For which stage runs where on the edge side, Plan edge vision inference deployment across camera and host walks the partition stage by stage; this comparison covers the two destinations end to end.

How much latency does a cloud round trip add to a vision decision?

Budget roughly 0.6 s per decision when a raw 5 MP frame travels to the cloud over an 80 Mb/s business uplink: upload alone takes 504 ms, before a 30 ms network round trip, 10 ms of queueing and 40 ms of server-side inference.

The upload dominates, and it scales with bytes, not with distance:

Worked example, mono frame, nearby region: 2592 × 1944 = 5,038,848 pixels = 5.04 MB at 8 bits. Upload: 5.04 × 8 / 80 = 0.504 s. Total: 504 + 30 + 10 + 40 + 1 = 585 ms, call it 0.6 s. Compress the frame 10:1 and upload falls to 50 ms, for a total of 131 ms — still longer than a 100 ms machine cycle. The same station deciding on the device spends 2 ms of exposure, 10 ms of readout, 3 ms of ROI transfer, 20 ms of inference and 1 ms of PLC handoff: 36 ms end to end.

How much bandwidth do raw vision frames need?

Raw 8-bit frames cost about one megabyte per megapixel, so one 5 MP camera at 20 fps streams 101 MB/s or 806 Mb/s — most of a GigE link — while the same station deciding on the camera sends verdicts of a few dozen bytes per frame.

At 8 bits per pixel, mono:

Colour at 12 to 16 bits roughly doubles the bytes. Six 5 MP cameras at full rate ask for 4.8 Gb/s, which is why a multi-camera cell sits on a vision controller with several network ports rather than one shared uplink: Two GigE cameras on one host: NIC ports and bandwidth budget works the per-port math, and Reduce USB3 camera bandwidth: the per-camera budget math does the same for a USB3 host.

Deciding on the device collapses the bill. A 32-byte verdict at 20 fps is 640 B/s, five orders of magnitude below the raw stream, and Smart camera data logging to the network: three paths and the math sorts what to send, log and keep.

When does edge AI beat the cloud?

Edge wins whenever a robot, rejector or gate acts inside the machine cycle: a palletizer at 600 picks per minute allows 100 ms per pick, motion consumes about 60 ms of it, and no cloud call — 131 ms even compressed — lands in the remaining 40 ms.

• Robot guidance. The pick target must update every cycle, so the verdict has to land inside the robot's window: 2D vision guided robot pick place grip: how the cycle works shows the loop, and 3D vision for robot palletizing: sizing boxes for pick the palletizing version.
• Reject removal at line rate. A verdict that arrives after the part does is worthless; at 600 parts per minute the window is the same 100 ms.
• Privacy and retention. Frames that show people, patients or unreleased product stay on site, and only verdicts leave.
• Weak or metered links. When the WAN drops, an on-device system keeps sorting; only the dashboard stops updating.

For a single fast station, the tier that fits is a vision sensor that inspects on the device. The MV-SC3050XC-16M-ATN-H is a 5 MP colour vision sensor with a global shutter and an M12 lens mount.

Its verdict crosses a few metres of cable rather than a continent, and keeps crossing them when the internet does not.

When is cloud AI the better choice?

The cloud wins when the tolerance is seconds or minutes: offline training, cross-site quality dashboards and one-frame-per-second monitoring all survive a 0.6 s round trip, and training wants elastic GPU capacity that no camera or controller can offer.

Training is the headline case: capture frames at the edge, ship batches on a schedule, train on GPU machines, deploy the finished weights back down. Scheduled upload makes the bandwidth problem small — 80 Mb/s is 10 MB/s, so an 8-hour window moves 10 × 28,800 = 288,000 MB, about 288 GB of frames, while the line keeps running on local inference.

Monitoring at one frame per second is equally comfortable: a 0.5 MB JPEG is a steady 4 Mb/s, inside any business uplink. And when the open question is whether a defect class needs a network at all, AI vs rule-based smart camera inspection: how to choose sorts the workload first.

If policy keeps frames inside the building, the cloud's role moves on site: a training server does the same workload next to the line. The MV-TS1004-256GR-960G16TR10 is a quad-GPU AI training server for exactly that job.

Either way, training stays offline; only the deployed model comes back to the line.

Which hardware runs AI at the edge?

Three hardware tiers cover edge inference: smart cameras inspect on the device with no PC, vision controllers run one model beside a whole multi-camera cell on banks of LAN ports, and AI inference terminals add a GPU card when the network outgrows a controller CPU.

Smart cameras sit at the tightest end: acquisition, inference and verdict in one housing, with no PC to license, cool or mount. The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm M12 lens on GigE, and the MV-SC6050C-08M-XBN covers the same role in 5 MP colour with a global shutter and a multi-color light source.

Match the shutter to the part: global shutter when the part moves during exposure, rolling shutter fine when it stands still.

Vision controllers cover the multi-camera cell: one box hosts the model, drives the lights and talks to the PLC for every camera at once. The entry tier looks like the MV-VC3301H-128G66, which offers 5+ LAN ports, four built-in light channels and 8 GB of memory, with a VM6200Pro license included. The MV-VC5525-256G70-NN steps up to PoE camera ports, eight built-in light channels and 32 GB of memory.

Frames stay on the local switch, verdicts reach the PLC in well under a millisecond, and one update refreshes the whole cell. When the network outgrows a controller CPU, GPU-based AI inference terminals take over, and the data path matters as much as the card: Feeding GPU tensors to a vision model without a CPU round trip keeps frames off the CPU entirely.

How do you build a latency budget for your own line?

Write the budget as cycle time minus reaction allowance, fill it with exposure, readout, transfer, inference and handoff, and keep a tenth of it spare: for the 100 ms palletizing cycle above, the 36 ms edge chain passes and the 131 ms compressed cloud call fails.

1. Fix the cycle. 600 picks per minute is 100 ms per pick.
2. Reserve the reaction. Robot motion and grip take 60 ms; the vision chain gets 40 ms.
3. Set the camera floor. Exposure plus readout is the part no software removes — Maximum frame rate on a hardware trigger: exposure plus readout time derives it.
4. Add the transfer. Bytes × 8 / link speed: a 0.31 MB ROI on a GigE link is 2.5 ms, budget 3 ms.
5. Add inference. Budget 20 ms, then measure the real figure with your model and your unit.
6. Add the handoff. A digital output or register write to the PLC: 1 ms.
7. Compare. 36 ms against a 40 ms budget passes with a 10% margin; 131 ms fails. A cloud call does not lose narrowly — it misses the budget by more than 3×.

What breaks when AI runs at the edge?

The edge's failure modes are local and predictable: a fanless controller throttles when heat cannot escape, model updates must roll out station by station, and a version mismatch between SDK and runtime can crash a device that ran fine the day before.

• Heat. Give a fanless controller airflow and derate the processor in hot cells; the fix is mechanical, not software.
• Model updates. Fifty stations means fifty deployments; the procedure and its rollback are laid out in Swapping a neural network model on edge vision hardware.
• Version drift. Pin SDK and runtime versions together, the way Edge inference device crashes: fix with SDK version pinning describes.
• Fit. Before promising a heavy anomaly model at line rate, check the pipeline fits the hardware: PatchCore edge inference: can the whole pipeline fit? runs that arithmetic.

None of this flips the decision — a 0.6 s round trip cannot be patched into a 40 ms budget — but it does change the maintenance plan: the edge needs a rollout routine, the cloud needs a contract.

Which one should your application get?

Pick edge for anything a machine acts on within its cycle, cloud for training, fleet analytics and second-tolerance monitoring, and run both together: the edge decides in 36 ms while the cloud learns after the shift from the frames the edge stores.

If your numbers land close to a boundary, send the cycle and frame sizes through the contact page and we will check the chain with you. Build the edge side in the vision system configurator, and the wider network-and-data material sits in the systems guides.