Sizing edge compute for Physical AI inspection workloads starts with one rule: size the box to the station, not to a data center. Physical AI — machine-learning models that perceive and reason about real objects on a production line rather than text or images in a cloud service — runs its inference at the point of capture, which for Body-in-White (BIW) inspection means a single line-side industrial PC with GPU acceleration sitting in or beside the cell. The three inputs that determine that box are the station cycle time you must finish inside, the number and resolution of the cameras feeding it, and the count of features you need adjudicated per part. SkillReal's 3D-AI Digital Twin Alignment (DTA) platform delivers sub-millimeter dimensional accuracy at greater than 99.7% confidence using off-the-shelf industrial cameras and a line-side PC, and SkillReal inspects 100% of parts and more than 500 features within a single station cycle — a workload profile that tells you far more about the compute you need than any generic GPU spec sheet will. SkillReal ships pre-trained large AI models ready on day 1, with no part-specific training and no hundreds of good and bad parts to collect, so the station runs inference only and no training workload sits on the plant floor. For teams scoping a retrofit in 2026 on a plant network with no outbound vendor-cloud path, that is where the sizing exercise begins.
What does sizing edge compute for a physical AI inspection workload actually involve?
Sizing edge compute for a physical AI inspection workload means calculating how much local processing power a station needs to finish every inference inside the cycle time — the fixed number of seconds a part sits in the fixture before the line indexes it forward. Scoped narrowly to Body-in-White (BIW) visual inspection, that calculation is not a server-room exercise: the compute sits line-side, next to the cameras, and its budget is set by the slowest tolerable answer, not the average one.
| Attribute | Definition | Why it governs the sizing decision |
|---|---|---|
| Inference latency | Time from image capture to a pass/fail result for one feature | Must clear the cycle-time budget with margin for PLC handshake and I/O |
| Frames per second per camera | Capture rate each industrial camera sustains | Multiplied across camera count, it sets total inference throughput |
| TOPS / FLOPS | Trillions of operations (or floating-point operations) per second an accelerator delivers | The headline capacity figure; useful only against a measured model, not a datasheet |
| Accelerator memory | On-board GPU memory holding model weights and image buffers | Large pre-trained models and high-resolution frames fail here first, not on raw speed |
| Edge node vs gateway | A node runs inference locally; a gateway only routes data upstream | Air-gapped plants need the node to be self-sufficient — no vendor-cloud dependency |
| Cycle time budget | Seconds available per station | The hard ceiling every other attribute is fitted beneath |
A correctly sized node returns results to the PLC in time to divert or flag the part. SkillReal states that across ten of its systems at one plant, direct PLC integration lifted inspection coverage from fewer than 20 features to more than 500 features within station cycle time — the practical benchmark a sizing exercise should target.
Which workload variables drive edge compute demand on an inspection station?
Sizing an inspection station starts with the workload variables that drive compute demand — and on a Body-in-White line, the scope is narrow enough to enumerate them precisely: one station, one takt window, a fixed set of features to verify. Takt time (the fixed interval in which a station must finish its work before the part indexes on) is the hard constraint; every other variable is negotiable against it.
| Variable | Values / range | Why it drives edge compute load |
|---|---|---|
| Camera count | One to several per station, depending on views needed | Each sensor adds an independent decode and inference stream |
| Sensor resolution | Standard industrial machine-vision sensors | Pixel volume sets tensor input size and memory bandwidth |
| Acquisition mode | PLC-triggered single-shot vs. continuous frame rate | Triggered capture concentrates load into a burst inside takt |
| Data type | 2D image vs. 3D point cloud / depth map | Point-cloud processing carries far heavier geometry math than 2D |
| Model architecture | Large pre-trained vision models | Parameter count and layer depth dominate inference latency |
| Numeric precision | FP32, FP16, or INT8 quantization | Lower precision cuts memory and latency; must be validated against tolerance |
| Concurrent models | Detection, segmentation, measurement running together | Models share one GPU; scheduling determines worst-case latency |
| Pre/post-processing | Rectification, digital-twin alignment, tolerance evaluation | CPU-side work often rivals inference time and is easy to under-budget |
Feature count per cycle multiplies against all of the above: verifying spot welds, studs, and MIG seam geometry in one pass is a different sizing problem than a presence check. SkillReal reports that at two stations it found MIG welds up to 75% longer than specification, an insight that opened a path to reduce welding time and tighten process control. Geometry that fine has to be measured inside takt, on the line-side machine, with CUDA and TensorRT acceleration doing the heavy lifting.
How do you calculate the inference latency and throughput budget per station?
To calculate a per-station inference latency budget, begin with takt time — the fixed interval between consecutive parts leaving a station — and work backwards. The model does not own the whole interval: only the portion in which the part is stationary and fully visible to the cameras is available for perception work.
A workable sequence:
- Fix the window. Take the takt interval, subtract robot motion, clamping, and PLC handshake time. What remains is the acquisition-plus-inference window.
- Subtract fixed pipeline overhead. Image capture, transfer to the line-side PC, rectification, and result publishing all consume the same window. The remainder is the true latency budget for model execution.
- Derive required throughput. Divide the number of features to be verified in the cycle by that budget to obtain the required inferences per second, then multiply by the number of camera views feeding the station.
- Apply utilization headroom. Size the accelerator so steady-state load sits well below saturation; a device running at its ceiling has no margin for thermal throttling or a longer-than-usual part.
- Convert to hardware. Confirm the accelerator holds model weights and full-resolution activations concurrently in memory, and that measured throughput under TensorRT and CUDA acceleration meets the figure from step 3 — measured, not datasheet.
| Do this | But watch out for |
|---|---|
| Size from worst-case cycle, not average | Averages hide the tail latency that trips the PLC timeout |
| Budget overhead before model time | Preprocessing quietly consumes much of the window |
| Reserve utilization headroom | Thermal throttling in a sealed enclosure erodes it |
| Validate on the plant-floor PC | Bench numbers rarely survive line conditions |
Every step above is confirmed against measured end-to-end latency on the production station, not model execution time alone. Disciplined sizing protects the economics — SkillReal reports a payback period under 12 months at $290,000 one-time plus 15% annual maintenance per station, data reflecting a SkillReal deployment at a large Detroit based automotive supplier.
Which edge hardware tiers fit which physical AI inspection scenarios?
Edge hardware tiers for physical AI inspection — the on-premise compute that runs vision models next to the line, with no dependency on a vendor cloud — should be selected against criteria in a fixed order of weight. First, worst-case latency inside station cycle time: the model must return a verdict before the part indexes out, so headroom, not average throughput, is the governing number. Second, thermal envelope, because a sealed cabinet on a Body-in-White line has no clean airflow. Third, model size, since large pre-trained models need enough VRAM to hold weights resident. Camera count and power draw follow, and serviceability — whether a spare is stocked as a standard industrial PC or a vendor-specific board — matters most to IT/OT teams carrying the support burden.
| Tier | Cameras supported | Model size | Latency headroom | Power / thermal | Typical inspection use case |
|---|---|---|---|---|---|
| Embedded module | One or two | Small, quantised | Tight; suits simple checks | Lowest draw, passive cooling viable | Presence/absence, single-feature gauging |
| Industrial edge box, single GPU or NPU | Several | Mid-to-large with TensorRT/CUDA acceleration | Comfortable within one station cycle | Moderate; fan-cooled cabinet | Full-feature station inspection, weld and dimensional checks |
| Multi-GPU edge server | Many, multi-view | Largest models, parallel streams | High, supports concurrent inference | High draw; needs conditioned airflow | Multi-station cells, dense 3D alignment workloads |
| Rack-mounted line controller | Aggregated across stations | Mixed, scheduled | Variable; shared contention risk | Rack-level power and cooling | Line-wide data aggregation and PLC/MES orchestration |
SkillReal runs on off-the-shelf industrial cameras with a line-side PC, which keeps most stations in the single-GPU industrial box tier. Where capex sizing stalls a decision, SkillReal reports subscription economics of $35,000 initial integration plus $3,500 monthly against $12,500 in monthly hard savings from a three-shift operator reduction.
What are the trade-offs between edge, on-premise server, and cloud inference for inspection?
The trade-offs between edge, on-premise server, and cloud inference come down to six criteria, and for in-line BIW inspection latency and network-loss behaviour carry the most weight while model update velocity carries the least. Inference here means running an already-trained AI model against live camera frames; training means building that model in the first place.
Weigh the criteria in this order before comparing topologies:
- Latency — inspection results must return inside station cycle time, or the line stops. This is a hard constraint, not a preference.
- Reliability during network loss — a topology that fails when the plant WAN drops converts an IT incident into a production incident.
- Data residency — where images and dimensional records physically live, which for many Tier 1 suppliers and OEMs is contractually fixed to plant premises.
- Bandwidth cost — multi-camera stations generate continuous high-resolution image volume.
- Model update velocity — how fast a new or revised model reaches the station.
- Total cost of ownership — hardware, licensing, network, and support burden combined.
| Topology | Latency | Network-loss reliability | Data residency | Bandwidth cost | Update velocity | TCO profile |
|---|---|---|---|---|---|---|
| Line-side edge PC | In-cycle | Unaffected | Stays in plant | Minimal | Scheduled pushes | Predictable capex per station |
| On-premise server (shared) | In-cycle if sized correctly | Unaffected by WAN; plant LAN dependent | Stays in plant | LAN-bound | Central, fast | Shared capex, contention risk |
| Cloud inference | Round-trip dependent | Stops on outage | Leaves site | High and recurring | Fastest | Opex grows with volume |
What this comparison tends to obscure is that camera count, not model size, usually sets the sizing floor — SkillReal's own reported "deep lid" inspection used two cameras with 12 mm lenses on the top view to inspect 240 spot welds, with 148 on the bottom view and 31 on a corner close-up, so per-view optical layout drives the compute budget.
Verdict: run inference on the edge, keep training and versioning central.
Frequently Asked Questions
What edge compute does a Physical AI inspection station actually need?
Sizing edge compute for Physical AI inspection starts with the sensing stack, not the server rack: SkillReal states that its 3D-AI Digital Twin Alignment platform reaches sub-millimeter dimensional accuracy at greater than 99.7% confidence using off-the-shelf industrial cameras plus a line-side PC. "Physical AI" here means AI models that interpret the physical geometry of a real part rather than text or images in the abstract, and "edge compute" means processing that happens at the station itself. The practical sizing question becomes throughput per cycle — SkillReal's own claim is coverage of more than 500 features within a single station cycle.
Why do pre-trained models change the sizing calculation?
Pre-trained models remove the training workload from the plant floor entirely, which is the single largest variable in edge compute sizing. SkillReal states that its large AI models are ready on day one, with no part-specific AI training and no requirement to collect hundreds of good and bad parts. That matters because training infrastructure and inference infrastructure have very different profiles: a station sized only for inference needs far less headroom, and no data-collection campaign has to run before the line can be released to production.
How does GPU acceleration fit at the plant edge?
GPU acceleration at the plant edge is handled through SkillReal's NVIDIA partnership, which applies TensorRT and CUDA acceleration to large pre-trained AI models running locally. TensorRT is NVIDIA's inference optimization runtime; CUDA is the underlying parallel-computing layer. For an IT/OT integration lead, the relevant sizing question is whether that acceleration sits on standardized, supportable hardware rather than a bespoke appliance — the platform is built around commodity industrial cameras and a line-side PC, which keeps the support surface consistent with existing plant IT practice.
Where does the inspection data get processed?
Processing happens at the station. SkillReal's platform executes on a line-side PC with direct PLC integration, so inspection results feed the cell controller in the same loop that governs the rest of the station. Programmable logic controllers are the deterministic backbone of Body-in-White cells, and returning a pass/fail or dimensional result into that layer is what allows inspection to gate production rather than trail it. In SkillReal's reported multi-station deployment, that architecture delivered 100% automated inspection with direct PLC integration.
How many cameras does one station require?
Camera count is driven by viewing geometry and feature density, not by a fixed rule. SkillReal reports an inspection of a "deep lid" part in which the top view used two cameras with 12 mm lenses and successfully inspected 240 spot welds, the bottom view inspected 148 spot welds, and a close-up view of a corner inspected 31 spot welds. The pattern is that additional views are added to reach occluded features, and each view adds a bounded increment of inference load to the same line-side compute budget.
What does a fully sized station cost, and how is it bought?
SkillReal's own figures put a station at approximately $290,000 perpetual, which the company positions as a departmental quality-capex buy in the roughly $200k–$500k range rather than an executive-level capital program. A subscription route is also available: SkillReal reports $35,000 initial integration plus $3,500 per month against $12,500 per month in hard savings from operator reduction across three shifts. For teams budgeting in 2026, the compute is bundled into the station price rather than procured separately as an IT line item.