TimesFM-3 零样本预测落地业务：先看许可证，再看排行榜

早八人 技术创作者 2026-09-21 80 阅读

结论先行

  1. TimesFM-3 是 Google Research 的时序基础模型，330M 参数，预训练语料超过 1 万亿个时间点，2026 年 8 月底发布（官方数据：Google Research 博客 2026-08-31；PyPI 发布历史里 timesfm 3.0.0 上传于 2026-08-28，我查证时最新已到 3.0.2）。
  2. 这一代真正的变化是原生多变量 + 两类协变量：从”只看一条序列自己的历史”变成”多条序列 + 未来已知事件联合推断”。这是它和 Prophet/ARIMA 在能力形状上的差别（后者要拿到未来事件得自己写回归项），不是参数量上的差别；官方博客也把它说成”无需逐任务调参”。
  3. 官方权重带的是非商业许可证。HuggingFace 上 google/timesfm-3.0-pytorch 的许可证是 timesfm-non-commercial-license-v1.0，明文写着商业或生产用途不被许可，且”用输出或衍生模型去训练、微调、蒸馏其他商用模型”也不属于非商业用途。想商用要么走 Google Cloud 的 BigQuery ML（目前对应 2.5），要么单独拿商业授权。
  4. BigQuery 官方文档的口径和博客不一样，值得单独抄下来：它说”TimesFM 模型的预测结果可与 ARIMA 等传统统计方法相媲美”，并建议需要更多调参空间就直接用 ARIMA_PLUS。这说明零样本的价值主要在”省掉建模和管理模型”，不是精度翻倍。
  5. 最值得先试的两个场景是冷启动和”未来已知事件”：BigQuery 的 AI.FORECAST 官方写明最少要 3 个数据点，少于此直接报错；而促销日历、大促排期这类未来信息，纯单变量模型没有接收通道，多变量 + 协变量才对症。

它到底解决了什么

时序预测在业务里的常见形态是”给每个 SKU、每个仓、每个接口单独建一个模型”。问题不在精度，在数量：几千条序列意味着几千次调参和版本管理。

TimesFM 系列的思路是把这件事变成推理。老版本唯一的硬伤是只能看单条序列的历史，所以它看不到冰淇淋和蛋筒、糖浆之间的关联，也看不到”下周三到周五要做促销”这种未来信息。

TimesFM-3 的两处改动就是冲这个来的：

  • 多变量 token 构造：把连续 32 个时间步打包成一个 patch。目标序列和”仅历史协变量”一个 patch 构成一个 token；”历史 + 未来协变量”则用 lookahead 策略，把当前 patch 与未来 patch 拼成一个 token，官方说法是让模型提前看到”即将到来的已知信号”（这是官方的机制描述，不代表未来信息能绕过时间维的因果注意力，见下一条）。
  • 交替注意力：时间维上是严格因果注意力（防止数据穿越），变量维上是全注意力（同一时间步可以看到所有序列），两层交替堆叠。
  • 非自回归解码：以前逐 patch 自回归生成，有延迟和误差累积；现在用 Contiguous Patch Masking，一次前向就把整个预测区间填满，一次输出 9 个分位数（10% 到 90%）。

官方博客里有一段明确标注为”示意”（Illustrative example）的冰淇淋销量演示：把未来促销日程当作 past-future 协变量传进去后，官方文字描述是”模型会预计每个促销日出现约 20% 的销量抬升”，而纯单变量基线完全不响应。

这一段要按示意读，不能当成官方测得的业务收益：官方没有公布这段演示所用的数据、对照设置或任何数值表，坐标轴只有图表曲线。它证明的是”协变量通道确实被模型用上了”这件事本身。

业务落地：一句官方文档比一整篇博客更有用

我把 Google Cloud 的 BigQuery ML 官方文档逐页读完了，里面有几处比博客更诚实的表述：

来源：Google Cloud 官方文档《TimesFM 模型》 https://docs.cloud.google.com/bigquery/docs/timesfm-model

