tfts: A TensorFlow Model Zoo for Time Series Forecasting
tfts: Time Series Deep Learning Models in TensorFlow
At a glance
- What is it?
- The tfts package wraps seq2seq, WaveNet, Transformer, DLinear, N-BEATS and other forecasting architectures behind one AutoConfig and AutoModelForForecasting interface. The convenience is real, but the data contract is stricter than the quickstart suggests.
- Who is it for?
- Adopt tfts if you already run TensorFlow 2.4 or newer and want to compare several published forecasting architectures without writing a training loop per model, and if your data fits the (batch, train_length, feature) tensor shape or the TimeSeriesBatch dict. Do not adopt it if you need probabilistic intervals, exogenous regressors outside the dict schema, or a framework other than TensorFlow.
- Can I use it commercially?
- Yes. MIT 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 8 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 tfts solves: architecture shopping without rewriting the training loop
Most forecasting work starts with a comparison. You want to know whether a WaveNet-style dilated convolution beats a plain RNN on your series before you invest in tuning either. In raw TensorFlow that means writing a separate input pipeline, a separate loss reduction and a separate checkpoint routine for each candidate, then keeping them consistent enough that the comparison means something. tfts removes that duplication. The README describes it as supporting "the classical and latest deep learning methods in TensorFlow or Keras", and the model list in the quickstart confirms the spread: seq2seq, wavenet, transformer, rnn, tcn, bert, dlinear, nbeats, informer, autoformer. The target user is an engineer or researcher who has TensorFlow already installed and wants to swap the model name string rather than the whole script. It is not aimed at someone who wants a scikit-learn style fit and predict on a DataFrame. The package assumes you can produce 3D tensors yourself.
How the AutoConfig and AutoModelForForecasting layer is wired
The mechanism is a registry pattern. You pass a model name string to AutoConfig.for_model, which returns a configuration object for that architecture. You then pass that config plus output_chunk_length to AutoModelForForecasting.from_config, which instantiates the Keras model. Training is delegated to KerasTrainer, which takes the model and exposes train, save_model and plot. The README shows the trainer accepting either a tuple of arrays or a (train_dataset, valid_dataset) pair, and the optimizer is passed straight through as a tf.keras.optimizers.Adam instance with a learning rate of 0.0007 in the example. That is the whole surface: config, model, trainer. The forecasting output is not a bare tensor. In the quickstart, predictions are read as restored_model(x_valid, training=False).predictions.numpy(), so the model returns an object with a predictions attribute. Anyone expecting a plain array from a direct call will need to adjust. The same file also demonstrates saving to a directory and reloading through AutoModel.from_pretrained with a sample_batch argument, which implies the loader needs a concrete batch to reconstruct input shapes before weights are restored.
The input contract is the part that will trip you up
tfts does not infer your schema. For encoder-only models such as rnn, the README specifies a single 3D array with shape (batch, train_length, feature) for inputs and (batch, predict_sequence_length, 1) for targets. For encoder-decoder models such as seq2seq, you must pass a dict with exactly three keys: past_values, past_time_features and future_time_features. The README calls these the "canonical TimeSeriesBatch fields". past_values carries the observed series at (batch, train_length, 1), past_time_features carries encoder covariates, and future_time_features carries decoder covariates at (batch, predict_sequence_length, decoder_features). Note the asymmetry: past_values is fixed at one channel while the feature tensors are variable width. If you hand a seq2seq model a flat array, or misspell a key, there is no documented coercion step. The README also lists three accepted container types, np.ndarray, tf.data.Dataset and tf.keras.utils.Sequence, but the examples only show arrays. Whether the dict form works inside a tf.data.Dataset is not demonstrated in the material provided.
Getting it running: install, train, save, reload
The install line is pip install tfts, with python >= 3.7 and tensorflow >= 2.4 as stated prerequisites. A minimal encoder-only run from the README looks like this: call tfts.get_data("sine", train_length, predict_sequence_length, test_size=0.2) to get a synthetic sine wave split, set model_name_or_path to one of the supported strings, build config = AutoConfig.for_model(model_name_or_path), build model = AutoModelForForecasting.from_config(config, output_chunk_length=predict_sequence_length), wrap it in trainer = KerasTrainer(model), then call trainer.train with the train and valid tuples, an optimizer and epochs=30. Saving is trainer.save_model("./outputs/quickstart_forecasting"). Reloading is AutoModel.from_pretrained(model_dir, sample_batch=x_valid[:1]). For encoder-decoder work the only change is the dict input and the model name, for example "seq2seq", with n_encoder_feature and n_decoder_feature set independently. The Colab and Kaggle badges in the README point to runnable notebooks if you want a working environment before touching your own data.
What the package does not do for you
Three gaps stand out from the documentation. First, there is no mention of prediction intervals or quantile output. The examples all read a point forecast. If your use case needs calibrated uncertainty, you are adding that yourself. Second, there is no data preparation layer. tfts.get_data exists for the bundled sine dataset, but the README gives no scaler, no windowing utility and no missing-value handling for real series, so normalization and gap filling are your responsibility and they will change results between models. Third, the reload path requires sample_batch, which means you cannot restore a model from a path alone. That is a real constraint for serving: whatever process loads the checkpoint must also be able to construct a representative input batch. The release cadence is also worth noting. Three tagged releases appeared within roughly three weeks in August and September 2026, which suggests active development but also that APIs may still move between minor versions. The version string is still 0.0.x. Pin it.
Where tfts sits next to a statistical baseline
The honest comparison is not against another deep learning library. It is against a classical forecaster such as statsmodels SARIMAX or a gradient-boosted tree on lagged features. Those alternatives need no GPU, train in seconds on a few thousand points, and give you confidence intervals out of the box. tfts needs TensorFlow, a GPU to be practical for the transformer and informer variants, and a 3D tensor you have already windowed and scaled. The difference in approach is that tfts treats forecasting as a sequence-to-sequence learning problem with a shared training harness, while a statistical baseline treats it as parameter estimation on a single series. On short series with strong seasonality and few observations, the baseline is usually the right first move. tfts earns its place when you have many related series, enough history to justify a neural model, and a reason to believe a learned representation beats an explicit seasonal term. The presence of dlinear and nbeats in the model list is telling: both are simpler, more linear architectures, and they are often the ones that hold up on tabular-style forecasting benchmarks.
Maintenance, licensing and what to check before you depend on it
The licence is MIT, declared in the README badge and the repository metadata. That permits commercial use and modification with attribution, but it also means no warranty and no obligation on the maintainer to fix anything. The README links a CONTRIBUTING.md and marks contributions welcome. CodeQL, lint and test workflows are configured on the master branch, and a coverage badge points at Codecov, so there is some automated checking in place. None of that tells you whether a given model implementation is correct, only that the repository passes its own suite. Before you build on tfts, run the quickstart unchanged to confirm your TensorFlow version is compatible, then run one encoder-only and one encoder-decoder model on your own arrays to confirm the shape contract holds. If you need to pin, note that the newest tagged release in the material is v0.0.22 from 2026-09-06. The practical cost of upgrading is low if you stay on the AutoConfig and AutoModelForForecasting surface, because that surface is the one the README commits to. The cost is higher if you reach into individual model classes, since nothing in the material promises those internal APIs are stable across 0.0.x releases.
Editorial conclusion
Adopt tfts if you already run TensorFlow 2.4 or newer and want to compare several published forecasting architectures without writing a training loop per model, and if your data fits the (batch, train_length, feature) tensor shape or the TimeSeriesBatch dict. Do not adopt it if you need probabilistic intervals, exogenous regressors outside the dict schema, or a framework other than TensorFlow. Before committing, verify two things on your own data: that your encoder-decoder inputs match the past_values, past_time_features and future_time_features keys exactly, and that AutoModel.from_pretrained can reload a checkpoint saved by the current release, since the README shows sample_batch being passed at load time.
Community notes