Google's TimesFM-3 Generates a Full Multivariate Forecast Horizon in One Forward Pass at 330M Parameters

Google Research states in its August 31, 2026 release of TimesFM-3 that the 330-million-parameter model produces an entire multivariate forecast horizon in a single forward pass, with no autoregressive loop. The model is pre-trained on a real-world and synthetic corpus of more than 1 trillion time points, and Google claims it is the top-ranked model on both point and probabilistic forecasting metrics among all pre-trained foundation models across GIFT-Eval, FEV-Bench, and the TIME leaderboard. Research scientists Ayush Jain and Rajat Sen authored the release. Unlike TimesFM-2.5, which shipped under Apache 2.0, TimesFM-3 is distributed under a non-commercial license.

Attention Alternates Between the Time Axis and the Series Axis

The structural core of TimesFM-3 is a pair of attention mechanisms applied in alternation across layers. Causal temporal attention has tokens attend horizontally across time, while full variate attention has tokens attend vertically across series. Google states that alternating between them enables both temporal pattern learning and cross-series relationship modeling within one model.

The Hugging Face model card adds implementation detail. The configuration uses 20 transformer layers at model dimension 1280 with 16 heads, a context patch length of 32, and a forecast horizon patch length of 64. The card describes the design as a stacked mixing transformer with variate attention and CPM iterative RevIN. Output covers nine quantiles from the 10th to the 90th percentile, with the median at index 4.

The addition of a series axis is what makes this version different in kind. A univariate model processes each series independently and therefore has no structural way to express several metrics moving together for a shared reason: store-level sales responding to one promotion, or multiple sensors responding to one equipment fault. Attention across series is a commitment to handling that common factor inside the model rather than through upstream feature engineering.

Filling the Horizon at Once, and What That Costs

TimesFM-3 uses Contiguous Patch Masking to fill every masked horizon patch simultaneously, with no iterative loop required. Google states that previous TimesFM versions generated forecasts iteratively and that the approach introduced latency, compounding error accumulation, and computational cost. A single forward pass targets all three at once.

Compounding error is the most operationally consequential of the three. Autoregressive decoding feeds each predicted step back in as input for the next, so a small early bias amplifies as the horizon lengthens. That property is one reason teams planning on 90-day or 12-month horizons kept classical statistical methods rather than switching to foundation models. Predicting the horizon in one pass conditions every step on observed inputs only, which removes the amplification path rather than damping it.

The cost lands on flexibility. Autoregressive decoding can extend indefinitely, while single-pass generation makes the horizon patch length defined at training time a design constraint. The forecast horizon patch length of 64 is the number that shows where that constraint sits, and use cases needing far longer horizons reintroduce stitching logic of their own. The announcement does not state a maximum supported horizon length.

Covariate Support Is the Most Practical Part of the Release

Covariate support in TimesFM-3 is three-way: multiple targets forecast jointly, past covariates known only historically, and past-future dynamic covariates that carry known future events into the forecast. Google describes the third as leveraging known future events to guide the forecast.

That third type is the boundary between benchmark forecasting and industrial forecasting. Real demand planning is not pure extrapolation but conditional prediction, because next month's promotion calendar, store opening dates, and holiday placement are already fixed and the question is what demand looks like given them. A model with nowhere to put those conditions is eliminated during evaluation regardless of its benchmark rank.

The weighting is stronger in markets with moving holidays. Korea's Seollal and Chuseok follow the lunar calendar and land on different Gregorian dates each year, so learned fixed-period seasonality captures them poorly. Being able to pass holiday placement and substitute holiday status as known future covariates is where this capability translates directly into retail and logistics forecasting accuracy. That expectation follows from the described capability; Google's release does not report performance on Korean data.

A Rank Claim Without a Score Table

Google's stated evidence is a rank: top-ranked on both point and probabilistic forecasting metrics among pre-trained foundation models across GIFT-Eval, FEV-Bench, and the TIME leaderboard. Named comparison models are Chronos-2, the Toto 2.0 family, and the prior TimesFM-2.5. The announcement text carries no individual metric values and no margin over second place.

