Pretrained Time-Series Foundation Models
Zero-shot forecasting, pretrained knowledge boundaries, covariate timing, and fair historical evaluation
QM025 · AI & Foundation Models · Advanced
Core idea. A pretrained time-series model brings statistical knowledge learned before the downstream task. It can produce forecasts without task-specific parameter fitting, but zero-shot inference does not mean information-free inference.
Use it for. Comparing pretrained forecasting models with conventional statistical or machine-learning baselines; rapid zero-shot forecasting; multiseries or covariate-informed forecasting when the selected model supports those inputs; and model-adoption research.
It does not establish. That a zero-shot forecast is a historical real-time out-of-sample forecast, that the pretraining corpus is temporally clean for every downstream backtest, or that foundation models must outperform task-specific models.
The Question
Traditional forecasting research usually estimates a model from the task’s own historical sample. Pretrained time-series models add another source of information: parameters learned from a large corpus before downstream inference.
This changes the evaluation problem.
A downstream user may provide only observations available at forecast origin \(t\), yet the model parameters may encode patterns learned from external data whose provenance and dates are only partly known. A fair study must therefore distinguish two information boundaries:
- inference-time information supplied to the model for the downstream forecast; and
- pretraining information already embedded in the model parameters.
Why It Matters
Pretrained time-series models are designed to transfer forecasting knowledge across datasets. Examples include TimesFM, Lag-Llama, Moirai, Chronos, and Chronos-2 (Das et al. 2023; Rasul et al. 2023; Woo et al. 2024; Ansari et al. 2024, 2025). They differ materially in architecture, training objective, input format, output distribution, and supported task types.
Those differences matter. It is inaccurate to describe all foundation models as if they tokenize values like the original Chronos, or to assume all support the same multivariate and future-covariate interfaces.
The methodological goal is not to memorize model architectures. It is to build an evaluation contract that remains valid as the model family changes.
Intuition
Consider a conventional Ridge model and a pretrained model evaluated on the same asset at a historical month-end.
Both may receive only price observations dated at or before that month-end. From the downstream dataset’s perspective, the inference inputs are matched.
But the information sets are not identical:
- Ridge parameters were estimated from the researcher’s admissible training history.
- The pretrained model arrived with parameters learned from an external pretraining corpus.
Therefore a careful description is:
The models share the same downstream inference-data cutoff, but the pretrained model contributes external prior information through pretraining.
That is different from claiming that the models use exactly the same information.
What Is a Pretrained Time-Series Model?
A pretrained time-series forecasting model is trained on a broad collection of series or generated time-series tasks and then reused on downstream forecasting problems.
The transfer can take several forms:
- zero-shot: use the pretrained parameters without task-specific gradient-based fitting;
- in-context adaptation: condition predictions on the supplied context and, where supported, related series or covariates without updating parameters;
- fine-tuning: update some or all model parameters on downstream data; or
- adapter/parameter-efficient tuning: update a restricted set of additional parameters.
These modes should not be mixed in one result label. A zero-shot benchmark and a fine-tuned benchmark answer different questions.
Representative Architectures Are Not Interchangeable
Original Chronos
The original Chronos framework scales and quantizes time-series values into discrete tokens and trains language-model architectures with a cross-entropy objective. Probabilistic forecasts are obtained from the predictive token distribution and sampled future trajectories (Ansari et al. 2024).
That description belongs to the original Chronos family.
Chronos-2
Chronos-2 is a later model designed for zero-shot univariate, multivariate, and covariate-informed forecasting. It uses a group-attention mechanism intended to share information across related series, variates, targets, and covariates (Ansari et al. 2025). The official implementation exposes a Chronos2Pipeline; its quantile interface can return quantile and mean forecasts, and its input schema distinguishes past covariates from covariates known into the forecast horizon (Amazon Science, n.d.).
It should not be described simply as the original Chronos tokenization architecture with a new version number.
Moirai
Moirai is a masked-encoder universal forecasting transformer trained on LOTSA, a large multi-domain time-series archive. Its design targets zero-shot forecasting across frequencies and varying numbers of variates (Woo et al. 2024).
TimesFM and Lag-Llama
TimesFM uses a decoder-only foundation-model approach for time-series forecasting (Das et al. 2023). Lag-Llama is a decoder-only probabilistic forecasting model that uses lagged values as covariates and was designed for zero-shot and fine-tuned use (Rasul et al. 2023).
These examples demonstrate why the category is methodological rather than one-model-specific.
Context and Forecast Horizon
Every downstream inference call has at least two temporal dimensions:
- context length: how much history is supplied to the model; and
- prediction length / horizon: how far ahead the output extends.
A model may have a maximum context, a default context, or a training distribution that makes some context/horizon combinations more natural than others. The researcher should record the actual downstream context and requested horizon rather than assume that a model name determines them.
When comparing models, target horizon should be aligned economically. A one-step daily forecast and a next-month portfolio target are not automatically comparable merely because both come from the same model.
Point and Probabilistic Outputs
Pretrained models can output point forecasts, quantiles, samples, or parameters of a predictive distribution, depending on architecture and interface.
Evaluation should match the output:
- point forecasts: MAE, RMSE, or another prespecified point loss;
- quantiles: pinball loss and coverage diagnostics;
- samples/distributions: proper probabilistic scores and calibration diagnostics; and
- downstream decisions: decision-level metrics in addition to forecast metrics.
QM015 — Multivariate Probabilistic Forecast Evaluation covers joint predictive-distribution evaluation.
Zero-Shot Does Not Mean No Prior Information
Zero-shot means that the model is used on the downstream task without task-specific parameter training. It does not mean the model contains no prior information.
A pretrained model’s parameters depend on its pretraining corpus, synthetic-data generation, preprocessing, objective, and model-development choices. For historical research, this creates a distinct audit question:
Could the pretrained model have learned from data overlapping the downstream evaluation period or from later information that would not have been available historically?
If the pretraining corpus and timestamps are fully documented, overlap can be audited. If they are not, the research should not claim that historical application recreates a clean real-time track record.
Retrospective Technology Counterfactual versus Historical Real-Time OOS
Suppose a foundation model released in 2025 is applied retrospectively to decision dates from 2017 onward.
Even if each inference call uses only downstream data available at its simulated 2017, 2018, or 2019 forecast origin, the model itself did not exist then. Such an experiment can be useful, but its correct interpretation is a retrospective technology counterfactual:
How would this current pretrained technology behave when fed historical point-in-time downstream inputs?
It is not a historical live out-of-sample track record of a technology that was actually available throughout the period.
This distinction is essential for model-adoption research.
Covariate Timing
Some pretrained models accept known future covariates. The word known is a data-governance condition, not merely an API field.
At forecast origin \(t\), a future covariate value for \(t+h\) is admissible only if it is genuinely known by \(t\). Examples that may be known include calendar features or contracted prices under a clearly specified dataset. A future realized macro release, market price, or weather outcome is not admissible merely because the model API permits a future-covariate tensor.
For Chronos-2, the official pipeline distinguishes past covariates from values supplied for the future prediction window (Amazon Science, n.d.). Research code must still enforce the external availability contract.
A model accepting future covariates does not certify that your future-covariate values were historically knowable. Availability must be audited at the research-data layer.
Fair Comparison with Conventional Models
A useful model-adoption comparison fixes as much of the downstream decision process as possible:
- same target definition;
- same historical decision dates;
- same downstream data cutoff where feasible;
- same evaluation horizon;
- same asset universe;
- same portfolio mapping, execution clock, and transaction costs when evaluating an investment system; and
- separately documented model-specific input representations.
The last condition matters. A conventional model may consume engineered features while a pretrained model consumes a raw sequence. They can share the same data domain without having identical input representations or prior information.
Forecast Accuracy versus Decision Value
A foundation model need not have the lowest average point-forecast error to improve a downstream portfolio process.
For a ranking strategy, what matters can be whether the new model changes relative ordering near the selection boundary. Therefore model-adoption research should examine at least two layers:
- forecast layer: error, calibration, and stability; and
- decision layer: ranks, selected assets, turnover, costs, and realized portfolio outcomes.
A change in downstream performance is not automatically causal evidence for the pretrained architecture. It is historical evidence about the full declared integration design.
Implementation Contract
A reproducible experiment should record:
| Field | Example audit item |
|---|---|
| Model identity | repository/model ID and version or commit |
| Inference mode | zero-shot, fine-tuned, adapter-tuned |
| Downstream context | exact observations and cutoff |
| Horizon | target period and model prediction length |
| Covariates | past-only versus historically known future values |
| Output | mean, quantiles, samples, path |
| Pretraining boundary | corpus documentation and overlap status |
| Evaluation | point/probabilistic loss and decision-level diagnostics |
| Technology timing | contemporaneously available or retrospective |
If a load-bearing field cannot be certified, state the limitation rather than silently filling it with an assumption.
Hands-on Lab
The lab now has two deliberately separate parts. Part A keeps the deterministic information-timing audit. Part B performs actual zero-shot inference with Amazon Chronos-2 on a synthetic monthly series through the official BaseChronosPipeline.from_pretrained(...) / predict_df(...) interface (Amazon Science, n.d.).
Run it yourself. Start with the lab guide. Direct source: information audit · actual Chronos-2 inference · optional Chronos-2 requirements.
From the QM025 folder, the offline audit remains:
python labs/python/qm025_tsfm_information_audit.pyFor actual pretrained inference:
pip install -r labs/python/requirements-chronos2.txt
python labs/python/qm025_chronos2_zero_shot.pyThe first actual run may download the model checkpoint if it is not cached. The lab compares the Chronos-2 point forecast with a seasonal-naive baseline on one synthetic holdout, but that comparison is only a usage demonstration. It does not establish model superiority.
Most importantly, Part B is labeled a retrospective technology counterfactual. Using only pre-cutoff downstream observations does not turn a current pretrained model into a historical real-time OOS technology. For governed work, record and preferably pin the model revision rather than silently following a mutable main.
Common Mistakes
- Calling zero-shot information-free. Pretraining is prior information.
- Claiming historical real-time OOS for a model that did not exist during the sample. Use retrospective-technology language unless the claim is genuinely supported.
- Assuming pretraining overlap is absent without evidence. Unknown overlap should remain an explicit limitation.
- Describing every TSFM with the original Chronos tokenization scheme. Architectures differ materially.
- Passing realized future covariates because the API permits them. Interface support does not make data historically admissible.
- Comparing different horizons as if they were the same target. Align the economic forecast object.
- Evaluating only RMSE when the downstream task is ranking or allocation. Inspect the decision layer too.
- Hiding model/version identity. Pretrained model behavior can change across checkpoints and software versions.
- Treating benchmark superiority reported by a model paper as guaranteed on a new financial task. Benchmark results are evidence on those tasks, not a universal performance theorem.
When Not to Use It
A pretrained model may be inappropriate when its input/output contract does not match the task, when latency or compute constraints dominate, when the pretraining provenance is incompatible with a strict historical-real-time claim, or when a simpler model performs comparably with much clearer governance.
A foundation model should earn adoption through matched evidence, not through model scale or novelty alone.
Used in SlackQuant Research
- Equity Alpha — benchmark-aware global equity ETF alpha system using point-in-time selection, rank-based decisions, and active-risk evaluation.
Forecast-to-Rank Allocation (F2R) uses Chronos-2 as a pretrained forecasting component alongside conventional supervised forecasting models.
- F2R Model-Adoption Research evaluates Chronos-2 and conventional forecasting approaches under a common decision and evidence framework.
The reusable Method documents the technology and information-boundary questions; it does not disclose protected live production settings.