Google 开源的「不用训练」时间序列预测模型 TimesFM 详解：原理拆解与上手实战

作者：莫潇羽 | 源码七号站（www.fuyuan7.com）
转载请注明出处，原文首发于源码七号站

快速摘要

这是一篇讲透 Google TimesFM 的长文。核心结论先给你:TimesFM 是 Google Research 开源的时间序列基础模型,它借鉴 GPT 类大模型的思路,把"时间片段"当作"词",用 decoder-only 的 Transformer 在 4000 亿真实世界时间点上完成预训练。最新的 TimesFM 2.5 版本参数压缩到 2 亿,上下文扩展到 16K,官方权重在 Hugging Face 公开可下载,GitHub 地址是 https://github.com/google-research/timesfm这是一篇讲透 Google TimesFM 的长文。核心结论先给你:TimesFM 是 Google Research 开源的时间序列基础模型,它借鉴 GPT 类大模型的思路,把"时间片段"当作"词",用 decoder-only 的 Transformer 在 4000 亿真实世界时间点上完成预训练。最新的 TimesFM 2.5 版本参数压缩到 2 亿,上下文扩展到 16K,官方权重在 Hugging Face 公开可下载,GitHub 地址是 https://github.com/google-research/timesfm 。它最颠覆传统的一点在于:针对一份新的时间序列数据,不用你再去做特征工程、不用你重新训练,直接把历史数据塞进去就能吐出预测值和置信区间,在 GIFT-Eval 等主流榜单上对零样本赛道形成全面压制。下面会从原理、架构、安装、代码实战、落地场景、常见坑六个维度做详细拆解,读完你就能在自己本地把它跑起来。 想直接看代码的朋友可以跳到「本地部署实操」和「代码实战演示」两节,想吃透底层机理的朋友从「核心原理拆解」读起最合适。全文由莫潇羽整理,首发于源码七号站(www.fuyuan7.com),内容较长,建议收藏后慢慢读。

一、从一个常见困境说起

做过数据分析或业务预测的朋友,大概都对下面这个流程无比熟悉:产品部门提了个需求——预测未来一周某个品类的订单量,或者预估下季度门店的客流走势。听起来挺直白,真动手就是另一回事。你得先把历史数据从数据仓库里拉出来,补齐缺失值、剔除异常点、对齐时间粒度;然后选模型,是上 ARIMA、Prophet,还是上 LSTM、Informer;选完还得调超参、切训练集和验证集、跑网格搜索;终于跑出一版结果,业务方看了说"能不能把促销日的影响再单独拟合一下",你只能推倒重来。

传统时间序列预测的痛点就在这里——每换一个场景就意味着一次全流程的重复劳作。模型对数据的敏感度极高,换个城市、换个品类、换个时间粒度,原本表现优秀的模型可能突然就崩了。这也是为什么很多中小团队最终放弃了复杂模型,退回到简单的移动平均或者指数平滑——不是不想要精度,是这个成本扛不动。

更让人头疼的是,时序预测的"模型选择"本身就是一门很难讲清楚的手艺。经典统计方法(ARIMA、指数平滑、状态空间模型)擅长处理平稳数据和明显的季节性,但对非线性模式和多变量关系力不从心;机器学习方法(树模型加特征工程)上限较高,但非常吃特征工程的手感;深度学习方法(LSTM、TCN、Informer、PatchTST)理论上能吃下各种复杂模式,但数据量要求高、训练时间长、调参门槛陡峭。更别说每一种方法都有自己的"脾气",同一套代码在 A 数据集上跑出 SOTA,换到 B 数据集可能直接崩盘。对于大多数没有专职算法团队的业务组来说,选模型这件事本身就是第一道卡点。

大语言模型的兴起给了大家另一个思路:既然 GPT 能通过在海量文本上预训练,做到"一次训练,各种任务零样本可用",那时间序列能不能也搞一个"基础模型"?让它把时间序列里的共性规律(趋势、周期、季节性、突变)提前学好,之后你直接拿来就用,不用再重复造轮子?

