Model or dataset
Time-MoE/Time-MoE avatar
Time-MoE/Time-MoE

Time-MoE: A Decoder-Only Forecaster Whose Real Constraint Is 4096 Tokens

[ICLR 2025 Spotlight] Official implementation of "Time-MoE: Billion-Scale Time Series Foundation Models with Mixture of Experts"

999 stars116 forksPythonApache-2.0

At a glance

What is it?
Time-MoE is a family of mixture-of-experts time series foundation models trained from scratch on Time-300B, and the part that matters most for adoption is not the parameter count but the 4096-token window and the pinned transformers version.
Who is it for?
Adopt Time-MoE if you are forecasting univariate series with context plus horizon under 4096 points and want a pretrained checkpoint rather than a per-dataset model. Do not adopt it if your inputs are multivariate with known covariates, since the README lists covariate support as an unfinished TODO, or if you need to pin a transformers version other than 4.40.1.
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 178 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 Time-MoE Targets: Forecasting Without Training a Model Per Dataset

Classical forecasting practice trains one model per series or per dataset. That works, but it means every new sensor, SKU, or meter needs its own training run, its own hyperparameter search, and its own retraining schedule. Time-MoE takes the opposite position. It is a pretrained decoder-only model that accepts a numeric sequence and emits the continuation, so the workflow becomes inference rather than fitting. The README describes it as operating auto-regressively, which is the mechanism that lets prediction horizons vary at call time rather than being fixed when the model is built. The intended user is someone with a forecasting problem and limited appetite for per-dataset modelling, who is willing to accept a general-purpose checkpoint instead of a tuned one. The project also ships Time-300B, described in the README as the largest open-access time series collection at over 300 billion time points across more than nine domains. That dataset exists for a second audience: people who want to fine-tune or pretrain their own forecaster rather than use the released checkpoints.

How the Mixture-of-Experts Decoder Actually Produces a Forecast

The architecture is a decoder-only transformer with mixture-of-experts layers, trained from scratch. Two released checkpoints are named in the README: Maple728/TimeMoE-50M and Maple728/TimeMoE-200M, both on Hugging Face. The paper title claims scaling to 2.4 billion parameters, so the released weights are the small end of the family. The data flow at inference is short and worth stating precisely, because one step is easy to miss. You pass a tensor shaped [batch_size, context_length]. You normalize it yourself along the last dimension using the per-sequence mean and standard deviation. You call model.generate with max_new_tokens set to the prediction horizon. The output tensor has shape [batch_size, context_length + prediction_length]. You slice the last prediction_length columns and multiply by the standard deviation and add the mean back. The normalization is not inside the model. If you skip it, the model still returns numbers, and nothing in the call will tell you they are wrong. That is the single most likely way to get a silently bad forecast from this repository.

Getting It Running: Pinned Dependencies and the Two Commands That Matter

Installation requires Python 3.10 or newer and pip install -r requirements.txt. The README adds a hard note: Time-MoE requires transformers==4.40.1. Treat that as a pin, not a suggestion. The optional but recommended extra is flash-attn==2.6.3, which the README says gives faster training and inference with reduced memory use. If the wheel install fails, the documented fallback is to install packaging and ninja first, then build from source with MAX_JOBS set to your core count, for example MAX_JOBS=64 pip install flash-attn==2.6.3 --no-build-isolation. Loading a model goes through the standard transformers entry point with trust_remote_code=True, and device_map set to cpu or cuda. Evaluation is a single command against a prepared CSV: python run_eval.py -d dataset/ETT-small/ETTh1.csv -p 96. The benchmark files are not in the repository. The README points to a Google Drive folder whose contents you place under ./dataset. Fine-tuning expects JSONL where each line is an object with a sequence field holding a list of observations, and the README notes that json and pickle are also accepted. For small datasets it recommends adding --stride 1 to the training command.

The 4096-Token Ceiling Is a Design Boundary, Not a Bug

The README states that max_position_embeddings is set during training and that the maximum sequence length is 4096. It then gives the operational rule: the sum of context_length and prediction_length should not exceed 4096 for optimal performance. If you need longer sequences, the documented path is to fine-tune Time-MoE at the longer length you want. This is the constraint that decides most adoption questions. A long-horizon forecast from a long history will not fit. You have to choose which side to cut, and cutting context changes the forecast. There is no sliding-window helper in the material provided, so if you want chunked inference over a long series you are writing that layer yourself. The second boundary is modality. The README's TODO list still contains covariate support and fine-tuning with dynamic features, plus time series classification. Until those land, Time-MoE is a univariate forecaster in practice, and a model that cannot see a known future driver is the wrong tool when that driver is the thing that moves the series.

Where Time-MoE Fits Against Per-Dataset Baselines

The obvious alternative is not another foundation model. It is the standard supervised route: train a model on your own series and evaluate it on a held-out split of that same series. The difference in approach is where the learning happens. A per-dataset model learns the seasonality and scale of your data directly and can be evaluated honestly on a split you control. Time-MoE carries patterns learned from Time-300B and applies them zero-shot, which is a real advantage when your series is short or you have many of them, and a real disadvantage when your series has structure the pretraining corpus did not cover. The repository gives you run_eval.py to measure this rather than argue about it. The material provided does not include published error numbers from the project, so any comparison you make has to be one you run yourself on your own CSV. That is the honest position: the tooling for the comparison is here, the verdict is not.

Maintenance, Licensing, and What the Repository Does Not Tell You

The project is Apache-2.0 and the default branch is main. The last push recorded is 2026-03-21, and no releases were retrieved, so there is no tagged version to pin against. That matters for reproducibility: cloning main today and cloning main in six months may not give the same code, and the transformers==4.40.1 pin means an environment upgrade elsewhere in your stack can conflict with it. Budget for that. The Apache-2.0 licence covers the code in this repository; the checkpoints on Hugging Face and the Time-300B dataset are separate artifacts with their own terms, and the README does not state what those terms are. Check the model and dataset cards before any commercial use. Nothing here is legal advice, but the gap between the repository licence and the artifact licences is the kind of thing that gets discovered late. On the upgrade side, the TODO list names covariate support and dynamic-feature fine-tuning as unfinished, so the interface you build against today may change when those arrive.

Who Should Take This Dependency

Time-MoE is a reasonable dependency for a team that has many univariate series, short histories, and a need for a forecast now rather than after a modelling cycle. The generate call is familiar to anyone who has used a causal language model, and the normalization step is two lines. It is a poor fit for a single high-value series where a tuned model would pay for itself, for anything requiring future covariates, and for any pipeline that cannot hold transformers at 4.40.1. The first thing to do is not read the paper. It is to run run_eval.py on your own CSV, with your own context and horizon, and compare the output against the simplest baseline you already have. If the pretrained checkpoint does not beat that baseline on your data, the mixture-of-experts architecture is not the part of the problem you need to solve.

Editorial conclusion

Adopt Time-MoE if you are forecasting univariate series with context plus horizon under 4096 points and want a pretrained checkpoint rather than a per-dataset model. Do not adopt it if your inputs are multivariate with known covariates, since the README lists covariate support as an unfinished TODO, or if you need to pin a transformers version other than 4.40.1. Verify first: run run_eval.py on your own CSV and compare against a naive baseline, because the repository ships no published error numbers for you to check against.

Official sources

  1. Issues
  2. License: Apache-2.0
  3. Project website
  4. README
  5. Time-MoE/Time-MoE on GitHub
Community notes

Community notes