The architecture decision should start with the production decision
“Edge versus cloud” is often presented as a technology choice. It is more useful to treat it as a decision about where computation needs to happen.
A vision inspection cell may need inference within a production cycle. A monthly maintenance analysis does not. A generative engineering assistant may benefit from a large hosted model. A machine diagnostic service may need to continue operating when the corporate network is unavailable.
When edge makes sense
Edge computing is attractive when latency, local availability or data locality matters. Raw images, high-frequency vibration data and machine-local diagnostics can generate large volumes of data that do not need to leave the production environment.
Keeping inference close to the equipment can also make failure behaviour easier to define. If the WAN connection is lost, the local inspection service can continue operating.
When cloud makes sense
Cloud infrastructure becomes attractive when workloads are large, variable or shared across locations. Model training, large-scale analytics, fleet-level comparisons and document intelligence can benefit from centralised resources.
Cloud also makes it easier to operate some services across multiple sites, provided the data governance and connectivity model is appropriate.
Hybrid is often the engineering answer
A common industrial architecture keeps time-sensitive inference on the edge while sending selected features and results upstream. Historical data can feed cloud or central analytics. Large language models can operate centrally while local systems provide controlled data access.
This avoids forcing one environment to solve every problem.
Consider operations, not only performance
Edge devices need patching, monitoring, hardware lifecycle management and physical protection. Cloud systems need identity management, network connectivity and provider governance.
The cheapest architecture on day one can become the most expensive if the support model is unclear.
The practical selection criteria
- Required decision latency.
- Expected data volume.
- Network availability.
- Data sensitivity and governance requirements.
- Need for local autonomy.
- Central management and model lifecycle.
- Total operational cost.
Once these criteria are written down, the edge/cloud decision is usually much less mysterious.
Latency is only one variable
It is tempting to compare edge and cloud systems on inference latency alone. A production system also has startup time, network dependency, model-update behaviour and recovery characteristics.
An inspection cell might perform inference locally but still send aggregates to a central platform. A forecasting application can work entirely centrally because minutes or hours of latency do not change the operational decision.
Data movement has a cost
High-frequency vibration, images and waveform data can become expensive to move and store centrally. Edge processing allows the system to reduce data before transmission, sending features or events rather than every raw sample.
Think about support ownership
Edge systems introduce physical devices that someone must replace, patch and monitor. Cloud systems introduce provider dependencies and network requirements. In either case, define who owns the service when it fails at 03:00 on a production day.
Use a reference architecture
A practical pattern is local acquisition and deterministic pre-processing, edge inference for latency-sensitive tasks, central storage for historical data and cloud or central AI services for heavier analytics and model development. The architecture should allow individual components to fail without taking down the control system.
Model lifecycle changes the cost picture
Edge deployment can simplify low-latency inference but makes model distribution and hardware compatibility a real operational concern. Centralised deployment can make updates easier but increases network dependency. The choice should therefore consider the full lifecycle rather than only the initial benchmark.
Design the boundary explicitly
Decide which data stays local, which results are transmitted, and which central services are permitted to request detailed plant data. The boundary becomes part of the architecture and security model, not merely a performance setting.
Consider offline operation deliberately
If production must continue during a network outage, define what the AI service does without connectivity. A local model can continue running; a cloud-only workflow may need to degrade to conventional controls. Neither choice is inherently right, but the failure mode should be explicit and tested.
Central management matters at scale
Ten edge devices can be maintained manually. Hundreds cannot. Fleet management, model versioning, health monitoring and controlled deployment become part of the architecture as the number of sites grows. The design should therefore anticipate scale before the first pilot becomes a plant-wide standard.
Edge hardware becomes part of the industrial asset base
Once an inference workload moves to the plant floor, the compute device needs an owner, a patch strategy and a replacement plan. Treat it like other industrial infrastructure rather than disposable laboratory equipment.
Model updates need controlled distribution
Sending a new model to every machine at once can create unnecessary risk. A better approach is staged rollout: one machine, then a small group, then the wider fleet after performance is verified.
Choose local preprocessing carefully
Feature extraction at the edge can reduce bandwidth, but it also means important logic is now distributed. Keep preprocessing versioned and observable so the central team knows which transformation produced a given result.
The architecture should tolerate network loss
Define what continues locally, what queues for later transmission and what simply becomes unavailable. This makes the operational behaviour predictable instead of leaving recovery to chance.
Avoid false precision in architecture comparisons
Benchmark numbers taken from a laboratory workload rarely predict the total performance of a production cell. Measure the actual pipeline: acquisition, preprocessing, inference, communication, storage and operator response. The useful latency is the time from physical event to usable decision.
Energy consumption can influence the decision
Large edge accelerators may provide excellent local performance while increasing power and cooling requirements. Cloud services may shift that energy and infrastructure elsewhere but add network and recurring service costs. For large deployments, those operational details can materially affect total cost.
Use identical models where practical
Comparisons are clearer when the same model and preprocessing pipeline are tested in both architectures. This isolates the architectural effects from differences in model quality.