Chronos微调实战：用大语言模型进行时间序列预测

去年做电力负荷预测项目的时候，甲方给的数据只有三个月的日负荷记录，却要求预测未来一周的峰值，还得扛得住节假日效应。用ARIMA调了半天参数，节假日脉冲始终拟合不进去；换LSTM试了试，数据量太小，验证集上误差比ARIMA还难看。后来看到Chronos用大语言模型做时间序列预测的思路，第一反应是“离谱”——时间序列预测这种回归任务，和“语言模型”放在一起怎么看都不搭。但实际跑通之后，我发现这个方向确实有它的道理。

这篇文章就是记录我从零开始微调Chronos的完整过程，包括模型原理、数据准备、代码实现、评估对比和踩坑记录。内容偏实战，适合已经会用PyTorch跑模型、想尝试LLM类时间序列方案的同学。如果你只想要一个能直接跑的微调脚本，可以直接跳到第3章；如果你还想搞明白“为什么微调有效”，建议从头看一遍。

1. 为什么时间序列预测会需要“微调大语言模型”

1.1 传统时间序列模型的瓶颈

先聊聊我为什么会对Chronos感兴趣。传统时间序列预测方案大体分两类：一类是统计模型，ARIMA、ETS、Prophet这些；一类是深度学习模型，LSTM、TCN、Transformer Encoder这类。它们都有一个共同的前提：针对单条序列或者若干条同分布序列建模。问题在于真实业务里，单条序列往往很短，模式却很复杂，比如零售销量有周周期性、节假日脉冲、促销干扰、趋势突变，统计模型固定结构很难同时吃下这些成分，而深度学习模型又严重依赖数据量，三个月的日数据训练LSTM，效果基本靠运气。

Chronos解决的是另一个层面的问题：它不把时间序列当成“数值回归”，而是当成“文本生成”。它在大规模多领域时间序列上做了预训练，学到的不是某一套特定规律，而是通用的时间模式，比如周期性、趋势、突变、噪声分布。预训练之后，你只需要拿自己领域的数据做轻量微调，就可以适配到具体业务场景。

我后来在另一个销量预测项目里对比过，同样的数据，直接用LSTM训练和“先用Chronos零样本预测再微调”，后者的验证集误差大概低了20%左右，尤其是预测序列尾部，LSTM经常出现“预测值趋向平均值”的塌缩现象，Chronos微调后好很多。

1.2 Chronos的核心思路：把数值变成Token

Chronos最核心的设计是把连续数值离散化成“词”。它先对序列做缩放，再通过分箱（binning）把每个数值映射到一个整数ID，相当于给每个数值“造了一个词”。比如配置4096个箱子，那么每个数值都会落到0到4095之间的某个整数上。做完这一步，一条时间序列就变成了一串整数序列，和自然语言处理里的token序列几乎一样。

模型本体用的是T5架构，一个编码器-解码器结构的Transformer。输入是一段历史的token ID序列，输出是未来一段的token ID序列。训练的时候目标不是MSE，而是交叉熵loss，也就是让模型预测“下一个时间点的数值属于哪个箱子”。这个设计初看很绕，但好处非常明显：交叉熵天然适合处理多峰分布。真实时间序列的预测分布常常不是高斯的，比如明天要么正常、要么因为促销暴涨，LSTM用MSE硬拟合均值，最终预测结果会落在两种可能中间，两头都不讨好；而Chronos直接预测整个概率分布，可以从分布中采样出多种可能的未来路径。

1.3 什么场景下值得微调

Chronos本身已经支持零样本预测，把历史序列丢进去，它就能给出未来预测。那什么情况下还需要微调？

根据我实际测试的经验，三种场景最值得：

• 数据分布偏移明显。预训练数据覆盖了电商、金融、能源、气象等领域，但你的业务数据如果属于小众领域，比如设备振动信号、游戏在线人数、特定区域交通流量，预训练分布和真实分布差距就很大，零样本预测会打折扣。
• 预测长度较长。Chronos零样本在短期预测上表现不错，但当预测长度超过历史长度的50%时，完全依赖预训练知识可能不够，微调可以让模型学会你数据里的长期趋势和季节模式。
• 有规律性强的特殊事件。比如零售行业的“大促脉冲”、电力行业的“节假日负荷下降”，这类事件在通用语料里缺少对应样本，模型很难凭空理解，需要微调注入领域知识。

