AOI false calls in SMT production: AI review of flagged images and the GPU at the line

What AI review of AOI false calls does

AI review of AOI false calls adds a second check after the automated optical inspection (AOI) of an SMT line: a classifier looks at each image the AOI has flagged and decides whether it shows a real defect or a false call, a good solder joint or component that the inspection program rejected. Calls the model is confident are false are released, and the rest go to the operator at the verification station as before. The AOI, its cameras and its inspection programs stay as they are; the review model is trained on your own board images and runs on a small GPU next to the line or on a server in the plant.

For the head of production or quality, the gain is operator time and attention. An operator who confirms hundreds of false calls a shift looks at real defects with less care, and every call costs line time. For the IT and process engineering team, the questions are where the images come from, which data trains the model and which card runs it. This page covers both, for AOI and for X-ray inspection (AXI), and stays with the SMT case; our guide to an AI server for manufacturing covers inspection across a plant.

Why AOI programs produce false calls

An AOI program compares measured features of each solder joint and component, such as position, shape or brightness, against tolerances and flags whatever falls outside them. Tight tolerances catch more defects and flag more good joints; loose ones do the opposite. A study by Ulster University with a UK electronics manufacturer and Monash University, published on arXiv on 6 May 2025, shows the scale. Across 917 parts its data set held 54,019 false calls and 544 real defects, so by our arithmetic about 99 of every 100 calls were false.

The same study points to the first step, before any AI: tune the program. With a statistical method that set tolerances from past inspection data and kept every known defect flagged, the authors cut false calls by 18 per cent at the 80th percentile and by 22 per cent at the 75th, with no real defect escaping in the validation on five unseen parts. A cleaner program means fewer images for the review model and fewer borderline cases.

AOI makers offer a second check of their own. Mycronic describes a two-step approach for its systems, Escape Tracker to optimise program parameters and tolerances and DeepReview, "a live double-check of identified defects using deep learning", which it says eliminates "a large majority of false-calls without human intervention"; its page gives no percentage. Ask the maker of your AOI what it offers for your models and software release before you build your own.

Where the review step sits in the line

The review sits between the AOI and the verification station, and it sees only what the AOI has already flagged:

1. The AOI inspects the board and stores an image of each call with its position, component reference and defect type.
2. The review service takes these images, cuts out the region of the call and runs the classifier.
3. A call classified as false with a confidence above the threshold is released and logged with the image.
4. Every other call goes to the operator, who confirms or rejects it as today; that decision is stored as a label.
5. A sample of released calls goes to the operator anyway, so that quality sees whether the model passes real defects.

Quality sets the threshold. A model that releases a real defect turns a false call problem into an escape, and the Ulster study kept every known defect flagged for that reason. Set the threshold on validation data so that no real defect in it is released, accept the false calls that remain, and let quality sign off the threshold and the size of the audit sample for each product family.

Your own deep-learning review model or the AOI maker's option

Our summary; maker's option as described on Mycronic's webinar page, read 25 October 2026.

An own model pays off where a plant runs AOI systems from more than one maker, where customers' board designs may not leave the site, or where the team wants to train on calls from several lines together. For an EMS company, the boards it assembles are its customers' designs and are often covered by non-disclosure agreements, so training on them on an own server keeps that question simple; our article on trade secrets, NDAs and AI tools covers it from the contract side.

Training data: the verification station already labels it

A review model needs flagged images with the right answer, and most lines produce them every shift. When the operator confirms a call as a defect or rejects it as false, the verification station records the decision; if your system stores the image with that decision, each record is a labelled example. Export a few months of records per product family, check a sample of the labels with quality, and keep the boards from one period aside for validation.

A published X-ray example gives an idea of scale. Researchers of FAU Erlangen-Nürnberg and Siemens's Amberg plant presented a CNN review of X-ray solder joint inspection at the IEEE SIITME 2020 symposium. They trained on 6,387 images, scaled to 224 × 224 pixels, with a VGG-16 classifier, and report 98 per cent accuracy in two of four tests, with five misclassifications in 647 test cases in one of them. They also report that forcing one kind of error to zero lowered the rate of correct decisions of the other kind. They give no inference time and no figure for the false calls removed, beyond "a significant reduction" compared with commercial X-ray machines.

Small classifiers and anomaly models both fit this task; our guides to visual inspection AI without data scientists and to anomaly detection with Anomalib cover the second route, which needs only good examples to start.

