pytorch-forecasting: a Lightning wrapper around neural forecasting models

The problem it solves: many series, shared patterns, covariates

Classical forecasting libraries treat each series as its own modelling problem. When you have thousands of SKUs, sensors or regions that share seasonality and respond to the same promotions or weather, fitting one model per series throws away the shared structure and leaves the sparse series with almost nothing to fit. pytorch-forecasting is aimed at that case. The README describes the goal as easing state-of-the-art timeseries forecasting with neural networks for real-world cases and research alike, with a high-level API for professionals and reasonable defaults for beginners. The audience is therefore the practitioner who already has a pandas DataFrame with a time index, a group column and some covariates, and who wants a neural forecaster without writing the training loop, the batching logic and the metric code from scratch. It is not aimed at someone who wants a one-line ARIMA on a single column.

What TimeSeriesDataSet actually does with your DataFrame

The central abstraction is TimeSeriesDataSet. The README lists what it handles: variable transformations, missing values, randomized subsampling and multiple history lengths. That list is the real mechanism. Rather than passing raw arrays to a model, you declare which columns are targets, which are static categoricals (a store id, for example), which are time-varying known covariates (a calendar flag or a planned price) and which are observed only in the past. The dataset then builds the windowed samples the network consumes, and it does so lazily, which is why randomized subsampling exists: you can train on a random subset of windows per epoch instead of materialising every window in memory. The same class is used for prediction, and the README points to a data tutorial for the details. The practical consequence is that your feature engineering moves into constructor arguments, and getting those arguments wrong is the most common source of confusing shape errors.

The model list and what each one is for

The documentation ships a comparison page, and the README names the architectures. Temporal Fusion Transformer is the interpretable multi-horizon option, with attention weights and variable selection you can inspect. N-BEATS is univariate and the README notes that as an ensemble it outperformed other methods in the M4 competition, though that claim is about the published method, not about this implementation. N-HiTS supports covariates and the README states it has consistently beaten N-BEATS, and that it suits long-horizon work. DeepAR is the autoregressive probabilistic baseline. PatchTST uses Transformer patching with channel independence for long-term forecasting. Alongside these there are deliberately plain options: LSTM, GRU, an MLP on the decoder, and a baseline that always predicts the latest known value. That last one matters more than it looks. It is the number your neural model has to beat, and the package making it a first-class model is a sensible design choice. The README also mentions a base model class providing training, TensorBoard logging, and visualisations such as actual versus predictions and dependency plots.

Installing it, and the MQF2 extra

The README gives two install paths. On Windows it says to install PyTorch first with pip install torch -f https://download.pytorch.org/whl/torch_stable.html, then proceed with pip install pytorch-forecasting. Elsewhere the single pip install pytorch-forecasting is enough. Conda users get conda install pytorch-forecasting pytorch -c pytorch>=1.7 -c conda-forge, with the note that the forecasting package comes from conda-forge while PyTorch comes from the pytorch channel. There is one optional extra: pip install pytorch-forecasting[mqf2] for the multivariate quantile loss. That extra is worth flagging because it pulls additional dependencies, and if you only need point forecasts or quantile losses you can skip it. Training itself runs through the PyTorch Lightning Trainer, so the usual Trainer arguments (accelerator, devices, max_epochs) are where GPU scaling is configured. The README states training works on CPUs, a single GPU or multiple GPUs out of the box.

Where it gets awkward: data volume, dependencies and the wrong shape of problem

Three limitations are visible from the material. First, this is a deep learning stack. It depends on PyTorch and PyTorch Lightning, and the README's Windows instruction to install torch separately is a hint that version alignment between the two is something you manage yourself. A pinned release of pytorch-forecasting expects particular ranges of both, and mismatches surface as import or Trainer errors rather than helpful messages. Second, the TimeSeriesDataSet approach assumes you can express your problem as a panel with a group identifier and a regular time index. Irregular event data, or a single series with fifty observations, does not fit the design and will not be rescued by switching architectures. Third, the README's benchmark claims (TFT outperforming DeepAR by 36 to 69 percent, N-HiTS beating N-BEATS) describe the published methods on the authors' datasets. Nothing in the supplied material says those gaps reproduce on your data, and the package's own inclusion of a naive baseline suggests the maintainers expect you to check. There is also no mention in the README of a CPU-only performance budget or of training-time guidance, so plan on measuring that yourself.

The alternative: statistical and gradient-boosted forecasters

The obvious alternative for tabular forecasting work is a gradient-boosted or statistical approach, for example the classical models in statsmodels or the forecasting estimators in sktime, the same organisation that hosts this repository. The difference in approach is not just accuracy. A statistical model fits per series and gives you a closed-form or iterative forecast with no training loop, no GPU and no windowing machinery. A gradient-boosted model with lag features sits between the two: you build the lag and calendar columns yourself, which is more manual than TimeSeriesDataSet but keeps the model inspectable and fast on a laptop. pytorch-forecasting's advantage appears when the number of related series is large enough that shared parameters help and when you need probabilistic multi-horizon output or covariate-aware attention. On a single series, the extra machinery buys you little and costs you a dependency stack.

Maintenance, releases and the MIT licence

The repository is not archived, the default branch is main, and the last push recorded is 2026-09-09. Releases in the supplied list are v1.6.1, v1.7.0 and v1.8.0, spaced roughly two to three months apart across 2026, which suggests active maintenance rather than a dormant project. The licence is MIT, which is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved in copies or substantial portions. That is a description of the licence text, not legal advice, and if you redistribute the package inside a product you should read the LICENSE file in the repository and take your own advice. Upgrade cost is the part the material does not cover. With a fast release cadence and hard dependencies on torch and pytorch-lightning, the realistic cost of staying current is re-running your training pipeline after each bump, because neither the README nor the release list tells you which versions are compatible. Pin your torch and lightning versions alongside pytorch-forecasting in the same requirements file, and re-validate one model end to end before moving the pin.

Editorial conclusion

Adopt it if you have a panel of related series, static or known-future covariates, and a GPU budget for training. Do not adopt it for a single short univariate series where a statistical baseline would answer the question in seconds. Before committing, verify two things yourself: that your installed torch and pytorch-lightning versions satisfy what the pinned release expects, and that your panel is large enough for the model you pick, since N-BEATS and PatchTST are the most parameter-hungry options in the list.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sktime/pytorch-forecasting on GitHub