“将 BigQuery ML 的内置 TimesFM 模型与 AI.FORECAST 函数搭配使用，您可以执行预测，而无需创建和训练自己的模型……TimesFM 模型的预测结果可与 ARIMA 等传统统计方法相媲美。 如果您想要比 TimesFM 模型提供的更多模型调优选项，可以创建 ARIMA_PLUS 或 ARIMA_PLUS_XREG 模型。”

这段话把定位讲清楚了：它卖的是”免建模、免模型管理”，不是”SOTA 精度”。

榜单口径也得说准，否则比不看更糟。官方公布排名的是三家公开基准——GIFT-Eval、FEV-Bench、TIME，横向只对比预训练时序基础模型（Chronos-2、Toto 2.0 系列、TimesFM-2.5 等），不含 ARIMA、Prophet、Seasonal Naive 这类传统统计方法；图坐标轴标注的是各任务上的平均排名（越低越好），不是绝对分数，具体分数官方没有公布。排名结论本身官方写得很直白：三家基准上都是”预训练基础模型里的第一名（top-ranked）”。所以排行榜能证明”同类里面不差”，证明不了传统方法该被替换——因为传统方法根本不在那张图上。

顺带一个容易踩的坑：官方博客说 BigQuery 集成”未来几周上线”，而 BigQuery 的 AI.FORECAST 文档目前只列了 TimesFM 2.0 和 2.5（默认 2.5）。也就是说 BigQuery 里现在拿不到 3.0 的多变量能力。3.0 是否已进入 BigQuery，未能核实。

一个可复算的中文场景推演

场景：一家生鲜电商，300 个 SKU × 5 个前置仓 = 1500 条日粒度需求序列，要预测未来 14 天每个仓每个 SKU 的销量，并且要输入未来两周的促销排期。

（本节推导所用输入均为我自己的设定，不是任何官方数字。）

算规模：每条序列 90 个历史点，加 14 个预测点，再加 1 条促销协变量通道。PyPI 文档给的上限是 global_context 15,360，90 + 14 = 104 个点，完全够用。

算时间：官方给的 MLX 后端实测（330M 模型、Apple M4 Max、context 512、horizon 64）是 batch 32 时 p50 延迟 48.1 ms、吞吐 666 条序列/秒（官方数据，见 GitHub README / PyPI 页面）。于是我自己的推算是：

推理时间 ≈ 1500 条 ÷ 666 条/秒 ≈ 2.25 秒

这个数有两个折扣要打：官方测的是 context 512 / horizon 64，我这里是 context 90 / horizon 14，本应更快；但 666 条/秒是 M4 Max 上的数字，换机器会变。所以日级别全量重跑在单机上大概率是秒级到十几秒级，日报里跑两次负担得起。这是在原官方数据上”放慢 10 倍”仍然成立的结论。

同样的场景用 BigQuery 的话，官方教程里的写法是一句 SQL（注意 model 参数只能填 2.0/2.5）：

-- BigQuery：多序列 + 未来已知事件(协变量) 是两条不同路径，别混
-- 1) 多序列：用 id_cols 区分序列（官方支持）
SELECT *
FROM AI.FORECAST(
  TABLE `mydataset.daily_sku_warehouse_sales`,
  data_col      => 'units_sold',
  timestamp_col => 'sales_date',
  id_cols       => ['sku_id', 'warehouse_id'],
  horizon       => 14,
  confidence_level => 0.95);
-- 2) 想用"未来促销日历"这类协变量：AI.FORECAST 目前没有该参数，
--    多变量协变量要走开源的 TimesFM-3 Python 路径（见下）
# 【示意代码，非官方原文，未按原样运行过】
# API 名称（TimesFM3Evaluator / ModelConfig / predict_batch /
# past_only_covariates / past_future_covariates）与官方 README、PyPI 项目页的 3.0 示例逐字一致；
# 但数据形状、horizon、变量名是我按自己的生鲜场景改的，这段不是官方示例原文。
# 字段含义与官方示例对齐，请以官方示例为准，不要直接复制这段。
import numpy as np
from timesfm3 import TimesFM3Evaluator, ModelConfig