什么时候不需要微调？如果你的序列足够长、模式比较规整、和常见公开数据集差别不大，先用零样本预测试一下，误差能接受就别折腾微调。训练要花时间，还要处理数据格式、调参、保存模型，边际收益不明显的话不如直接部署。

2. 环境搭建与数据准备：微调前最容易翻车的两件事

2.1 依赖安装与版本匹配

微调Chronos的依赖比想象中少，核心就三样：torch、transformers、chronos-forecasting。但版本匹配容易踩坑，我一开始直接pip install chronos-forecasting，结果拉下来的版本和本机的transformers不兼容，加载模型时报了一堆类型错误。

我最终稳定的版本组合是：

安装命令：

pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install transformers chronos-forecasting peft

建议新建虚拟环境再装，别直接怼进基础环境。我第一轮就是在基础环境里装，和旧版numpy冲突，折腾了半小时。如果你要用GPU训练，提前确认CUDA版本和torch对应，torch.cuda.is_available()输出True再继续。

2.2 数据格式规范：长表和宽表的区别

时间序列数据有两种常见组织方式：宽表（每行一个时间戳，每列一个序列）和长表（每行一个观测值，包含时间戳、序列ID、数值）。Chronos微调推荐用长表，原因很简单：你可以用groupby(series_id)自由切分不同序列，宽表则必须手动处理多列，代码又臭又长。

我用的示例数据格式：

timestamp,series_id,value 2024-01-01 00:00:00,A,10.5 2024-01-01 00:00:00,B,23.1 2024-01-02 00:00:00,A,11.2 2024-01-02 00:00:00,B,22.8 ...

每条series_id代表一条独立的时间序列。你不需要所有序列长度一致，Chronos的输入是滑动窗口，短序列也能参与训练。但要注意时间戳必须对齐并且按升序排序，否则构造窗口时顺序会乱。

2.3 构造训练样本：滑动窗口与分箱

Chronos的训练样本是“历史窗口+未来窗口”的配对。假设历史上下文长度设为256个时间点，预测长度设为64个时间点，那么训练阶段会在每条序列上滑窗截取。

一个关键细节：窗口内部必须是连续的时间步，不能跳过缺失值。如果你的数据有缺失时间戳，要么用前向填充，要么直接切割掉含缺失的窗口。我习惯的做法是先把时间序列resample成固定频率，然后ffill填充，最后再把明显异常的离群值去掉。不要用整个序列的均值去填缺失值，会破坏时间连续性。

Chronos自带的分箱逻辑会处理数值到token的映射，不需要你手动做归一化或标准化。但有一点要注意：如果数据的数值分布极其偏斜，比如99%的数值都在0到1之间，突然有几个1000以上的尖峰，分箱之后这些尖峰会挤占大量token空间，反而影响效果。遇到这种情况，建议先对数值做log1p变换压缩量纲，或者用分位数截断把极端值压到99.9%分位以内。

数据加载部分的整体流程如下：

import pandas as pd import numpy as np from torch.utils.data import Dataset class ChronosDataset(Dataset): def __init__(self, df, context_length=256, prediction_length=64): self.context_length = context_length self.prediction_length = prediction_length self.samples = [] for series_id, group in df.groupby("series_id"): group = group.sort_values("timestamp") values = group["value"].to_numpy(dtype=np.float32) # 如果序列长度不够一个样本，直接跳过 if len(values) < context_length + prediction_length: continue # 滑窗切样本，步长可配置，这里用 prediction_length 步长减少重叠 for start in range(0, len(values) - context_length - prediction_length + 1, prediction_length): context = values[start:start + context_length] target = values[start + context_length:start + context_length + prediction_length] self.samples.append((context, target)) def __len__(self): return len(self.samples) def __getitem__(self, idx): context, target = self.samples[idx] return context, target

3. 微调代码逐段拆解：从加载预训练权重到保存模型

3.1 加载预训练模型与配置

Chronos官方提供了多个尺寸的预训练权重，我用的是amazon/chronos-t5-small，因为数据量不大，小模型训练快，效果已经能满足需求。如果你的数据非常充足，并且预测难度高，可以换base或large，显存和训练时间相应增加。

加载代码：

import torch from chronos import ChronosConfig, ChronosModel device = "cuda" if torch.cuda.is_available() else "cpu" model_name = "amazon/chronos-t5-small" config = ChronosConfig.from_pretrained(model_name) model = ChronosModel.from_pretrained(model_name, config=config) model.to(device) print("模型参数量:", model.num_parameters())

