NeuralForecast: A Model Zoo Wrapped in a fit/predict Interface

The Problem NeuralForecast Targets

The README states the motivation directly: neural forecasting methods are believed to improve accuracy and efficiency, but available implementations are hard to use, fail to beat statistical methods, and are computationally prohibitive. NeuralForecast is Nixtla's answer to that gap. It is not a single model. It is a collection of more than 30 neural architectures, including MLP, LSTM, GRU, RNN, TCN, TimesNet, BiTCN, DeepAR, NBEATS, NBEATSx, NHITS, TiDE, DeepNPTS, TSMixer, TSMixerx, MLPMultivariate, DLinear, NLinear, TFT, Informer, AutoFormer, FedFormer, PatchTST, iTransformer, StemGNN, and TimeLLM, all exposed through one interface. The intended user is an engineer or data scientist who already works with time-series panels and wants to test neural approaches without writing a training loop per architecture. The library also claims official implementations of NHITS and NBEATSx, which matters if you need to reproduce published results rather than a reimplementation of unclear provenance.

What the NeuralForecast Wrapper Actually Does

The core object is NeuralForecast. You construct it with a list of model instances and a frequency string, then call .fit() and .predict(). The README's minimal example passes NBEATS(input_size=24, h=12, max_steps=100) and freq='ME', fits on AirPassengersDF, and predicts. That is the whole surface. Each model in the list is a separate PyTorch module with its own hyperparameters: input_size is the lookback window, h is the forecast horizon, max_steps bounds training. The wrapper handles the shared plumbing: data formatting, training loops, and output assembly. According to the README, the interface is unified with StatsForecast, MLForecast, and HierarchicalForecast, meaning the same input and output shapes carry across Nixtla's libraries. That unification is the real product. Swapping NBEATS for NHITS or TFT is a one-line change in the model list, not a rewrite of your data pipeline. The README also notes built-in integrations with utilsforecast and coreforecast for visualization and data wrangling.

Models, Losses, and Probabilistic Output

The feature list is broad. Support for exogenous variables and static covariates is listed, along with interpretability methods for trend, seasonality, and exogenous components. Probabilistic forecasting is handled through adapters for quantile losses and parametric distributions, and the training and evaluation losses cover scale-dependent, percentage, and scale-independent errors plus parametric likelihoods. Automatic model selection is available through distributed hyperparameter tuning, with integrations for Ray and Optuna. The README points to Auto models for this. There is also a transfer-learning path for forecasting with little to no history, documented in a separate repository rather than inside this one. One caveat worth stating plainly: the README lists these capabilities but does not quantify them. There are no accuracy tables, no runtime figures, and no guidance on which model suits which series length or seasonality pattern. Model selection is left to the user, and with more than 30 options that is a real cost.

Installation and the Smallest Working Example

Installation is a single command: pip install neuralforecast, or conda install -c conda-forge neuralforecast. The README links to an installation guide for further details. The quick start imports NeuralForecast from neuralforecast, NBEATS from neuralforecast.models, and AirPassengersDF from neuralforecast.utils, then builds the wrapper with models=[NBEATS(input_size=24, h=12, max_steps=100)] and freq='ME'. Two config keys carry most of the weight: input_size and h. Setting input_size too short starves the model of seasonality; setting it too long inflates memory and training time. max_steps is the training budget, and the example uses 100, which is a demonstration value rather than a production one. The frequency string follows pandas offset conventions, so 'ME' means month-end. Nothing in the README describes GPU requirements, expected training duration, or memory scaling with the number of series, which are the first things you will need to measure on your own hardware.

Where NeuralForecast Is the Wrong Tool

The README's own framing admits the failure mode: neural implementations continuously fail to improve over statistical methods while being computationally prohibitive. NeuralForecast is an attempt to fix that, not a guarantee that it is fixed. If your problem is a single series with a few hundred observations, training a neural network is the wrong move; a statistical baseline will be faster to fit, easier to explain, and often as accurate. The library's strengths show up with many related series, where shared parameters and covariates pay off. There is a second constraint: the training loop is PyTorch, so you need the hardware and the dependency stack that implies. The README does not state minimum versions, GPU memory requirements, or whether CPU-only training is practical for the larger transformers. The model list includes architectures like Informer, AutoFormer, and FedFormer that are known to be heavy, and the README offers no guidance on trimming that list. You are expected to know which models fit your budget before you start.

How It Differs from StatsForecast

The most direct alternative is StatsForecast, from the same organization and sharing the same interface. The difference is the model class, not the API. StatsForecast implements statistical methods such as ARIMA, ETS, and Theta, which fit fast, need no GPU, and produce results that are straightforward to explain to a stakeholder. NeuralForecast implements neural architectures that learn shared representations across series and can incorporate exogenous variables and static covariates in ways classical models handle awkwardly. The trade is training cost and tuning burden against the ability to exploit cross-series structure. Because both share the NeuralForecast().fit(df).predict() shape, you can run a StatsForecast baseline and a neural model on the same dataframe and compare. That is the sensible workflow the README's unification enables, and it is the reason the shared interface matters more than any individual model in the zoo.

Maintenance, Versioning, and Licence

NeuralForecast is actively maintained. The repository is not archived, the last push is dated 2026-09-09, and releases v3.2.0, v3.2.1, and v3.2.2 landed between July and September 2026, roughly monthly. That cadence means you should pin versions in production and read release notes before upgrading, because a minor bump can change model defaults or training behaviour. The project is Apache-2.0 licensed, which permits commercial use and modification, and the README lists 11 contributors. The README does not describe a deprecation policy or a compatibility guarantee across minor versions, so treat upgrades as something to test rather than assume. There is no stated support contract; help runs through GitHub issues and a Slack community linked in the README. For a library that sits in a training pipeline, that is a support model you should weigh before depending on it for a production forecast.

Editorial conclusion

Adopt NeuralForecast if you have a panel of many related series, exogenous covariates, and the GPU time to train neural models, and you want to sweep NHITS, NBEATSx, TFT, and PatchTST without rewriting your pipeline each time. Do not adopt it for a single short series where a statistical baseline would be cheaper, or if you cannot provision the hardware the training loop expects. Before committing, verify three things against your own data: that your dataframe matches the long-format schema the library expects, that the models you plan to use accept your exogenous columns, and that the transfer-learning path actually helps on your series rather than the pretrained source.

Official sources

1. License: Apache-2.0
2. Nixtla/neuralforecast on GitHub
3. Project website
4. README
5. Releases