DIMER-oriented zero-shot forecasting wrapper for NX-AI TiRex-2, supporting univariate and multivariate targets plus optional past and future-known covariates through the upstream open inference API.
NX-AI/TiRex-205e5b26db52bfb256f1ae1bdf785589850482de3tirex-2==0.2.1from tirex_forecasting_pipeline import TiRexForecastPipeline
pipe = TiRexForecastPipeline.from_pretrained(device="cpu") # loads the digest-verified weights/tirex-2/ snapshot
result = pipe.forecast([1, 2, 3, 4] * 16, horizon=12)
print(result["median"])
weights/tirex-2/
dimer-base-manifest.json # modelId, revision, per-file bytes + sha256 (verified on every load)
model-config.yaml # TiRex-2 architecture config read by tirex2.load_model
model.ckpt # 380613375 bytes, git-ignored (PyTorch checkpoint, weights_only deserialisation upstream)
from_pretrained() calls stage_missing_files() then verify_snapshot() and refuses to load if any file is missing or its SHA-256 differs from the manifest; allow_download=True fetches only the absent manifest entries at revision 05e5b26db52bfb256f1ae1bdf785589850482de3. Without a snapshot directory the same flag falls back to upstream tirex2.load_model with hf_kwargs={"revision": ...}; the default is to refuse. To stage the snapshot by hand: hf download NX-AI/TiRex-2 --revision 05e5b26db52bfb256f1ae1bdf785589850482de3 --local-dir weights/tirex-2 (the manifest is committed).
For covariate-conditioned forecasting, the DIMER wrapper enforces the upstream time-axis contract before model execution: past_covariates must have exactly the target context length, while future_covariates must contain exactly context_length + horizon steps. Both accept shape (n_covariates, time) or a one-dimensional single-covariate input and must contain finite values.
tutorials/tirex_forecasting_colab.ipynb is declared TASK-INFERENCE and GUIDED under DIMER Notebook Specification 2.2 and is standalone (§4): generated by tools/build_notebook.py (/3), it carries the package's four modules, the stage runner, a hash-locked requirements file and the manifest, so the exported notebook runs without this repository (parity enforced by tests/test_notebook_parity.py). Nothing is installed into the notebook kernel: a pinned uv builds an isolated environment and each stage runs in its own process, so Run all needs no restart. Its default path generates a deterministic synthetic series in code, withholds the final horizon chronologically, surfaces the pipeline ceilings, resolves the pinned checkpoint through the public API, forecasts on the CPU with the q=0.5 median as the point forecast, scores mae/rmse/interval_coverage against a last-value baseline and a least-squares trend + season reference through evaluation_report, validates BYOD CSVs before pandas ingestion, and exports JSON plus an aligned CSV. BYOD is optional and gated off by default. See tutorials/README.md for the registry and docs/release-verification.md for the release gate.
Candidate. Static/unit checks do not constitute clean-runtime notebook evidence. The regenerated standalone tutorial (blob 1fd4afa76a0f, commit 9ee5922) completed one pass with no restart and 0 errors on a fresh Colab Tesla T4 VM on 2026-10-10 (Colab CLI 0.7.4 sequential execution, 10/10 code cells, 138.2 s, forecast on the CPU reference path; MAE 0.0491 against last-value 0.6729, least-squares 0.0437 and noise floor 0.0414); status stays Candidate until an integrator promotes it; earlier local pre-flight runs of the previous (repository-installing) notebook are recorded in docs/release-verification.md and do not cover the standalone carrier. Complete that file against the exact release revision before calling the notebook release-grade. CPU is the portable reference path; CUDA has additional upstream compiler/kernel requirements and is not the default tutorial assumption. On a machine where a CUDA GPU is visible but no CUDA toolkit is installed, upstream xlstm fails at import even for device="cpu"; from_pretrained uses PyTorch's own toolkit resolution (CUDA_HOME/CUDA_PATH, nvcc on PATH, /usr/local/cuda) and raises a typed RuntimeError naming the fix (hide the GPU with CUDA_VISIBLE_DEVICES="" before importing torch, or set CUDA_HOME) only when none resolves.
This repository’s code and accompanying documentation were developed with generative AI assistance for code development and technical writing under maintainer direction. The maintainer remains responsible for reviewing the implementation, validating results, and making release decisions. AI assistance does not constitute independent verification, provider endorsement, or release approval.
DIMER-oriented zero-shot forecasting wrapper for NX-AI TiRex-2, supporting univariate and multivariate targets plus optional past and future-known covariates through the upstream open inference API.
NX-AI/TiRex-205e5b26db52bfb256f1ae1bdf785589850482de3tirex-2==0.2.1from tirex_forecasting_pipeline import TiRexForecastPipeline
pipe = TiRexForecastPipeline.from_pretrained(device="cpu") # loads the digest-verified weights/tirex-2/ snapshot
result = pipe.forecast([1, 2, 3, 4] * 16, horizon=12)
print(result["median"])
weights/tirex-2/
dimer-base-manifest.json # modelId, revision, per-file bytes + sha256 (verified on every load)
model-config.yaml # TiRex-2 architecture config read by tirex2.load_model
model.ckpt # 380613375 bytes, git-ignored (PyTorch checkpoint, weights_only deserialisation upstream)
from_pretrained() calls stage_missing_files() then verify_snapshot() and refuses to load if any file is missing or its SHA-256 differs from the manifest; allow_download=True fetches only the absent manifest entries at revision 05e5b26db52bfb256f1ae1bdf785589850482de3. Without a snapshot directory the same flag falls back to upstream tirex2.load_model with hf_kwargs={"revision": ...}; the default is to refuse. To stage the snapshot by hand: hf download NX-AI/TiRex-2 --revision 05e5b26db52bfb256f1ae1bdf785589850482de3 --local-dir weights/tirex-2 (the manifest is committed).
For covariate-conditioned forecasting, the DIMER wrapper enforces the upstream time-axis contract before model execution: past_covariates must have exactly the target context length, while future_covariates must contain exactly context_length + horizon steps. Both accept shape (n_covariates, time) or a one-dimensional single-covariate input and must contain finite values.
tutorials/tirex_forecasting_colab.ipynb is declared TASK-INFERENCE and GUIDED under DIMER Notebook Specification 2.2 and is standalone (§4): generated by tools/build_notebook.py (/3), it carries the package's four modules, the stage runner, a hash-locked requirements file and the manifest, so the exported notebook runs without this repository (parity enforced by tests/test_notebook_parity.py). Nothing is installed into the notebook kernel: a pinned uv builds an isolated environment and each stage runs in its own process, so Run all needs no restart. Its default path generates a deterministic synthetic series in code, withholds the final horizon chronologically, surfaces the pipeline ceilings, resolves the pinned checkpoint through the public API, forecasts on the CPU with the q=0.5 median as the point forecast, scores mae/rmse/interval_coverage against a last-value baseline and a least-squares trend + season reference through evaluation_report, validates BYOD CSVs before pandas ingestion, and exports JSON plus an aligned CSV. BYOD is optional and gated off by default. See tutorials/README.md for the registry and docs/release-verification.md for the release gate.
Candidate. Static/unit checks do not constitute clean-runtime notebook evidence. The regenerated standalone tutorial (blob 1fd4afa76a0f, commit 9ee5922) completed one pass with no restart and 0 errors on a fresh Colab Tesla T4 VM on 2026-10-10 (Colab CLI 0.7.4 sequential execution, 10/10 code cells, 138.2 s, forecast on the CPU reference path; MAE 0.0491 against last-value 0.6729, least-squares 0.0437 and noise floor 0.0414); status stays Candidate until an integrator promotes it; earlier local pre-flight runs of the previous (repository-installing) notebook are recorded in docs/release-verification.md and do not cover the standalone carrier. Complete that file against the exact release revision before calling the notebook release-grade. CPU is the portable reference path; CUDA has additional upstream compiler/kernel requirements and is not the default tutorial assumption. On a machine where a CUDA GPU is visible but no CUDA toolkit is installed, upstream xlstm fails at import even for device="cpu"; from_pretrained uses PyTorch's own toolkit resolution (CUDA_HOME/CUDA_PATH, nvcc on PATH, /usr/local/cuda) and raises a typed RuntimeError naming the fix (hide the GPU with CUDA_VISIBLE_DEVICES="" before importing torch, or set CUDA_HOME) only when none resolves.
This repository’s code and accompanying documentation were developed with generative AI assistance for code development and technical writing under maintainer direction. The maintainer remains responsible for reviewing the implementation, validating results, and making release decisions. AI assistance does not constitute independent verification, provider endorsement, or release approval.