Google Research 团队把这个思路真的落地了,名字叫 TimesFM(Time Series Foundation Model,时间序列基础模型)。相关论文 A decoder-only foundation model for time-series forecasting 已经被 ICML 2024 接收,代码和权重全部开源。截至本文发稿时,项目在 GitHub 的 star 数已经逼近 2 万,在时序预测这个相对小众的细分领域里,是相当炸裂的成绩。

我(莫潇羽)在源码七号站(www.fuyuan7.com)持续追踪开源项目已经有些时日,TimesFM 是少数几个让我觉得"范式转移"的项目之一。下面就把它从里到外讲清楚,争取让完全没接触过时序预测的读者也能看明白。

二、TimesFM 到底是个什么东西

一句话总结:TimesFM 是一个专门为时间序列预测训练的、decoder-only 架构的 Transformer 基础模型。它接受一段历史时间点作为输入,输出未来若干个时间点的预测值。

拆开来看几个关键词。

「基础模型」(Foundation Model)这个说法最早源于大语言模型领域,指那些在海量、多样化数据上预训练,能够被直接或经过少量适配就能用到下游任务上的大模型。TimesFM 把这一理念移植到了时序领域——它看过的数据实在太多了,多到任何一份新的业务数据,放进去它都能找到似曾相识的模式。

「decoder-only」指的是架构风格。Transformer 原始论文里的结构是 encoder + decoder,BERT 类模型只保留了 encoder,而 GPT 类模型只保留 decoder。decoder-only 的核心特征是「因果注意力」——每个位置只能看到自己以及之前的位置,看不到未来。这种设计天然适合生成式任务,因为时间序列预测本质上就是「看过去、猜未来」。

「零样本」(Zero-shot)是 TimesFM 最吸引人的性能标签。传统做法里,你要预测 A 公司的销量和 B 公司的流量,就得为这两份数据分别训练两套模型。TimesFM 的承诺是——它在预训练阶段就把"预测未来"这件事的通用能力学会了,任何一份没见过的数据都能直接出结果,不用你再训练。

值得一提的是,TimesFM 的论文作者来自 Google Research 的时序预测团队,他们之前在这个领域深耕多年,对经典方法的利弊了然于心。TimesFM 的设计里能明显看到这种"知其所以然"的痕迹——比如 patch 机制借鉴了 PatchTST 这种前沿的时序 Transformer 工作,分位数头借鉴了概率预测领域的经典做法,合成数据增强借鉴了统计时序的仿真思路。这不是一个把 LLM 套壳到时序的项目,而是在时序领域本身的长期积累之上做的一次架构升级。这种扎实的技术背景,是 TimesFM 在榜单上稳定领先的底气。

官方发布过三个主要版本:

• TimesFM 1.0 (200M 参数,上下文长度 512)——2024 年初发布的首个开源权重,仅支持点估计。
• TimesFM 2.0 (500M 参数,上下文长度 2048)——2024 年底升级版,在主流榜单上相比 1.0 提升可达 25%。
• TimesFM 2.5 (200M 参数,上下文长度 16384)——2025 年 9 月发布,同时也是当前官方主推版本。它在参数量减半的前提下,把上下文扩展了 8 倍,并原生支持概率性(分位数)预测。

2.5 版本看起来很"反直觉"——大模型的普遍趋势是越堆越大,它反而缩了回来。这背后其实是 Google 团队对架构细节做了大量优化,把低效的参数剥离,只留下真正对预测有贡献的部分。结果就是:模型小了,跑得更快,效果反而更好。这种"瘦身成功"的版本,在落地时格外友好,普通一张消费级显卡就能推理。

三、核心原理拆解:它凭什么不训练就开工

TimesFM 能做零样本预测,表面上看像魔法,拆开后其实是几个朴素思路的组合。我尽量用大白话讲清楚每一块。

3.1 Patching:把时间片段当作「词」

