2025 年 5 月,NX-AI 团队(LSTM 发明人 Sepp Hochreiter 领衔)发布了 TiRex——一个只有 35M 参数、基于 xLSTM 架构的预训练时间序列预测模型。它的核心卖点可以浓缩成一句话:下载即用,不需要在你的业务数据上训练任何东西,直接就能输出未来若干步的点预测与分位数预测,并且在长、短两种预测视野上同时刷新了当时的零样本基准。

这句话里藏着两个”反常识”:

  • 它没有用当前时间序列基础模型主流的 Transformer 架构,而是回到了”过时”的循环神经网络家族;
  • 它用最小的参数量(35M),赢过了 200M、500M 的对手。

为什么需要 TiRex?

传统预测的困境

在深度学习主导的经典范式里,时间序列预测基本是”一个数据集,一个模型”:要为每条业务序列训练 DeepAR、PatchTST、TFT 这类模型,需要专业的数据清洗、特征工程与调参,而且训练数据往往不够。对非专家用户、对高频变更的业务场景,这个门槛几乎是致命的——你可能只是想知道”下周这个城市的客运量会怎样”,却要先搭一套建模流水线。

in-context learning 范式迁移

大语言模型(LLM)的 in-context learning(上下文学习)提供了另一条路:模型在预训练阶段见过海量”序列 → 续写”任务,推理时只要把当前序列作为上下文(prompt)喂进去,就能零样本续写。时间序列领域把这套范式搬了过来——把历史观测值当作上下文,让预训练模型直接预测未来值,这就是 zero-shot forecasting(零样本预测)。它让非专业用户也能用上强大模型,也显著改善了训练数据稀缺场景的表现。

演进时间线:时间序列基础模型(TSFM)的兴起

零样本时间序列预测是 2024 年才爆发的方向,TiRex 站在一排先行者之后,用一张表可以看清它的位置:

时间 模型 组织 架构 意义
2024-03 Chronos Amazon Encoder-Decoder Transformer 首个大规模”token 化 + 语言建模式”预训练时序模型
2024-02 TimesFM Google Decoder-only 因果 Transformer 自回归生成,1.0 / 2.0 两个版本
2024-05 Moirai Salesforce Encoder-only + 掩码建模 统一训练、支持多变量输入的通用时序 Transformer
2025-04 Chronos-Bolt Amazon Encoder-Decoder Transformer Chronos 的加速蒸馏版,推理更快
2025-05 TiRex NX-AI xLSTM(sLSTM) 首个基于 xLSTM 的零样本时序模型,长短视野双优
2026 TiRex-2 NX-AI xLSTM 扩展原生多变量预测与已知协变量支持

遗留的结构性矛盾

TiRex 论文指出了一个被主流忽视的结构性矛盾:主流零样本模型几乎清一色是 Transformer,但 Transformer 在时间序列预测上经常不如循环模型。原因在于时序建模的关键是”状态追踪”——记住”这个序列走到哪一步了、周期到了哪个相位”。LSTM 天生擅长这一点,却缺少 Transformer 那种上下文学习能力;反过来,Transformer 擅长从上下文学习模式,却不擅长跨长视野稳定地追踪状态。TiRex 的任务,就是弥合这道裂缝。

TiRex 是什么:架构与技术核心

底座:xLSTM——LSTM 之王的现代回归

Sepp Hochreiter 是 LSTM 的发明人(1997 年),2024 年 5 月他领衔发布了 xLSTM 论文,把经典 LSTM 升级为具备上下文学习能力的现代架构(arXiv:2405.04517)。xLSTM 家族包含两类核心单元,两者差异直接决定了 TiRex 的设计选择:

特性 sLSTM(标量 LSTM) mLSTM(矩阵 LSTM)
记忆表示 标量记忆 矩阵记忆
显式状态追踪 ✅ 支持(真实递归路径) ❌ 不支持
并行计算效率 较低(需自定义 CUDA 内核加速) ✅ 高效
记忆容量 较小 较大

TiRex 全部采用 sLSTM 模块——因为只有 sLSTM 保留了显式的状态追踪能力,这是长视野预测的关键属性。代价是牺牲了部分记忆容量与并行效率,但论文的消融实验证实:对零样本预测任务来说,状态追踪的价值高于记忆容量。

模型配置一览

TiRex 是一个标准的 decoder-only 模型:轻量输入层与输出层之间堆叠 12 个 xLSTM 块。具体配置如下:

