TimesFM: Google Research开源的时序预测基础模型
posts posts 2026-05-23T13:09:23+08:00TimesFM 用 decoder-only 架构在 1000 亿真实时间点上预训练了一个仅 2 亿参数的模型,实现跨领域的零样本时序预测。技术笔记GitHub-TrendingTimesFM:时序预测的预训练模型
TimesFM 用 decoder-only 架构在 1000 亿真实时间点上预训练了一个仅 2 亿参数的模型,实现跨领域的零样本时序预测。本文拆解 patching、频率指示器和输出分位数机制。
可以这样理解:TimesFM 把时序预测的接口从「每场景一个模型」切换到了「一个模型接不同数据,直接出预测」。
本文覆盖以下内容:
- TimesFM 为什么用 decoder-only 而不是 encoder-decoder,以及 patching 要解决什么计算瓶颈
- 如何跑通一个零样本预测,拿到结果
- 如何判断一个具体业务场景适不适合直接用零样本预测、什么时候该微调
- TimesFM v2.5 相比 v1 做了什么取舍,尤其是为什么砍掉了频率指示器
学习目标
读完本文后,你应该能够:
- 解释 TimesFM 的 patching 机制为什么能把序列长度除以 32,以及 patch size 的选择标准
- 描述 decoder-only 架构为什么比 encoder-decoder 更适合时序预测任务
- 区分零样本预测和微调的适用场景,并给出一个具体判断标准
- 理解 v1 → v2.5 的版本变化,尤其是为什么砍掉频率指示器
- 跑通一个零样本预测的最小可跑示例,并解释输出结果
目录
- 总览:TimesFM 的三条主线
- 核心架构:patched decoder-only
- 一条数据怎么流过 TimesFM
- 版本变化:v1 → v2.5
- 安装与快速验证
- 零样本预测的边界
- benchmark:数字在说什么
- 适用场景与采用顺序
- 常见问题
- 场景问答(FAQ)
- 自测题
- 练习
- 进阶路线
总览:TimesFM 的三条主线
TimesFM 内部有三条容易混淆的主线,先拆开再看细节:
| 主线 | 做什么 | 为什么关键 |
|---|---|---|
| Patching(分块) | 把连续时间点打包成固定长度的块(patch),作为 transformer 的输入 token | 不 patching 的话,序列太长 transformer 根本推不动;patching 让模型同时学到局部形状和长程趋势 |
| Decoder-only 因果推理 | 每个 patch token 只能看到它之前的 token,预测下一个 patch | 和 GPT 一样的自回归逻辑,天然适合"给历史推未来" |
| 频率感知与归一化 | 输入时做 per-patch 归一化,v1 版本还注入频率标记(v2.5 移除) | 不同场景的量纲差异巨大(零售销量 vs 股价 vs 温度),不归一化模型会把量纲当信号 |
一句话总结:TimesFM = 把时间序列切成块(patch)→ 扔进一个小型 GPT → 逐块预测未来。
核心架构:patched decoder-only
TimesFM 的架构选型到 2.5 版已经收敛得很明确:
原始时序 → 归一化 → 分块(patch) → 残差块 + 输入投影
↓
stacked transformer layers
(因果注意力, 只往左看)
↓
输出头 → 预测 patch与传统时序模型的关键区别:
- 传统方法(ARIMA、Prophet、DeepAR)要么逐点建模、要么依赖显式的季节性和趋势分解。TimesFM 不显式建模这些——它依赖 transformer 的注意力机制自己去学。
- 和 T5/GPT 等文本模型的区别在于 token 的含义不同:文本 token 是离散子词,TimesFM 的 token 是连续时间点的打包。这意味着输入投影和输出头需要特殊设计(不是简单查表 embedding),而是小型的残差 MLP(多层感知机)。
Patching 为什么不是可有可无
不 patching 时,1000 个时间点就是 1000 个 token,transformer 的计算量随序列长度平方增长。patching 把 32 个连续点压缩成一个 token,序列长度当场除以 32。32 这个数字不是随便选的——太短学不到局部模式,太长则在"token 内平滑"和"token 间推理"之间失衡。
Decoder-only 为什么比 encoder-decoder 更合适
时序预测是天然的单向任务:已知过去,推未来。decoder-only 的因果注意力恰好匹配这个约束——不让模型"偷看"未来信息。encoder-decoder 结构在翻译任务里有优势是因为源语言和目标语言的关系不是简单的时间先后,但对时序预测来说,所有输入(历史值、协变量)和输出(预测值)都沿同一个时间轴排列,decoder-only 的结构负担更小。
一条数据怎么流过 TimesFM
以零售 SKU(库存单位)日销量预测为例。假设某个 SKU 过去 512 天的日销量已知,要预测未来 64 天。
第一步:归一化。 输入序列的每个 patch 先除以自己的均值(per-patch normalization)。这一步把"日均销量 1000 件的 SKU"和"日均销量 3 件的 SKU"拉到同一量级,让模型专注形状而非绝对值。
第二步:分块。 512 个历史点被切成 16 个 patch,每个 patch 32 个时间点。每个 patch 先过一个小的残差块做投影,得到一个固定维度的向量。
第三步:transformer 前向。 16 个 patch token 依次经过多层 causal transformer。第 1 个 token 只能看自己,第 9 个 token 能看前 8 个——和 GPT 生成文本的逻辑一样。
第四步:输出。 最后一个 transformer 层的输出 token 走过输出头,预测下一个 patch(未来第 1~32 天)。然后这个预测 patch 被拼回序列末尾,再预测下下个 patch,直到凑满 64 天(2 个 patch)。
第五步:还原尺度。 预测值乘以对应 patch 的归一化因子,回到原始量纲。
整个过程不需要任何模型训练——权重是 Google 预训练好的。这也就是"零样本预测"的含义:直接把数据喂进去,拿结果。
版本变化:v1 → v2.5
TimesFM 经历了两次重大迭代:
| 特性 | v1.0 / v2.0 | v2.5 |
|---|---|---|
| 参数量 | 最高 500M | 200M |
| 上下文长度 | 2,048 时间点 | 16,384 时间点 |
| 频率指示器 | 有(注入频率标记) | 移除 |
| 分位数预测 | 基础 | 连续分位数(最多 1,024 水平) |
| 框架 | PAX/PyTorch | PyTorch + Flax/JAX 双后端 |
v2.5 的有趣之处在于:参数更少了(500M → 200M),但上下文长了 8 倍,还加入了连续分位数预测。这说明 Google 在架构效率上做了不少文章——移除频率指示器是一个信号:per-patch 归一化 + 足够的训练数据本身就能隐式学到频率特征,不需要显式注入。
分位数预测意味着 TimesFM 不只是给一个点预测,而是可以输出预测区间(比如"第 30 天销量有 90% 概率落在 80~120 之间"),这对库存和安全库存决策有直接价值。
安装与快速验证
pip install timesfm零样本预测的最小可跑示例:
import timesfm as tfm
model = tfm.TimesFM()
forecast = model.forecast(
input_ts=[1.0, 2.1, 3.2, 4.1, 5.0],
horizon=24
)
print(forecast)微调示例:
from timesfm import TimesFMFinetuner
finetuner = TimesFMFinetuner(model=model, task="retail_demand")
finetuner.finetune(train_data=retail_data)实际使用时建议直接用 HuggingFace 加载 v2.5 权重:
import timesfm as tfm
model = tfm.TimesFM.from_pretrained("google/timesfm-2.5-200m-pytorch")零样本预测的边界
零样本不等于万能。以下场景中零样本效果通常打折扣:
- 高噪声稀疏序列。如果序列里大部分是 0 或缺失值,patching 机制会把噪声当作信号。此时传统统计方法(如 Croston)可能更合适。
- 强外生变量驱动。如果预测高度依赖促销活动、节假日、政策变化等外部协变量(covariate),零样本模式下模型看不到这些信息,需要走微调或改用支持协变量的接口(TimesFM 2.5 支持 XReg 协变量输入)。
- 极短历史。少于 32 个时间点(一个 patch 的长度)的序列,模型基本没有足够上下文做推理。
零样本更适合的场景:有足够历史长度(≥ 128 个时间点)、规律性较强、不需要复杂外部特征的时序——零售 SKU 日销量、服务器 CPU 利用率、网站日活、电网小时负荷,都在这个范围内。
benchmark:数字在说什么
TimesFM 论文和社区评测(GIFT-Eval)主要测试指标是 MAE(平均绝对误差)和 sMAPE(对称平均绝对百分比误差)。核心结论:
- 在 Monash 时序预测基准的多个数据集上,TimesFM 的零样本结果与各数据集上专门训练的最优模型差距在 10%~20% 以内,部分数据集持平。
- 当目标序列与预训练语料分布接近时(如零售、金融、IoT),零样本效果最好;偏离较大的领域(如流行病传播)效果下降明显。
这些数字能说明的是:用一个模型覆盖多个领域是可行的,预训练语料中的时序模式确实可以迁移。不能说明的是:TimesFM 可以替代所有专业模型——在需要极高精度且允许投入训练资源的场景,微调后的专用模型仍然有优势。
适用场景与采用顺序
按优先级从高到低:
- 先上的团队:有大量不同 SKU/传感器/指标的时序需要预测,但每个序列单独建模不现实。TimesFM 的零样本能力让你先拿到可用基线,再决定哪些序列值得微调。
- 可以试试的团队:已经在用 Prophet 或统计方法做基线的团队。TimesFM 的 point forecast 和分位数区间可以作为第二意见,尤其是在 Prophet 对趋势转折点不敏感的场景。
- 不急着上的团队:只在 1~2 条核心时序上做预测,且已有成熟专用模型。此时 TimesFM 的边际收益有限;但可以关注它的微调路线——在自己的数据上 fine-tune 后替换现有模型。
- 需要评估后再决定的团队:预测严重依赖外部特征(促销、天气、新闻事件)。TimesFM 2.5 支持协变量但文档和生态尚不完善,建议先在代表性序列上跑零样本对比,看与现有带协变量模型的差距。
常见问题
我的数据是 15 分钟级的风电功率,TimesFM 能处理吗?
可以。TimesFM 不依赖显式的频率标记(v2.5 已移除),靠 per-patch 归一化适配任意时间间隔。但默认的 32 点 patch 在 15 分钟级数据上只覆盖 8 小时,不一定能捕获日周期——建议根据业务周期(如日周期 96 个点)调整 patch 长度。
零样本预测准不准?能直接上线吗?
看场景和容忍度。在零售、IoT 等与预训练语料接近的领域,零样本通常能达到专用模型的 80%~95% 水平。如果是关键决策系统(库存补货量直接影响营收),建议先用零样本出基线,再在自己的历史数据上微调后上线。
怎么选 patch size?
默认的 32 是个通用起点。如果序列有明显周期——比如小时级数据的日周期 = 24 点——patch size 最好能被周期整除或与之对齐,让每个 patch 完整覆盖一个模式段。太短学不到局部形状,太长则 patch 内平滑过度、patch 间推理能力下降。
微调需要多少数据?
建议至少几千个时间点。数据太少(比如只有几百个点)时,微调提升不明显,还不如直接用零样本预测。数据量够但场景与预训练语料差异大(如流行病传播)时,微调收益最显著。
注意事项
- CPU 推理可用但较慢,生产环境建议 GPU。
- 微调需要一定训练数据量(建议≥数千个时间点)才有明显提升。
- v2.5 移除了频率指示器,意味着模型对数据频率(日/周/月)的自动适配依赖归一化策略,极端频率(如毫秒级 tick 数据)可能需要重采样。
场景问答(FAQ)
Q:TimesFM 能替代 Prophet 吗?各自的适用场景是什么?
Prophet 适合强季节性、需要可解释性的场景(比如"为什么这个月预测偏高"——Prophet 能分解出趋势、季节性、节假日分量)。TimesFM 的优势在"大量不同序列、每个序列单独建模不现实"的场景——比如你有 10,000 个 SKU 的日销量,用 Prophet 逐个建模太慢,TimesFM 零样本一次出结果。建议:先用 TimesFM 出基线,对关键序列再用 Prophet 做可解释分析。
Q:v2.5 的连续分位数预测怎么用?能给出预测区间吗?
可以。v2.5 支持最多 1,024 个分位数水平。用法:调用 model.forecast() 时指定 quantiles=True,返回的不只是点预测,还有每个分位数的值。比如"第 30 天销量有 90% 概率落在 80~120 之间"——这对库存和安全库存决策有直接价值。
Q:TimesFM 2.5 支持协变量(covariate)输入吗?怎么用?
支持。v2.5 的 API 支持 XReg 协变量输入。用法:在 model.forecast() 中传入 covariates 参数(一个和输入序列等长或更长的时序,代表外部特征)。但文档和生态尚不完善,建议先在代表性序列上跑零样本对比,看与现有带协变量模型的差距。
Q:TimesFM 的预训练语料包含哪些领域?我的数据不在这些领域怎么办?
预训练语料主要包含零售、金融、IoT 等领域的时间序列。如果你的数据不在这些领域(如流行病传播、传感器故障预测),零样本效果会下降明显。此时有两个选项:1) 在自己的数据上微调;2) 用传统统计方法(如 ARIMA、Croston)做基线,TimesFM 作为第二意见。
自测题
读完这篇文章,试试回答下面 5 道题:
TimesFM 的 token 和 GPT 的 token 本质区别是什么?为什么输入投影不能是普通的查表 embedding?
点击查看参考答案
GPT 的 token 是离散子词(subword),通过查表 embedding 映射到向量空间。TimesFM 的 token 是连续时间点的打包(一个 patch = 32 个连续时间点),输入投影需要把连续值映射到向量空间——这不是查表能做的,而是需要小型的残差 MLP(多层感知机)。
一个 SKU 只有 20 天的历史销量,能用 TimesFM 做零样本预测吗?为什么?
点击查看参考答案
不能。TimesFM 的 patch size 默认是 32——小于 32 个时间点的序列,模型无法形成一个完整的 patch,也就无法做推理。建议:要么收集更多历史数据(至少 32 个点),要么用传统统计方法(如 ARIMA 对短序列更友好)。
v2.5 移除了频率指示器,模型靠什么区分日数据和周数据?
点击查看参考答案
per-patch 归一化 + 足够的训练数据。模型在预训练时见过大量不同频率的序列,per-patch 归一化把"日均销量 1000 件"和"日均销量 3 件"拉到同一量级——模型学到的是"形状"而不是"绝对值",所以能隐式地区分不同频率。但极端频率(如毫秒级 tick 数据)可能需要重采样。
什么场景下 TimesFM 的零样本效果会明显不如专门训练的模型?举一个具体例子。
点击查看参考答案
场景:强外生变量驱动(如预测销量高度依赖促销活动、节假日、政策变化)。零样本模式下模型看不到这些外部协变量,只能靠历史值推断——效果会明显不如带协变量的专用模型。具体例子:某个 SKU 在"双十一"期间的销量是平时的 50 倍,TimesFM 零样本预测会严重低估。
TimesFM v2.5 的连续分位数预测对业务决策有什么价值?举一个具体例子。
点击查看参考答案
价值:不只是给一个点预测,而是可以输出预测区间(比如"第 30 天销量有 90% 概率落在 80~120 之间")。这对库存和安全库存决策有直接价值。具体例子:某零售商的某个 SKU 的补货提前期是 14 天,用 TimesFM 的分位数预测可以得到"未来 14 天销量有 95% 概率不超过 X"——这个 X 就是安全库存的参考值。
练习
练习 1:跑通零样本预测
任务:安装 TimesFM,跑通一个零样本预测的最小可跑示例。
步骤:
pip install timesfm- 运行文中的最小可跑示例(输入
[1.0, 2.1, 3.2, 4.1, 5.0],预测 24 个点) - 观察输出:是一个数组吗?长度对吗(24 个)?
- 尝试把输入序列改成自己的数据(比如某个 SKU 的过去 100 天销量)
练习 2:在代表性序列上对比 TimesFM 和 Prophet
任务:选一个你熟悉的时序数据集,用 TimesFM 零样本和 Prophet 分别预测,对比效果。
步骤:
- 找一个公开数据集(如 Monash 基准中的某个零售数据集)
- 用 TimesFM 做零样本预测
- 用 Prophet 做预测(需要安装
prophet包) - 计算两者的 MAE 和 sMAPE
- 分析:TimesFM 在哪些序列上更好?Prophet 在哪些序列上更好?
练习 3:微调 TimesFM
任务:在自己的数据上微调 TimesFM,观察效果提升。
步骤:
- 准备训练数据(建议至少几千个时间点)
- 用
TimesFMFinetuner微调模型 - 在测试集上评估微调后的模型 vs 零样本模型
- 观察:微调后 MAE 下降了多少?分位数预测更准确了吗?
进阶路线
- 入门:跑通零样本预测的最小可跑示例,理解 patch 和 decoder-only 架构
- 应用:在一个真实业务场景(如零售销量预测)中用 TimesFM 出基线
- 对比:在代表性序列上对比 TimesFM、Prophet、ARIMA 的效果
- 微调:在自己的数据上微调 TimesFM,观察效果提升
- 深入:阅读 TimesFM 论文,理解预训练语料的构建和分位数预测的数学原理
- 扩展:尝试把 TimesFM 集成到你的数据处理 pipeline(如用 Apache Airflow 定时跑预测)
- 研究:如果你是研究者和工程师,可以尝试改进 TimesFM 的 patch 设计或预训练目标函数
仓库地址: https://github.com/google-research/timesfm 论文: https://arxiv.org/pdf/2310.10688.pdf
相关工具: Telegraf