NLP 里,Transformer 的输入单位是「token」,大致对应一个词或子词。时序数据没有天然的"词",怎么办?TimesFM 的答案是借鉴 PatchTST 的做法——把连续的若干个时间点打包成一个 patch,把这个 patch 当作一个 token 喂给模型。

举个具体例子。假设你有一段 150 个时间点的历史销量数据,patch 长度设为 32。那么这 150 个点会被切成 (\lceil 150 / 32 \rceil) 个 patch(边缘会做 padding 处理)。每个 patch 包含 32 个原始数值,经过一个线性层(官方叫 Residual Block,残差块)投影到模型维度(1280 维)空间中,得到一个向量。这个向量就是 Transformer 眼中的一个"token"。

为什么要做 patching?有两个直接的好处:

• 降低序列长度。注意力机制的计算复杂度是 (O(n^2)),直接把每个时间点当 token,序列会长到离谱。patching 相当于做了压缩,32 个点合并成 1 个 token,计算量直接降到原来的 (1/32^2)。
• 捕捉局部语义。单独一个时间点(比如"星期三销量 = 105")几乎没有信息量,但连续 32 个点(能看出一个完整周的波形)就有明确的结构意义。patching 保留了这种局部结构,让注意力机制能在更高的抽象层面上工作。

TimesFM 2.5 里,输入 patch 长度是 32,输出 patch 长度是 128。意思是模型每次"说一句话"就是一下子预测未来 128 个时间点,比那种一步一步递归预测的模式效率高得多。

3.2 Decoder-only 架构与因果注意力

把 patch 做成 token 之后,接下来就是 Transformer 的标准操作。TimesFM 2.5 用了 20 层堆叠的 Transformer,每层包含多头因果自注意力(multi-head causal self-attention)和前馈网络(FFN)。

「因果」这个词是重点。标准的 Transformer encoder 里,每个位置能看到序列中的所有位置;但在 decoder 里,每个位置只能看到自己以及前面的位置——这正是时间序列预测所需要的。模型在预测第 5 个 patch 时,只能基于前 4 个 patch 的信息,绝对不允许"偷看"未来,否则训练阶段就信息泄漏了。

每个 patch 进入 Transformer 之前还会叠加一个「位置编码」(positional encoding),用来告诉模型"你现在处理的是第几个 patch"。因为自注意力本身不带顺序信息,位置编码是 Transformer 处理序列数据的标配。

经过 20 层堆叠的计算之后,模型会输出一系列隐状态。最后一个位置的隐状态,通过一个输出残差块(Output Residual Block)映射回数值空间,得到长度为 128 的预测向量——这就是接下来 128 个时间点的预测值。

3.3 训练语料:4000 亿时间点见识广

一个基础模型的上限,很大程度上取决于它"见过多少世面"。TimesFM 的预训练语料规模相当惊人。早期 1.0 版本的训练集是 1000 亿个真实世界时间点,到了 2.5 版本,Google 官方在云产品集成中透露的数字已经扩大到超过 4000 亿。这些数据来自:

• Google Trends 搜索趋势。几乎涵盖所有热门查询词在过去十几年里的每日、每周搜索量曲线,天然带有丰富的周期性、季节性、突发性模式。
• 维基百科页面浏览量。不同语言、不同主题页面的访问曲线,既有新闻事件引发的突刺,也有百科文章长期稳定的长尾。
• 公开的时间序列数据集。涵盖零售、能源、气象、交通、金融等多个行业的公开基准,让模型见识不同领域的常见波形。
• 合成数据。针对一些在真实数据中覆盖不足的模式(比如极端长周期、特殊噪声结构),团队专门合成了一批数据做补充。这一点在论文的消融实验中被证明对泛化能力极其关键。

这种"博览群书"的训练方式,让 TimesFM 对趋势、季节性、周期性、异常突变这些时序里的通用规律非常敏锐。你把一份陌生数据扔进去,模型不需要"学习",只需要"识别"——它会在自己的"经验库"里找到最相似的模式,然后给出预测。莫潇羽在源码七号站做开源评测时,反复看到类似的设计思路,这种基础模型范式在 CV、NLP 之外,正在向时序、表格、图结构等更多数据形态蔓延。

