Back to all work Project 01 of 03
Research · 2026

Foundation Models for Predictive Maintenance

github.com/blozanod/TSFM-pdm-benchmark
18% lower RMSE than a tuned LSTM on remaining-useful-life prediction — zero-shot, with no per-dataset training
Abstract

Predictive-maintenance teams are being told to replace their bespoke LSTMs with pretrained time-series foundation models, usually on evidence that does not hold the evaluation fixed. I rebuilt the comparison end to end: identical windowing, identical normalisation, no target leakage, and an LSTM baseline tuned with the same compute budget the foundation models got for prompting. Zero-shot, the foundation model lands 18% lower RMSE on remaining-useful-life prediction; fine-tuned, the gap widens on the noisiest dataset and closes on the cleanest. The cost is real — two orders of magnitude more parameters and 25× the inference time — which is the trade the write-up is actually about.

Fig 1 — drop the RUL prediction plot
Fig 1 Predicted vs true remaining useful life, one held-out engine

Most published gaps come from evaluation drift, not modelling. I fixed the window length, the health-index normalisation and the train/test split before running anything, then gave the LSTM the same search budget as the prompt tuning — 40 Optuna trials each. Every number below comes from the same loader.

Fig 2 — drop the evaluation pipeline diagram
Fig 2 Evaluation pipeline — one loader, both model families

The advantage is not uniform: it concentrates at long horizons, where the LSTM has to extrapolate a degradation trend it only saw once. Inside 30 cycles of failure the two are indistinguishable — which matters, because that is the window a maintenance team actually schedules on.

TSFM holds up 10 30 50 80 120 high low
LSTM TSFM Fig 3 — RMSE vs horizon, cycles
Set A
Set B
Set C
Tuned LSTM TSFM RMSE · lower is better
Metric
LSTM
TSFM
RMSE, cycles
21.4
17.5
MAE, cycles
15.9
12.8
Parameters
1.2 M
205 M
Inference, window
3 ms
74 ms
What I'd do differently

I picked the datasets before deciding what question I was asking, so two of the three are too clean to separate the models — I'd choose noisier data with real maintenance logs next time. I'd also log inference cost from day one instead of measuring it at the end; the 25× latency gap is the most decision-relevant number in the whole benchmark and it nearly got left out.