Predictive maintenance hardware: which machine data needs a GPU and which does not
Eurokommerz, Vienna, since 2006: Private AI/ML · IT Managed Services · Enterprise Training · AI Hardware & Software
- Low-rate process values such as temperatures, currents and pressures add up to about 0.35 MB per signal and day at one value a second by our estimate, and threshold, statistical and tree models on them run on a CPU
- Vibration is sampled thousands of times a second: the Case Western Reserve bearing data was recorded at 12,000 and 48,000 samples per second, about 2.1 and 8.3 GB per channel and day if recorded without pause, by our arithmetic at 16 bits
- The DCASE 2025 baseline for anomalous machine sounds is a dense autoencoder on log-mel spectrograms with 267.9k parameters and about 165.8M multiply-accumulates per 10-second clip, small enough to test on a CPU first
- Time-series foundation models are small as well: Chronos-2 has 120M parameters and runs on GPU or CPU, TimesFM 2.5 0.2B, MOMENT-1-large about 0.3B with anomaly detection among its tasks
- A GPU earns its place for camera checks, for many high-rate channels on deep models, for training on months of data and for a language model that turns alarms into maintenance notes; the 72 W NVIDIA L4 with 24 GB is the usual edge card
Supplied by Eurokommerz: RTX PRO 6000 and H200 NVL Check price and availability →
Which predictive maintenance tasks need a GPU
Predictive maintenance needs a GPU only for some kinds of machine data: temperatures, motor currents, pressures and counters that arrive once a second or less are analysed with thresholds, statistics or classical machine learning on an ordinary processor. A GPU starts to pay for vibration and sound on many high-rate channels, camera images of wear, foundation models fine-tuned on your own history and a language model that writes maintenance notes. At the line that is an NVIDIA L4 or an RTX PRO 4000 SFF; centrally, a server with NVIDIA RTX PRO 6000 Blackwell Server Edition cards.
We wrote this for the head of maintenance or production who has sensor data and a supplier pitch on the table, and for the IT and OT team that has to place the hardware. The first sections sort the data by type and volume, the later ones give the configurations and the technical notes. Figures from vendors and datasets are named with their source; data volumes and power are our estimates, labelled as such.
Data per machine and day: the first sizing input
The amount of data a machine produces decides where it can be analysed. A sensor that sends one value a second produces little, while an accelerometer on a bearing housing produces a stream that a network and a disk notice. The Case Western Reserve University bearing data centre, a public data set used in many papers on bearing faults, describes its test stand with a 2 hp motor: "Digital data was collected at 12,000 samples per second", and for drive-end bearing faults also at 48,000.
| SIGNAL | RATE | PER CHANNEL AND DAY | WHERE TO START |
|---|---|---|---|
| Process values | 1 value per second | about 0.35 MB | CPU, existing server |
| Vibration, continuous | 12,000 samples/s | about 2.1 GB | CPU test at the edge |
| Vibration, continuous | 48,000 samples/s | about 8.3 GB | edge node, GPU if the model needs it |
| Vibration, 10 s every hour | 12,000 samples/s | about 5.8 MB | CPU |
| Sound, continuous | 16,000 samples/s | about 2.8 GB | CPU test, GPU for many microphones |
| Camera images | per part or per stream | depends on resolution | GPU at the line |
Sampling rates of 12,000 and 48,000 per second from the Case Western Reserve University bearing data centre (apparatus and procedures page, read 25 October 2026); 16,000 per second for sound is an example value. Our arithmetic: 4 bytes per process value, 2 bytes (16 bits) per vibration or sound sample, 86,400 seconds a day.
The arithmetic is simple. A process value stored as a 4-byte number once a second gives 4 × 86,400 = 345,600 bytes a day. One vibration channel at 12,000 samples a second and 2 bytes per sample gives 24,000 bytes a second and about 2.07 GB a day. A machine with three axes on two bearings has six such channels, and a hall with 50 such machines about 622 GB a day by our estimate. A system that records snapshots instead, ten seconds every hour, stores 240 seconds a day, about 5.8 MB per channel.
Count the channels, the sampling rate and the recording pattern per machine before anyone talks about cards. Continuous high-rate data is usually reduced at the machine to features or spectra, and only those travel to the central server.
Anomaly detection on process values with classical models
Most of what a maintenance team monitors first is process data from the control system: spindle load, motor current, oil and bearing temperatures, hydraulic pressure, cycle counts. A rising bearing temperature at constant load, a current that drifts over weeks or a pressure that takes longer to build up are detected with limits, moving averages, regression against load and classical anomaly detection such as an isolation forest. Gradient-boosted trees predict remaining time to a known failure where enough failures have been recorded.
These models run on a processor. Training them on a year of minute values from a few hundred machines is a job for a normal server, and scoring them once a minute is negligible load. If data sets grow, NVIDIA's cuML library offers an accelerator mode that, in its documentation's words, "runs supported scikit-learn, UMAP, and HDBSCAN workloads on an NVIDIA GPU without changing the Python code" and "transparently falls back to the original CPU implementation when an estimator or operation cannot be accelerated". It is started with python -m cuml.accel script.py. That is a way to test whether a GPU shortens your training runs on data you already have.
For this tier, the hardware question is mostly the historian and the data path from the control network, which the IT notes below cover.
Vibration and sound analysis with deep learning
High-rate vibration and sound carry the early signs of bearing, gear and pump damage. A common approach turns each recording into a spectrogram, an image of frequencies over time, and trains a model on recordings of the machine in good condition; a recording the model cannot reconstruct or classify well is flagged.
The DCASE challenge, a research competition on sound analysis, publishes such a setup. Its 2025 task 2 on "first-shot unsupervised anomalous sound detection" trains on normal sounds only, from machine types such as fans, gearboxes, bearings, slide rails and valves, with clips of 10 or 12 seconds and 990 normal training clips per section. The baseline is a dense autoencoder on log-mel spectrograms with 128 mel bands, 64 ms frames and five frames per input vector. The task page gives about 267.9k parameters and about 165.8M multiply-accumulate operations for one 10-second file, about 0.33 billion floating-point operations by our arithmetic at two per multiply-accumulate. A model of that size needs no GPU for scoring.
The GPU earns its place in three situations, and a test on your data shows which one applies:
- Many channels, continuously. Dozens of machines with several accelerometers or microphones each, scored continuously on a convolutional or transformer model, can exceed what the processor of an edge PC handles. Run one day of recorded data through the model on that processor first; if it keeps up with a margin, no card is needed.
- Training. Training deep models on months of high-rate recordings, and retraining after a machine rebuild, is a GPU job on the central server.
- Larger pretrained models. Foundation models for audio and time series run faster on a card, and fine-tuning them on your machines needs one.
Where the edge node needs a card, the NVIDIA L4 has 24 GB, a 72 W maximum and a single-slot, low-profile format on PCIe Gen4, according to NVIDIA's product page. It is a passive card for edge servers with server airflow, as our guide to AI servers for manufacturing explains; in an industrial PC without that airflow, the actively cooled RTX PRO 4000 SFF with 24 GB at 70 W is the card to check against the PC maker's list.
We supply the L4, the RTX PRO 4000 SFF and the RTX PRO 2000 for edge systems you already run, after a compatibility check of platform, power and cooling; send us your machines, sensors and sampling rates and our team replies with a placement and the cards for it.
Cameras for wear, leaks and surface damage
Camera checks are the data type in this article that usually needs a card at the line. A camera over a tool, a belt, a coupling or a hydraulic line takes images at fixed intervals or as video, and a visual anomaly model trained on images of the part in good condition marks wear, cracks, leaks or missing parts. anomalib, an open-source library under Apache 2.0, collects such models, PatchCore and PaDiM among them; its release 2.7.0 installs with options for CPU, CUDA 12.6 and CUDA 13.0, according to its GitHub page. Our guide to visual anomaly detection with anomalib on a GPU covers the models and their memory, and our guide to visual inspection without data scientists covers the project side.
Video streams load the card's decoders before its compute. The L4 has four NVDEC video decoders, four JPEG decoders and two NVENC encoders by NVIDIA's product page, which suits a few cameras per edge node. Many cameras on one server is a video-analytics task, sized in our guide to the GPU server for video analytics.
Time-series foundation models for machine data
Time-series foundation models are pretrained on large collections of series and forecast or analyse a new series without training a model per machine. Three are published with open licences, and all three are small next to language models.
| MODEL | SIZE | LISTED TASKS | LICENCE |
|---|---|---|---|
| Chronos-2 | 120M parameters | forecasting with covariates | Apache 2.0 |
| TimesFM 2.5 | 0.2B parameters | forecasting | Apache 2.0 |
| MOMENT-1-large | about 0.3B, 1.39 GB file | forecasting, classification, anomaly detection, imputation | MIT |
Hugging Face model cards amazon/chronos-2, google/timesfm-2.5-200m-pytorch and AutonLab/MOMENT-1-large and the MOMENT file list, read 25 October 2026.
Amazon's model card describes Chronos-2 as "a 120M-parameter, encoder-only time series foundation model for zero-shot forecasting", "delivering over 300 time series forecasts per second on a single A10G GPU" and "supporting both GPU and CPU inference". Forecasting suits slow trends, such as the rise of a temperature or a wear measure towards a limit. MOMENT lists anomaly detection, classification and imputation among its tasks, and its model card says all variants were trained on a single RTX A6000. The Chronos-2 and TimesFM model cards do not list anomaly detection.
Memory does not limit these models: the 1.39 GB MOMENT file fits every card we supply, and a MIG instance of an RTX PRO 6000 Server Edition, a quarter of the card with 24 GB, holds it with room for batches. What decides between CPU and GPU is the number of series, how often they are scored, and whether you fine-tune on your own history. Our guide to AI servers for energy and utilities shows the same models for load forecasting.
From an alarm to a maintenance note
The part of predictive maintenance that most often needs a large GPU is the language model. An alarm with its trend, the machine's manual, the spare-parts list and the history of earlier repairs are put together into a draft maintenance note: likely cause, checks to run, parts to prepare, and the pages of the manual to read. A technician approves or corrects it, and the note goes into the maintenance system.
This is retrieval over your documents with a language model, as our guide to RAG on company data describes. OpenAI publishes gpt-oss-120b under Apache 2.0 with 117B parameters, 5.1B of them active per token. Its safetensors files add up to about 65 GB, 60.8 GiB. By our users-per-card rule, which takes 90 per cent of the 95.6 GiB the driver reports on an RTX PRO 6000, less 3 GiB per card and less the weights, it leaves 22.2 GiB for the cache on one card, enough for 39 conversations of 16,384 tokens at the same moment with a 16-bit cache. Maintenance notes are a modest load next to that, so the same card can serve an assistant over the manuals for the whole maintenance team. Our guide to an AI service assistant for machine builders covers the same pattern from the side of the company that builds the machines.
Hardware by tier: none, edge, central
| TIER | WHAT RUNS THERE | HARDWARE | POWER (ESTIMATE) |
|---|---|---|---|
| No GPU | limits, statistics, trees on process values | existing server or VM | no extra |
| Edge node per line or hall | vibration and sound models, camera checks | one L4, or RTX PRO 4000 SFF in an industrial PC | 72 W or 70 W per card |
| Central entry server | training, foundation models, LLM notes and manuals assistant | 2 × RTX PRO 6000 Server Ed., 384 GB | about 1.8 kW |
| Central four-card server | the same plus more training and several plants | 4 × RTX PRO 6000 Server Ed., 768 GB | about 3.4 kW, 2.7 kW at 450 W |
Card power from NVIDIA's product pages; server power by our estimate (cards at 600 W, two AMD EPYC processors, plus 15 per cent for the rest of the server), to be confirmed by a measurement on the delivered system. Reference configurations as on our AI servers page.
No GPU. A maintenance team that starts with process values and a few vibration snapshots per day needs no card. Spend the effort on clean data from the historian and on recording failures.
Edge node. Where continuous vibration, sound or cameras are scored at the line, one L4 per node in an edge server with server airflow, or an RTX PRO 4000 SFF in an industrial PC, keeps the scoring next to the machine. The node keeps working when the link to the data centre fails.
Central entry server. Our entry configuration has two RTX PRO 6000 Server Edition cards, two AMD EPYC processors, 384 GB of DDR5 ECC and two NVMe drives. One card runs gpt-oss-120b for maintenance notes and the manuals assistant; the other is split by MIG into four isolated 24 GB instances for training signal and image models, foundation models and tests. By our estimate it draws about 1.8 kW and fits one 230 V 16 A feed, which carries 2.94 kW at 80 per cent.
Central four-card server. With several plants, larger image models or a training queue that keeps two instances busy, the inference node with four cards and 768 GB gives training and the language model whole cards. It needs 32 A or three-phase, as our guide to GPU server power on 16 A, 32 A and three-phase feeds explains.
The RTX PRO 6000 Max-Q is the workstation card, a 300 W blower card; in a rack it belongs only in a chassis whose maker lists it, and for continuous operation we recommend the Server Edition. Our Private AI/ML service sets up the language model, retrieval and the connection to your maintenance system; describe your machines and the data you already collect, and we propose where each model should run.
Notes for the IT and OT team
- Network zones. Edge nodes at the line usually belong to the zone of their cell, and the central server to IT. Model packages down and features, images or alarms up pass through a defined conduit in the sense of IEC 62443-3-2, as our manufacturing guide explains; the plant's risk assessment sets the zones. Our guide to network segmentation covers the OT zone and its DMZ.
- Data path. Read process values from a copy of the historian, not from the controllers. Reduce high-rate signals at the edge to features or spectra and keep raw recordings only around events, so that the uplink carries a few MB per channel and day instead of the full stream.
- Software versions. Pin the driver branch, the CUDA release and the container image per card type, and test updates on a staging node in a planned production stop. anomalib 2.7.0 offers CUDA 12.6 and 13.0 builds and requires PyTorch 2.10 or later by its release notes; the driver must support the card generation, as our guide to RTX PRO Blackwell software support explains for the Blackwell cards.
- MIG. An RTX PRO 6000 Server Edition splits into up to four isolated instances, so training jobs and tests do not disturb the language model on the other card. Our guide to RTX PRO 6000 MIG profiles lists the profiles.
- Validation. Keep a record of every failure and repair with its date, machine and cause. That record is what you compare the model's alarms against in a pilot with clear metrics.
What we supply
You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We supply the L4, RTX PRO 4000 SFF and RTX PRO 2000 for edge nodes and build central AI servers to order with two, four or eight RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered within the EU 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. Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up the language model and retrieval on top. The L4 server guide and our comparison of the L4 and the RTX PRO 4500 Server Edition help with the card choice.
FAQ
Do I need a GPU for predictive maintenance?
What are the hardware requirements for predictive maintenance?
Which GPU is suitable for vibration analysis with deep learning?
Do time-series foundation models like Chronos need a GPU?
Can predictive maintenance run on premise without the cloud?
How much power does a predictive maintenance GPU setup need?
We supply L4 and RTX PRO cards for edge nodes and build central AI servers for predictive maintenance and maintenance assistants. Describe your task in a few sentences and our team will help. We reply within one business day. The first call is free.
Talk to an expertWe reply within one business day