What is Granite TimeSeries Ensemble R1?
Granite TimeSeries Ensemble R1 is an open IBM Granite framework for zero-shot and probabilistic time-series forecasting. It is intended for numerical sequences such as measurements recorded over time, rather than text generation, image creation, or general-purpose language-model tasks.
The framework does not contain one newly trained set of ensemble weights. Instead, it loads four existing IBM Granite forecasting checkpoints, obtains predictions from each member, and combines those predictions. This lets a user evaluate several forecasting approaches through one ensemble workflow instead of committing to a single architecture at the beginning of a project.
Its default output includes forecast quantiles from 0.1 through 0.9. Quantiles describe possible forecast outcomes at different probability levels; the 0.5 quantile is used as the point forecast or median prediction. The remaining quantiles provide information about forecast uncertainty.
Where it fits in the IBM Granite catalog
IBM presents Granite TimeSeries Ensemble R1 as part of its Granite time-series collection. It is best understood as a reusable forecasting framework layered over several Granite time-series models, not as a conventional standalone checkpoint comparable to a single forecaster.
This positioning matters in practice. A single forecasting model may be easier to deploy, but its results can depend heavily on whether its architecture matches the patterns in a particular dataset. The ensemble instead combines models with different design characteristics and inductive biases. That approach can provide a more general baseline, although it requires more computation and does not guarantee better results for every series or forecast horizon.
Which models are combined?
The default Granite-only configuration uses four member forecasters:
- PatchTST-FM-r1: a transformer-based time-series forecaster.
- PatchTST-FM-r2: a conformer-based time-series forecaster.
- FlowState-r1.1: a state-space forecasting model.
- TTM-r3: a lightweight Tiny Time Mixers forecasting model.
These members can respond differently to context length, forecast horizon, recurring patterns, and other characteristics of the input data. Combining them is intended to reduce dependence on the strengths and failure modes of one architecture. The ensemble does not make the members identical: differences in preprocessing, context limits, supported horizons, and missing-value behavior still need to be checked when deploying it.
How forecast combination works
Uniform probabilistic pooling with linear_pool
The recommended default is the linear_pool probabilistic ensemble. It gives each member equal influence and pools their quantile predictions into an empirical mixture. Requested quantiles are then extracted from the combined forecast values.
This method does not learn weights from historical forecast errors and does not require a fitted validation set. That makes it straightforward and reproducible for zero-shot use. It also means that the method is not automatically adapted to a particular business dataset. Equal weighting can be a useful starting point, but it does not ensure that the resulting probabilities are calibrated, meaning that an advertised probability level will not necessarily match the observed frequency of outcomes.
IQR-weighted alternative
The optional iqr_weighted method changes member influence based on forecast dispersion. IQR means interquartile range, the distance between the 25th and 75th percentiles. For each sample, target, and forecast step, members with narrower forecast intervals receive more weight.
Isotonic regression is applied to preserve nondecreasing output quantiles. This helps prevent an invalid ordering in which a lower probability quantile is greater than a higher one. However, a narrow interval is not automatically evidence of accuracy. The weighting method can favor an overconfident member, so it should be compared with the uniform method using representative historical backtesting before production use.
Outputs and supported data
The framework produces numerical time-series forecasts, including a median point forecast and quantiles from 0.1 to 0.9 in the default root configuration. These outputs can support applications that need both a central estimate and an indication of uncertainty, such as demand planning, capacity forecasting, monitoring, or operational scheduling.
The supplied specifications do not describe Granite TimeSeries Ensemble R1 as a multimodal system. It has no documented image, audio, video, speech, or general text-generation output. It also is not presented as a language model with a conventional text context window or maximum token limit. Its input is supplied time-series data, and the research does not publish one universal context length for the ensemble because member models can have different limits and requirements.
Multivariate channels are forecast independently in the default ensemble. The framework therefore does not use relationships between channels to improve the prediction. If cross-channel interactions are central to the problem, a model or forecasting design that explicitly models those dependencies may be more appropriate.
What do the reported benchmarks show?
IBM evaluated two Granite-only ensemble recipes on 97 GIFT-Eval dataset configurations. In the published evaluation snapshot, the probabilistic ensemble achieved a normalized MASE of approximately 0.683, while the IQR ensemble achieved approximately 0.684. These aggregate point-forecast results were slightly better than those of the strongest individual member in the comparison.
PatchTST-FM-r2 had the best aggregate CRPS or mean weighted quantile loss among the compared individual and ensemble forecasts. This is an important qualification: the ensemble showed a strong general result, but the benchmark does not establish that it will beat PatchTST-FM-r2 or another individual model on every dataset, horizon, or uncertainty metric. Users should backtest both ensemble recipes and individual members on data that resembles the intended deployment.
Deployment cost and operational trade-offs
The main practical cost is that the ensemble runs four checkpoints instead of one. The first load downloads the member repositories, increasing setup time and storage requirements. Inference also generally uses more memory and has higher latency than a single-model forecast. The supplied product assessment rates its speed below the fastest options, while its cost assessment is comparatively favorable, but these are editorial scores rather than IBM-published performance guarantees.
There is no official hosted API pricing or token-based pricing published for this forecasting framework. It is distributed as an open recipe and software stack, so operational cost depends on the hardware, storage, inference volume, and hosting arrangement selected by the user. There is also no published fixed maximum output-token limit because the system produces time-series forecast values rather than language-model tokens.
The ensemble is accessed through the Granite TSFM software stack and the QuantileEnsembleForecaster interface. Compatible forecasters can be added when they implement the common forecasting interface and return predictions at compatible quantile levels. Expanded recipes may reference separately licensed IBM Research checkpoints, so every member's repository license should be reviewed before redistribution or commercial deployment.
Strengths and limitations
Granite TimeSeries Ensemble R1 has several concrete strengths:
- It provides a ready-made way to compare and combine four forecasting architectures.
- The default method needs no retraining and no fitted ensemble weights.
- It returns both a central forecast and multiple uncertainty quantiles.
- It can reduce the risk of selecting a poorly matched architecture before testing a dataset.
- The framework can be extended with compatible forecasters.
Its limitations are equally important:
- Four checkpoints increase memory use, storage, startup time, and inference latency.
- Member models may differ in context limits, preprocessing requirements, forecast horizons, and missing-value handling.
- The default configuration forecasts multivariate channels independently and does not model cross-channel effects.
- Neither aggregation method guarantees calibration or robustness under distribution shift.
- IQR weighting may reward narrow but overconfident forecast intervals.
- Aggregate benchmark improvements do not guarantee an improvement on an individual dataset.
- There is no conventional language-model API, tool-calling interface, or structured text-generation mode documented for this item.
When to choose Granite TimeSeries Ensemble R1
Choose this ensemble when you need a zero-shot or low-configuration forecasting baseline and do not yet know which of several time-series architectures will work best. It is particularly suitable when uncertainty estimates are useful and when the additional resource cost of running four models is acceptable. The uniform linear_pool recipe is a sensible first evaluation because it avoids fitting weights and is easy to reproduce.
Use the IQR-weighted method only after checking its behavior on historical data. It may help when forecast dispersion provides a useful signal about member reliability, but narrower intervals should not be treated as proof that a model is more accurate.
A single member such as PatchTST-FM-r2 may be a better choice when latency, memory, or deployment simplicity matters more than ensemble diversity, especially if validation shows that it performs best for the target workload. A cross-channel model may be preferable when relationships between variables are essential. A conventional language model or hosted AI API is more appropriate for text, code, tool use, or multimodal tasks, because Granite TimeSeries Ensemble R1 is specialized for numerical time-series forecasting.
Licensing and availability
The ensemble recipe and Granite TSFM implementation are provided under Apache-2.0 according to the supplied research. The default Granite-only configuration uses checkpoints hosted in the IBM Granite organization, but each member repository retains its own licensing terms. Optional expanded configurations can include checkpoints with additional restrictions.
Overall, Granite TimeSeries Ensemble R1 is best viewed as an open forecasting recipe for combining point and probabilistic predictions. Its main value is reducing the need to choose one architecture in advance; its main cost is the extra operational burden of loading and running four separate forecasting models.