数据多样性的重要程度怎么强调都不过分。论文中有一个很有意思的消融实验:在只用真实数据的前提下,模型在某些罕见周期(比如半年、两年这种不常见的季节性)上表现明显偏弱;加入合成数据之后,这些弱项得到了系统性修复。这说明模型的泛化能力并不完全来自"数据多",更来自"数据的覆盖广"。这也是为什么开源社区里很多人自己爬了几百亿时间点却训不出 TimesFM 同等水平的模型——量堆上去不够,结构多样性跟不上。

3.4 分位数预测:不止告诉你点,还告诉你范围

传统时序模型大多数只给点估计——"下周三的销量大约是 1000"。但这个数字到底有多靠谱?是 950 到 1050 的微小波动,还是 500 到 1500 的大区间?业务方做决策时,这个不确定性区间往往比点估计本身更重要。

TimesFM 2.5 引入了一个可选的 30M 参数的分位数头(quantile head),支持连续分位数预测,最远能预测 1000 个时间步长。开启这个能力之后,模型同时输出 10 个数字:均值,以及 10%、20%、……、90% 九个分位数。

具体怎么用呢?假设你在做库存规划,模型预测下周销量的均值是 1000,10% 分位数是 800,90% 分位数是 1300。这意味着有 80% 的概率销量会落在 800 到 1300 之间。如果你希望做到"95% 不断货"的服务水平,那备货量应该参考 90% 分位数(1300),而不是均值(1000)。反过来,在一些希望保守的场景(比如现金流预算),你可能会选择 10% 分位数作为保守估计。

这一点让 TimesFM 从"一个预测模型"升级到了"一个决策辅助工具"——它给出的不再是单一数字,而是一个可以直接用于风险权衡的分布。从工程角度说,分位数输出还有一个隐形的好处:你可以用 90% 分位数和 10% 分位数的差值,作为"预测不确定性"的指标。这个指标很小说明模型对这段未来非常确信;这个指标很大则说明未来充满变数,依赖预测做决策时需要更谨慎。很多风控、容量规划系统都需要这种"我有多确定"的信号,而 TimesFM 原生就能输出它,不用额外训练。

3.5 预训练目标:让模型学会"猜下一块"

讲完架构,再聊聊 TimesFM 是怎么被训出来的。训练目标和 GPT 非常相似——给定前 N 个 patch,预测第 N+1 个 patch。整个训练过程用的是 teacher forcing,也就是每一步的输入都用真实值而不是模型预测值,这样训练效率最高。

损失函数上,TimesFM 同时用了两个:

• 均方误差(MSE) 用于点预测的主干网络。
• 分位数损失(quantile loss) 用于分位数头,具体地,对每个分位点 (\tau),用 (\max(\tau \cdot e, (\tau-1) \cdot e)) 作为单点损失,其中 (e) 是预测误差。这是做概率预测的标准做法,能让模型同时学会估计多个分位数。

训练硬件用的是 TPUv5e,200M 模型完成 1.5M 步迭代需要大约 2 天。相比那些动辄训几十天的大语言模型,TimesFM 的训练成本已经算相当低。

3.6 为什么 patch 长度选 32 而不是别的

这是个细节但很有意思。论文里做过 patch 长度从 8 到 128 的消融实验。结论是 16 和 32 是效果最好的两个选择,两端都会变差。

为什么会这样?patch 太小的话,每个 token 包含的信息量太少,Transformer 要靠拼接很多 token 才能看到完整模式,自注意力的优势发挥不出来,训练速度也慢。patch 太大的话,每个 token 压缩的信息太多,一个粗粒度 token 没法再表达局部细节,相当于把时间序列"过度抽象"了,模型丢失短期动态。

32 是个理论和工程上都合适的折中点——既能保留足够的短期细节,又让序列长度缩到能接受的范围。同时 patch=32 比 patch=16 训练速度快大约一倍,所以 Google 最终把 32 定为默认值。这种权衡是很多深度学习系统里都存在的"工程口味",值得初学者多琢磨。

