Time-Series Foundation Models for Predictive Maintenance: Sizing the Stack
Overview
Predictive maintenance has failed in most Indian factories for an unglamorous reason: it required training a separate model for every asset class, and nobody had the labelled failure data or the data science headcount to do it. Time-series foundation models change that economics. Pretrained transformers now forecast sensor behaviour zero-shot, without asset-specific training, and reported throughput is high enough that a single GPU covers a substantial plant. This article sets out what these models do, where they are weak, and how to size the infrastructure around them.
Key takeaways
- Zero-shot removes the per-asset training burden — the barrier that stalled most predictive maintenance programmes.
- Model sizes are small — from roughly 9 million to 710 million parameters, so GPU memory is rarely the constraint.
- Multivariate matters industrially — vibration, temperature and current interact, and univariate-centric models handle that poorly.
- Reported throughput is high — over 300 forecasts per second on a single GPU for a production-grade model.
- Forecasting is not diagnosis — anomaly detection tells you something changed, not what to do about it.
What changed in the model landscape
Until recently, forecasting a machine’s vibration signature meant fitting a statistical model or training a neural network on that machine’s history, per asset, per failure mode. Foundation models pretrained on large heterogeneous time-series corpora now generalise across signals they have never seen. The 2026 landscape includes Amazon’s Chronos-2, Google’s TimesFM, Salesforce’s MOIRAI family and several others, and benchmark work reports these models beating tuned statistical baselines out of the box.
The operational significance is the removal of a per-asset cost. A plant with 400 monitored machines across 30 asset classes previously faced 30 modelling projects; with a zero-shot model it faces one deployment plus a validation exercise. That is the difference between a programme that finishes and one that stalls after the pilot line.
Univariate versus multivariate: the industrial catch
The most important selection criterion for industrial use is whether the model handles interacting signals. Machine health is rarely visible in one channel: a bearing failure shows as a change in the relationship between vibration, temperature and motor current, not necessarily as an anomaly in any one of them. Published analysis notes that TimesFM 1.0 and 2.0 are fundamentally univariate-centric, and that Chronos-2 or the MOIRAI mixture-of-experts variants have the edge where multiple sensors interact.
For a maintenance programme, that is close to decisive. Evaluate candidates specifically on multivariate performance using your own sensor sets rather than on headline benchmark rankings, which are dominated by univariate datasets. A model that ranks first overall may be the wrong choice for a plant floor.
Sizing the GPU tier
| Plant profile | Monitored signals | Forecast cadence | Indicative compute |
|---|---|---|---|
| Single line pilot | Under 500 | Every few minutes | One entry GPU, shared |
| Single plant | 2,000-10,000 | Every minute | One dedicated GPU |
| Multi-plant enterprise | 50,000+ | Every minute | Small GPU server, central |
| High-frequency vibration | Fewer signals, high rate | Continuous | Edge GPU near the asset |
| Fine-tuning and evaluation | Periodic | Weekly to monthly | Shared or rented capacity |
These models are small by contemporary standards — the largest in the Chronos family is reported at 710 million parameters — so memory is rarely the binding constraint. With reported throughput above 300 forecasts per second on a single GPU, a plant with 10,000 signals forecast every minute needs roughly 170 forecasts per second, comfortably within one accelerator. The scaling factor to watch is forecast frequency, not signal count.
Where the edge tier belongs
Most predictive maintenance forecasting can be centralised, because the data rates are modest and the latency requirement is minutes rather than milliseconds. The exception is high-frequency vibration analysis, where raw sampling rates in the kilohertz range make it impractical to ship everything to a central system. There the pattern is edge preprocessing — extracting spectral features locally — with only the derived features forwarded.
That split has a useful side effect for Indian plants with unreliable connectivity: edge preprocessing means a network outage degrades resolution rather than stopping monitoring entirely. The edge hardware and environmental discipline is the same as for vision workloads, covered in the manufacturing vision AI edge deployment playbook.
Forecasting is not diagnosis
The honest limitation of this approach deserves emphasis. A time-series foundation model tells you that a signal is deviating from its expected trajectory. It does not tell you which component is failing, how long you have, or what to do. Bridging that gap requires either labelled failure history, which most plants lack, or engineering knowledge encoded as rules, or a maintenance engineer looking at the alert.
The productive pattern is therefore a two-stage system: foundation model detects deviation and ranks assets by anomaly severity, and a retrieval layer over maintenance manuals, past work orders and SOPs helps the technician interpret it. That second stage is a RAG problem, and the same on-premises knowledge stack described in shop-floor copilots for maintenance and SOP knowledge serves it directly.
Deploying this in an Indian plant
Four practical steps. Start with instrumentation quality, not models — a forecasting model on badly calibrated or intermittently reporting sensors produces alerts nobody trusts, and trust lost early is hard to recover. Second, establish a baseline period of normal operation per asset before enabling alerts; zero-shot models need context even when they need no training.
Third, tune alert thresholds against the maintenance team’s tolerance for false positives, which is typically much lower than data scientists expect. A system generating twenty alerts a day will be ignored within a fortnight. Fourth, close the loop: every alert should be dispositioned by a technician and that disposition recorded, because those records become the labelled dataset that eventually enables genuine diagnosis. The broader programme framing is in AI infrastructure for manufacturing.
Frequently asked questions
What is a time-series foundation model?
A transformer pretrained on large heterogeneous time-series data that forecasts signals it has never seen, without asset-specific training. For predictive maintenance this removes the per-asset modelling cost that stalled most programmes.
Which model should an industrial plant choose?
One that handles multivariate signals well, since machine health typically shows in the relationship between vibration, temperature and current rather than in any single channel. Evaluate candidates on your own sensor sets, not on headline benchmarks dominated by univariate datasets.
How much GPU does predictive maintenance need?
Less than most teams expect. These models range from roughly 9 million to 710 million parameters, and reported throughput exceeds 300 forecasts per second on a single GPU. A plant with 10,000 signals forecast every minute needs around 170 per second.
Should forecasting run at the edge or centrally?
Centrally for most signals, since data rates are modest and latency tolerance is minutes. High-frequency vibration is the exception: preprocess at the edge to extract spectral features and forward only those, which also degrades gracefully when connectivity fails.
Can these models diagnose the fault?
No. They detect that a signal is deviating from its expected trajectory. Diagnosis needs labelled failure history, encoded engineering knowledge or a technician. A practical system pairs anomaly ranking with a retrieval layer over manuals and past work orders.
Ready to deploy?
Talk to an RDP architect about power, cooling and lead time.