配置项 取值
参数量 35M
上下文长度(context length) 2048
输入 / 输出补丁大小(patch size) 32
嵌入维度 512
前馈维度 2048
xLSTM 块数 12
输出 9 个等距分位数(0.1 ~ 0.9)与均值点估计

数据与 tokenization:把连续序列变成 token

TiRex 的预训练数据合计约 4750 万条时间序列,构成如下:

数据来源 规模 说明
Chronos 训练数据 约 3000 万 采用与 Chronos 相同的 TSMixup 增强
合成高斯过程数据 约 1500 万 类似 KernelSynth 的 GP 生成
GiftEval 预训练语料 约 250 万 与评估数据无重叠

tokenization 分三步:先把序列切成不重叠的窗口(每个窗口 32 个观测值,即一个补丁),再通过两层残差块把每个窗口映射到 512 维的 xLSTM 输入空间,最后把”是否有值”的二进制掩码与序列值拼接后输入模型。输入前还会做一次 z-score 实例归一化($z = (x-\mu)/\sigma$),统一不同量纲的序列尺度。输出层则直接预测目标序列补丁对应的 9 个分位数,训练时优化分位数损失。

CPM:训练时”挖掉一段”再续写

TiRex 的第二个创新是训练策略 CPM(Contiguous Patch Masking,连续补丁掩码)。先看它要解决的问题:标准自回归多步预测存在两个顽疾——一是误差累积,预测值越滚越偏;二是每步用点估计做输入会”重置”概率分布,分位数预测逐渐塌缩。CPM 的做法非常直白:训练时随机掩码连续的补丁块,逼模型学会在”缺了一段”的情况下续写。这与推理时多补丁预测的输入结构(未来补丁全是缺失值)完全一致,相当于让训练与推理的输入分布对齐。

CPM 的具体步骤(对每个训练样本):

  • 均匀采样掩码补丁数量 $c_{mask} \sim U(1, c_{mask\_max})$;
  • 采样掩码概率 $p_{mask} \sim U(0, p_{mask\_max})$;
  • 以 Bernoulli($p_{mask}$) 生成二值掩码(长度 $\lfloor T / (c_{mask} \times m_{out}) \rfloor$);
  • 将掩码重复 $c_{mask} \times m_{out}$ 次,扩展至序列总长度 $T$。

虽然 CPM 借鉴了 BERT 风格的掩码建模,但它的训练本质仍是因果掩码(decoder-only):目标被移位,信息流始终单向。消融实验给出的结论很干脆:CPM 是唯一既能保住短期预测性能、又能增强长期预测性能的训练策略——标准自回归会拖垮长期预测,朴素多补丁(rollout 固定到序列末尾)会拖垮短期预测,只有 CPM 两头兼顾。

多补丁推理:把未来当缺失值

CPM 之所以有效,是因为它与推理策略形成了闭环。当预测视野 $h$ 超过输出补丁长度时,TiRex 不是自回归地用预测值作为下一补丁的输入,而是把未来补丁当作缺失值,让 sLSTM 的内部记忆状态自然地在补丁间传播预测信息与不确定性,一次前向传播输出全部预测补丁。这一设计与大多数 Transformer 时序模型形成鲜明对比:

直观地说:自回归像”走一步看一步,每走一步都把自己的猜测当真”,TiRex 像”闭着眼走完一段路,但每一步的脚感都记住并传给下一步”。后者保留了不确定性的连贯传播,这也是它在概率预测指标(CRPS/WQL)上明显占优的原因之一。

TiRex 效果如何:基准测试与性能

两大零样本基准

TiRex 的评估基于 HuggingFace 上的两个零样本时序基准,分别侧重长、短视野:

基准 规模 特点 核心指标
GiftEval-ZS 24 个数据集、97 个评估设置 覆盖短、中、长期视野与多种频率 MASE(点预测)、CRPS(概率预测)
Chronos-ZS 27 个数据集、27 个评估设置 主要侧重短期预测 MASE、WQL(加权分位数损失)

结果:以最小参数刷新 SOTA

在 GiftEval-ZS 上,TiRex 的 CRPS 为 0.411(±0.002,6 个随机种子),显著优于其他零样本模型,次优模型的得分是 0.459、0.463、0.481。更值得注意的是:TiRex 是唯一在短期与长期预测上同时表现出色的模型——其他模型往往只擅长其中一个视野;并且在长期预测上,TiRex 成为首个超越任务特定模型 PatchTST 与 TFT 的零样本模型。在 Chronos-ZS 上,TiRex 的 WQL 与平均排名取得最佳,MASE 排名第二(紧次于 TabPFN-TS)。