3.7 masking 机制:避免死记硬背

有一个细节我想单独讲,叫做随机掩码训练(random masking)。

训练阶段,模型输入的 patch 里会随机挑出一部分位置做 mask(遮住)。为什么?因为如果不做这个操作,模型会学到一个取巧:只在 patch 边界做预测,不做 patch 内部位置的预测。换句话说,它会默认"输入长度永远是 patch 长度的整数倍"。但真实场景里用户的数据长度五花八门,比如 150 个点、237 个点,不一定是 32 的整数倍。

随机 mask 强迫模型必须对"从任意位置切分的 patch"都要有预测能力,保证了推理阶段面对任意长度输入都能给出合理结果。这是个很朴素但非常关键的细节,也是 TimesFM 能在各种粒度的陌生数据上都跑得稳的原因之一。

3.8 flip-invariance、positivity 等推理期增强

TimesFM 2.5 还引入了几个推理期的辅助机制,我简单提一下每一个的用途:

• flip-invariance(翻转不变性)。对输入做一次水平翻转(时间倒序)后再反过来,取两次预测的平均。这是个工程 trick,对少数病态数据能明显改善稳定性。
• positivity inference(正数推断)。如果历史数据都是正数(例如销量、访问量、功率),开启这个 flag 后,模型会把预测值 clip 到非负区间,避免出现物理上不合理的负值。
• fix_quantile_crossing(分位数交叉修复)。理论上 90% 分位数一定大于等于 10% 分位数,但模型是拟合出来的,偶尔会出现低分位数大于高分位数的"交叉"现象,这个 flag 开启后会自动校正。

这些都是从大量实际落地反馈中打磨出来的细节,直接写在了配置项里,真上手的时候默认打开就行。

四、TimesFM 2.5 对比前代有哪些硬核升级

单独把 2.5 版本拎出来再梳理一遍,因为它是目前大家最值得关注的版本。先通过一个对比表直观感受一下三代模型的迭代:

• 参数减半,从 500M 到 200M。这背后是架构剪枝和训练策略优化的成果。小模型意味着更低的显存占用、更快的推理速度,以及更低的部署门槛。一块 16GB 的消费级显卡完全够跑,甚至纯 CPU 也能勉强跑起来(只是慢一些)。
• 上下文从 2K 扩到 16K。能够一次性看完 16384 个历史时间点。对于按小时采样的数据,这相当于能看近 2 年的历史;对于按分钟采样,接近 12 天。这对捕捉多周期模式(比如日周期 + 周周期 + 月周期的叠加)非常关键。
• 原生支持连续分位数预测。前面详细讲过了。
• 去掉了 frequency indicator。之前版本要你告诉模型数据粒度是日、周还是月,2.5 版本去掉了这个参数,模型自己从数据的统计特性中推断。对用户来说就是少了一个容易填错的坑。
• 新增多个推理期 flag。flip-invariance、positivity inference、fix_quantile_crossing,都是开箱即用的稳定性保障。
• LoRA 微调示例。官方仓库里的 timesfm-forecasting/examples/finetuning/ 目录下提供了基于 Hugging Face Transformers + PEFT 的 LoRA 微调代码。意味着你如果有一批自己场景下的历史数据,可以用非常低的成本(通常一张 A10 或 4090 就够)做一次轻量适配,效果比纯零样本再上一个台阶。
• GIFT-Eval 基准第一。在时序预测权威评测 GIFT-Eval 的零样本赛道,TimesFM 2.5 在 MASE(平均绝对缩放误差)和 CRPS(连续排序概率得分)两大指标上都拿到了 SOTA(当前最佳)。

莫潇羽在整理这份资料时,特意去 Hugging Face 核对了官方权重仓库 google/timesfm-2.5-200m-pytorch,里面关于训练数据构成写得很清晰——Google Trends 查询、维基百科页面浏览、合成和增广数据三大来源。这种透明度在开源基础模型里不算常见,值得点赞。

