Latest in AI
IBM Granite Timeseries Ensemble R1: Forecasting, Benchmarks and Limits
IBM's new forecasting recipe combines four models without retraining, trading a simpler starting point for more inference work.
IBM introduced Granite Timeseries Ensemble R1 on October 22, a forecasting recipe that combines four pretrained Granite models. It produces point and quantile forecasts without retraining or fitting ensemble weights, giving developers a starting configuration before they choose a single architecture.
The release is a recipe and implementation, not a new merged checkpoint. That distinction matters for deployment: one interface still runs several models underneath.
What the four-model recipe contains
The model card lists PatchTST-FM-r1, PatchTST-FM-r2, FlowState-r1.1 and TTM-r3. Their checkpoints load from their own repositories. The default recipe uses permissively licensed Granite members; optional expanded recipes include separately licensed research models.
The default aggregation gives each member equal influence by pooling its quantile values. Quantiles describe positions in a forecast distribution, such as the median and the lower or upper ends of a predicted range. The alternative IQR method favors members with narrower forecast intervals.
That narrower-interval preference deserves care. Confidence is useful only when it is justified. An overconfident model can produce a narrow interval while being wrong, so IQR weighting is an alternative to test rather than an automatic upgrade.
What changed in the benchmark
IBM's release analysis reports GIFT-Eval results over 97 dataset configurations, using an October 20 leaderboard snapshot. Lower scores are better in the following comparison.
| Forecast | Aggregate MASE | Probabilistic CRPS/MWQL score |
|---|---|---|
| Probabilistic Ensemble | 0.683 | 0.471 |
| IQR Ensemble | 0.684 | 0.471 |
| PatchTST-FM-r2 alone | 0.685 | 0.467 |
The default ensemble has a small advantage on aggregate point-forecast error. The strongest individual member still has the better aggregate probabilistic score. These results do not support a blanket claim that combining four models improves every forecast.
For an engineering team, the appeal is a reasonable default across different series. The cost is running four checkpoints when one might already be good enough. A tiny aggregate improvement can be useful at sufficient volume, but it can also disappear in a particular dataset.
How to start using it
The published setup uses Granite TSFM version 0.3.11 or later and loads the recipe named ibm-granite/granite-timeseries-ensemble-r1 through QuantileEnsembleForecaster.from_pretrained. The first run needs time and storage to retrieve the member checkpoints.
IBM also provides a getting-started notebook that separates the historical context from held-out observations, runs a forecast and plots the resulting interval against actual values. That is a more useful evaluation pattern than examining a smooth-looking forecast in isolation.
The notebook retains some development-era setup notes and different IQR defaults from the released model card. Follow the release documentation for the published recipe, and record the package version and configuration when comparing results. No training or execution of the models is claimed here.
The limits that affect deployment
The release does not establish a hosted per-call API price. For self-hosted use, compute, memory and runtime are part of the cost even when model access does not require a usage-based fee.
The current implementation forecasts multivariate channels independently, rather than learning relationships between them. It can also continue when a member fails. Check the inference logs: a result produced by three surviving models is not the four-member recipe used in the reported comparison.
Measure the value of the ensemble against a single-model baseline. Use the same forecast origins and horizons, then compare error, interval coverage, runtime and memory. A sensible starting configuration should make that experiment easier, not remove the need for it.
The useful outcome is less time spent choosing an initial architecture. Whether the ensemble should stay in production depends on how much uncertainty it removes from the actual forecast, and how much extra computation it takes to do so.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical teams turn model releases and engineering decisions into clear stories that developers and founders want to read and share.