Predictive maintenance inference is the step where a trained failure-prediction model scores live machine data and turns the score into a maintenance action. In 2026 most teams run that inference in three places: on the edge next to the asset for fast anomaly alerts, in a plant or cloud cluster for remaining-useful-life forecasts, and inside AI agents that open work orders. Getting this production layer right matters more than picking the model.
Updated October 2026
What changed in 2026
- A managed PdM service was retired. AWS discontinued support for Amazon Lookout for Equipment on 7 October 2026, so teams that relied on it must now run their own model serving and inference pipeline (AWS).
- Generative AI joined the maintenance desk. Siemens extended its Industrial Copilot with a maintenance offering built on Senseye Predictive Maintenance and says first pilots cut reactive maintenance time by an average of 25% (Siemens, March 2025).
- Edge hardware got much stronger. NVIDIA's Jetson AGX Thor became available in August 2025 with up to 2,070 teraflops of AI compute and 128 GB of memory in the T5000 module, enough to run vision and language models beside a production line (TechRepublic).
- Inference now dominates AI compute. Deloitte expects inference to make up two-thirds of all AI compute in 2026 (Deloitte TMT Predictions 2026). Maintenance models are part of that shift from training to running.
Why inference is the hard part of predictive maintenance
Most predictive maintenance projects do not fail in the notebook. They fail when the model meets the plant. Sensor data arrives late or with gaps, machines get new firmware, and alerts reach a technician who cannot see why the model flagged the pump. The business case is real: Deloitte's position paper cites average gains of 25% higher productivity, 70% fewer breakdowns and 25% lower maintenance costs (Deloitte). You only see those gains if predictions run reliably, every minute, on every asset.
If you are new to the topic, start with our pillar guide to predictive maintenance with IoT. This post focuses on the next step: deploying and running the models.
The three inference patterns
| Pattern | What runs | Where | Typical latency | Example output |
|---|---|---|---|---|
| Streaming anomaly detection | Autoencoders, isolation forests, small time-series models | Edge gateway or industrial PC | Milliseconds to seconds | "Vibration on motor 4 is outside its normal pattern" |
| Batch remaining useful life (RUL) | Gradient boosting, LSTMs, temporal transformers | Plant server, private cloud or lakehouse | Minutes to hours | "Bearing has an estimated 12 to 18 days left" |
| Agentic diagnosis | LLM or vision-language model plus tools | Private cluster near the data | Seconds | "Likely cause is misalignment; draft work order and parts list" |
Most mature programs use all three. The edge model raises the flag, the batch model estimates how much time is left, and an AI agent explains the issue and drafts the work order for a human to approve.
Reference architecture for PdM inference
1. Ingest and clean at the edge
Collect vibration, temperature, current, pressure and acoustic data through OPC UA or MQTT. Filter, resample and compute features (RMS, kurtosis, FFT bands) at the edge so you send features, not raw waveforms. Our guide to edge data management covers this layer.
2. Serve models where the latency budget says
Package each model as a versioned container. Run the fast anomaly model on the gateway. Run RUL models on a central endpoint; if your data already sits in a lakehouse, managed endpoints such as Databricks Model Serving are one option. For sites with strict data rules or weak connectivity, run the same container on-premises.
3. Keep features consistent
The biggest silent bug in PdM is training-serving skew: features computed one way in training and another way in production. Use one feature definition for both, and log the exact feature values used for each prediction.
4. Turn scores into actions
A score alone does nothing. Set thresholds per asset class, route alerts to the CMMS or EAM system, and attach evidence such as the sensor trend and the top contributing features. This is where AI agents help: they can read the alert, check the maintenance history and propose a fix, while a planner approves it.
5. Monitor and retrain
Track data drift (a new sensor or firmware changes the signal), prediction drift and, most importantly, outcomes: did the predicted failure happen? Feed confirmed failures and false alarms back into training. See MLOps for edge AI for rollout, rollback and fleet updates.
Edge vs cloud inference for maintenance
| Factor | Edge inference | Central inference |
|---|---|---|
| Latency | Best for safety trips and fast alerts | Fine for daily RUL and fleet planning |
| Bandwidth | Sends features and alerts only | Needs reliable uplink for raw or feature data |
| Model size | Small models, quantized | Large models, ensembles, LLMs |
| Fleet view | One asset or line | Compare across plants and asset classes |
| Data control | Data stays on site | Depends on where the cluster runs |
For a deeper comparison, see edge vs fog vs cloud computing. Many plants also feed predictions into a digital twin so planners can see asset health on a model of the line.
Common mistakes to avoid
- Training on too few failures. Real failures are rare. Combine anomaly detection (which needs only normal data) with supervised models once you have labeled events.
- Ignoring operating context. A motor at full load looks different from one idling. Include load, speed and product type as features.
- Alert floods. If technicians get 50 alerts a shift, they stop reading them. Start with high thresholds and tune with the maintenance team.
- No owner for the model. Assign who approves a new model version and who is on call when inference stops.
- Locking into one managed service. The Lookout for Equipment retirement shows why portable containers and open model formats matter.
For the latency side of these choices, see our companion guide on real-time AI inference.
Where it's heading: 2026 → 2030
| When | What it looks like |
|---|---|
| Around 2020 | Condition monitoring dashboards and threshold alarms; ML pilots on a few critical assets, mostly batch scoring in the cloud. |
| 2026 (now) | Edge anomaly models plus central RUL models; generative AI copilots explain alerts and guide repairs; teams move off retired managed services to portable serving. |
| By 2028 (expected) | Our view: AI agents handle the loop from alert to draft work order to parts check for routine faults, with humans approving. Vision and acoustic models run on edge devices alongside sensor models. |
| By 2030 (expected) | Our view: maintenance becomes prescriptive by default; models recommend operating changes (slow the line, swap a tool) to extend life, and plants share anonymized failure patterns across sites. |
How NexaStack helps
NexaStack is a platform to deploy, run and govern AI models and agents across edge devices, plant servers and private cloud. For predictive maintenance, that means one way to ship anomaly and RUL models to gateways and clusters, roll back a bad version, monitor drift and keep sensor data inside your network. Agents built on NexaStack can read alerts and draft work orders under the policies you set. Learn more about our Edge AI solution.
Frequently asked questions
What is inference in predictive maintenance?
Inference is running a trained model on new sensor data to produce a prediction, such as an anomaly score or remaining useful life. Training builds the model; inference uses it in production, continuously.
Which algorithm is best for predictive maintenance?
There is no single best one. Autoencoders and isolation forests work well for anomaly detection with little failure data. Gradient boosting and LSTM or transformer models suit remaining-useful-life prediction once you have labeled failures.
Should predictive maintenance models run at the edge or in the cloud?
Usually both. Run fast anomaly detection at the edge for low latency and lower bandwidth, and run heavier remaining-useful-life and fleet models centrally.
What replaces Amazon Lookout for Equipment?
AWS ended support on 7 October 2026. Teams typically rebuild with their own models served on a general ML platform, in the cloud or on-premises, using portable containers so they are not tied to one service again.
What are the latest predictive maintenance trends in 2026?
Generative AI maintenance copilots, more powerful edge AI hardware, AI agents that create work orders, vision and acoustic monitoring, and a move from managed point services to portable, governed model serving.
Put your maintenance models into production
Book a NexaStack demo to deploy and govern predictive maintenance models from edge to cloud →
