GluonTS: a PyTorch toolkit for probabilistic time series forecasting
Probabilistic time series modeling in Python
At a glance
- What is it?
- GluonTS packages deep learning forecasters behind an estimator/trainer/predictor interface and returns full predictive distributions rather than point estimates. It is a good fit when you need quantiles or intervals and can afford to train a neural model per dataset.
- Who is it for?
- Adopt GluonTS if you need probabilistic forecasts from neural models and are willing to manage a PyTorch training loop, dataset splits and prediction-length choices yourself. Do not adopt it if you only need a point forecast from a handful of short series, or if you cannot install or pin a torch extra.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 47 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem GluonTS addresses: forecasts as distributions, not single numbers
Most forecasting code returns one number per future timestamp. That is enough when the cost of being wrong is symmetric and small, and useless when you need to size inventory against a 90th percentile or staff a queue against a bad day. GluonTS is built around the second case. The README describes it as a Python package for probabilistic time series modeling that focuses on deep learning based models and is based on PyTorch. The example output is a plot where, in the project's own words, the shaded areas represent the 50% and 90% prediction intervals. That is the product: a distribution per timestamp, from which you can read any quantile you want. The intended user is a data scientist or ML engineer who already works in Python, has a dataset of many related series, and wants a neural forecaster without writing the likelihood, the training loop and the sampling code from scratch. It is not aimed at someone who wants a quick ARIMA on a single column of numbers.
Estimator, trainer, predictor: the three objects you actually touch
The API is deliberately uniform. You construct an estimator with hyperparameters, call train on a dataset to get a predictor, then call predict on inputs to get forecast objects. The README example shows exactly this shape: DeepAREstimator(prediction_length=12, freq="M", trainer_kwargs={"max_epochs": 5}).train(training_data), followed by list(model.predict(test_data.input)). The trainer_kwargs dictionary is the seam where PyTorch Lightning training options pass through, which is how max_epochs is set here rather than through a GluonTS-specific key. Data enters through a dataset abstraction. The README imports PandasDataset and wraps a DataFrame with a named target column, PandasDataset(df, target="#Passengers"), so the library is not tied to a bespoke binary format for the common case. Splitting is handled by a separate module: split(dataset, offset=-36) returns a training set and a test generator, and the generator produces windows via generate_instances(prediction_length=12, windows=3). That windowing step is the part people underestimate. A rolling-origin evaluation with three windows is three forecasts over overlapping history, not three independent models, and the README's single call hides that bookkeeping. Because every estimator shares the same train/predict contract, swapping DeepAR for another torch estimator is mostly a constructor change. The cost of that uniformity is that model-specific knobs are reachable mainly through constructor arguments and trainer_kwargs, so reading the per-model documentation is unavoidable.
Installing GluonTS and the extras that decide what you get
Installation is a single command, but the extra matters. The README recommends uv for environment management and gives `uv pip install "gluonts[torch]"` for support for torch models, with the plain pip equivalent `pip install "gluonts[torch]"`. Installing without the torch extra is possible but the README frames the extra as the thing that enables torch models, so a bare install is not the configuration the example assumes. For development the README clones the repository, changes into it, and runs `uv sync --all-extras`. Version constraints are explicit: GluonTS requires Python 3.10 to 3.14. That range is narrow enough to matter in practice. If you are pinned to 3.9 by another dependency, or running a newer interpreter that has not been added yet, the install will fail before you reach any modelling decision. The package is published on PyPI, and the README points to the stable and development documentation sites for anything beyond the quickstart. There is no mention of a conda channel or a Docker image in the supplied material, so container users will be building their own image around the pip or uv install.
Where GluonTS is the wrong tool
The library assumes you can train. The README example trains a DeepAR model on nine years of monthly data and forecasts the remaining three, which is a small and tidy problem, but the workflow still requires a training run, a chosen prediction_length, a frequency string, and a split. If your series are short, few, or dominated by a strong seasonal pattern that a classical method handles in milliseconds, the neural path adds setup and compute for no clear gain. There is a second boundary the README itself draws. The breaking-news banner points to Chronos, described as a suite of pretrained models for zero-shot time series forecasting that can generate probabilistic predictions for series not seen during training, hosted in a separate repository. That is an admission that the in-repo estimators expect per-dataset training, and that the zero-shot case lives elsewhere. A third constraint is version churn. The supplied release list shows v0.17.0, a v0.17.0rc1 two weeks earlier, and v0.16.3 the month before, on a default branch named dev. Frequent minor releases with release candidates mean pinning a version is the sane default, and that an upgrade can move behaviour under you. Finally, the estimator interface assumes a dataset abstraction. If your data arrives as a stream of irregular events rather than a set of series with a frequency, you will spend your time reshaping before any model sees it.
GluonTS against a gradient-boosted tabular forecaster
The obvious alternative for many teams is a feature-based regressor: build lag features, calendar features and rolling statistics, then fit LightGBM or XGBoost and predict a single quantile per model. The difference in approach is structural. A gradient-boosted model treats each series and each timestamp as a row, so cross-series learning happens only through shared features you engineer, and a probabilistic output requires either quantile regression per model or a separate distributional assumption. GluonTS instead trains one neural network across many series, with the probabilistic head built into the estimator, and produces the whole predictive distribution in one pass. That is a real advantage when you have thousands of related series and want intervals without training a model per quantile. The trade-off runs the other way too. A boosted-tree pipeline has no epoch count, no trainer_kwargs, no GPU requirement, and its artefacts are inspectable feature importances. GluonTS gives you a trained network whose behaviour is harder to explain to a stakeholder asking why next month's interval widened. Both can be correct; the deciding question is whether you need calibrated intervals across many series, or a defensible point forecast you can attribute.
Maintenance, upgrades and the Apache-2.0 licence
The repository is not archived and the last push in the supplied metadata is 2026-07-31, the same day as the v0.17.0 release, so the project is actively moving. For a team adopting it, that cuts both ways: fixes and new estimators arrive, and so does the need to re-verify your pipeline on each minor bump. Budget for pinning a version in your lockfile and re-running your backtest before moving the pin, especially across a release-candidate boundary like 0.17.0rc1 to 0.17.0. The licence is Apache-2.0, which is permissive and includes an explicit patent grant, and the README carries a LICENSE link and a PyPI licence badge. Apache-2.0 does not, by itself, resolve questions about the provenance of a pretrained checkpoint you might load, and the README's pointer to Chronos is to a separate repository whose terms you would need to check independently. Nothing here is legal advice; if you are shipping a model inside a product, have your own process confirm the licence of every artefact you bundle, including model weights.
What to verify before you commit a quarter to GluonTS
Start by reproducing the README example end to end on your own machine, including the pandas CSV load and the split call, because that single script exercises the dataset wrapper, the splitter, the estimator and the forecast plotting path in one go. Then replace the AirPassengers data with one of your own series and check two things: whether PandasDataset accepts your target column and frequency without reshaping, and whether your history is long enough relative to the prediction_length you need. The example uses 36 held-out months and predicts 12 at a time over 3 windows, which is a comfortable ratio; a series with 40 observations and a 12-step horizon is not. After that, decide how you will evaluate. The README shows forecast.plot(), which is for eyeballing, not for scoring, and the supplied material does not describe a metrics module. You will need your own interval coverage and quantile loss computation before you can claim the probabilistic output is calibrated. If any of those three checks fails, the honest alternative is a feature-based regressor and a quantile model, and GluonTS is a later conversation.
Editorial conclusion
Adopt GluonTS if you need probabilistic forecasts from neural models and are willing to manage a PyTorch training loop, dataset splits and prediction-length choices yourself. Do not adopt it if you only need a point forecast from a handful of short series, or if you cannot install or pin a torch extra. Before committing, verify that Python 3.10 to 3.14 matches your environment, that "gluonts[torch]" resolves on your platform, and that your series length comfortably exceeds the prediction_length you intend to set, since the README example splits off 36 months and predicts 12 at a time.
Community notes