TimesFM：当时间序列学会"读下一个词"

✨步子哥 · 2026-08-16T21:56:48+00:00

时间序列预测这件事，过去 50 年的进展可以用一句话概括：从 ARIMA 到 XGBoost，从 XGBoost 到 LSTM，从 LSTM 到 Transformer。每一步都更复杂，但每一步都没有解决一个根本问题：**你仍然需要为每个新场景从头训练模型**。电商销量预测、电力负载预测、服务器流量预测——每个场景都需要标注数据、特征工程、模型调参。一个新业务上线，数据科学家要花几周才能给出一个还过得去的预测。 TimesFM 做的事情是：把 NLP 里"预训练 + 零样本泛化"的范式搬到时间序列领域。你不需要标注数据，不需要特征工程，给它一段历史数据，它直接预测未来。 ## Decoder-only：为什么时间序列不需要 Encoder TimesFM 最反直觉的设计是它用了 decoder-only 架构。在 NLP 里，decoder-only（GPT 系列）的成功是因为语言生成本质上是"给定前文预测下一个 token"。但时间序列预测不也是"给定历史值预测下一个值"吗？是的，但有一个关键区别：语言是离散的（token 是离散的），时间序列是连续的。你不能直接把

一个不该成立的故事

2023 年底，Google Research 的四个人做了一个看似荒唐的实验：把 GPT 的架构原封不动搬到一个完全不同的领域，看它能不能工作。

这个领域是时间序列预测——预测明天的电价、下个月的销量、下一秒的服务器负载。和语言不一样，时间序列是连续的浮点数，没有词表，没有语法，没有"下一个 token"的天然定义。

按理说，这个实验应该失败。语言模型的成功依赖于一个关键假设：文本可以被切分成离散的 token，每个 token 携带语义信息。时间序列没有这个结构。一段 CPU 使用率曲线，你能切出什么"词"来？

但 TimesFM 工作了。不只是勉强工作——它在 30 个公开数据集上的零样本性能，接近那些专门在每个数据集上训练过的监督模型。一个 200M 参数的模型，在笔记本上就能跑，打败了一堆需要 A100 集群训练的深度学习模型。

这个故事告诉我们：基础模型范式的核心不是"语言"，而是"序列"。任何能被切成块的数据，都能用这套范式建模。

核心设计：把连续曲线切成"词"

TimesFM 最反直觉的设计是 patching（分块）。把一段长度 1024 的时间序列，按每 32 个点切一块，每块量化成一个 token。这样 1024 个点就变成了 32 个 token，可以直接喂进 decoder-only transformer。

这个想法来自 PatchTST（2022 年的另一个工作），但 TimesFM 做了一个关键改进：输入块和输出块长度不一样。

输入 patch 长度 = 32（每 32 个点一个 token）
输出 patch 长度 = 128（每步预测 128 个点）

为什么这么设计？因为在时间序列预测里，直接一次性预测整个 horizon 比自回归一步步预测更准（这是长期预测的一个经验结论）。但基础模型在推理时不知道 horizon 有多长，不能一次性预测全部。

TimesFM 的折中方案：让每步自回归预测的块更长。预测 512 步的未来，传统做法要 16 步自回归（每步 32 个点），TimesFM 只要 4 步（每步 128 个点）。更少的自回归步骤 = 更少的误差累积。

这个"非对称 patch"设计是 TimesFM 和标准 LLM 的关键区别。在 LLM 里，输入和输出都是 token，长度对称。TimesFM 把输出块做大，是为了在"一次性预测"和"自回归"之间找到平衡点。

论文的消融实验直接验证了这一点：output_patch_len=128 的模型在 ETT 数据集上预测 512 步，明显优于 output_patch_len=32 的版本。前者 4 步，后者 16 步——步骤少四倍，误差也低。

Decoder-only：为什么不需要 Encoder

这是 TimesFM 第二个反直觉的设计。在时间序列预测领域，主流架构是 encoder-decoder（比如 Informer、Autoformer）或者纯 encoder（比如 PatchTST）。TimesFM 选择了 decoder-only——和 GPT 一样。

decoder-only 的核心是因果注意力：每个位置只能看到它之前的位置，不能看到之后。训练时，模型同时学习"用前 32 个点预测第 33-160 个点"、"用前 64 个点预测第 65-192 个点"...一次前向传播，所有子序列的预测同时进行。

这和 LLM 的训练方式完全一样：给定前文，预测下一个 token。TimesFM 把这个范式搬过来，只是把"下一个 token"换成了"下一块时间序列"。

decoder-only 的好处是推理时自然支持任意长度的上下文。你给它 100 个点，它能预测；给它 1000 个点，它也能预测。不需要重新训练，不需要改变架构。这是零样本泛化的前提。

200M 参数：为什么这么小就够了

GPT-4 有 1.7 万亿参数，TimesFM 只有 200M。差了四个数量级。

论文里的 scaling 实验给出了答案：在 17M、70M、200M 三个规模上，性能随参数量单调提升，但提升幅度在递减。从 17M 到 70M 提升明显，从 70M 到 200M 提升放缓。

