Amazon时序预测模型Chronos-2

Chronos-2 是 Amazon Web Services 在 2025 年 10 月发布的时序基础模型（Time Series Foundation Model）：一个 120M 参数、encoder-only 架构的预训练模型，能在零样本（zero-shot）方式下同时处理单变量预测、多变量预测和带协变量的预测任务，不需要任何微调。它的定位很明确——做一个”开箱即用、能力面最宽”的通用预测器，让你像调用一个 API 一样把历史数据喂进去、把未来预测拿出来。

理解 Chronos-2，得先看它从哪来。Amazon 的时序基础模型走过了三代，每一代都在补前一代的短板：

这张表是读懂 Chronos-2 价值的最快入口。前两代只能做单变量——一次只看一条序列的历史，预测它的未来，对”零售需求受促销影响””能源消耗被天气驱动””多个云指标协同演化”这类现实场景无能为力。即便 Chronos-Bolt 通过外挂协变量回归器能”部分”处理未来协变量，也只是逐时间步建模效应、无法刻画跨时间的依赖。Chronos-2 用”组注意力”这一个机制把单变量、多变量、协变量三类任务统一进了同一个架构，并把上下文从 512 拉到 8192、预测长度从 64 拉到 1024。

架构总览：encoder-only 与交替注意力

Chronos-2 的第一个关键选择是把架构从 T5 的 encoder-decoder 改成了 encoder-only。这个选择的意义在于：它不做自回归采样（像 GPT 那样一步一步往后生成），而是一次前向就把整段未来的预测全部吐出来。这带来的直接好处是长 horizon 预测不需要反复展开模型，效率高、误差也不会随预测步数累积。

120M 参数的基础版基于 T5 编码器设计，做了两处改动：用旋转位置编码（RoPE）替代 T5 原始的相对位置编码，以及在标准的”时间注意力”层之间交替插入”组注意力”层。整个数据流是这样的：历史目标值与过去协变量先经过鲁棒缩放和补丁化，拼接元特征后通过 ResNet 嵌入，插入一个 REG token 作为分隔符，然后进入编码器堆叠——时间注意力层和组注意力层交替出现，最后接一个 21 分位数回归头输出多步预测。

这张图里最值得记住的是那个虚线框里的”交替层”。标准 Transformer 只有时间注意力——在同一条序列内的不同时间步之间做 self-attention，用来捕获趋势和季节性。Chronos-2 在时间注意力层之间插入了组注意力层，后者干的活完全不同：在同一时间步的补丁索引处，把属于同一”组”的多条序列的信息聚合起来。两种注意力各司其职，交替堆叠让模型既能看懂单条序列的时间结构，又能借用同组其他序列的信息。REG token（注册 token）同时充当历史区与未来区的分隔符和注意力沉（attention sink），帮助模型分离上下文区域和预测区域。

组注意力：通吃多变量与协变量的核心机制

组注意力是 Chronos-2 的核心创新，也是它能”一个架构通吃三类任务”的根本。理解它的方式是先看”组”这个概念有多灵活——同一个”组”在不同任务里代表不同的东西：

• 一组相关的单变量序列：比如同一品类下多个 SKU 的销量，同组内做跨样本交叉学习，让销量模式相近的 SKU 互相借力。
• 一个多变量序列的各个变量：比如电力、天然气、水的消费量协同演化，同组内建模它们的依赖关系，实现多变量预测。
• 目标变量加它的协变量：比如要预测的销量加上促销标记、节假日、天气这些外生变量，同组内让目标”看见”协变量，实现协变量融合。

切换这三类模式不需要改模型，只需要改推理时传入的 group ID——把哪些序列归入同一组，组注意力就只在组内做信息共享。这就把”单变量/多变量/协变量”三种原本需要不同模型的任务，统一成了同一个模型的同一种操作。

组注意力在工程上有一个关键设计：它沿批次轴（batch axis）而非上下文轴做 attention。这意味着内存随变量数 V 线性增长（O(V)），而不是把所有变量拼成一条超长序列那种二次增长（O(V²)）。这两者的差距在高维面板预测里是决定性的——变量数从 10 涨到 20 时，拼接方式的内存翻 4 倍，组注意力只翻 2 倍。

同样预测 16 个变量，拼接方式把内存推到接近上限，组注意力只用了约四分之一——这正是高维面板预测在工程上可行的原因