从工程角度看,2.5 版本另外一个容易被忽视但很重要的改进是对推理链路的整体简化。以前的版本里,frequency indicator 这个字段经常让初学者犯错——填错了,效果会大幅下降且难以排查;2.5 直接把这个字段移除,模型自动推断数据频率。类似这种"减少用户做选择"的改动,看起来不起眼,但对落地友好度的提升是实实在在的。工程项目里有一句老话——"默认配置就是设计",好的默认配置能避免大量误用。TimesFM 2.5 在这一点上做得很用心。

五、本地部署实操:从零到跑通第一条预测

这一节我按"零基础小白"的视角手把手写,假设你只装过 Python,没接触过 PyTorch。

5.1 环境准备

TimesFM 官方推荐 Python 3.10+。先检查一下版本:

python --version

如果版本低于 3.10,去 python.org 下一个新版本,或者用 conda 新建一个:

conda create -n timesfm python=3.11
conda activate timesfm

官方推荐用 uv 做包管理,uv 是 Rust 写的新一代 Python 包管理工具,速度比 pip 快很多。没装过 uv 的话,一行命令:

pip install uv

5.2 拉代码、建虚拟环境

# 克隆官方仓库
git clone https://github.com/google-research/timesfm.git
cd timesfm

# 创建虚拟环境
uv venv

# Linux / macOS 激活
source .venv/bin/activate
# Windows 则执行
# .venv\Scripts\activate

5.3 安装依赖

TimesFM 支持 PyTorch 和 Flax/JAX 两套后端,大部分人用 PyTorch 就够了:

uv pip install -e .[torch]

如果你用的是 Apple Silicon 的 Mac,PyTorch 会自动走 MPS 后端,不用额外配置。如果你有 NVIDIA 显卡,参考 PyTorch 官网安装对应 CUDA 版本的 torch。

想要协变量(covariate)支持——也就是除了时间序列本身,还能让模型利用外部变量(比如促销标记、天气、节假日)——额外加一个 xreg 选项:

uv pip install -e .[xreg]

5.4 第一条预测:Hello World

装好之后,打开 Python 交互环境或新建一个 demo.py,贴入下面的代码:

import torch
import numpy as np
import timesfm

# 开启 TF32,能在支持的显卡上获得更快推理
torch.set_float32_matmul_precision("high")

# 加载预训练模型(首次运行会从 Hugging Face 下载权重,约 800MB)
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,    # 修复分位数交叉
    )
)

# 准备两条测试数据
inputs = [
    np.linspace(0, 1, 100),              # 一条线性增长
    np.sin(np.linspace(0, 20, 67)),      # 一条正弦波
]

# 做预测,预测未来 12 步
point_forecast, quantile_forecast = model.forecast(
    horizon=12,
    inputs=inputs,
)

print("点预测形状:", point_forecast.shape)
# 输出:(2, 12) — 两条序列,每条 12 步

print("分位数预测形状:", quantile_forecast.shape)
# 输出:(2, 12, 10) — 每步 10 个分位数(均值 + 9 个分位点)

print("第一条的点预测:", point_forecast[0])
print("第一条的 10% / 50% / 90% 分位:", 
      quantile_forecast[0, :, 1], 
      quantile_forecast[0, :, 5], 
      quantile_forecast[0, :, 9])

运行:

python demo.py

第一次跑会有几十秒在下载权重,之后就跑得很快了。一台 2022 年以后的主流笔记本,这段代码通常 2 秒内出结果。

六、代码实战演示:三个真实场景

光看 demo 不过瘾,我挑三个生活中比较能感知到的场景跑一遍。所有代码我都在源码七号站(www.fuyuan7.com)亲自验证过,读者可以直接复制运行。

6.1 场景一:电商日销量预测

假设你运营一家小电商,每天记录一个 SKU 的销量。历史数据放在 CSV 里,列名是 date 和 sales。目标是预测未来 14 天的销量。

import pandas as pd
import numpy as np
import torch
import timesfm
import matplotlib.pyplot as plt

