For edge AI in machine vision, a GPU is the default for deep learning on multiple cameras, a CPU handles rule-based vision and light models, an FPGA gives the lowest and most deterministic latency for high-speed preprocessing, and an NPU or AI accelerator in a smart camera or embedded module suits a single, well-defined check at low power. The right choice comes from the line rate, the number and resolution of cameras and the models you need to run, so size it with numbers rather than by brand.
This article is part of our guide to industrial AI. It compares the four processor types for image processing in AI and traditional machine vision, walks through a sizing example and lists the industrial factors that spec sheets leave out.
CPU vs GPU vs FPGA vs NPU at a glance
| CPU | GPU | FPGA | NPU / AI accelerator | |
|---|---|---|---|---|
| Strength | Flexible, sequential logic | Massively parallel math | Custom hardware pipelines | Efficient neural-network inference |
| Best for | Rule-based vision, control, light AI models | Deep learning on several cameras, training | Frame-grabber preprocessing, line-scan, ultra-low latency | One smart camera or embedded check |
| Deep learning throughput | Low to moderate | High | Moderate to high, with effort | Moderate |
| Latency determinism | Moderate | Good, with some variation | Excellent (fixed clock cycles) | Good |
| Power | Moderate | High | Low to moderate | Low |
| Development effort | Low | Low to moderate (mature AI tools) | High (hardware design skills) | Moderate (model conversion, operator limits) |
| Flexibility to change models | High | High | Low | Moderate |
CPUs: the default for rule-based vision
Classical machine vision tools such as pattern matching, edge measurement, blob analysis and code reading run well on modern multi-core CPUs, and the CPU also runs the application, the operator screen and communications with the PLC. Small AI models, especially after INT8 quantization, can run on a CPU at modest rates. When the job is mostly measurement, a CPU-only system is often the simplest and cheapest answer; see deep learning vs rule-based machine vision.
GPUs: the workhorse for deep learning vision
Neural networks are mostly large matrix multiplications, which GPUs perform in parallel across thousands of cores. An industrial PC with a GPU can run detection, segmentation and anomaly models on several cameras at line rate and still log data and serve the operator interface. The software ecosystem for training and deploying models on GPUs is the most mature, which shortens development.
FPGAs: deterministic, high-speed processing
An FPGA implements the processing as custom logic, so every frame takes exactly the same number of clock cycles. That makes FPGAs ideal for work that must happen at the sensor’s full data rate with fixed latency: flat-field correction, filtering, compression and simple decisions in frame grabbers, high-speed line-scan web inspection and triggering. They can run neural networks too, but development takes specialized skills and model changes are slower.
NPUs and AI accelerators: AI at low power
Neural processing units are dedicated inference engines built into embedded modules, smart cameras and some industrial PCs. They run quantized models efficiently at a few watts, which suits a single camera doing one well-defined check. Limits to plan for: models must be converted to a supported format, not every network layer is supported, and capacity for several cameras or large models is limited.
Sizing example: four cameras on a 120-parts-per-minute line
A station inspects each part with four 5-megapixel monochrome cameras (2,448 × 2,048 pixels, 8 bits per pixel):
- Data per image: 2,448 × 2,048 ≈ 5.0 million pixels × 1 byte ≈ 5.0 MB
- Time per part: 60 ÷ 120 = 0.5 s, for capture, transfer, inference, decision and the reject signal
- Images per second: 120 parts/min × 4 cameras ÷ 60 = 8 images per second, about 40 MB/s of image data
- If the cameras instead streamed continuously at 30 frames per second: 5.0 MB × 30 × 4 ≈ 600 MB/s, which changes the interface, memory and compute requirements entirely
With a triggered capture of 8 images per second, a single industrial GPU usually has headroom for a segmentation model per camera; a CPU alone would likely struggle with deep learning at that rate. With continuous 600 MB/s streams, you would add FPGA preprocessing or crop regions of interest before inference. The model’s real inference time on the chosen hardware should be measured in the proof of concept, at the target image size, with margin for peaks.
Model precision and quantization
Models are trained in 32-bit floating point (FP32) but can usually run in 16-bit (FP16) or 8-bit integer (INT8) form. INT8 weights take a quarter of the memory of FP32 and run much faster on GPUs and NPUs, typically with a small accuracy loss that must be checked on the validation set. Quantization is often what lets a model fit an embedded accelerator or hit the cycle time.
Running vision language models at the edge
Hosting a vision language model locally keeps images on site and removes per-token fees, but needs much more memory than an inspection model. A 7-billion-parameter model in FP16 needs about 7 × 2 = 14 GB for its weights alone, and about 3.5 GB when quantized to 4 bits, before the memory for image tokens. That points to a high-memory GPU in an industrial PC or on-premise server rather than a smart camera. See VLM token usage for the token side.
Industrial factors the spec sheet leaves out
- Temperature and enclosure: fanless or filtered cooling, rated ambient temperature, dust and washdown requirements.
- Long-term availability: consumer GPUs change every year or two; industrial and embedded parts offer longer supply and support.
- Power and space: GPU power draw and heat inside a control cabinet.
- Deterministic I/O: trigger inputs and reject outputs with predictable timing, often handled by a PLC or FPGA rather than the AI processor.
- Software lifecycle: drivers, operating system and AI runtimes that can be frozen for validated systems and updated safely.
Which processor should you choose?
| If your system… | Start with |
|---|---|
| Measures and checks consistent parts with classical tools | CPU |
| Runs deep learning on one or more cameras at production rate | Industrial PC with GPU |
| Processes very high data rates with fixed latency (line-scan, high-speed web) | FPGA in the frame grabber, plus CPU or GPU |
| Does one compact, low-power AI check per camera | Smart camera or module with an NPU |
| Hosts a vision language model on site | High-memory GPU server or industrial PC |
Need help sizing edge hardware for AI vision?
Sciotex designs and builds industrial AI systems and sizes the cameras, compute and I/O to your line rate, with inference times measured on your parts, designed, programmed, built and supported in the US since 1997.
Frequently asked questions
For classical rule-based machine vision, a CPU is usually enough. For deep learning on one or more cameras at production rate, a GPU is the standard choice because it runs neural networks in parallel.
When the system must process very high data rates with fixed, predictable latency, such as preprocessing in a frame grabber, high-speed line-scan inspection or hardware triggering.
A neural processing unit is a dedicated, low-power AI inference engine. In a smart camera it runs a quantized neural network for one inspection without a separate PC.
Edge AI means running AI models on hardware at or near the machine, such as an industrial PC, GPU or smart camera, so decisions are made within the cycle time and keep working without a network connection.
Roughly two bytes per parameter in FP16, so a 7-billion-parameter model needs about 14 GB for weights, or about 3.5 GB at 4-bit quantization, plus memory for image tokens and processing.
Related articles
- Industrial AI: How AI Is Used in Manufacturing
- VLM Token Usage: How Image Tokens Are Counted vs LLM Text Tokens
- Deep Learning vs Rule-Based Machine Vision: When Is AI Worth It?
- Physical AI: What It Means for Factory Automation
- High-Speed Data Acquisition: Sample Rates, Throughput and System Architecture