mrkeyoor.com_
Sun 16 Aug 14:46 UTC
Dataevaluationupdated 16 Aug 2026

timesfm

TimesFM is Google's pretrained model for predicting the future values of a single time series, such as weekly sales or sensor readings, without first training a model on that series. The open Python package supplies point forecasts and uncertainty ranges, with optional covariates for known influences such as prices, holidays, or region.

google-research/timesfm · ★ 27,573 · Python · v2.0.2 · reviewed by Keyoor

Verdict

TimesFM 2.5 is an excellent baseline generator: small enough for ordinary machines, easy to call, and capable of point and quantile forecasts with no task-specific training. It should earn a place in a forecasting bake-off, not automatic control of purchasing, staffing, or risk decisions. Use the core univariate forecast first, beat a naive seasonal baseline honestly, and treat XReg as experimental until your own leakage and batch-isolation tests pass.

Setup4/5Simple Torch install and API, followed by an on-demand model download
Docs4/5Clear examples and an extensive forecasting skill, with version drift
Community4/5Large adoption and active fixes, though issue responses are uneven
Maturity4/5Research-backed model with tests, but the open package lacks support

Who it’s for

Data scientists who need a strong zero-shot baseline before building a specialized forecasting model.
Teams forecasting many unrelated univariate series and wanting one shared model instead of per-series tuning.
Python users who need point estimates plus quantile ranges from a local Apache-licensed checkpoint.
Researchers comparing foundation models against ARIMA, ETS, boosted trees, and domain-specific baselines.

Who it’s NOT for

Teams that need an officially supported Google product: the README and model card explicitly say the open release is not one, and direct support-sensitive users toward BigQuery ML.
Analysts who need interpretable coefficients, causal effects, vector autoregression, classification, or clustering: TimesFM's core job is univariate forecasting, not those tasks.
Production users relying on covariates without strict backtests: open reports describe possible test leakage and forecasts changing with batch composition in forecast_with_covariates, with the latter reproduced on TimesFM 2.0.
High-throughput teams assuming the smaller 2.5 checkpoint is automatically faster: one open L40S report measured its batch inference around 15 times slower than 2.0 in that configuration.
CPU-only users who specifically need Flax or XReg and expect the extras to install cleanly: issue #443 reports that both dependency groups hardcode jax[cuda].

Setup reality

The basic Torch path is refreshingly small: install timesfm[torch], download the roughly 800 MB 2.5 checkpoint on first use, compile it with context and horizon limits, then pass arrays to forecast. CPU use is possible, while GPU, TPU, and Apple Silicon need the appropriate PyTorch or JAX backend installation. The real work begins after the demo: clean timestamps and missing values, choose a defensible history window, prevent future information from entering covariates, compare against simple baselines, calibrate intervals on your own data, and monitor errors by horizon and series type.

A foundation model that makes a good first forecast

TimesFM gives time-series teams a useful new default: before tuning a separate model for every demand curve, metric, or sensor, run one pretrained model across them and see what it knows. Version 2.5 accepts between one and 16,384 historical points, produces up to 1,000 future points, and uses 200 million parameters. An optional 30 million-parameter head returns quantiles, so the output can include ranges rather than one deceptively precise line.

The basic interface is direct. Load the checkpoint from Hugging Face, compile it with maximum context and horizon values, then pass a list of one-dimensional NumPy arrays. The result contains a point forecast and quantile forecasts. Inputs can have different lengths within a batch, which suits collections of products or devices that did not all start at the same time. The model no longer needs a frequency indicator, removing one choice that users had to make in earlier releases.

This is the project's strongest use: a common zero-shot baseline. It is much faster to deploy than training hundreds of local neural models, and it can expose where a classical seasonal forecast is already sufficient. The right question is not whether a foundation model sounds more advanced. It is whether TimesFM improves the errors and uncertainty calibration that matter for a particular decision.

Installation is easy, evaluation is not

For the Torch path, installation is one package extra. The 2.5 checkpoint is about 800 MB and downloads from Hugging Face on first use. The repository's contributed forecasting skill recommends at least 4 GB of system memory for CPU use and 2 GB of GPU memory, though workload size and batch configuration change the practical requirement. The code also offers a Flax backend, and users can install XReg for covariate forecasting.

Naming takes a moment to untangle. TimesFM 2.5 is the latest model, while the July 2026 PyPI package and GitHub release are numbered 2.0.2. Older 1.0 and 2.0 code lives under v1, and the README points users of those checkpoints to package version 1.3.0. Pin the package and checkpoint together in production rather than assuming model and library version numbers match.