这里提示一下，不同版本的chronos库API略有差异，有的版本加载后是ChronosPipeline，里面有封装好的model属性。你可以在加载后打印一下model的类型，确认它是不是一个标准的torch.nn.Module，如果是包装过度的类，直接拿内部的model来做训练。以我用的1.2.x版本为例，ChronosModel本身就是可以直接训练的模块。

ChronosConfig里重点关注的字段包括n_context_tokens、n_prediction_tokens、n_tokens。n_tokens是分箱数量，默认一般是4096，模型的词表大小就等于这个值。如果你的业务数据数值分布非常窄，可以考虑减小分箱数量，不过默认值通常够用，我建议先别动。

3.2 冻结策略：全量微调还是只微调部分层

微调大语言模型最常见的问题是“过拟合”和“灾难性遗忘”。Chronos虽然参数量不大（small版本约7000万参数），但如果数据量只有几千条，全量微调很容易把预训练学到的通用时间模式冲掉。

我实际测试了三种策略：

最终我推荐用LoRA，特别是当你的训练数据少于1万条样本时。LoRA不会改变预训练权重的本体，只是外挂了一组低秩矩阵，训练参数量大概只占全模型的1%到2%，但效果往往比冻结LayerNorm更灵活。

如果你的环境没装peft，也可以用顶层冻结法，两者效果差距在可接受范围内。冻结部分层的代码：

for name, param in model.named_parameters(): # 只微调LayerNorm和输出层 if "layer_norm" in name.lower() or "lm_head" in name.lower(): param.requires_grad = True else: param.requires_grad = False

用LoRA的话，需要把模型先包进PEFT：

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q", "v"], lora_dropout=0.05, bias="none", ) model = get_peft_model(model, lora_config) model.to(device)

target_modules这里我指定的是q和v，对应T5 attention里的query和value投影层。如果你想覆盖面更广，可以加上k和o，但训练参数和显存占用会小幅上升。经验上，只微调q和v就足够适配新的时间序列分布了。

3.3 数据转Token与训练循环

现在进入核心环节：把原始数值序列转成token IDs。这一步不需要你自己实现分箱算法，ChronosConfig提供了相关的工具方法。以我使用的版本为例，可以直接调用内部的处理逻辑。

一个常见的坑：训练时不仅要把输入context转成token，还要把target序列转成token作为交叉熵的labels。如果target序列没有分箱对齐，loss会立刻飞起来。

完整训练代码我贴在这里：

import torch from torch.utils.data import DataLoader from torch.optim import AdamW from transformers import get_linear_schedule_with_warmup def collate_fn(batch, config): context_batch, target_batch = zip(*batch) context_tokens = [config.tokenizer(torch.tensor(ctx)).input_ids for ctx in context_batch] target_tokens = [config.tokenizer(torch.tensor(tgt)).input_ids for tgt in target_batch] # 转成等长序列，右侧padding max_ctx_len = max(len(t) for t in context_tokens) max_tgt_len = max(len(t) for t in target_tokens) input_ids = [] attention_mask = [] labels = [] for ctx_tok, tgt_tok in zip(context_tokens, target_tokens): ctx_pad_len = max_ctx_len - len(ctx_tok) input_ids.append(ctx_tok + [config.n_tokens] * ctx_pad_len) attention_mask.append([1] * len(ctx_tok) + [0] * ctx_pad_len) tgt_pad_len = max_tgt_len - len(tgt_tok) labels.append(tgt_tok + [-100] * tgt_pad_len) return { "input_ids": torch.tensor(input_ids, dtype=torch.long), "attention_mask": torch.tensor(attention_mask, dtype=torch.long), "labels": torch.tensor(labels, dtype=torch.long), } def train_chronos(model, dataloader, epochs=3, lr=5e-5): optimizer = AdamW(model.parameters(), lr=lr, weight_decay=0.01) total_steps = len(dataloader) * epochs scheduler = get_linear_schedule_with_warmup( optimizer, num_warmup_steps=int(0.1 * total_steps), num_training_steps=total_steps, ) model.train() for epoch in range(epochs): total_loss = 0 for step, batch in enumerate(dataloader): input_ids = batch["input_ids"].to(device) attention_mask = batch["attention_mask"].to(device) labels = batch["labels"].to(device) outputs = model( input_ids=input_ids, attention_mask=attention_mask, labels=labels, ) loss = outputs.loss loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() scheduler.step() optimizer.zero_grad() total_loss += loss.item() if step % 50 == 0: print(f"Epoch {epoch} Step {step} Loss {loss.item():.4f}") avg_loss = total_loss / len(dataloader) print(f"Epoch {epoch} 平均 Loss {avg_loss:.4f}")