组内序列没有天然顺序（一组 SKU 谁排第一无所谓），所以组注意力层不加位置编码，只靠注意力掩码确保信息不跨组泄漏。值得注意的是，组注意力打破了深度学习里”batch 内样本相互独立”的惯例——这里 batch 维度被用来做信息共享，group ID 实际上就是 batch 里的切片。这种设计要求使用者在定义”谁和谁共享信息”时小心，避免把不该耦合的序列归入同一组造成泄漏。

输入表征四步管线

Chronos-2 把原始时间序列变成模型能懂的补丁嵌入，经过四步管线，每一步都有明确的设计意图。

第一步是鲁棒缩放。先对历史窗口做标准化（减均值、除标准差），再施加 asinh 变换（反双曲正弦）。asinh 对大值呈现对数行为（压制离群值），对小值保持线性（不扭曲正常区间）。这比直接取 log 更安全——log 在零或负值处无定义，而真实业务数据里销量为零、指标为负很常见，asinh 对所有实数都有定义。

第二步是补丁化（patching）。把连续的时间步分成不重叠的补丁，每个补丁包含 P 个连续时间步的值。这和 PatchTST、ViT 的思路一致：补丁让模型一次看到局部上下文而非单个时间点，既提升计算效率（token 数变少），也让模型学到局部时间模式。这是”把连续数值序列翻译成 Transformer 能处理的 token”的关键一步，但不把数值离散化成词表——和第一代 Chronos 的量化分箱路线不同。

第三步是元特征注入。每个补丁不只包含数值，还拼接了两类信息：相对时间索引（标量，告诉模型这个补丁处在时间轴的什么位置）和掩码（1=观测值，0=缺失或未来不可知）。掩码机制让模型天然区分”历史观测”和”未来已知协变量”——未来目标值是缺失的（掩码=0），而已知未来协变量是有值的，这一区分是协变量预测能成立的基础。分类型协变量则用目标编码（target encoding）或序数编码（ordinal encoding）转成实数表示后再进入同一管线。

第四步是 ResNet 嵌入与 REG token。拼接后的多维向量（数值 + 时间索引 + 掩码）通过一个小型残差网络投影到模型隐藏维度。在历史补丁和未来补丁之间，插入那个前面提过的 REG token——它既是分隔符又是注意力沉，帮模型把”看过的历史”和”要预测的未来”隔开。

输出与训练：21 分位头与合成多变量数据

Chronos-2 的输出端不是分布采样，而是直接的分位数回归。对未来每个目标补丁，通过一个残差块一次性预测 21 个分位数，分位水平从 0.01 到 0.99 均匀覆盖。相比其他模型常用的 9 分位数网格（0.1 到 0.9），21 分位数多了 0.01 和 0.99 两个极端分位，能更丰富地刻画预测分布的尾部——这对异常检测和风险感知预测很有价值。由于一次前向能输出多个补丁的预测，长 horizon 预测不需要自回归展开。

需要注意的是，21 个分位数是独立回归的，可能出现”分位数交叉”——低分位的预测值反而高于高分位。风险敏感场景需要做单调性后处理或 conformal 校准来保证分位数的有序性。这是分位数回归方法的通病，不是 Chronos-2 独有，但用的时候要心里有数。

训练策略里最反直觉的设计是：多变量和协变量训练数据完全来自合成。原因是高质量的真实多变量时序数据极为稀缺——真实多变量数据要么隐私受限、要么长度不够、要么变量配比不均衡。具体做法是引入”多元化器”（multivariator）概念：从基础单变量生成器（AR 模型、ETS 模型、TSI 合成器、KernelSynth 等）采样多条独立序列，然后用两种多元化器施加依赖——同期多元化器在同一时间步做线性或非线性变换引入瞬时相关，序列多元化器跨时间步引入领先-滞后效应和协整关系。这些合成多变量数据既有真实单变量序列的统计特性，又被赋予了可控的多元结构。

训练分两个阶段：第一阶段用最大上下文 2048 和较少输出补丁训练，让模型先学会基本的补丁建模；第二阶段把上下文扩展到 8192 并增加输出补丁数量，让模型捕获高频序列的长期季节性，并实现长 horizon 预测。损失函数为分位数回归损失，只在目标维度上计算——已知协变量和缺失的目标值不纳入损失，避免模型去”预测”本该作为输入的协变量。训练数据是三类混合：Chronos 数据集子集、GIFT-Eval Pretrain 子集，以及合成的单变量与多变量数据。