推理效率:小模型就是快

性能之外,推理效率是 TiRex 的另一大优势:它比 TimesFM-2.0 快超过 11 倍,比 Chronos-Bolt Base 快超过 4 倍,比 TabPFN-TS 快超过 2176 倍(GPU 显存消耗的差距也遵循类似顺序)。参数量上的碾压级差距见下图:

公平性说明:数据泄漏问题

零样本评估最忌讳”训练数据与测试数据重叠”(数据泄漏)。TiRex 论文专门核查了各对比模型的情况,结果值得玩味:

模型 GiftEval 数据重叠 Chronos-ZS 数据重叠
Moirai 19% 82%
TimesFM 10% 15%
TTM 16% 11%
TiRex 严格零重叠 严格零重叠

Moirai 在 Chronos-ZS 上的表现之所以大幅提升,正是因为其预训练数据与测试集有 82% 重叠;而 TiRex 的预训练数据与两个评估集都严格无重叠,成绩是”干净”的。

怎么用 TiRex:安装与代码实战

安装

TiRex 已发布到 PyPI(包名 tirex-ts),一条命令即可安装。基础安装只包含核心推理能力:

pip install tirex-ts

如果需要 GluonTS 或 HuggingFace Datasets 作为输入 / 输出适配器:

pip install "tirex-ts[gluonts,hfdataset]"

一次性安装全部扩展:

pip install "tirex-ts[all]"

如果要用 sLSTM 的自定义 CUDA 内核加速,加上 cuda extra:

pip install "tirex-ts[cuda,gluonts,hfdataset]"

注意:TiRex 目前仅在 Linux 和 macOS 上测试通过。

快速开始:5 行代码出预测

核心 API 只有两个:load_model 加载模型,model.forecast 做预测。下面的例子对 5 条长度为 128 的序列各预测未来 64 步:

import torch
from tirex import load_model, ForecastModel

model: ForecastModel = load_model("NX-AI/TiRex")
data = torch.rand((5, 128))  # Sample Data (5 time series with length 128)
quantiles, mean = model.forecast(context=data, prediction_length=64)

quantiles 返回 9 个分位数(0.1~0.9)的概率预测,mean 是均值点估计。仓库还提供了扩展快速开始 Notebook(含不同输入 / 输出数据类型的用法),可以直接在 Google Colab 里运行。

CUDA 内核配置

sLSTM 的自定义 CUDA 内核会在模型首次加载时编译,要求 GPU 支持 CUDA 计算能力 8.0 及以上。可以显式指定 CUDA 后端:

model = load_model("NX-AI/TiRex", backend="cuda")

编译前先声明 GPU 的计算能力范围(例如 8.0 / 8.6 / 9.0):

export TORCH_CUDA_ARCH_LIST="8.0;8.6;9.0"

遇到自定义 torch / CUDA 环境时,可用环境变量注入 CUDA 头文件路径:

export XLSTM_EXTRA_INCLUDE_PATHS='/usr/local/include/cuda/:/usr/include/cuda/'

也可以在 Python 里设置:

import os
os.environ['XLSTM_EXTRA_INCLUDE_PATHS']='/usr/local/include/cuda/:/usr/include/cuda/'

仓库还提供了 requirements_cu124.yaml(CUDA 12.4 conda 环境),官方强烈建议按此环境配置。

不止预测:三大任务与多种部署形态

TiRex 不止是一个预测模型,围绕它还扩展出了分类、回归等下游任务,以及 Docker、ONNX 等多种部署形态:

能力 说明 入口
零样本预测 点估计 + 9 分位数概率预测 快速开始 Notebook / Colab
时间序列分类 把预训练预测模型当作特征提取器,再接入分类头 分类文档与快速开始 Notebook
时间序列回归 在预训练表示上做回归任务 回归文档与快速开始 Notebook
ONNX 推理 跨硬件平台 / 框架的优化推理 ONNX Notebook
Docker 部署 容器化推理服务,内置 MCP 协议支持 inference/README 与部署文档
微调(Finetuning) 官方不提供开源微调流程,有需求需联系团队 contact@nx-ai.com

其中 Docker 镜像配合 fastmcp 提供 MCP 协议推理服务,意味着 TiRex 可以作为 AI Agent 的一个工具被调用——把”预测能力”标准化成服务接口。