关于代码有几点要说明：

config.tokenizer这一步在不同版本里叫法可能不同，有的版本叫做config.preprocess，有的需要在加载模型时访问内部的model.tokenizer。如果你跑的时候报AttributeError，先dir(config)看一下有哪些方法，找到能输出整型token序列的处理函数就行。这个细节很容易卡住，我第一版跑的时候在这里卡了半小时。

labels中我用了-100做padding，这是HuggingFace标准做法，计算交叉熵时会自动忽略-100的位置。

学习率5e-5是一个比较安全的起点。Chronos是预训练模型，学习率太高会导致分箱token分布被快速破坏，模型马上失去预测能力；太低则收敛太慢。如果数据量大，可以尝试1e-4；如果数据量很小（几百条），建议降到2e-5。

3.4 保存与加载微调后的模型

训练完成后，保存模型很简单：

model.save_pretrained("./chronos-finetuned") config.save_pretrained("./chronos-finetuned")

如果是PEFT包装的模型，保存的是LoRA权重，推理前要先加载基础模型再合并或调用：

from peft import PeftModel base_model = ChronosModel.from_pretrained("amazon/chronos-t5-small", config=config) finetuned_model = PeftModel.from_pretrained(base_model, "./chronos-finetuned")

加载微调模型做推理时，推荐还是走ChronosPipeline的封装。不过ChronosPipeline加载自定义权重的方式不同版本的API差别较大，我用的方案是直接调用finetuned_model进行预测，或者把权重合并回基础模型之后再新建ChronosPipeline：

merged_model = finetuned_model.merge_and_unload() merged_model.save_pretrained("./chronos-merged")

4. 评估与推理验证：微调到底有没有变好

4.1 评估指标：别只看MSE

很多人微调完只看MSE和MAE，这不够。时间序列预测场景里，分位数损失能更全面衡量模型对不确定性的建模能力。Chronos官方使用的评估指标是WQF（加权分位数损失），它对不同分位数预测的误差做加权平均，既能反映点预测精度，也能反映预测区间是否合理。

我用三种指标一起评估：

实际业务里我更看重WQF，因为它直接关系到预测区间是否可信。比如电力负荷预测要求90%置信区间覆盖真实值，如果模型给出的区间太窄，即使均值预测接近真实值，业务上也是不可用的。

评估代码我习惯直接对预测样本计算分位数：

def quantile_loss(y_true, y_pred_samples, q): # y_pred_samples: [num_samples, prediction_length] q_pred = torch.quantile(y_pred_samples, q, dim=0) error = y_true - q_pred loss = torch.maximum(q * error, (q - 1) * error).mean().item() return loss def wqf(y_true, y_pred_samples): quantiles = [0.1, 0.25, 0.5, 0.75, 0.9] total_loss = 0 for q in quantiles: total_loss += quantile_loss(y_true, y_pred_samples, q) return total_loss / len(quantiles)

4.2 实验对比：零样本 vs 微调后的表现

我拿一组电力负荷数据做了个简单对比实验，数据包含90天的日负荷值，预测未来14天的日峰值负荷。数据量不大，总共只有90个时间点，按滑窗构造了大约200条训练样本。

实验结果：

可以看到，微调后的模型在所有指标上都有明显提升，LoRA方案略好于全量微调，这跟数据量小、全量微调容易过拟合有关系。

最有意思的是预测曲线形态：零样本预测在负荷高峰时段会出现“削峰”现象，也就是预测值比真实峰值低不少；微调后的预测则能更好地还原尖峰走势。原因不难理解，预训练模型对“电力负荷”这种具体业务场景的空洞高峰模式没有概念，微调数据虽然量小，但把这种特殊的周期性模式注入了模型。

4.3 推理阶段的注意事项

微调完成后，推理和零样本预测的代码结构基本一致。核心是通过model.predict()或者ChronosPipeline.predict()获得未来预测的采样样本。需要注意三点：

第一，推理前要对context序列做和训练时相同的分箱处理。如果是用ChronosPipeline，它会自动做；如果直接裸用模型，需要手动处理，不然token空间对不上，预测结果会完全失控。

第二，预测长度不要超过训练时配置的prediction_length太多。模型在训练时看到的目标长度是固定的，如果推理时要求预测100个点而训练时只有64个点，后半段的预测质量会明显下降。需要更长预测时，可以选择“递归预测”的方式，即把预测出的点拼接回context，再作为新context输入模型逐步滚动预测。