We supply the GPUs for the line and the server that trains the review models; send us your lines, AOI models and calls per shift, and our team replies with a configuration.

How much GPU the line-side check needs

Very little per board. Ultralytics publishes inference times for its YOLO26 classification models at 224 pixels, measured with TensorRT 10 on an NVIDIA T4 at a batch size of one: 1.1 ms for YOLO26n-cls with 2.8 million parameters, 2.0 ms for YOLO26m-cls with 11.6 million and 3.8 ms for YOLO26x-cls with 29.6 million.

Ultralytics classification docs (YOLO26, ImageNet, T4 TensorRT10, batch 1), read 25 October 2026; calls per board and cycle time are example values; our arithmetic. Image transfer and cropping add time; measure your own model on the card you plan.

The figures are for the T4, an older 70 W card; we found no published figures for these models on the RTX PRO 4000 or the L4, so test your model on the card before you order for every line. The arithmetic still shows the scale: GPU time is not what limits a review station. Memory is not either, since a classifier of 29.6 million parameters is small next to 24 GB, and one card can hold a model per product family. What decides the card is the place it goes: the industrial PC beside the line, an edge server in the line's cabinet or a server in the plant's server room.

RTX PRO 4000, RTX PRO 4000 SFF or L4 at the line

NVIDIA RTX PRO 4000 datasheet 5323450 (June 2026) and L4 product page, read 25 October 2026; RTX PRO 4000 SFF from our canonical card sheet; cooling of the L4 from NVIDIA's product brief as quoted in our manufacturing guide.

The NVIDIA RTX PRO 4000 Blackwell is the usual choice for an industrial PC with a full-height slot: an active fan, one slot, one 16-pin power connector and 145 W. Where the PC or cabinet has only a low-profile slot or a tight power budget, the RTX PRO 4000 SFF does the same job at 70 W. The L4 is passive and needs the airflow of a server chassis, so it belongs in an edge server, not in a fanless PC. None of the three has MIG, which this task does not need. Our comparison of the RTX PRO 4000 SFF, RTX PRO 2000 and L4 and the RTX PRO 4000 Blackwell specs go into detail.

One card per line keeps the review running if the plant network fails, and a node failure stops only one line's review; the operator then sees every call again, as before. A central server can review the calls of several lines, since a decision within seconds is fast enough for a verification station, but it puts all lines on one network path. Many plants start with one line-side PC on the line with the most false calls and decide after the pilot.

Training the review models

Training runs away from the line, on a workstation or a server that sees the images of all lines. Classifiers of this size train on a single card, and our guide to a GPU server for training vision models covers memory, data loading and the choice between two and eight cards. For a plant that retrains a model per product family when new boards arrive, a server with two NVIDIA RTX PRO 6000 Blackwell Server Edition cards runs several training jobs at once, each card split into up to four MIG instances for small jobs, and draws about 1.8 kW by our estimate. A smaller team can start on a workstation; our page on buying an RTX PRO 4000 workstation describes one.

Retrain when the product mix changes: a new board, a new component package, a new solder paste or a new AOI program can change what false calls look like. Keep the previous model on the line PC until the new one has run on validation data and on one line.

Notes for the IT and process engineering team

1. Image export. Ask the AOI maker how images and verification decisions leave the system: files on a share, a database or an interface of its software. This decides how the review service reads calls and writes results back.
2. Inference engine. Export the trained model to ONNX or TensorRT and serve it with a small service or Triton; our guide to serving vision models with Triton, ONNX and TensorRT covers the options. Ultralytics' published times above were measured with TensorRT 10.
3. Network zone. The line PC belongs to the line's OT zone; model packages come in and images go out through a defined path, as our manufacturing guide describes under IEC 62443.
4. Versions. Pin driver, CUDA, container image and model version per line, record them, and change them only in planned stops with a rollback.
5. Licences. Ultralytics states that "All Ultralytics YOLO trained models fall under the AGPL-3.0 License by default" and that an Enterprise Licence is needed to use YOLO "without open-sourcing your entire project". Our article on the Ultralytics YOLO licence explains the choice; your legal department decides.
6. Logs. Store every released call with its image, model version and confidence, so that quality can trace a later field failure back to the review decision.

What we supply

We supply the RTX PRO 4000, RTX PRO 4000 SFF and L4 for industrial PCs and edge servers you already run, after a check of slot, power and cooling, and we build workstations and AI servers to order for the training side. Systems are assembled and tested before delivery and come on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Operating system, driver, CUDA and a container runtime are installed on request.

FAQ