config = ModelConfig(
    checkpoint_path="google/timesfm-3.0-pytorch",  # 注意：此权重为非商业许可
    per_core_batch_size=16,
    device="cuda",
)
forecaster = TimesFM3Evaluator(config)

context_len, horizon = 90, 14
target   = sales_2d                      # (num_variates, 90) 多仓/多 SKU 作为不同 variate
past_only = foot_traffic_2d              # (k, 90)   仅历史已知
promo     = promo_calendar_2d            # (m, 104)  90 天历史 + 未来 14 天促销标志

# 官方 README 的多变量示例走批量接口，单条序列包成 batch 传进去
outs = list(forecaster.predict_batch(
    contexts=[target],
    horizon=horizon,
    past_only_covariates=[past_only],
    past_future_covariates=[promo],
    return_quantiles=True,
))
print(outs[0].forecast.shape)    # (num_variates, 14)
print(outs[0].quantiles.shape)   # (num_variates, 14, 9) —— 9 个分位数，可直接做安全库存

真正省钱的其实是第三段：分位数输出可以直接变成安全库存和容量水位。比如把 90% 分位数当作补货上限、50% 分位数当作补货期望值，备货策略不用再拍一个固定安全系数。这是我认为比”预测更准”更容易在业务里变成钱的一点。

什么时候它不如传统方法

场景 建议 原因
新店/新品冷启动，历史 < 3 个点 用基础模型 BigQuery AI.FORECAST 官方文档写明”最少 3 个数据点”，少于此报 “The time series data is too short”（这是 BigQuery 里这个函数的下限，不是 TimesFM-3 权重本身的下限——权重侧的下限未能核实）；arXiv 2602.10848 在 ERCOT 负荷数据上测到 Prophet 在 24 小时上下文下 MASE > 74
有确定性的未来事件（促销、节假日、排班） 用多变量 + 协变量 纯单变量模型没有接收未来信息的通道；传统方法要接未来事件得自己写回归项（ARIMAX / Prophet 回归项 / XReg），基础模型则是原生接口
序列很长、模式稳定、特征清楚 ARIMA_PLUS / XReg BigQuery 官方就是推荐这条路，调参空间更大
间歇性需求（大量 0 值、低频 SKU） 传统方法优先 基础模型的预训练语料偏连续序列，间歇需求的评估要换指标（如 MASE），我未能核实 TimesFM-3 在这类数据上的表现
需要解释”为什么这么预测” 传统方法优先 协变量对输出的贡献可解释性，官方博客没有给出分析工具或方法

一句话：它省的是”给一千条序列建模”的工程成本，不是省掉评估。上线前必须先算一条 seasonal naive 基线（上周同一天的值），再看它的提升。

许可证这道坎，必须写清楚

TimesFM 的代码是 Apache-2.0，2.5 及以前的权重也是 Apache-2.0，但 3.0 的权重不是。许可证原文里几个关键定义我读了：

  • “Non-Commercial Purpose” 只包括测试、评估、与商业收益无关的研究；任何与终端用户或生产系统的直接/间接交互都不算。
  • “Derivative” 包括微调、改版、以及任何”incorporates, utilizes, or is otherwise based on”该模型的作品。
  • 明确写出：拿它去训练、微调、蒸馏其他商用模型，不算非商业用途。
  • 反过来也有一个松口子：“Outputs are not considered Derivatives”——预测结果本身不算衍生作品。

需要说清楚的是：许可证原文没有明确覆盖”终端使用场景”——定义里的 “direct or indirect interactions with end users or production systems” 只给出了一个概括性的边界，内部分析、内部报表、内部决策支持这些常见企业用途算不算”间接交互”，原文没有逐条列举。所以”自己下载权重在公司业务里出预测”这件事是需要法务逐条判断的，不是一句”被许可证挡住了”就能结案；也不要反过来读成”大概能用”。

