End-to-end forecasting with TimesFM 2.5 (MarkTechPost)
A runnable Colab walkthrough of TimesFM 2.5 published by marktechpost on 2026-08-01, and the first source in this wiki that spends most of its length on how to tell whether a model works rather than on how to build one (time-series-forecasting).
What it does
Generates a synthetic retail dataset — 1,200 days × 6 stores, with trend, weekly and yearly seasonality, price elasticity, promotions, holidays, temperature and noise — trains on nothing (the model is zero-shot), and holds out 56 days. Then it runs the model through nine exercises:
Zero-shot forecast. model.forecast(horizon=HORIZON, inputs=[train]) returns a point array and
a (n_series, horizon, 10) quantile array.
Scoring. MAE, RMSE, MAPE, sMAPE and MASE for the point forecast; pinball loss and 80% prediction-interval coverage for the probabilistic one. Baselines are seasonal-naive (repeat the last 7-day cycle) and last-value.
Rolling-origin backtest. Six folds (three in fast mode), each a 56-day test window stepped backwards by 56 days, aggregated over 36 store-fold combinations. The reported result is a MASE reduction against seasonal-naive, with the size depending on configuration.
Context ablation. max_context ∈ {64, 128, 256, 512, 1024} days: accuracy rises and then
plateaus while inference cost keeps climbing — 512-context runs about 2× faster than 1024 at
per_core_batch_size=16. This is the one result here with a real decision attached to it.
Covariates (XReg). Dynamic numerical (price, temperature), dynamic categorical (promotion,
holiday, day-of-week) and static categorical (store, region), fused either as
xreg + timesfm (regress first, then forecast the residual) or timesfm + xreg (forecast first,
then correct), both compared to the univariate baseline, with ridge=1.0.
Anomaly detection. Compare the observed value to the 80% interval: inside is OK, outside is WARNING, beyond ±1.5× the interval width is CRITICAL. Run against injected spikes, outages and level shifts, it flags about 20% of points on the anomaly-injected series. This is forecasting reused as monitoring — the model supplies the expected band and the residual does the alerting.
Long horizon. Direct 256-day forecast versus recursive 64-day chunks fed back into context; direct generally wins, which is what error accumulation predicts.
Throughput and robustness. Series/second across batch sizes 1–48;
force_flip_invariance=False claimed to roughly double throughput on strictly positive series.
Then NaN handling, very short contexts (8–128 days), positive clipping via infer_is_positive,
determinism across repeated calls, and a warning that forecast() mutates the input list.
Outputs land as a forecast CSV and a JSON of backtest, ablation and throughput results.
The production checklist is the part that transfers
Quoted: “regular spacing, one row per period, gaps as NaN (not dropped rows); max_context multiple of 32; quantile index 0 = MEAN, 1..9 = q10..q90, 5 = median.”
None of that is about forecasting. It is the shape of the data contract, the alignment requirement of the model’s patching, and an API indexing convention that will silently produce plausible wrong answers if misread — the class of detail demo-to-production-gap argues is what actually decides whether a demo survives contact with a real pipeline. A tutorial that ships the checklist alongside the notebook is doing something the corpus’s other sources don’t.
What the numbers are worth
The data is synthetic and the tutorial generated it. Every accuracy claim here — MASE below 1, the backtest improvement, the covariate comparison — is measured on a series whose seasonality, elasticity and noise the author chose. Beating seasonal-naive on a series built from a weekly cycle plus noise demonstrates that the code runs, not that the model forecasts demand. The spoke’s standing benchmark caveat applies at full strength, and then some: this isn’t a vendor’s number on a vendor’s hardware, it’s a number on a vendor-shaped problem with no real data anywhere in it.
What survives that: the method. Rolling-origin backtesting, MASE against a seasonal-naive baseline, pinball loss and interval coverage are the right apparatus regardless of which series they’re pointed at, and the corpus had none of them written down.
T3. A practitioner tutorial from an AI-news outlet: code is specific and runnable, the API surface and configuration flags are checkable against the library, and the evaluation design is sound. Against that, no real dataset, no comparison to established forecasting baselines beyond seasonal-naive (no ARIMA, no ETS, no gradient-boosted tabular baseline), no independent replication, and the throughput claims are unmeasured by anyone else. Read it as a reference implementation, not as evidence about TimesFM’s accuracy.
Related
timesfm · time-series-forecasting · demo-to-production-gap · fine-tuning · ml-system-design · marktechpost · synthesis