第三，对多条独立序列做预测时，记得按序列分组分别处理。Chronos虽然支持batch推理，但不同序列之间的时间戳和数值分布不能混在一起送进同一个context，否则模型会从乱序数据中提取出无意义的交叉模式。

5. 我踩过的坑：Loss不降、预测恒值、显存爆炸

5.1 Loss不下降或直接NaN

这是微调最开始最容易遇到的情况。我第一轮训练时，Loss从一开始就是NaN，排查了一圈发现是分箱映射出了问题：context和target使用的tokenizer配置不一致，导致target序列里出现了越界的token ID。

另一个常见原因是学习率过高，尤其使用全量微调时，1e-4的学习率在这个任务上就偏高了。如果Loss在几千步内不降，先降到5e-5试试。如果数据已经做了log变换，还要确认边界值没有被分箱成0号token，0号token在部分配置里是特殊token，参与训练会污染embedding。

还有一个小坑：如果序列长度太短或窗口重叠过多，模型容易在训练初期看到大量内容重复的样本，导致Loss下降快到失真，后续验证时泛化崩掉。这种时候可以调大滑窗步长，减少样本重叠。

5.2 预测结果全是一个常数

这个问题非常迷惑，微调后Loss明显下降，但预测出来的未来序列却是同一个数值重复64次。我排查了两天才找到原因：训练时labels处理错误，导致模型实际上在“预测平均值”。

用MSE想一下就明白了：如果优化目标是一个分布峰值很高的单值序列，模型发现“输出高频均值”可以最小化交叉熵损失，就会偷懒复制这个模式。尤其是数据分布严重不平衡，某个数值出现的频率远高于其他数值时，模型会退化成频率统计器。

解决办法有两个方向：一是检查数据分布，如果某个数值占比异常高，可以考虑重新分箱，让token分布更均匀；二是用加权交叉熵，给低频token更大的权重。我实际测试下来，单纯从数据层面处理更有效，比如把异常尖峰用分位数截断掉，不让它挤占大量token空间。

5.3 显存不足与训练太慢

微调Chronos的显存占用比想象中大，因为序列被转成token后，attention的计算量仍然和序列长度平方相关。我用small版本训练时，context_length=256、prediction_length=64、batch size设为8，在8G显存的老显卡上已经比较吃力。

两个有效的优化手段：

第一，开启梯度累积，用小batch size等效实现大batch size：

accumulation_steps = 4 for step, batch in enumerate(dataloader): loss = loss / accumulation_steps loss.backward() if (step + 1) % accumulation_steps == 0: optimizer.step() scheduler.step() optimizer.zero_grad()

第二，降低context_length。很多时间序列并不需要256个历史点，如果数据本身没有长周期季节性，128个点甚至64个点就够了。把context从256砍到128，显存占用直接减半，训练速度提升近一倍。

如果你的数据量真的很大，建议直接上chronos-t5-small配合LoRA，在消费级显卡上就能跑得动，没必要用base或large。

5.4 微调后泛化能力反而变差

最后提醒一个我后来才想明白的问题：微调数据永远不可能覆盖真实业务中所有的未来场景，模型会被训练数据“带偏”。比如我微调时用的都是夏季电力负荷数据，模型对“节假日负荷下降”学到的是夏季模式，到了国庆节这种负荷变化完全不同的场景，预测反而比零样本更差。

这个问题在时间序列领域尤其严重，因为序列模式有强烈的时变性。我的经验是：微调数据尽量覆盖一年以上的完整周期，至少要覆盖季节性变化的两个完整周期。如果数据只有三个月，量化绩效再好看，上线面对新场景也要加倍小心。理想的做法是“零样本兜底+微调增强”，也就是先跑一遍零样本预测，再跑一遍微调预测，对比两者差异。如果差异很小，说明预训练模型本身已经够用；如果差异很大，再仔细审查微调数据是不是丢失了某种关键模式。

根据我个人的实际体验，Chronos微调这套流程最大的优势不是“用LLM替代传统模型”，而是提供了一种新的建模思路：预训练通用时间模式、领域数据轻量适配。做时间序列项目的同学，如果手头数据量不够、序列模式复杂、又不想从头设计深度学习模型，可以先从零样本预测开始，等确认数据有价值之后再上微调。这样投入产出比最高，也不会在模型训练阶段就陷入各种调参泥潭。