这和语言模型的 scaling law 形成对比。在 NLP 里，Hoffmann 等人（2022）发现模型性能和参数量、数据量之间存在精确的幂律关系，更大的模型总是更好。TimesFM 也观察到了类似的幂律，但斜率更平缓。

为什么？因为时间序列的信息密度远低于自然语言。

一段 1024 个 token 的文本可能包含一个完整的故事——情节、人物、情感、逻辑关系。一段 1024 个点的时间序列可能只是一个服务器的 CPU 曲线，信息量有限。信息密度低，需要的模型容量就小。200M 参数已经足以拟合时间序列的统计规律。

这个发现有一个工程上的重要含义：时间序列基础模型可以在普通硬件上运行。你不需要 A100 集群，甚至不需要 GPU——200M 的模型在 Apple Silicon 上就能推理。这和 LLM 的"只有大厂能玩"的局面完全不同。

100B 个时间点：训练数据从哪来

基础模型的三大要素：架构、参数量、数据。前两个 TimesFM 都给出了答案，数据呢？

时间序列数据不像文本那样有互联网规模的开源语料。TimesFM 团队用了一个组合策略：

1. Google Trends：22k 个搜索词，从 2007 到 2022 年的小时/日/周/月粒度数据 2. Wikipedia Pageviews：2012 到 2023 年的所有 Wikimedia 页面浏览量，同样多粒度 3. 公开数据集：M4、Electricity、Traffic、Weather 4. 合成数据：ARMA 过程、季节模式（正弦余弦混合）、趋势（线性/指数/变点）、阶跃函数

最终语料库包含约 1000 亿个时间点。这个量级和 GPT-3 的训练数据（约 5000 亿 token）相比不算大，但对于时间序列领域已经是前所未有的规模。

合成数据的使用值得注意。在 NLP 里，合成数据通常不如真实数据。但在时间序列领域，合成数据可以精确控制模式类型——你可以生成纯季节性数据、纯趋势数据、混合数据——让模型学到每种模式的"纯净版本"。这是一种"课程学习"策略，和 Euclid-MCP 的"让专门工具做专门的事"有异曲同工之处。

零样本性能：一个模型打败一群专家

论文在三个 benchmark 上测试了 TimesFM 的零样本性能：

Monash（30 个数据集）：TimesFM 在平均 scaled MAE 上进入 top-3，接近专门训练的 DeepAR 和 N-BEATS。注意这些 baseline 是在每个数据集上单独训练的，而 TimesFM 是一个模型直接零样本推理。

Darts（8 个数据集）：TimesFM 和 ARIMA 并列最佳。这里有个有趣的点——Darts 的数据集每个只有一条时间序列，统计方法（ARIMA）在这种情况下反而有优势，因为深度学习需要更多数据来训练。

ETT（4 个数据集，96 和 192 步 horizon）：TimesFM 和 PatchTST 并列最佳。

关键对比：论文还比较了 llmtime（用 GPT-3 做零样本预测的工作）。TimesFM 在 200M 参数下打败了 GPT-3 的 175B 参数版本。这说明：把通用 LLM 直接用在时间序列上不是最优解——你需要一个为时间序列设计的基础模型。

这个发现挑战了一个流行思路："用 LLM 做所有事"。TimesFM 的证据表明，不同数据类型需要不同的基础模型。语言模型的优势在于语义理解，时间序列模型的优势在于模式识别。强行用 LLM 做时间序列，就像用文字处理器处理 Excel 表格——能做，但不是最优。

协变量支持：从"纯零样本"到"零样本+增强"

TimesFM 2.5（2025 年 9 月发布）加回了协变量支持，通过 XReg 模块。这意味着除了目标变量本身，你还可以输入外部特征：

预测销量时加入促销日历、天气数据
预测电力负载时加入温度、湿度
预测服务器流量时加入部署事件

这个升级让 TimesFM 从"纯零样本预测"进化到"零样本+外部信息增强"。你仍然不需要标注数据来训练模型，但可以在推理时提供额外上下文。

这是一个重要的工程化改进。纯零样本模型在实际业务中往往不够用——业务方有额外的领域知识（促销日、节假日、特殊事件），这些信息如果不输入模型，就浪费了。XReg 让这些信息有了入口。

从研究到产品：Google 的三步落地

TimesFM 的落地速度值得注意。论文 2023 年 10 月发布，2024 年 ICML 接收，到 2026 年已经集成到三个 Google 产品中：

1. BigQuery ML：企业级 SQL 查询，直接在数据仓库里做预测 2. Google Sheets：电子表格里做时间序列预测 3. Vertex Model Garden：Docker 化端点，支持 agentic 调用

从研究到产品的路径不到两年。这个速度暗示了两件事：

第一，Google 内部对 TimesFM 的实用性有信心。研究模型要进入产品，需要通过可靠性、延迟、成本等多重考验。TimesFM 的 200M 参数规模让它能在各种环境部署——从云端 TPU 到笔记本 CPU。

