IBM Granite Timeseries Ensemble R1: Four Open Forecasters, One Call, No Retraining

IBM Research has published a way to stop agonizing over which pre-trained forecasting model to use: run four of them and pool the answers. Granite Timeseries Ensemble R1 combines four open Granite time-series architectures into one recipe that returns point and quantile forecasts with no retraining and no fitted weights, and on the GIFT-Eval benchmark it edged out every individual member on point-forecast error. The announcement is on the IBM Research Hugging Face blog.

If you forecast demand, load, sensor readings or any other time series and want a strong default without fine-tuning, this is a practical option. Below: the code, the two recipes, the numbers, and what the numbers do not show. For other zero-shot forecasters see our coverage of Mistral's Timestral, Google's TimesFM 3 and TimesFM 2.5.

TL;DR

The four members

IBM chose models with different architectures so their errors do not line up.

The logic comes from weather forecasting, where ensembles explore a range of outcomes. IBM cites the North American Multi-Model Ensemble as an example and a 50-year review of forecast combination. Different architectures capture trends, seasonality and local variation in different ways, so their mistakes differ, and averaging them reduces the risk of picking the wrong single model.

Run it in a few lines

IBM's example installs the library and loads the recommended recipe directly from Hugging Face:

pip install "granite-tsfm>=0.3.11"

import pandas as pd
from tsfm_public.models.ensemble.modeling_ensemble import QuantileEnsembleForecaster

df = pd.read_csv(
    "https://raw.githubusercontent.com/zhouhaoyi/ETDataset/main/ETT-small/ETTh1.csv",
    parse_dates=["date"],
)

ensemble = QuantileEnsembleForecaster.from_pretrained(
    "ibm-granite/granite-timeseries-ensemble-r1",
)

result = ensemble(
    df.tail(1024),
    timestamp_column="date",
    target_columns=["OT"],
    context_length=1024,
    prediction_length=24,
)

print(result.prediction_outputs)  # point forecast
print(result.quantile_outputs)    # quantiles

Two practical notes from IBM. The recipe stores the ensemble configuration rather than merged weights and downloads the four member checkpoints at runtime, so the first run is slow. And the default quantiles run from 0.1 to 0.9, so the 0.1 and 0.9 values form a central interval with nominal 80% coverage.

Two ways to combine the forecasts

Probabilistic Ensemble (the default)

Each member gets equal influence. The recipe pools their quantile forecasts in probability space and reads off the requested quantiles from the combined values. Fixed weights mean no fitting step and no hyperparameters to tune for a new series. IBM points to the "forecast combination puzzle": in point forecasting, simple equal-weight combinations often hold up well against methods with estimated weights.

IQR Ensemble (the adaptive option)

This recipe weights members by forecast spread, giving narrower intervals more influence. It estimates each member's interquartile range from the quantiles near the 25th and 75th percentiles, with weights varying by sample, target and horizon step, and isotonic regression to stop quantiles from crossing. IBM warns that a narrower interval does not mean a more accurate or better-calibrated forecast, and weighting can favor an overconfident member. A temperature setting moves weights toward uniform, and an optional cap limits any member's weight. To load it, add subfolder="recipes/granite-iqr".

What the benchmark shows

IBM evaluated both recipes on 97 GIFT-Eval configurations, zero-shot, with no test targets used to select or fit the aggregation. Scores are normalized to Seasonal Naive and geometrically averaged; lower is better. IBM captured the leaderboard on October 20, 2026.

Reading the table honestly:

• Both ensembles beat all four members on aggregate MASE and average MASE rank. The Probabilistic Ensemble has the lowest MASE at 0.683.
• The margin is small. 0.683 versus 0.685 is not a dramatic win; IBM itself says the main benefit is robustness, comparable or better accuracy without knowing in advance which architecture suits your data.
• PatchTST-FM-r2 keeps the best aggregate probabilistic loss (0.467 versus 0.471), while the IQR Ensemble has the best average CRPS rank (47.619). Aggregate error and average rank favor different choices.
• It is not the leaderboard leader. IBM says the ensemble ranks 3rd among eligible systems on MASE and CRPS rank, and that some excluded systems, fine-tuned or non-permissively licensed, score better.

