Why AIVEX Chose Hybrid Computing

One late judgment pushes back the entire line

Vision inspection on a manufacturing floor is the work of judging dozens of images per second in real time. When a single inspection is delayed, the delay does not end with that one product — it pushes back the takt time of the entire line. When a judgment is wrong, it is either a miss that lets a defect through or overkill that rejects a normal part, and both land directly on yield and cost.

So the first decision in designing the system is not which algorithm to use but where the computation lives. Do we process this calculation inside the equipment, or send it to a server? Our answer to this question was not to pick one of the two, but to use both — with their roles divided so they never overlap.

We divided by what each environment cannot do, not what it does well

In deciding where computation lives, our criterion was not what each environment does well but what it structurally cannot do.

Computation running inside the inspection equipment never touches the network. The judgment comes out right where the trigger fires, so response stays in the millisecond range, and the line keeps running even if communication drops. Raw images never leave the equipment either. In exchange, the equipment's compute resources are almost entirely consumed by judging the product passing through right now. The same resources cannot run retraining across tens of thousands of images. Inspection equipment judges; it cannot train.

The cloud sits at the opposite end. To see the operational status of multiple lines and multiple sites in one place, trace model lineage, and manage when which training ran, this layer is necessary. But the moment a judgment request makes a network round trip, response time becomes hostage to the connection — and putting training in this layer means raw images must cross the customer's boundary. The cloud cannot do real-time judgment, and it must not receive raw images.

Then where does training run? The remaining place is the customer's server room. It is the only environment that is not pressed for time the way the equipment is, yet still sits inside the customer's network boundary — and that is why we put the training node there. "Hybrid" usually brings to mind an architecture that lifts training into the cloud, but in our architecture, what goes up to the cloud is not the training computation. It is the record of what that training used, when it ran, and what it produced.

[Table 1] What each layer does and does not do

So we split the system into three layers

We divided the inspection lifecycle into three layers — the device layer, the factory layer, and the cloud layer — and fixed the boundary of what each layer owns. The first two layers both sit inside the customer's premises. Judgment finishes inside the equipment; raw-image storage and training computation happen in the server room of the same factory; and the cloud carries only the MLOps platform that requests that training and traces its results. More than the layering itself, the real design decision was determining which traffic may cross a layer boundary and which traffic must never cross.

[Table 2] The three-layer configuration and the data that moves between layers

The data moving between layers is as follows. Between device and factory, inspection results and raw images go up, and retrained models come down. Between factory and cloud, inspection history and training-result metadata go up, and training requests and management commands come down.

Judgment finishes inside the equipment

Three things live in the device layer. The material-handling control system governs infeed, transfer, and discharge, and fires the inspection trigger the moment a product enters the inspection zone. The real-time inspection system receives that trigger and runs the deep learning model together with rule-based algorithms to produce an immediate judgment. The operator console handles real-time control and monitoring of the equipment and stores inspection results as the first tier.

For speed and device connectivity, the two systems are implemented in native languages and run together on a single inspection PC. On equipment with many imaging surfaces or heavy algorithms, multiple inspection PCs are installed and multiple instances of the inspection system run in parallel.

The reason we pinned judgment to this layer is simple. If judgments had to round-trip to the cloud, line speed would be held hostage to network conditions. The first principle we set was that the line must not die when the network does.

Training also runs inside the factory

The factory layer sits in the customer's server room. The inspection-history and yield management platform collects inspection results from each machine's operator console, visualizes them, and provides screens for re-reviewing overkill and misses. An image-transfer agent moves images accumulated on the inspection PCs to storage at the same site, and the training node keeps those images while performing the actual training computation.

The heart of this layer is that the training instance is here, not in the cloud. Images move only from the equipment to a server inside the same factory, and everything — re-review, labeling, training runs, and the model files training produces — stays on the customer's own resources. There is simply no segment in which sensitive raw manufacturing images cross the customer's network boundary.

The cloud carries only the MLOps platform

The cloud layer holds the MLOps platform and the metadata database. Just as the equipment's operator console handles the equipment and the factory's management platform handles inspection history, the MLOps platform handles training and models. Requesting training runs, checking the versions of deployed models, and viewing the operational status of multiple sites in one place all happen here. The metadata database records which model was built from which data, and when.

Training computation does not happen in this layer. The cloud is not where training executes; it is what makes training executed inside the factory manageable by people. As operational metadata from multiple customers and multiple lines accumulates in this layer, improvement know-how accumulates with it. In short: only requests and records flow to the cloud, while raw images and training computation stay inside the customer's boundary.

Data does not flow in one direction only

The three layers are not an org chart stacked top to bottom; they are the path data circulates through. In the forward direction, inspection results and raw images produced on the floor go up to the training node inside the same factory, and only the history and metadata generated along the way are passed to the cloud. In the reverse direction, a training request coming down from the cloud spins up the training node on the factory server, and the model retrained there is deployed to each inspection machine. The model file does not come by way of the cloud — it goes straight down to the line from where it was made.

Each time this loop completes a cycle, the overkill and misses screened on the floor become training data for the next model. The inspection machine stops being a terminal that only judges and becomes a point that produces training data, and the model is not frozen at deployment — it keeps updating while the line runs.

For the loop to hold, four principles must not break. Judgment traffic must complete inside the equipment for line speed to be protected; raw images and training computation must stay inside the customer for security and compliance to hold; the cloud must stay confined to management and record-keeping for sites to be added easily; and only when these three hold does judgment accuracy actually rise with every turn of the loop.

Where it collapses if you go all one way

We examined the all-on-premise option first. In our architecture the training computation already runs inside the customer, so pushing the remaining management layer into the customer as well was not an impossible choice. But doing so means every customer stands up and operates its own system for managing training history and model versions — improvement know-how gained at one site can never carry over to another. The burden of installing and updating the management tools also falls on the customer, raising total cost of ownership. Viewing the operations of multiple lines and multiple customers together becomes impossible as well.

Go all-cloud instead, and three things fail at once. Network latency enters the judgment path and takt time collapses; raw images must leave the premises for training, making security requirements hard to pass; and a communication outage becomes a line stoppage, dragging down availability.

So instead of piling everything into one place, we split responsibility by concern. The reason each concern sits in its layer is as follows.

[Table 3] Which layer owns each concern, and why

The difference this architecture makes on the floor

First, line speed is decoupled from network conditions — on days the connection is unstable, judgment speed does not change. Second, sensitive manufacturing images never leave the customer's physical boundary, so fewer stages get stuck in security review. Because training also finishes inside the same boundary, data requiring export approval never comes into existence in the first place. Third, models retrained on field data are folded back into the line on a regular cadence, so performance does not stay frozen at deployment level — it improves over time. Fourth, as new lines or new customers are added, the cloud management layer scales as-is, so the operational burden does not grow in proportion to the number of sites. Finally, cost becomes predictable. Field equipment, including the training server, is a one-time capital asset, and since only the management layer sits in the cloud, cloud costs do not spike as image volume or training volume grows.

Before you choose a vendor

We did not choose a hybrid architecture to make the diagram look sophisticated. We chose it because three demands arrive from the floor at once: the line must not stop, the data must not leak, and the model must not stand still. To satisfy all three together, computation cannot be piled into one place.

If you are evaluating a vision inspection system, we suggest checking three things about any vendor's architecture: whether judgment stops when the network goes down, where raw images are stored and on which server training runs, and whether the model is still improving six months after deployment. If the vendor you are talking to cannot answer all three, our door is always open.