The Pulse
IBM Releases a Four-Model Granite Forecasting Ensemble
IBM Research introduced Granite Timeseries Ensemble R1 on Hugging Face, combining four pretrained models for time-series forecasts. On 97 GIFT-Eval configurations, the ensemble slightly improved aggregate point-forecast error over its stron
AI.info Team · Written with AI · fact-checked ·
IBM Research published Granite Timeseries Ensemble R1 on Hugging Face on October 22, pairing four pretrained Granite forecasting models in one recipe. The ensemble returns point forecasts and quantiles without retraining on a user’s data or fitting weights from historical forecast errors. IBM recommends equal-weight probability pooling as the default, with an adaptive alternative that weights models by the spread of their forecasts.
Four Granite architectures share one recipe
The ensemble brings together PatchTST-FM-r1, PatchTST-FM-r2, FlowState-r1.1 and TTM-r3. The models use different approaches: patched Transformer and Conformer architectures, a state-space model, and a lightweight mixer. IBM’s stated rationale is that their differing approaches may produce errors that do not coincide, reducing reliance on choosing a single model for every series and forecast horizon.
The release stores a configuration rather than merged model weights. When run, it downloads the four checkpoints from their own Hugging Face repositories; that means the first run takes extra time and uses more memory than a single-model forecast. Developers install the Granite TSFM package and load the recipe through a shared forecasting interface.
Equal pooling edges the point-forecast result
IBM evaluated both ensemble recipes without fine-tuning across 97 GIFT-Eval dataset configurations. In results captured on October 20, the equal-weight Probabilistic Ensemble recorded a MASE score of 0.683, narrowly ahead of 0.685 for PatchTST-FM-r2, the best individual member on that measure. Lower MASE scores are better; the margin is small, and IBM presents the benefit as a strong general starting point rather than a decisive win on every dataset.
The point-forecast comparison does not settle the probabilistic results. PatchTST-FM-r2 had the lowest aggregate CRPS/MWQL score, 0.467, while both ensembles scored 0.471. The IQR Ensemble had the best average CRPS rank among the six Granite forecasts shown, while equal pooling led on average MASE rank. IBM also notes that rank values compare models against the broader GIFT-Eval leaderboard and can change as entries are added.
Quantiles show a range, not a guarantee
The default recipe outputs quantiles from 0.1 through 0.9, alongside a point forecast based on the median. Users can use the 0.1 and 0.9 quantiles to form an interval with nominal 80% coverage, then check whether that interval actually matches observed outcomes on their own data. A nominal interval is not proof of calibration.
“A narrower interval does not necessarily mean a more accurate or better-calibrated forecast, and IQR weighting can favor an overconfident member.”
Fearghal O’Donncha, Chandramouli Kamanchi, Guruprasad Ranjini, Wesley M. Gifford, Natalia Martinez Gil, Bradley Eck, Pankaj Dayama, Roman Vaculin and Ayhan Sebin, IBM Research
The IQR method gives greater influence to members with narrower predicted intervals, with weights that vary by sample, target and forecast step. It does not learn from past forecast errors, and IBM cautions that a narrow interval may reflect overconfidence rather than accuracy. The fixed equal-weight method avoids that particular weighting choice, which is why IBM recommends it as the first comparison.
Backtesting still decides whether it fits
The benchmark does not show that the ensemble will improve forecasts for every application. IBM says its current recipe forecasts multivariate channels independently, without using information across channels, and that combining four checkpoints increases inference time and memory use. Member models also differ in context limits, forecast horizons, preprocessing and missing-value handling.
IBM advises users to backtest both ensemble methods against a strong individual model on representative historical windows, checking point error, quantile loss and interval coverage while measuring runtime and memory. The recipe can also be extended with compatible external forecasters, but those combinations need their own checks for accuracy, calibration, cost and licensing. Its four-model scores offer a benchmarked starting point; application-specific tests determine whether the added compute is justified.