The metrics in plain language

Forecast leaderboards use jargon that hides what is being compared.

• MASE (mean absolute scaled error) measures point-forecast error relative to a naive baseline. A value below 1 means better than the baseline. Here scores are further normalized to Seasonal Naive, which repeats the last seasonal cycle, so 0.683 means roughly a third less error than that simple rule, averaged geometrically across datasets.
• CRPS / MWQL measure the quality of the whole predictive distribution, not just the middle. A forecast that is right on average but wildly overconfident scores badly here. GIFT-Eval reports a weighted quantile loss for this.
• Rank columns say where each forecast sits against everything on the leaderboard, averaged over dataset configurations. They are useful for consistency, but they move whenever a new entry is added, which is why IBM stamps the capture date.

Why report both? A model can win on average error and lose on interval quality, as the table shows. If you plan to act on ranges, for example setting safety stock from the 0.9 quantile, the probabilistic columns matter more than the point error.

When an ensemble helps, and when it does not

Pooling helps most when members are individually decent but wrong in different ways, which is the situation for a mixed portfolio of series: smooth industrial signals, spiky retail demand, long seasonal cycles. It helps least when one member is clearly better on your specific series, because equal weights then dilute the best model with weaker ones. That is the case for running the backtest above before standardizing on the ensemble. If a single member such as PatchTST-FM-r2 beats the pool on your windows by a clear margin, use it and save the compute.

The cost side is also real. Four checkpoints mean roughly four times the loading and inference work of a single small model in the worst case, although the Tiny Time Mixers member is built to be light. For batch forecasting overnight this barely matters; for low-latency serving of thousands of series, measure first.

Extending the recipe

The common Forecaster interface accepts compatible external models, so you can change the member mix or the aggregation method and keep the same downstream forecast format, without merging or retraining checkpoints. The repository also includes expanded recipes that add IBM Research checkpoints with separate terms, including non-commercial and research-use restrictions. Review each model card before commercial use. For any new combination, IBM advises checking compatibility, accuracy, calibration, latency and licensing.

How to evaluate it for your data

Aggregate gains do not mean every series benefits. IBM's suggested backtest:

1. Match your use case. Use historical windows that reflect the data available at each forecast origin, your real horizon, and the kind of series you serve.
2. Compare like with like. Run the Probabilistic Ensemble, the IQR Ensemble and a strong single member such as PatchTST-FM-r2 on the same windows.
3. Look beyond point error. Compare quantile loss with MASE, and check the empirical coverage of the 0.1 to 0.9 interval against its nominal 80%.
4. Measure cost. Record runtime and memory to decide whether four models are worth it.

Limitations to keep in mind

• Multivariate channels are forecast independently, so cross-channel information is not used.
• Four checkpoints increase inference time and memory relative to one.
• Context limits, horizons, preprocessing and missing-value handling differ across members.
• Neither aggregation method guarantees calibration or robustness under distribution shift, so keep monitoring forecasts after deployment.

Why it matters

Zero-shot time-series models are attractive because most teams do not have the data or time to fine-tune. The remaining pain is choice: no single architecture wins everywhere. An equal-weight pool of diverse open models is a cheap hedge, and the permissive licensing of the default members makes it usable in products. Compared with a single large foundation model, the trade is more compute for less risk. For energy, retail or operations teams, that is often the right trade.

For readers who build on weather and climate series, see how NVIDIA's StormScope EU approaches nowcasting with satellite data, and for IBM's wider open-model line see Granite 4.2 reasoning models.

Related reading

• Mistral Timestral time-series foundation models
• Google TimesFM 3 multivariate
• Google TimesFM 2.5
• IBM Granite 4.2 open reasoning models
• NVIDIA StormScope EU weather nowcasting
• NVIDIA Kumo relational foundation model
• Official: IBM Research on Hugging Face · GIFT-Eval benchmark

Figures are from IBM Research's post of October 22, 2026 and the GIFT-Eval leaderboard as captured on October 20, 2026; leaderboard ranks shift as entries are added.