The sample configuration turns on input normalization, continuous quantiles, sign-flip invariance, positive-value inference, and quantile-crossing correction. Those flags are sensible starting points, not universal truths. Positive clamping is wrong for temperatures, profit changes, and other series that may cross zero. Context and horizon limits affect compilation and resource use. Quantile correction makes intervals ordered, but it does not prove those intervals are calibrated for a hospital, warehouse, or trading strategy.

A serious trial needs rolling backtests. Hold out several historical windows, compare TimesFM with seasonal naive, moving-average, ETS, and any incumbent model, then score the horizons the business actually uses. Break results down by sparse series, new products, promotions, regime changes, and missing data. A single average metric can hide costly failures. Zero-shot means no fitting is required, not that local validation is optional.

Covariates need extra suspicion

XReg brings known external information into the forecast. Dynamic numerical variables might include future prices or weather predictions; categorical values might mark holidays; static features might identify regions. The feature is valuable because many business series cannot be understood from their own history alone. It also creates the easiest route for future information to leak into a backtest.

Two open reports deserve attention. Issue #338 alleges that sequence relationships in the test set can allow later context to influence an earlier series. Issue #274 provides a TimesFM 2.0 example where the same series receives different XReg output depending on another series in its batch. Neither report establishes that every 2.5 covariate forecast is wrong, but together they justify a hard release gate: forecast each test series alone and in different batch groupings, assert near-identical results, and trace every future covariate to information genuinely available on the prediction date.

The optional dependencies also have a current packaging trap. Issue #443 says the Flax and XReg extras hardcode jax[cuda], which breaks or misconfigures installation on CPU-only machines. Torch-only forecasting avoids that path. CPU users who need covariates should inspect the resolved JAX build rather than trusting pip to choose the right backend.

Performance and scope have boundaries

The smaller model is not guaranteed to be the faster model in every deployment. Issue #313 reports a test of 1,024 series on an NVIDIA L40S where 2.5 took about 28 seconds and 2.0 took under two seconds. That is one user's configuration, not a project benchmark, and later code includes speed-oriented QKV fusion. It is still a reminder to measure warm inference with your batch size, history length, horizon, backend, and hardware.

TimesFM forecasts a target series. It is not a causal-analysis package, an explainable regression model, a time-series classifier, or a monitoring system. Quantile bands can help flag surprising observations, but the model does not include a dedicated anomaly detector. Analysts who need coefficients and assumptions they can explain may get more value from StatsForecast. Teams needing multivariate relationships should evaluate a model designed for that structure.

Health, support, and the decision

The repository's last push was July 14, 2026, and version 2.0.2 was released July 2. GitHub listed 220 open issues and pull requests combined. Recent repository work added LoRA fine-tuning examples, tests, community fixes, and a detailed agent skill. The code and 2.5 checkpoint use Apache 2.0, and the associated paper provides a research basis beyond the README.

The caveat is support. Google states that this open release is not an officially supported product. BigQuery ML is the supported route for organizations that want a managed SQL interface and enterprise operating model. Self-hosting means your team owns dependency pinning, model serving, monitoring, and forecast validation.

TimesFM belongs in almost every modern univariate forecasting comparison because trying it is cheap and its zero-shot results may be immediately useful. Keep a boring seasonal baseline beside it, validate uncertainty instead of admiring it, and test covariates for isolation. Adopt it when the measured improvement survives those checks, not merely because the model arrived pretrained.

Alternatives

ProjectWhat it isPick it when
ChronosAmazon's pretrained family for zero-shot probabilistic time-series forecasting.pick this instead when you want another mature foundation-model approach and need to compare checkpoint sizes or probabilistic behavior.
MoiraiSalesforce's unified training and inference code for universal time-series transformers.pick this instead when multivariate forecasting or experimenting with a broader universal-model research stack matters.
StatsForecastA fast collection of classical statistical forecasting models for large groups of series.pick this instead when interpretability, small compute, and proven statistical baselines matter more than zero-shot neural transfer.

What people are saying

  1. [github-trending] google-research/timesfm

Sources

  1. TimesFM README
  2. TimesFM 2.5 model card
  3. TimesFM v2.0.2 release
  4. Issue #338: possible XReg test leakage
  5. Issue #274: XReg batch-dependent results
  6. Issue #313: TimesFM 2.5 performance report
  7. Issue #443: CPU-only optional dependency failure