上下文学习：零样本融合协变量的秘密

Chronos-2 最被强调的能力是上下文学习（In-Context Learning, ICL）——在推理时，把目标序列和相关协变量放进同一组，模型就能”现学现用”地融合它们的关联信息，不需要任何微调。这种能力令人惊讶的地方在于：它很大程度上是从合成数据里学来的。模型在预训练时见过大量”目标 + 协变量”的合成样本，学会了”同组内的其他序列可能是目标的驱动因素”这种通用模式，推理时遇到真实的协变量就能迁移过来。

ICL 带来的增益在三类子集上差异明显，这个差异本身就很说明问题：协变量任务增益最大（因为 ICL 能融合目标与协变量的关联信息，这正是协变量预测最需要的），单变量任务次之（尤其短上下文场景受益于跨序列交叉学习，多条相似序列放一组能互相借力），多变量任务增益最小。多变量增益小的原因有点反直觉但合理——强单变量模型可以通过 Takens 嵌入定理从单变量延迟观测中重构系统动态，多元建模的额外增益因此有限。

零售领域的 Rossmann 案例最能说明 ICL 的价值：单变量模式下促销日的预测曲线平缓且不确定性高（模型不知道为什么这一天销量会涨），启用 ICL 把促销标记作为协变量放入同组后，模型能正确捕捉促销和假期带来的销量波动，预测区间也随之收紧。能源领域的案例则展示了”已知未来协变量”的威力——未来的天气预报是已知的，把它作为未来协变量喂给模型，电价预测精度显著提升。Chronos-2 对协变量任务”始终以显著优势胜出基线”，这正是它在 fev-bench（强调多变量与协变量）上领先的根本。

基准表现与实战上手

Chronos-2 在三大综合基准上均取得预训练模型最优，且对前身 Chronos-Bolt 的逐项胜率超过 90%。具体数值如下：

与其他模型的对比

Chronos-2的安装

pip install chronos-forecasting

Chronos-2的使用

加载模型

使用 Chronos2Pipeline 从 Hugging Face 加载预训练模型：

import pandas as pd
from chronos import Chronos2Pipeline

# 加载模型，device_map="cuda" 使用 GPU，"cpu" 使用 CPU
pipeline = Chronos2Pipeline.from_pretrained(
    "amazon/chronos-2",
    device_map="cpu"  # 或 "cuda "
)

模型会自动下载。我这边下载到一半出现网络错误，然后重新执行会报如下错误

OSError: amazon/chronos-2 does not appear to have a file named pytorch_model.bin or model.safetensors.

问题原因：from_pretrained 在加载模型时，会先去本地缓存（通常在 ~/.cache/huggingface/）查找。如果找到了同名文件，它会认为模型已存在，直接尝试加载。但之前中断的下载导致模型权重文件（pytorch_model.bin 或 model.safetensors）不完整，加载时找不到有效文件，所以就报错了。

解决方案：强制删除损坏的缓存，让程序重新下载。

• 找到 Hugging Face 的缓存目录，并删除amazon/chronos-2 对应的文件夹。
  • Linux/macOS：默认在~/.cache/huggingface/hub/。
  • Windows：默认在C:\Users\你的用户名\.cache\huggingface\hub\。
• 在这个目录下，找到名字包含amazon–chronos-2 的文件夹，把它删掉。

备选方案：强制重新下载（如果不想手动找文件夹）

你也可以通过编程的方式，强制 from_pretrained 重新下载：

import pandas as pd
from chronos import Chronos2Pipeline

# 加载模型，device_map="cuda" 使用 GPU，"cpu" 使用 CPU
pipeline = Chronos2Pipeline.from_pretrained(
    "amazon/chronos-2",
    device_map="cpu", # 或 "cuda"
    # force_download=True  # 加上这个参数，强制重新下载
)

注意：force_download=True 会忽略本地缓存，每次都重新下载，比较耗时。建议只在修复问题时使用，成功后去掉这个参数。

核心入口是 pandas 友好的 predict_df：输入一个长格式 DataFrame（id + timestamp + target，外加可选的协变量列），输出点预测与分位数预测。完整参数签名如下：

