This decision gets made on instinct far more often than it should. There are five questions that settle it, and they are all answerable before anyone writes code.
1. What is the latency budget?
Measure the time between the moment the frame is captured and the moment something must act. If a reject gate has to fire before the part clears the station, you are talking milliseconds, and the decision has to happen at the camera. If a supervisor needs to know within a minute, you have options.
2. What happens when the network drops?
Not whether it might — what the process does when it does. If the line must keep running, the vision system cannot have a remote dependency in its decision path.
3. Is the imagery allowed to leave?
Controlled technology, clinical areas and some customer contracts settle this immediately. If frames cannot leave the building, edge is not a preference, it is the only option.
4. How many cameras, and what resolution?
Continuous video from many cameras is expensive to move and expensive to store. Processing at the edge and sending structured events instead of frames usually costs less to run, and the gap widens with every camera added.
5. Who maintains it?
Edge hardware lives in heat, dust and vibration, and it needs a spares plan and health monitoring. That is a real operational cost, and it is the one honest argument for centralising when the other four allow it.
The usual answer
For industrial inspection and site safety, the first three questions almost always force the decision to the edge. For analytics that inform a weekly meeting, they rarely do. Most real deployments end up split — inference at the edge, aggregation and reporting centrally — and knowing which side each function belongs on is most of the architecture.