简介Informer实战资源包围绕ProbSparse自注意力机制与自注意力蒸馏展开提供完整可运行的Informer工程面向时间序列预测方向的研究者、算法工程师以及具备一定深度学习基础的学习者。压缩包内共64个文件主要包含17个Python源码涵盖模型定义、数据加载、掩码工具、特征处理、训练与评测脚本、3个CSV格式的ETTh1数据集、2个模型权重文件、17个npy格式的预测与评估结果以及yml、xml、iml等环境与工程配置文件整体约115.95MB。目录结构按照data、utils、models、exp等模块拆分便于对照源码理解长序列预测模型的完整训练链路。随包附带的ETTh1数据集与pred.npy、true.npy等结果文件覆盖不同预测长度下的实验输出可帮助读者快速复现实验深入理解ProbSparse自注意力如何在较低复杂度下捕捉长期依赖也便于在此基础上扩展自己的改进方案。资源已有2862人学习下载适合作为从理论走向实战的参考样例。1. Informer模型实战案例为什么长序列预测必须换掉Transformer做电力负荷预测和量化策略的同行应该都遇到过这个场景把Transformer搬到长序列上输入长度一过800显存先报警训练时间按小时起步。Informer是冲着这个问题来的。它用ProbSparse自注意力机制把自注意力复杂度从O(L²)降到O(L log L)靠蒸馏层逐级压缩特征图让同一块GPU能塞进更长的历史窗口。这篇文章从数据、代码到参数逐层拆解直接照着跑就能复现中间会讲清楚每个旋钮是干什么的、什么时候该动它。适合正在做多变量时间序列预测、被Transformer长序列高开销卡住的工程同学也适合想了解稀疏注意力到底怎么做选型的算法从业者。2. ProbSparse自注意力机制把O(L²)的开销算明白2.1 标准自注意力的瓶颈在哪标准Transformer的自注意力对每个query做全量内积。给定序列长度L和特征维度dQK^T的结果是L×L矩阵内存和计算都是O(L²)量级。L200时4万个元素还好L1000时就是10^6L5000时2.5×10^7单层就吃掉几百MB。在多变量时序场景里输入经常要覆盖几百上千步——一天的分钟级数据就是1440步再加上负荷、气象等多个特征显存和训练时间双双失控。但这只是表面问题。更深层的问题在于大量query的注意力分布其实和均匀分布差不了多少。也就是说绝大多数位置的信息是冗余的真正起作用的少数query被淹没在庞大的全量计算里。如果能提前判断哪些query有信息量只对它们做完整注意力复杂度就能明显降下来。2.2 稀疏度量与Top-u采样ProbSparse的计算过程Informer的改进策略不是预先规定每个query看哪一段窗口而是先给每个query算一个“信息量评分”再只对得分最高的Top-u个query做完整注意力计算。具体做法是对第i个query计算它对所有key的注意力分布与均匀分布之间的KL散度散度越大说明这个query越“特立独行”越值得保留。这里有个工程技巧完整KL散度本身要遍历所有key计算代价不低。Informer的做法是从key里随机采样一部分来估算然后用max减mean这种简化算子逼近KL值避免引入log_sum_exp之类的重计算。Top-u的选取数量由factor参数控制u factor × log2(L)。L96时factor5对应约34个queryL1000时约50个占比只有5%。其余query不参与完整注意力输出直接用value的等权平均替代。下面是一个演示性质的最小实现核心逻辑和论文一致方便你理解数据流动import torch import math def prob_sparse_attention(query, key, value, factor5): # query: [B, L, D], key/value: [B, L, D] B, L, D query.shape u int(factor * math.log2(L)) # 保留的query数量 # 1. 随机采样key来估算稀疏分避免遍历全部key idx torch.randint(0, L, (B, u)) sampled_key key.gather(1, idx.unsqueeze(-1).expand(-1, -1, D)) # 2. 简化KL散度max - mean 近似稀疏度 score torch.matmul(query, sampled_key.transpose(-2, -1)) / math.sqrt(D) sparse_score score.max(-1).values - score.mean(-1) # 3. 只对Top-u的query做完整注意力 top_u sparse_score.topk(u, dim-1).indices full_q query.gather(1, top_u.unsqueeze(-1).expand(-1, -1, D)) attn torch.softmax(full_q key.transpose(-2, -1) / math.sqrt(D), dim-1) out attn value # 4. 其余query用value的均值兜底 mean_v value.mean(dim1, keepdimTrue) return out, top_u, mean_v逻辑说明第一步采样key是为了用少量样本估算每个query的稀疏分避免完整计算KL第二步的max减mean是论文里的简化算子它不直接算log和exp但能保持单调性即真正的稀疏query分数一定偏高第三步gather取出Top-u的query做完整注意力最后把兜底均值返回实际模型里会将长尾query的输出与Top-u输出拼接。参数说明factor是这里唯一的超参数u factor × log2(L)。factor越大保留的query越多注意力越接近标准Transformer但省下的计算量变少factor太小则可能丢掉关键query。默认值5在多数数据集上表现稳定后面第四章会讲怎么调。2.3 蒸馏层与生成式解码器Informer的另外两块拼图ProbSparse解决的是注意力计算量但整个Informer落地还需要两块配套结构它们也直接影响你要调的参数。第一块是自注意力蒸馏。每过一层encoder就对特征做一次池化把序列长度减半。这样做有两个目的一是进一步压缩计算量让深层特征聚焦在全局结构二是让网络形成层次化时间感受野对长周期模式更敏感。代价是空间分辨率下降所以Informer只在encoder里做蒸馏decoder保持全部分辨率。第二块是生成式解码器。传统Transformer解码是逐token自回归预测96步要串行跑96次。Informer把解码输入做成start token加0填充占位的形式start token取预测点之前的一段真实序列长度就是label_len占位符等待解码输出一次前向就把整个预测序列吐出来。这个设计让训练和推理都变成并行计算也是为什么label_len这个参数很关键——它决定解码器的“冷启动”条件。2.4 稀疏注意力方案怎么选方法复杂度是否自适应适用场景标准TransformerO(L²)无短序列、小数据量LogSparseO(L log L)否固定窗口中长序列、周期模式简单ProbSparseO(L log L)是数据驱动选query长序列、多变量、依赖模式复杂实际选型我的建议是序列长度在100以内直接标准Transformer不折腾长度在500左右、周期模式明显LogSparse够用且实现简单超过500且数据维度多或者部署环境对显存有硬上限再上Informer。还有一个信号如果你调LogSparse时频繁改窗口大小还是跑不好说明依赖模式不是固定形状这时候ProbSparse的数据驱动稀疏更有优势。3. 跑通Informer最小案例环境、ETTh1数据集与训练命令3.1 环境依赖与版本匹配常见开源实现基于PyTorch。我一般用Python 3.8或3.9PyTorch 1.10到2.0都跑过主要依赖是torch、numpy、pandas、scikit-learn和matplotlib。有一个容易忽略的点repo对sklearn的StandardScaler有直接依赖sklearn版本太新会在索引方式上给警告但不影响结果。GPU显存建议至少6GB。下面给出的batch_size 32、seq_len 96配置在4GB卡上比较勉强。没有GPU也能跑把batch_size调到8、序列长度降到48用CPU训练验证代码通不通代价是训练时间翻很多倍。conda create -n informer python3.8 conda activate informer pip install torch1.13.1 # 按你的CUDA版本选新卡可直接用2.x pip install numpy pandas scikit-learn matplotlib参数说明torch版本按显卡的CUDA版本来。如果是RTX 30系配CUDA 11.x1.13.1很稳如果是40系新卡直接装torch 2.x省得后面编译算子时报错。Informer这类模型我一般不开自动混合精度因为稀疏采样和topk这类操作在低精度下容易出现NaN排查起来很头疼。3.2 ETTh1数据集字段、切分与标准化做这个标题最常见的数据集是ETTh1电力变压器温度数据集小时级采样总共17420行左右。字段是date加五个电力负荷特征HUFL、HULL、MUFL、MELL、MULL最后一个是油温OT通常作为预测目标。同系列的ETTm1是15分钟级WTH是气象数据代码接口完全一致改--data参数就行。数据切分必须按时间顺序不能随机shuffle。切分比例我习惯用6:2:2和论文对齐这样对比指标时有据可查。标准化只fit训练集这是防止信息泄漏的红线。import pandas as pd from sklearn.preprocessing import StandardScaler df pd.read_csv(ETTh1.csv, parse_dates[date]) features [HUFL, HULL, MUFL, MELL, MULL, OT] data df[features].values.astype(float32) # 时序数据按顺序切分不能随机shuffle n len(data) train_slice slice(0, int(n * 0.6)) valid_slice slice(int(n * 0.6), int(n * 0.8)) test_slice slice(int(n * 0.8), n) # 标准化参数只用训练集拟合防止信息泄漏 scaler StandardScaler() scaler.fit(data[train_slice]) X scaler.transform(data) print(ftrain mean/std after scaling: {X[train_slice].mean():.2e}, {X[train_slice].std():.4f})逻辑说明read_csv用parse_dates把date列解析成时间戳后续Informer的时间特征生成依赖这一列。切分用slice而不是直接索引是为了保持原始顺序避免shuffle破坏时序依赖。标准化先fit再transform只让训练集的统计量参与拟合。注意一个细节Informer的数据加载器内部默认会做标准化。如果你在数据预处理阶段又fit一次相当于双重标准化指标会乱。常见做法是让repo内部的scaler负责标准化上面这段代码只是为了让你理解字段和切分逻辑真正跑训练时不需要手动转换数据。3.3 最小训练命令与日志解读环境没问题、数据路径放对后训练命令是参数讲解的核心载体。下面这组是我在ETTh1上验证过的最小配置python -u main_informer.py \ --model informer \ --data ETTh1 \ --features M \ --seq_len 96 \ --label_len 48 \ --pred_len 96 \ --d_model 512 \ --n_heads 8 \ --e_layers 2 \ --d_layers 1 \ --factor 5 \ --dropout 0.05 \ --batch_size 32 \ --learning_rate 0.0001 \ --train_epochs 10 \ --patience 3 \ --use_gpu 1参数说明features M表示多变量输入多变量输出即用所有特征预测所有特征。如果只想预测OT油温、其他五个特征作为输入把features改成MS同时设enc_in6、dec_in1、c_out1。featuresS则是单变量到单变量只保留目标列。这三者的区别在初跑时最容易忽略直接影响输入输出维度。训练日志在第一个epoch结束会打印train loss和valid loss。如果valid loss在第二个epoch不降反升优先怀疑learning_rate太大降到0.00005再试。如果前两个epoch的loss基本不变化检查数据路径是不是真的指向ETTh1目录以及是不是手动做过了双重标准化。显存占用在6GB上下单卡训练时间在十几分钟到半小时的量级具体取决于显卡型号和CPU进程数。4. 参数讲解影响预测精度的6个旋钮与我的调法4.1 核心参数表与默认组合Informer的参数可以分成三类模型结构参数、任务长度参数、训练策略参数。下面这张表把最关键的几项列全后续小节展开讲。参数默认值作用我的常用改法factor5控制Top-u采样数量噪声大调到3周期强调到5-7d_model512特征映射维度数据量小用256n_heads8注意力头数保证d_model能被n_heads整除e_layers2encoder层数数据长加到3d_layers1decoder层数一般不动dropout0.05防过拟合小数据集0.1seq_len96输入历史窗口长度覆盖一个完整周期即可label_len48解码器start token长度通常为pred_len的一半pred_len96预测长度按业务需求48/96/192batch_size32批大小显存不够降到16learning_rate0.0001Adam初始学习率数据大可以0.0005train_epochs100最大epoch数看loss不降就停patience3早停阈值数据大可以54.2 seq_len、label_len、pred_len三者怎么配很多人把seq_len当成模型结构参数其实它是任务参数。pred_len是业务要预测多远需求定的模型不会自己变。seq_len是输入历史窗口至少要覆盖一个完整周期小时级数据有日周期就设24有周周期就设16815分钟采样的一天是96个点。label_len是解码器的start token长度它不能太长也不能太短。太短解码器像冷启动等于让模型在几乎零信息的情况下开始生成预测段容易退化成常数太长则输入和label重复太多模型学会“复制”而不是“预测”。我的习惯是label_len取pred_len的一半。具体例子15分钟采样、预测未来24小时pred_len96。如果数据有明显日周期seq_len至少设192如果还有周周期seq_len设672会比较稳这时显存吃紧factor调回3或者减少e_layers。label_len设48和pred_len的比值保持1:2。4.3 factor和d_model怎么配factor控制Top-u采样数量d_model决定特征映射宽度。这两个参数不能分开调d_model越大单个query的特征越丰富需要保留的query越多否则稀疏采样会丢掉关键信息。我的一般调法按数据量分档数据量5万以下d_model 256加factor 3训练快过拟合风险低数据量5万到30万d_model 512加factor 5这是最常见组合和默认参数一致数据量30万以上d_model 512或768加factor 7容量和稀疏度都要跟上。判断信号是训练集loss还很高而验证集已经不再下降说明模型容量不够先加d_model而不是加层数验证集和训练集差距很大优先把dropout从0.05提到0.1而不是减d_model。参数扫描可以用一个脚本自动化避免手动改命令来回折腾# 对factor做网格扫描用valid loss选参数 import subprocess, re results {} for factor in [3, 5, 7]: cmd (fpython -u main_informer.py --model informer --data ETTh1 f--factor {factor} --train_epochs 10 --patience 3 f--d_model 512 --batch_size 32) output subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue).stdout match re.search(rbest_valid_loss[:\s]([0-9.]), output) results[factor] float(match.group(1)) if match else float(inf) print(ffactor{factor}: valid_loss{results[factor]})逻辑说明脚本循环执行训练命令从stdout里抓取best_valid_loss按数值大小选最优factor。每次只动一个参数才可比较否则多个参数同时变最后没法定位是谁在起作用。subprocess调用在Windows和Linux下都能跑shellTrue在目录路径带空格时反而省事。参数说明这个脚本在cpu_only环境下也能跑只是每个factor跑10个epoch的时间会拉长。如果你在远程服务器上跑建议用nohup加日志重定向别让终端断连把训练打断——这是我在实际项目里踩过的坑跑了三个小时的扫描一回终端断掉全没了。5. 避坑Informer复现中常见的5个翻车现场5.1 数据集找不到或路径报错现象启动训练后直接报FileNotFoundError找不到ETTh1.csv或者报KeyError: HUFL说明数据文件内容不对。原因数据下载脚本没跑或者工作目录不对。大多数repo的默认路径是./data/ETT/ETTh1.csv需要先建目录、下载文件、确认文件名大小写一致。另外某些博客给的下载链接已经失效下载到的是个HTML错误页pandas解析时就会报列名错误。解决先用pandas单独读一次文件确认能读、字段对再跑训练。路径用绝对路径是最稳的别依赖相对路径和当前工作目录的耦合。5.2 显存溢出长序列加蒸馏没生效现象seq_len设672时报CUDA out of memory但同样的配置在论文里能跑。原因蒸馏层把序列长度逐层减半的机制默认开启但如果你在配置里手动动了distil参数或者改了encoder层数导致特征图尺寸没按预期衰减显存就按原始长度计算。三种情况叠加长序列、大d_model、大batch_size4GB卡必炸。解决确认distil保持True打印每层输出的形状看序列长度是否逐层减半。如果只改了小部分配置优先把batch_size降到16、d_model降到256先跑通再逐步往上加。我一般把显存占用控制在显卡容量的80%以内留出给验证集推理和临时张量的余量。5.3 预测结果是一条直线现象画预测曲线时发现预测段几乎是水平的常数MSE看着不高但曲线完全没形状。原因最常见是数据没标准化特征尺度差异大导致优化器在局部震荡其次是label_len太短解码器进入占位符区域后拿不到有效信息还有一个隐蔽原因是pred_len远大于训练时见过的周期长度模型学不到有效外推。解决先确认训练时用了标准化scaler默认开启把label_len提到pred_len的一半到三分之二如果还是直线把pred_len从96降到48验证模型本身没问题。这个坑了我一整天最后发现是数据加载器里scale参数被我不小心设成了False。5.4 测评指标和论文对不上现象MSE、MAE总是比论文公布的结果高一截调参也追不上。原因切分比例不一致是最常见原因。有的实现训练验证测试按6:2:2有的按7:1:2不同切分下的指标没有可比性。另一个原因是预测目标不一致featuresM预测所有特征featuresMS只预测OT两者数值不能直接比。还有少数实现把最后一个维度当作目标你以为是OT实际可能不是。解决统一切分比例到6:2:2统一features和c_out再对比指标。如果你想对比论文表格里的数值先确认论文用的是哪个数据集、哪个pred_len、哪种features设置逐项对齐后才谈得上复现。5.5 训练loss下降但valid loss在中途崩掉现象前几个epoch train loss稳步下降第三个epoch左右valid loss突然爆炸之后开始震荡。原因学习率太大加batch太小优化器在验证集的泛化临界点上震荡。Informer对学习率比较敏感0.0001起步是稳的0.001基本必炸。数据量大但batch设太小梯度方差大验证集曲线天然不稳。解决learning_rate降到0.00005batch_size升到64如果显存允许把patience从3提到5给早停多一点容错。我在长序列任务里还会做一件事前两个epoch用一个较小的学习率预热第三个epoch再切到目标学习率能明显减少这种中期崩溃。6. 进阶用曲线验证预测质量再把Informer接进量化场景6.1 用MSE、MAE和曲线做双重验证训练完不能只看log里的数字。我习惯把测试集真实值和预测值画成两条曲线叠在一张图里曲线能立刻暴露出三类问题直线预测、相位偏移、峰值削平。指标上MSE对峰值敏感但容易被均值主导我会同时看MAE如果两者的量级差明显偏大说明误差集中在少数尖峰上模型对突发模式不敏感这时要考虑加时间特征或者换数据集。画图用matplotlib就可以pred_len在96以内直接plot三条曲线真实值、训练集拟合值、测试集预测值。每次调参都重新生成同一张图对比形态差异比只看数字直观得多。6.2 把Informer接进分钟级K线的量化因子时序预测在量化里最自然的落地是分钟级K线的特征外推。Informer的优势是能用过去几百根K线预测未来几十根的走势形态比单点回归多一个时序维度。常见做法是把OHLCV五维特征加成交量做归一化后作为输入预测未来N根K线的收盘价或成交量分布。注意不要直接预测涨跌标签再当信号用——很容易过拟合。把预测结果作为因子输入到策略里比单点预测稳健。我自己在类似项目上的习惯是先固定数据切分和随机种子生成一张基线预测图存成png每次改参数都对比同一张图的形态差异。MSE好看但曲线相位偏移的话检查日期特征是否正确传入——Informer的时间特征hour和weekday是自动生成的如果你把date列解析出错模型的周期先验会整个错位。这套方法论同样适用于电力负荷和气象预测核心就一句话先把baseline跑稳再谈调参。希望这些经验帮到你。本文还有配套的精品资源点击获取