# 现在调用 predict_df
pred_df = pipeline.predict_df(
    context_df,
    prediction_length=24,
    quantile_levels=[0.1, 0.5, 0.9],
    id_column='id',              # 对应新加的列名
    timestamp_column='ds',       # 你的时间戳列
    target='y'                   # 你的目标值列
)

predict_df 要求必须有 id_column 来区分不同的序列，但它不强制要求 id 列有实际意义。对于单序列情况，最简单的方法是：添加一个常量 id 列

带协变量的预测以能源价格为例——目标是用历史价格、日前负载预测与可再生能源发电预测，预测次日 24 小时逐时电价。要点在于 future_df 的构造：从测试集中去掉目标列，剩下的列就是”未来已知”的协变量：

target, prediction_length = "target", 24

energy_context_df = pd.read_parquet(
    "https://autogluon.s3.amazonaws.com/datasets/timeseries/electricity_price/train.parquet"
)
# future_df = 测试集去掉目标列 → 剩余列即已知未来协变量
energy_future_df = pd.read_parquet(
    "https://autogluon.s3.amazonaws.com/datasets/timeseries/electricity_price/test.parquet"
).drop(columns=target)

energy_pred_df = pipeline.predict_df(
    energy_context_df,
    future_df=energy_future_df,
    prediction_length=prediction_length,
    quantile_levels=[0.1, 0.5, 0.9],
    id_column="id",
    timestamp_column="timestamp",
    target=target,
)

如果已经在用 AutoGluon-TimeSeries，集成更顺。通过 TimeSeriesPredictor 的 preset 直接选模型，Chronos 会像本地统计模型一样在推理时完成全部计算，fit 几乎不耗时：

from autogluon.timeseries import TimeSeriesDataFrame, TimeSeriesPredictor

data = TimeSeriesDataFrame.from_path("australian_electricity_subset/test.csv")
predictor = TimeSeriesPredictor(prediction_length=48).fit(
    train_data, presets="chronos2",   # 120M；轻量版用 "chronos2_small"
)
pred = predictor.predict(data)

优势、局限与结论

Chronos-2 的核心优势可以浓缩成一句话：它是目前唯一一个用单架构零样本通吃单变量、多变量、协变量（含过去协变量、已知未来协变量、分类型协变量）的预训练模型。组注意力的 O(V) 内存缩放让高维面板预测在工程上可行，21 分位数输出比竞争对手的 9 分位更丰富，上下文从 512 拉到 8192 能容纳更长的季节性，Apache 2.0 开源加上 AutoGluon / Hugging Face 生态降低了使用门槛——按 Amazon 官方口径，Chronos 系列在 Hugging Face 累计下载已超 6 亿次，是 TSFM 赛道事实上的默认选项。

局限同样值得正视，这里不回避。

• 分位数独立回归可能产生交叉，风险场景需要单调性后处理或 conformal 校准。
• 在极简线性协变量关系（如目标 = 协变量本身）的对比实验中，TabPFN-TS 比 Chronos-2 更有效，说明组注意力对简单关系的利用还不够完美——简单线性关系直接建模可能更划算。
• 虽然组注意力内存是 O(V)，但如果把所有变量都归入一组，每个补丁的计算开销仍随组大小增长，所以论文建议只把强耦合的变量归入同一组，或拆分为子组分批处理。
• 已有第三方独立评测显示 Chronos-2 在特定领域（如农业价格预测）未必超过原版 Chronos，零样本结论需以自有数据验证为准，别迷信”新版本一定更好”。

从实践角度，最稳妥的起步方式是：先用零样本模式在自有数据上跑一条基线（Chronos-2 零样本已经很强），再按”协变量→多变量→长上下文”的顺序逐项开启看增益。如果零样本不够，微调的优先级排序也很明确——先把能拿到的已知未来协变量喂进去（这往往比微调本身收益更大），再考虑组合＋协变量的 LoRA 方案，最后才是仅目标序列的微调。选型上，如果你的场景天然是多变量或需要协变量（零售促销、能源天气、云运维多指标），Chronos-2 几乎是目前零样本唯一能直接上手的选择；如果只是纯单变量且预算极紧，更轻的模型可能更划算，但 Chronos-2 的能力面和生态成熟度让它成为大多数”先跑通再说”场景的默认项。

参考文献 / 扩展阅读

• amazon-science/chronos-forecasting: Chronos: Pretrained Models for Time Series Forecasting
• autogluon/chronos-2 Hugging Face