Stop Guessing Which Time-Series Model to Use IBMs Granite Ensemble Does It for You

Why picking a single forecasting model is a trap

You have a time-series dataset. You try PatchTST — it does great on smooth industrial signals but struggles with noisy retail demand. You try FlowState — better on long seasonal horizons but worse on short-term spikes. You try TTM — fast, but not always accurate.

Choosing the right architecture is half the battle, and the best choice depends entirely on your series and horizon. IBM's answer: stop choosing. The Granite Timeseries Ensemble bundles four complementary Granite architectures into a single forecaster that returns median and quantile predictions — no retraining, no fitted ensemble weights, no guesswork.

The idea mirrors weather forecasting: ensemble models explore a range of outcomes and merge them into one forecast. Time-series forecasting benefits the same way — complementary models see different patterns, and the ensemble averages out their individual errors.

Get running in under 5 minutes

Install the package and load the recommended four-model 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

# Load the ETTh1 dataset (hourly electricity transformer temperature)
df = pd.read_csv(
    "https://raw.githubusercontent.com/zhouhaoyi/ETDataset/main/ETT-small/ETTh1.csv",
    parse_dates=["date"],
)

# Load the default ensemble recipe (downloads 4 member checkpoints at runtime)
ensemble = QuantileEnsembleForecaster.from_pretrained(
    "ibm-granite/granite-timeseries-ensemble-r1",
)

# Forecast the next 24 steps using the last 1024 observations as context
result = ensemble(
    df.tail(1024),
    timestamp_column="date",
    target_columns=["OT"],
    context_length=1024,
    prediction_length=24,
)

print(result.prediction_outputs)  # point forecast (median)
print(result.quantile_outputs)    # quantiles 0.1 through 0.9

What's inside the box

The default recipe combines four pre-trained Granite models with different architectures:

Each architecture captures trends, seasonality, and local variation differently, so their errors don't line up. The recipe stores the configuration, not merged weights — the four checkpoints download on first run, so budget extra time for the initial call.

Two ways to combine the forecasts

Probabilistic Ensemble (default): equal influence for every member, quantiles pooled in probability space. No fitting, no hyperparameters to tune.

IQR Ensemble (adaptive): weights each member by forecast spread — narrower intervals get more influence. Swap it in with one line:

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

Does it actually beat the individual models?

On 97 GIFT-Eval configurations, both ensembles beat all four individual members on aggregate MASE:

The margin over the best single model is small — the real win is robustness. You get comparable or better aggregate accuracy without knowing in advance which architecture suits your data.

Limitations to keep on your radar

• Independent channels: the current recipe forecasts multivariate channels independently — no cross-channel information is used.
• Latency cost: four checkpoints load at inference time, so memory and latency are higher than a single model.
• No calibration guarantee: neither aggregation method guarantees calibration or robustness under distribution shift. Monitor forecasts after deployment.
• IQR caveat: a narrower interval doesn't mean a better-calibrated forecast — IQR weighting can favor an overconfident member. The recipe exposes a temperature setting and an optional weight cap if you want to experiment.

How to evaluate it for your use case

1. Match your use case. Use historical windows reflecting the data available at each forecast origin, the horizon you need, and the series you expect to serve.
2. Compare like with like. Run Probabilistic, IQR, and a strong individual member (e.g., PatchTST-FM-r2) on the same windows.
3. Look beyond point error. Assess quantile loss alongside MASE, and check empirical coverage of the 0.1–0.9 interval against its nominal 80%.
4. Measure the cost. Record runtime and memory to judge whether combining four models justifies it for your workload.

Where to go next

Start with the default Probabilistic Ensemble — it's the sensible baseline that requires zero tuning. If forecast spread looks informative for your application, backtest the IQR Ensemble against it on representative data before committing.

The Forecaster interface also accepts compatible external models, so you can swap members or aggregation methods while keeping the same downstream forecast format. Just check compatibility, accuracy, calibration, latency, and licensing for any new mix — some expanded recipes include IBM Research checkpoints with non-commercial or research-only terms.

Practical advice for teams shipping this: treat the ensemble as your baseline, not your final answer. It removes the "which model do I pick?" decision from day one, but you still owe your application a proper backtest. And whenever you're scaling AI-driven workflows, remember the tradeoff between velocity and quality — as we explored in AI Doubled Our Merged PRs — Here's What Actually Broke (And What Didn't), shipping faster without measurement is just shipping noise faster.

For a broader look at how infrastructure and AI are converging at the edge, see our breakdown of Post-Quantum IPsec interoperability across Cloudflare, Cisco, and Fortinet.

Next steps to learn:

• Read the Granite TSFM repository for the full recipe API.
• Run the getting-started notebook end-to-end on your own data.
• Benchmark against GIFT-Eval to see where your series lands.

Source: IBM Research — Granite Timeseries Ensemble R1