简介：面向长时间序列预测与分类研究者的Transformer算法代码合集，涵盖Autoformer、PEDformer、Informer、Crossformer、ETSformer、Pyraformer、TimesNet、Reformer、DLinear等15种代表性模型，适用于电力负荷、ETT油温、外汇汇率、病情监测、交通车流量、天气等多元时序场景，兼顾新手复现与算法对比需求。资源共1378个文件，压缩包大小182.2MB，核心为137个Python源码与228个Shell脚本，配套774个PDF说明文档、36个CSV数据文件及48个npy数据格式，便于直接运行、阅读与扩展实验。除完整代码外，还包含PyTorch模型定义、训练脚本、数据处理流程与结果可视化等模块，可帮助读者快速搭建基线模型并评估不同Transformer变体在真实数据集上的表现。目前已有3469人学习下载，适合需要系统性掌握长时间序列预测前沿算法或开展横向对比实验的研究者与工程师。
1. 十五份Transformer长序列代码放在一起，先要解决的其实是“可复现性”而非模型选型
很多第一次接触长时间序列预测的工程师，都会经历这个阶段：代码是开源的，数据是标准的ETTh1，按默认参数训完，预测曲线却比naive baseline还差。这不是个别现象，而是基于Transformer的长时间序列代码在工程上有一个共同的脆弱点——复现链路太长。从数据文件路径、归一化方式到einops的版本，任何一环不对，模型就从精妙的算法退化成“复制最近一段”。这篇文章想把Autoformer、PEDformer、Informer这类15个算法的代码汇总当成一套工具箱来拆：先建立两条技术主线，再给最小跑通路径、关键参数边界和五个高频踩坑点。适合已经会用PyTorch、但还没系统性跑过这些长序列Transformer变体的工程师。
2. 从Informer到Autoformer：长序列预测里Transformer变体的两条技术主线
15个算法名字各异，但你得先抓住长序列预测里Transformer面对的两个核心矛盾，后面读代码才有抓手。第一个矛盾是复杂度：序列长度L一涨，标准自注意力的计算量和显存都按L的平方涨，工业场景里动辄几百上千的长度直接把attention变成瓶颈。第二个矛盾是非平稳性：真实业务序列的均值、方差和周期都在漂移，模型很容易找到“把最近一段历史复制到未来”这种捷径，结果是loss很低、预测曲线整体滞后。Informer和Autoformer分别是针对这两个矛盾的典型代表，PEDformer及大部分后续变体都能归到这两条主线上。
2.1 标准注意力在长序列上撑不住：Informer的ProbSparse注意力
标准的Transformer在时间序列上原生有两个问题。一是复杂度，每个query都要和所有key算点积，L=1000时意味着100万次交互，训练和推理都吃不消。二是时间序列的注意力分布里，真正对预测有用的query只是少数，大部分query的注意力权重摊得很均匀，学了半天其实在给噪声加权。Informer的ProbSparse注意力就是抓住第二点做的：用KL散度估计每个query的注意力分布和均匀分布之间的差异，留下差异最大的top-k个query做完整计算，其余query直接跳过。代码里核心就是models/informer.py中attn那一段，你会在里面看到随机采样一部分query做估计、挑出top-k再计算的流程。
如果你打开transformer源码，Informer里还有个细节值得单独说：encoder和decoder各有一层稀疏注意力，factor参数控制保留的query比例。factor=5意味着每个头只保留约1/5的query参与完整计算。这个参数不是越大越好，后面第4章我会讲怎么调。把这点看懂，你就知道Informer跑的到底是什么——它不是在完整注意力上做近似，而是先判断哪些位置值得算，再只算这些位置。这也是它与后来自注意力变体最大的区别。
很多初学者自己手写过一遍标准Transformer，会把attention当成一个黑匣子直接调用。跑长序列项目时，建议先打开models/informer.py里的prob_sparse_attention函数，把Q、K、V的形状和mask的广播方式在纸上画一遍。我一般是带着两列问题去读：它的计算图里哪里从O(L²)降到了O(L log L)？它的mask是用在key侧还是query侧？把这两个问题搞明白，后面换Autoformer和PEDformer时，你自然知道每一家的“注意力替代品”到底代替了什么。
2.2 分解与周期：Autoformer和PEDformer破解非平稳
Autoformer走的完全是另一条路：它不跟注意力效率较劲，而是把精力放在“序列本身不稳定”上。它先把原始序列拆成趋势项和季节项，趋势项用移动平均提取，季节项是残差；预测是分别对这两项做的。这样模型不再直接拟合非平稳的原序列，而是拟合两个相对平稳的分量。注意力也换成了Auto-Correlation，它不再按绝对位置对齐token，而是按周期相似度把相隔若干个周期的片段聚合起来。这个设计在用电量、利率这类有强周期性的数据上非常有效。
PEDformer可以归到同一条主线的加强版。这个名字在不同代码仓库里的实现略有出入，但我见过的几套代码里，它通常是“周期增强分解”的定位：先检测序列里的主周期，把周期分量单独建模，再和趋势项重组。拿到的代码包如果只有FEDformer而没有PEDformer，也不用慌，这两种模型在频域分解上的血缘很近，调参思路是通用的。你在读这类源码时，最先要看的就是它们各自对序列做的分解操作在哪里、分解窗口多大、分解后的分量是否进入独立的预测分支。这三个问题能帮你把一堆看似不同的名字很快归类。
2.3 15份代码的选型地图：注意力效率、分解周期与token化三条线
现在把视野拉远，看整个代码包。一个典型的基于Transformer的长时间序列预测代码汇总，通常包含三类模型，建议你按这个表格建立自己的选型地图。
主线 | 代表模型 | 解决的问题 | 入坑建议 注意力效率 | Informer、LogTrans、Reformer、Pyraformer | 降低注意力的计算复杂度 | 适合做第一步基线，代码结构最简单 序列分解与周期 | Autoformer、PEDformer、FEDformer、DLinear | 处理非平稳和周期漂移 | 周期明显的数据优先试 Token化与多变量 | PatchTST、Crossformer、iTransformer | 把时间步抽象成patch或变量token | 多变量强相关时收益明显
这三种线不互斥，很多新模型是混合体。拿到代码包后，你可以把models目录里的所有.py文件按这三个抽屉放进去，放完你就有自己的选型地图。如果文件里还有TimesNet这种用CNN做序列的模型，它严格说不是Transformer变体，但它和PEDformer在一套代码里高频出现，原因是它们共享同一套数据加载和评估管线，跑起来最省事，我一般也把它算进对比基准。
我建议你跑项目时不要每个模型都调一遍，而是先用Informer摸清数据规律，再用Autoformer或PEDformer验证周期假设，最后用PatchTST这类token化模型对比上限。一套代码库里15个算法，真正值得精调的通常不超过三个。
3. 把15个算法代码跑通：环境、数据与最小复现命令
这一章的目标不是让所有算法出SOTA，而是先让最小链路跑通。我给的命令是这类Transformer长序列代码库最常见的用法，不管仓库目录长什么样，核心套路都是统一的：建环境、放数据、改命令行参数、换模型。
3.1 环境与依赖：PyTorch版本、CUDA和einops的匹配
先建一个干净的conda环境，把版本锁死。这类代码大多是2021年到2022年发布的，用新版本PyTorch跑大概率能跑通，但会遇到个别算子行为变化导致的数值差异，排查起来很费时间。我一般直接用PyTorch 1.12作为起步版本。
conda create -n longseq python=3.8 -y conda activate longseq # GPU环境请按自己的CUDA版本从PyTorch官网安装对应wheel pip install torch==1.12.1 pip install einops==0.6.2 scipy scikit-learn pandas matplotlib逻辑说明：einops是这类代码里引用最频繁的库，用于rearrange和repeat操作，几乎所有模型的attention实现都依赖它。版本不要追新，0.6.2配合PyTorch 1.12是最稳的组合。pandas和scikit-learn是数据加载和评估指标的依赖，scipy在部分时序平滑操作里会用到。
提示：如果你的显卡显存只有8G，先把seq_len降到48或96。长序列Transformer的显存占用随seq_len增长非常快，这个习惯能帮你避开后面一半的坑。
3.2 数据准备：ETT、Exchange、Traffic等标准数据集的下载目录
代码包普遍会在data目录下按数据集放csv，目录结构常见是这样的：
data/ ├── ETTh1.csv ├── ETTh2.csv ├── ETTm1.csv ├── ETTm2.csv ├── exchange_rate.csv ├── traffic.csv └── weather.csv拿到代码包后先别急着训练，先把数据检查做了。ETT系列的csv第一列是date，后面是HUFL、HULL等油温特征列，下载链接一般在仓库README里。我习惯用下面这段脚本验证数据完整性：
import pandas as pd import numpy as np df = pd.read_csv("data/ETTh1.csv", parse_dates=["date"]) print(df.shape) print(df.head(3)) print("NaN数量:", df.isna().sum().sum()) num_cols = df.select_dtypes(include=[np.number]) print("Inf数量:", np.isinf(num_cols.values).sum())逻辑说明：第一行读入csv并解析时间列，print查看列名和结构；后面两行分别统计NaN和Inf的数量。很多Transformer长序列代码跑出NaN，问题不在模型，而在数据文件本身。发现NaN就dropna，发现Inf就replace成NaN后再drop，这一步能省掉一整天的排错时间。
3.3 最小训练命令：先跑Informer，再换Autoformer
环境就绪、数据就位，先跑一个最小的Informer。第一次跑建议pred_len设24而不是168，预测长度越短收敛越快，两分钟就能验证链路是否通。
python -u run.py \ --model informer \ --data ETTh1 \ --seq_len 96 \ --label_len 48 \ --pred_len 24 \ --e_layers 2 \ --d_layers 1 \ --attn prob \ --factor 5 \ --batch_size 32 \ --learning_rate 0.0001 \ --loss mse \ --gpu 0参数说明：--model informer对应models/informer.py里的Informer类，类名转小写后作为命令行值。seq_len是编码器看到的历史窗口长度，label_len是解码器开始时已知的真实值长度，pred_len是预测长度。attn prob启用ProbSparse注意力，factor=5是稀疏因子。learning_rate这里先用1e-4，这是这类模型最常见的稳定起点。
然后换Autoformer，只需要改模型名和加一个分解窗口参数：
python -u run.py \ --model autoformer \ --data ETTh1 \ --seq_len 96 \ --label_len 48 \ --pred_len 24 \ --e_layers 2 \ --d_layers 1 \ --moving_avg 25 \ --batch_size 32 \ --learning_rate 0.0001 \ --loss mse \ --gpu 0参数说明：--model autoformer会去models/autoformer.py里找类；--moving_avg 25是趋势项分解时移动平均的窗口大小，如果你的数据有明显日周期且采样是小时级，24或25是比较合理的起步值。模型换起来只有这两个参数的区别，正是因为这类仓库把所有模型统一注册到了run.py的入口里，你跑PEDformer、FEDformer都是同样的套路。
3.4 models/、exp/、utils/三个目录怎么配合
这类代码包的结构基本逃不出三个目录，搞清楚它们的职责后，改代码时才知道该动哪里。
目录 | 职责 | 你通常要动哪里 models/ | 每个模型一个.py文件，定义模型结构 | 改注意力实现、加新模型 exp/ | 训练与验证主流程，组织dataloader和评估 | 改评价指标、训练策略 utils/ | 时间特征编码、loss计算、学习率调度 | 改early stopping、改时间特征
换模型真的只改--model就行吗？前提是代码包统一走了run.py注册模型名。很多仓库存量模型都在models/init.py里统一导出了，你手动加新算法时如果只放了一个.py文件而没注册，跑起来就是“module not found”。遇到模块导入错误，第一反应不是去改run.py，而是看models/init.py有没有把新模型import进来，这是新手最常撞的墙。
4. 关键参数与调参：informer调参时真正影响精度的几个旋钮
模型跑通后，下一步就是真正花时间的调参。Informer这套代码的argparse里有四五十个参数，但真正影响精度的旋钮其实就那么几个。我按对结果的影响程度排了序。
4.1 Seq_len、Label_len、Pred_len三个窗口的物理含义
这三个窗口必须第一个讲清楚。seq_len是编码器看到的历史长度，直接决定模型能接触多少上下文；label_len是解码器输入里已知真实值的长度，相当于给decoder的“引导”片段；pred_len是预测长度。它们的关系是：decoder的输入等于label部分的真实值加pred部分的占位填充。label_len越大，decoder在预测早期越有真实依据，但过大的label_len会让模型偷懒，倾向于把label段的最后状态顺势滑出去。
场景 | seq_len | label_len | pred_len | 备注 快速冒烟 | 96 | 48 | 24 | 链路验证 小时粒度日周期数据 | 168 | 168 | 24到168 | label_len至少覆盖一个完整周期 长预测基准 | 336 | 336 | 336 | 先缩到96跑通再放大 多变量强相关数据 | 96 | 48 | 96 | 配合Crossformer或iTransformer
这是我的习惯起步值，不是最优值。如果你发现预测曲线总是“慢半拍”，第一个要怀疑的就是label_len过大。
4.2 Factor、d_model、d_ff与注意力头的取舍
factor是Informer稀疏注意力的核心参数，控制保留的query比例，默认5。对于seq_len=96这种不算长的序列，factor=5的稀疏程度偏高了，降到3往往更好；对512以上的超长序列，factor=7也可能更优。这个参数需要和seq_len联动调整，单看因子数字本身没有意义。
参数 | 默认值 | 我常用的范围 | 踩坑点 factor | 5 | 3到7 | 与seq_len联动，不是越大越好 d_model | 512 | 128到512 | 小数据用128，大数据用512 d_ff | 2048 | 512到2048 | 显存吃紧时先砍d_ff n_heads | 8 | 4到16 | d_model必须能整除n_heads
d_model和d_ff的值取决于数据量。如果你的训练集只有几千条样本，d_model=512基本必过拟合，我一般会降到128或256。n_heads则有个硬约束：d_model必须整除n_heads，否则每个头的维度会出现小数，forward直接报shape错误。
4.3 Learning Rate与Batch Size：长序列训练最容易忽视的稳定性问题
长序列预测的训练稳定性，经常比模型结构更影响最终效果。这类代码的常用学习率调度是ReduceLROnPlateau，所以初始learning_rate很关键，1e-4起步。如果loss前几个epoch剧烈震荡，说明lr偏高，往5e-5降就对了。
Batch size在长序列里很容易撞显存。seq_len=336、d_model=512时，batch_size=32能在24G显存的卡上堪堪跑，16G的卡老老实实设16。梯度累积要小心：这些老代码里layer norm和batch norm的位置不统一，梯度累积会改变每个有效batch的统计特性，导致验证集结果不稳定。我一般只在显存不够而且模型里没有BatchNorm时才用梯度累积。
4.4 用正弦数据做冒烟测试：Transformer预测正弦数据的最小实验
调参光看不练，只能靠玄学。我强烈建议在跑真实数据前，先用一段正弦数据做冒烟测试，这几乎是这类模型最早期的“后悔药”。先造一个sine.csv，让整套数据管线先跑起来：
import numpy as np import pandas as pd t = np.arange(0, 2000) / 20 sine = np.sin(2 * np.pi * t).astype("float32") df = pd.DataFrame({ "date": pd.date_range("2020-01-01", periods=len(t), freq="H"), "sine": sine }) df.to_csv("data/sine.csv", index=False) print("sine.csv已生成，样本数:", len(df))然后用Informer在正弦数据上做最小训练：
python -u run.py --model informer --data sine --features S --target sine \ --seq_len 48 --label_len 12 --pred_len 12 \ --d_model 64 --d_ff 128 --n_heads 4 --factor 3 \ --e_layers 2 --d_layers 1 --batch_size 16 --learning_rate 0.001 \ --train_epochs 3 --gpu 0逻辑说明：features S表示单变量预测，--target sine指定用csv里的sine列。d_model压到64、d_ff压到128，显存占用很低，三分钟能跑完几个epoch。正弦序列理想干净、周期确定，如果连它都学不出下降的loss，问题几乎都出在代码链路而非数据。期望结果是loss从0.6量级明显下降；如果loss纹丝不动，去检查data_loader里是否真的读到了sine这一列、归一化是否把序列压成了零均值附近的噪声。
这个冒烟测试同时验证了数据读取、时间特征生成、模型forward和优化器四个环节。等它通了，再回去跑ETTh1，你就知道之前的报错不是模型问题。
5. 避坑：15个算法代码汇总里最常见的5个坑与排查方法
下面这五个坑，是我在跑Informer、Autoformer、PEDformer这类长序列代码时反复遇到的，也是新手最容易花掉几天时间的点。每一条按现象、原因、解决来写。
5.1 数据文件里的NaN让loss变成NaN
现象：第一个epoch的loss正常，第二个epoch突然变成NaN，或者从一开始就是NaN。很多人第一反应是模型写错了，其实大多数情况是数据问题。
原因：ETT、Exchange这类csv里偶尔有空值和Inf，data_loader读进来后这些值直接进到损失计算。另一个常见来源是learning_rate设到0.001以上，长序列Transformer很容易因此loss爆炸。
解决：先按3.2的脚本检查csv文件，发现NaN要dropna，发现Inf先replace成NaN再drop；然后把learning_rate降到5e-5或1e-4。如果都无效，关闭混合精度再跑一次，省得在精度转换的隐蔽bug上浪费时间。
5.2 d_model和n_heads不整除导致shape错误
现象：forward时报“The size of tensor a must match the size of tensor b”，或者“last dimension doesn't match expected size”。这类报错往往发生在改完参数后的第一个batch。
原因：你改了d_model=128却忘了n_heads还是8，这能整除；但如果你改成d_model=512、n_heads=6，512除以6有余数，每个头的维度就变成了小数，多头注意力的拼接维度自然对不上。
解决：在模型初始化加一条断言，assert d_model % n_heads == 0。n_heads尽量用4或8，少用6这种跟512不匹配的值。d_ff建议取d_model的2到4倍，但它没有整除约束，报错时不用考虑它。
5.3 Autoformer的分解输出是常数
现象：预测曲线是一条接近水平的直线，看不到任何周期波动，但loss看起来并不高。
原因：Autoformer把序列分解成趋势项加季节项，要么moving_avg窗口过大，把季节项都平滑掉了；要么数据归一化后均值严重偏移，趋势项包揽了几乎全部能量，季节项成了一个幅度很小的残差。
解决：把moving_avg从25往13调，缩小移动平均窗口，让更多波动留在季节项里；把归一化改成只减均值、不除以方差；如果代码支持norm参数，先关掉RevIN再看分解结果。实在不行就跑Informer做对照，如果Informer有波动，问题基本锁定在分解参数。
5.4 GPU利用率低但显存见顶
现象：nvidia-smi里utilization不到40%，显存却占用接近满，一个epoch跑到天荒地老。这个现象在seq_len=336起步的项目里非常常见。
原因：seq_len太长导致attention矩阵太大，显存被占满但计算密度不高；或者dataloader的num_workers=0，GPU一直在等CPU喂数据；也有可能是pin_memory没开，页面锁定内存的传输开销拖慢了整体节奏。
解决：先用seq_len=96、batch_size=16把链路跑通再放大；num_workers设成4到8，pin_memory=True打开。Windows上num_workers大于0时，启动脚本必须有ifname== "main"保护，删掉这行会直接多进程崩溃。
5.5 预测曲线整体滞后，像“复制最近一段”
现象：MSE很低，但把预测和真实画在一起，曲线形状完全错位，整体右移了一个周期。这是长序列预测里最大的玄学现场，新手很容易在这里怀疑人生。
原因：非平稳序列里，模型发现“复制最近一段”是减loss的捷径，于是它不再学周期变化，只学“把最后一段平移出去”。label_len过大会加剧这个捷径，decoder拿到太多真实值引导，自然顺着滑出去。另一个可能原因是验证时的归一化统计量用错，推理分布和训练分布对不上。
解决：先把label_len调到pred_len的一半以下，断了模型偷懒的后路；然后用DLinear或线性AR模型做同一实验对照，如果线性模型也滞后，说明是数据定义问题而不是Transformer的锅；再检查验证时scaler是否用了验证集自身的统计量。最后用第6章的滞后检测脚本量化延迟步数，别靠眼睛判断。
6. 最后：验证自己改出来的代码，从一张滞后曲线开始
前面讲了这么多坑，但真正让你对模型建立信心的，不是跑出多低的loss，而是你有一个能快速判断“这个预测到底行不行”的手段。我最后的建议是：每次训练完，不要只看MSE，先做一次滞后检测。模型结构可以很复杂，但输出曲线如果整体右移，那这个模型就是废的，再低的MSE都是假象。下面是我常用的检测脚本。
import numpy as np def find_lag(pred, truth, max_lag=50): best_lag, best_corr = 0, -1 for lag in range(-max_lag, max_lag + 1): if lag >= 0: a, b = pred[:-lag], truth[lag:] else: a, b = pred[-lag:], truth[:lag] if len(a) < 10 or len(b) < 10: continue corr = np.corrcoef(a, b)[0, 1] if corr > best_corr: best_corr, best_lag = corr, lag return best_lag, best_corr用法很简单：把验证集的预测和真实值各自保存成一维数组，传给这个函数。返回的best_lag如果是正数，表示预测比真实晚那么多步；如果最佳corr对应的lag在0附近，说明没有明显滞后，这时候的MSE才值得信。如果lag明显不为0，先去查第5.5节的四个排查点，别急着改网络结构。
我自己的习惯是，把预测结果存成npz文件，每跑完一组实验就跑一次这个检测，然后把lag值记在实验表格里。这个方法在真实业务数据上救过我很多次——有一个项目表面上看MSE降了15%，lag从0变成了12步，预测曲线完全是上一周的复制品，要是只看loss就上线，后果可想而知。长序列Transformer的可解释性本来就差，画出滞后曲线、量化它、记录它，是你对模型唯一可靠的掌控感。希望帮到你。
本文还有配套的精品资源，点击获取