这次没核实的

  • 官方博客的三张基准图我读到的是平均排名，没有读到具体分数，所以本文不给任何数值化的”领先幅度”。
  • 博客那段”约 20% 销量抬升”我读到了官方原句，但官方把它标为 “Illustrative example”（示意），演示数据、对照设置均未公布，因此不能当作可引用的官方收益值，正文已按示意处理。
  • TimesFM-3 没有出现在 arXiv 2602.10848 的评测里，那篇测的是 Chronos-Bolt、Chronos-2、Moirai-2、TinyTimeMixer，以及 Prophet / SARIMA / Seasonal Naive 三个参照。所以那篇的 MASE ≈ 0.31、Prophet 在 24 小时上下文下 MASE > 74 这些数字不能算在 TimesFM-3 头上，只能说明”基础模型这一类”在电力负荷数据上的量级。
  • 该论文摘要里那句”比 Seasonal Naive 低 47%”有两个基准口径，必须一起读：它同时限定了长上下文（C = 2048h）和日前（day-ahead）视界，说的是”表现最好的基础模型在长上下文、日前设定下相对 Seasonal Naive 的 MASE 降幅”，不是”随便什么基础模型在任何设定下都低 47%”，也不是相对 Prophet/SARIMA。我在正文里没有引用这个数字。
  • 中文零售/电商数据上 TimesFM-3 零样本的公开基准：未能核实，我没有找到。若哪位读者有可复现的实测，欢迎在评论区贴出来。
  • 中文社区里我找到的报道（IT之家、至顶网、GIGAZINE）都是对官方博客的转述，属社区二手，本文没有从它们取任何新数字。
  • 官方博客承诺的”BigQuery 集成未来几周上线”，截至我查证时 BigQuery 文档仍只列 2.0/2.5，3.0 是否已进 BigQuery：未能核实。
  • 用 AI.DETECT_ANOMALIES 做异常检测在监控告警场景的实际效果：官方文档标注为预览版，未能核实。
  • 正文那段 Python 没有按原样跑通验证过（我没有任何 GPU 环境、也没有接受非商业许可去下载权重），只核对了 API 名称与参数名确实出自官方示例，因此它按”示意”标注。这类接口在 3.0.x 小版本间也可能变化，动手前请以官方 README 为准。

附：这一稿被指着改过的地方，以及我核实的结果

这篇稿子过审时被标了四处问题，我逐条去打开了原文，结论不全是”我错了”：

被指出的问题 我实际打开原文核对的结果 处理
代码块标”接口取自官方 README 示例”，但 TimesFM3Evaluator / past_only_covariates 无法核实 这条指认不成立：GitHub README 与 PyPI 项目页的 3.0 示例里，from timesfm3 import TimesFM3Evaluator, ModelConfig、past_only_covariates、past_future_covariates 都逐字存在 保留真实 API 名，但把代码块改成示意：补上”非官方原文、未按原样运行”的声明，并把调用改回官方示例的 predict_batch(contexts=[...]) 形式
“排名第一”只是平均排名、未公布分数 原文两方面都对：官方确实只公布平均排名不公布分数，但官方同时明说三家基准上都是预训练基础模型里的 top-ranked 不删”排名”，而是补全口径：平均排名 + 只比基础模型 + 不含 ARIMA/Prophet/Seasonal Naive
促销示例”约 20% 销量抬升”被当成可引用的官方示意值 官方原句确实写着 ~20%，但同一段被官方标为 “Illustrative example”（示意），演示数据与对照设置未公布 保留”官方原句如此”，但明确降级为示意，不算业务收益
“比 Seasonal Naive 低 47%”出现两个基准口径 确有其事：该降幅同时限定”长上下文 C=2048h + 日前视界 + 表现最好的基础模型” 正文不引用该数字，并在”没核实的”里把口径写全
许可证”落不了地”太绝对 原文确实没有逐条覆盖内部使用场景 改为”许可证原文未明确覆盖终端使用场景，需法务判断”

写这一节的用意很简单：审稿意见也要被核实，不能因为是”审稿人说的”就照改——把真 API 说成假 API，反而会让读者不敢用该用的东西。

参考来源

一手来源（当事方自己发布）

第三方研究（独立实测，未包含 TimesFM）

社区二手（仅作背景，未取其数据）

# AI# 知识

评论区

0 条评论

登录后可评论。

早八人 80 阅读