torch.set_float32_matmul_precision("high")

# 读数据
df = pd.read_csv("sku_sales.csv", parse_dates=["date"])
df = df.sort_values("date").reset_index(drop=True)
history = df["sales"].values.astype(np.float32)

# 加载模型
model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)
model.compile(
    timesfm.ForecastConfig(
        max_context=512,
        max_horizon=64,
        normalize_inputs=True,
        use_continuous_quantile_head=True,
        force_flip_invariance=True,
        infer_is_positive=True,       # 销量必为正数
        fix_quantile_crossing=True,
    )
)

# 预测未来 14 天
point, quant = model.forecast(horizon=14, inputs=[history])

mean_forecast = point[0]            # (14,)
low  = quant[0, :, 1]               # 10% 分位
high = quant[0, :, 9]               # 90% 分位

# 可视化
future_dates = pd.date_range(
    df["date"].iloc[-1] + pd.Timedelta(days=1), periods=14
)

plt.figure(figsize=(12, 5))
plt.plot(df["date"], history, label="历史销量", color="#2878B5")
plt.plot(future_dates, mean_forecast, label="预测均值",
         color="#C82423", linestyle="--")
plt.fill_between(future_dates, low, high, alpha=0.2, color="#C82423",
                 label="80% 置信区间")
plt.legend()
plt.title("SKU 日销量未来 14 天预测")
plt.tight_layout()
plt.savefig("sales_forecast.png", dpi=150)
plt.show()

画出来的图里,历史曲线后面会接上一条虚线(均值预测)和一个半透明色带(置信区间)。业务方一眼就能看出未来两周的大致趋势,以及波动可能的上下界。

6.2 场景二:网站访问量周预测

网站运营最常见的需求——下周流量会怎么走?基于过去半年的日访问量(180 个点),预测未来 7 天。这个场景的特点是明显的"周周期":工作日高、周末低。

import numpy as np, torch, timesfm

torch.set_float32_matmul_precision("high")

# 模拟一段带周周期的数据(真实场景替换成自己的数据)
np.random.seed(42)
days = 180
t = np.arange(days)
base = 5000 + 30 * t                   # 长期上升趋势
seasonal = 1500 * np.sin(2 * np.pi * t / 7)  # 周周期
noise = np.random.normal(0, 200, size=days)
pv = np.maximum(base + seasonal + noise, 0).astype(np.float32)

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)
model.compile(timesfm.ForecastConfig(
    max_context=256, max_horizon=32,
    normalize_inputs=True,
    use_continuous_quantile_head=True,
    force_flip_invariance=True,
    infer_is_positive=True,
    fix_quantile_crossing=True,
))

point, quant = model.forecast(horizon=7, inputs=[pv])

for i, v in enumerate(point[0]):
    lo, hi = quant[0, i, 1], quant[0, i, 9]
    print(f"未来第 {i+1} 天:预计 {v:.0f},80% 区间 [{lo:.0f}, {hi:.0f}]")

把这个跑一次,你会发现 TimesFM 非常自然地把周周期延续了下去——周六周日的预测明显低于周中。而这个过程你没写任何一行"季节性建模"的代码,模型自己从数据里认出来了。

6.3 场景三:服务器 CPU 负载预测

运维同学常做的工作之一——根据历史 CPU 使用率,判断未来几小时是否需要扩容。这里数据粒度是分钟级,周期是日周期。

# 假设你有一个 data.npy,存储了过去 72 小时每分钟采样的 CPU 使用率
# shape: (4320,)  即 72 * 60
import numpy as np, torch, timesfm

cpu_usage = np.load("cpu_usage.npy").astype(np.float32)  # 历史 72 小时

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)
model.compile(timesfm.ForecastConfig(
    max_context=4320, max_horizon=240,     # 最多看 72 小时,预测 4 小时
    normalize_inputs=True,
    use_continuous_quantile_head=True,
    force_flip_invariance=True,
    infer_is_positive=True,
    fix_quantile_crossing=True,
))