第二，时间序列预测的市场需求巨大。每个有数据仓库的企业都需要预测——销量、流量、库存、风险。传统方案需要数据科学家团队花几周建模，TimesFM 把这个时间压缩到一次 API 调用。

开源代码：一个活跃的生态

TimesFM 的 GitHub 仓库（google-research/timesfm）保持着活跃更新：

2025 年 9 月：TimesFM 2.5 发布，200M 参数，16K 上下文
2025 年 10 月：协变量支持（XReg）回归
2026 年 3 月：Agent 支持（SKILL.md 发布）
2026 年 4 月：LoRA 微调示例（HuggingFace Transformers + PEFT）
2026 年 7 月：PyPI 发布 timesfm=2.0.2

代码使用非常简洁：

import timesfm
model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)
model.compile(timesfm.ForecastConfig(
    max_context=1024, max_horizon=256,
    normalize_inputs=True, use_continuous_quantile_head=True,
    force_flip_invariance=True, infer_is_positive=True,
    fix_quantile_crossing=True,
))
point_forecast, quantile_forecast = model.forecast(
    horizon=12,
    inputs=[np.linspace(0, 1, 100), np.sin(np.linspace(0, 20, 67))],
)

几行代码就能做零样本预测，还能输出分位数预测（不只是点预测）。force_flip_invariance、infer_is_positive、fix_quantile_crossing 这些 flag 说明团队在实际应用中遇到了很多边界情况——非负约束、分位数交叉、翻转不变性——这些都是工程化的产物。

范式迁移的启示

TimesFM 的意义不只是"又一个时间序列模型"。它验证了一个更大的假设：基础模型范式可以从 NLP 迁移到其他序列数据领域。

这个范式的核心三件套： 1. 大规模无监督预训练：不需要标注数据，用数据本身的统计结构 2. Patching + Tokenization：把连续数据切成离散块，变成"词" 3. Decoder-only 自回归：给定前文预测下一步，一次训练覆盖所有子序列

TimesFM 证明这套范式在时间序列上有效。下一个可能迁移的领域：

蛋白质序列：氨基酸序列本质是一维序列，已有 AlphaFold 用 transformer 解决结构预测
音乐旋律：MIDI 事件序列，已有 Music Transformer 等工作
代码执行轨迹：函数调用序列，Agent 系统的日志
生物信号：EEG、ECG、fMRI 时间序列

每个领域都需要自己的"patching"策略——如何把领域数据切成 token。但一旦切好，剩下的架构和训练流程可以直接复用。

这和"换层面解决问题"的概念谱系形成了呼应：章鱼用 RNA 编辑绕过 DNA 转录限制，TimesFM 用 patching 绕过连续数据不可 token 化的限制。不是更强地做同一件事，而是换一个层面让事情变得可能。

一个未解的问题

TimesFM 论文在结论里留了一个诚实的开放问题：

> "In future work, we plan to delve into a more theoretical understanding of how such a time series foundation model can obtain good performance for out-of-distribution data."

翻译：我们也不知道为什么它在没见过的数据上能工作得这么好。

这不是谦虚，是真实的理论空白。LLM 的泛化能力有 in-context learning 等理论解释，但时间序列的零样本泛化缺乏类似的理论框架。TimesFM 在 Monash 的 30 个数据集上表现良好，这些数据集涵盖了金融、气象、交通、旅游等不同领域——为什么在 Google Trends 和 Wikipedia Pageviews 上训练的模型，能预测澳大利亚电力需求？

一个可能的解释：时间序列的"语法"比自然语言简单得多。趋势、季节性、自相关、异方差——这些模式在不同领域反复出现。模型只要学会这些基本模式，就能组合出对新场景的预测。

另一个解释：合成数据的课程学习效应。ARMA、季节性、趋势、阶跃——这些合成数据覆盖了时间序列的"原子模式"，模型在合成数据上学到的能力可以迁移到真实数据的"分子组合"上。

但这些都是事后解释，不是理论预测。TimesFM 的成功是一个经验事实，等待理论解释。

结语：小模型的胜利

TimesFM 的故事里有一个容易被忽略的细节：2.5 版本把参数量从 500M 降到了 200M。

这在"越大越好"的 AI 主流叙事里显得格格不入。但 TimesFM 的团队发现，500M 参数在时间序列任务上是过参数化的——200M 已经足够拟合数据，更小的模型意味着更快的推理、更低的部署成本、更广的设备覆盖。

这个决策让 TimesFM 能跑在 Google Sheets 里——一个浏览器电子表格。如果你的模型需要 A100 才能推理，你永远进不了 Sheets。

TimesFM 的故事最终是关于"合适规模"的故事。不是最大的模型赢，而是最匹配数据信息密度的模型赢。时间序列的信息密度低于语言，所以模型也应该更小。这个洞察比任何具体的架构创新都重要——它告诉我们，基础模型的 scaling 不是无脑堆参数，而是要理解你的数据。

---

相关链接：

论文：A decoder-only foundation model for time-series forecasting（ICML 2024）
代码：google-research/timesfm
模型：HuggingFace Collection
Google Research Blog：research.google/blog