Rank claims and score claims differ in how they can be verified. A rank can change with the next leaderboard update, and being first by 0.1% versus first by 5% carries entirely different weight in an adoption decision. All three benchmarks are public leaderboards, so an external verification path exists, but quoting a launch-day rank is not the same as quoting a reproduced score.

One further condition deserves attention. Evaluating a model pre-trained on more than 1 trillion time points against public time-series benchmarks leaves the separation between training corpus and evaluation set unverifiable from outside. Google describes the corpus only as a mixture of real-world and synthetic data and does not publish its composition. Zero-shot as a claim requires that evaluation data was excluded from training, and the released material does not establish that.

The License Moved From Apache 2.0 to Non-Commercial

The change with the largest operational impact in TimesFM-3 is not performance but licensing. Per the Hugging Face model cards, the 200-million-parameter TimesFM-2.5 shipped under Apache 2.0, while TimesFM-3 ships under the TimesFM Non-Commercial License v1.0. Open weights and commercial usability have been separated in this version.

That separation breaks the upgrade path. A team already running TimesFM-2.5 inside a commercial forecasting service cannot swap weights to 3.0 and must instead re-examine license terms to capture the accuracy gain. Google's statement that BigQuery integration lands in the coming weeks fits this structure, positioning the managed service rather than self-hosted weights as the sanctioned commercial route.

As a release strategy the combination is coherent: publish weights so the research community benchmarks and cites the model, and monetize commercial demand through the cloud product. The consequence differs from the language-model case, though. Self-hosting is common in time-series work precisely because the data being forecast is internal operational data subject to transfer restrictions, and for organizations under those restrictions neither a non-commercial license nor a managed service resolves the problem.

What a Team Evaluating TimesFM-3 Should Check First

Three checks are required before any performance comparison of TimesFM-3, and none of them involves a benchmark number: license scope, future covariate design, and the choice of comparison baseline. License scope comes first, because where internal analytics ends and commercial service delivery begins must be read directly from the TimesFM Non-Commercial License v1.0 text rather than inferred from the performance write-up.

The second is future covariate design. Since the differentiator is conditional forecasting, how promotion calendars, holidays, and planned price changes get structured as known future inputs determines whether adoption succeeds. The third is choosing the comparison set. Google's named baselines are Chronos-2 and the Toto 2.0 family, not an in-house tuned gradient boosting model, and leading among foundation models does not mean outperforming a specialist model trained on one organization's own domain data.

What is verified as of August 31, 2026 is that TimesFM-3 runs at 330 million parameters with multivariate and covariate support, generates its horizon in one pass, and is available on GitHub and Hugging Face under a non-commercial license. Per-benchmark scores, training corpus composition, and maximum horizon length are not published, and the BigQuery integration remains announced rather than shipped.

Source: Google Research blog, "TimesFM-3: A zero-shot foundation model for multivariate forecasting," August 31, 2026 (authors Ayush Jain and Rajat Sen, with Yichen Zhou, Petros Mol, Abhimanyu Das, and Samet Oymak): 330 million parameters, pre-training on more than 1 trillion time points from a real-world and synthetic corpus, alternating causal temporal and full variate attention, Contiguous Patch Masking for single-forward-pass decoding, support for multiple targets and past and past-future dynamic covariates, the top-rank claim on point and probabilistic metrics among pre-trained foundation models on GIFT-Eval, FEV-Bench, and TIME, comparisons to Chronos-2, the Toto 2.0 family, and TimesFM-2.5, availability on GitHub and Hugging Face with BigQuery integration in coming weeks, and the stated latency, compounding error, and compute costs of prior iterative versions. Plus Hugging Face model cards google/timesfm-3.0-pytorch (0.3B params, 20 layers, model dim 1280, 16 heads, context patch 32, horizon patch 64, nine quantiles with median at index 4, TimesFM Non-Commercial License v1.0) and google/timesfm-2.5-200m-pytorch (0.2B params, apache-2.0).