# 预测未来 2 小时(120 分钟)的 CPU 负载
point, quant = model.forecast(horizon=120, inputs=[cpu_usage])

# 业务规则:如果 90% 分位数在任意时刻超过 80%,触发扩容告警
p90 = quant[0, :, 9]
if (p90 > 80).any():
    t = int(np.argmax(p90 > 80))
    print(f"警告:预测未来 {t} 分钟后,CPU 90% 分位将突破 80% 阈值")
else:
    print("未来 2 小时 CPU 负载平稳,无需扩容")

这种基于置信区间的告警逻辑,比用均值做判断稳得多——它考虑了波动的不确定性。

七、TimesFM 在 Google 生态里的落地

TimesFM 不只是一个开源项目,Google 已经把它整合进了几个主流产品,大幅降低了不同角色用户的使用门槛。

7.1 BigQuery ML:一行 SQL 搞定预测

如果你的数据本来就在 BigQuery 里,那用 TimesFM 简单到离谱——你根本不用碰 Python,用一行 SQL 就行:

SELECT *
FROM ML.FORECAST(
  MODEL `bqml_tutorial.timesfm_model`,
  STRUCT(
    (SELECT AS STRUCT sale_date AS time_series_timestamp_col,
                      units_sold AS time_series_data_col
     FROM `project.dataset.sales`) AS input_data,
    14 AS horizon,
    0.9 AS confidence_level
  )
);

这是数据分析师和数据工程师的福音。以前做一个销量预测需要 ML 工程师介入、部署模型、对接数据管道,现在业务数据分析师在自己熟悉的 SQL 工作流里就能搞定。

BigQuery 在 2025 年下半年进一步发布了更简洁的 AI.FORECAST 通用函数,不需要预先建模型,直接对一张表执行预测:

SELECT *
FROM AI.FORECAST(
  TABLE `project.dataset.daily_traffic`,
  data_col => 'pageviews',
  timestamp_col => 'event_date',
  horizon => 30,
  confidence_level => 0.95,
  model => 'TimesFM 2.0'
);

这种"零建模"的 SQL 体验,大幅降低了业务团队使用时序预测的门槛。配合 BigQuery 的物化视图和调度任务,可以实现每天自动更新预测、把结果推送给 BI 工具或业务系统的闭环。

另一个常见的玩法是用 AI.FORECAST 的结果和原始数据做对比,驱动异常检测:

WITH actual AS (
  SELECT event_date, pageviews FROM `project.dataset.daily_traffic`
),
forecast AS (
  SELECT forecast_timestamp, forecast_value, 
         prediction_interval_lower_bound AS lo,
         prediction_interval_upper_bound AS hi
  FROM AI.FORECAST(...)
)
SELECT a.event_date, a.pageviews, f.forecast_value, f.lo, f.hi,
       CASE 
         WHEN a.pageviews < f.lo OR a.pageviews > f.hi 
         THEN 'ANOMALY' ELSE 'NORMAL'
       END AS status
FROM actual a JOIN forecast f 
  ON a.event_date = f.forecast_timestamp;

把"预测 + 置信区间 + 对比"三件事打包在一条 SQL 里,每日一跑,异常就自动标红。

7.2 Connected Sheets + BigQuery ML:Excel 用户也能上手

2026 年初,Google 又把 TimesFM 接到了 Google Sheets 的 Connected Sheets 功能里。操作逻辑是这样:数据在 BigQuery 里,你在 Sheets 里用 Connected Sheets 连上,点击"预测"按钮,填写时间列、数值列、预测长度,几秒钟后预测结果和置信区间就填到表格里了。整个过程不写代码、不写 SQL。

这对完全不懂编程的业务用户是巨大的解放。以前做预测必须找技术团队,现在自助完成。

7.3 Vertex AI Model Garden:容器化服务

如果你需要把 TimesFM 集成到自己的线上服务里,又不想自己维护推理基础设施,可以直接用 Vertex AI Model Garden。里面提供了 Docker 化的 TimesFM 端点,按调用量付费,支持 age