项目结构

仓库目录组织清晰,核心代码在 src/tirex/:

目录 / 文件 说明
src/tirex/ 核心源代码(模型、加载器、适配器)
examples/ 快速开始、分类、回归、ONNX、基准测试等 Notebook
inference/ 推理服务(Docker 镜像、MCP 协议)
benchmark/ GiftEval / Chronos-ZS 基准复现代码
tests/ 测试用例(pytest)

应用场景、局限性与生态展望

适合用 TiRex 的场景

  • 数据稀缺的冷启动预测:新业务、新产品线没有足够历史数据,零样本模型是唯一现实选择。
  • 多序列长尾场景:零售 SKU 销量、设备传感器、城市客流、线路票量等成千上万条序列,逐条建模成本不可接受,一条流水线批量预测才可行。
  • 概率预测需求:需要分位数 / 区间输出做风险预警(如库存安全水位、需求高峰预警、容量规划),而不是只要一个均值。
  • 快速原型与基线:上线复杂定制模型前,先用 TiRex 的结果当基线,判断”定制值不值”。
  • 推理延迟敏感的服务:相比同级别 Transformer 模型 4~2176 倍的推理加速,适合嵌入实时监控与告警链路。

局限性:边界要看清

TiRex 很强,但不是万能的。以下边界在使用前必须确认:

维度 限制 影响
平台支持 仅在 Linux 和 macOS 上测试 Windows 用户需要容器或云环境
硬件要求 CUDA 内核需计算能力 ≥ 8.0(非必需,可用 CPU 推理,但慢) 老 GPU 无法获得内核加速
模型容量 35M 参数、上下文 2048、补丁 32 固定 超长历史依赖需自行裁剪
单变量假设 原生版本面向单变量序列 多变量联动场景需 TiRex-2 或自行拼接特征
许可证 NXAI Community License(社区许可证,非标准开源协议) 商用前需自行评估条款
微调能力 官方不开放开源微调流程 定制化需求需联系团队走商业渠道

TiRex-2 与生态展望

TiRex 的后续版本 TiRex-2 已经发布,在保留零样本预测能力的基础上,扩展了原生多变量预测与 past / future 已知协变量支持(arXiv:2607.01204)。这标志着时间序列基础模型的演进路径:单变量 → 多变量 → 已知协变量 → 多模态。对从业者来说,这意味着”零样本”的适用范围正在从”预测一条曲线”扩展到”预测一整张业务表”。TiRex 用 35M 参数证明的”递归架构 + 状态追踪”路线,也会在后续版本中继续延续。

结论

TiRex 的核心贡献是三件事:一是把 xLSTM(具体说是 sLSTM)引入零样本时间序列预测,用显式状态追踪补齐了 Transformer 在长视野上的短板;二是用 CPM 训练策略 + 多补丁推理,把”训练时掩码”与”推理时把未来当缺失值”对齐,同时解决了误差累积与分布塌缩;三是以 35M 参数在 GiftEval-ZS 与 Chronos-ZS 上刷新 SOTA,并给出 4~2176 倍的推理加速。一句话浓缩:TiRex 用递归架构、最小参数和”把未来当缺失值”的推理方式,重新定义了零样本时间序列预测的性价比。

行动建议:想快速验证零样本预测能力,直接 pip install tirex-ts 跑快速开始;需要概率输出或长视野预测,优先把 TiRex 加进对比基线;面对多变量、带协变量的业务场景,直接看 TiRex-2;而如果你的数据与模型属于”必须自己微调”的范畴,提前评估 NXAI 社区许可证与商业条款。

参考文献 / 扩展阅读

  • Auer 等,TiRex: Zero-Shot Forecasting Across Long and Short Horizons with Enhanced In-Context Learning,NeurIPS 2025,https://arxiv.org/abs/2505.23719
  • Auer 等,Pre-trained Forecasting Models: Strong Zero-Shot Feature Extractors for Time Series Classification,NeurIPS 2025 Workshop (BERT2S),https://arxiv.org/abs/2510.26777
  • Beck 等,xLSTM: Extended Long Short-Term Memory,arXiv:2405.04517
  • TiRex 官方仓库,https://github.com/NX-AI/tirex
  • TiRex 官方文档,https://nx-ai.github.io/tirex/
  • TiRex-2 仓库与论文,https://github.com/NX-AI/tirex-2 arXiv:2607.01204
  • HuggingFace 模型权重,https://huggingface.co/NX-AI/TiRex
0