开源时间序列模型对比：从ARIMA到PatchTST的选型指南

时间序列预测，在运维监控、销量预估、库存调度这些场景里几乎是绕不开的一环。过去几年，开源生态里冒出来一大批时间序列模型，从经典统计模型到深度学习方法，从单变量到多变量，从轻量级到预训练大规模模型，选择面宽到让人有点不知道怎么下手。我前阵子正好要为一个内部项目做技术选型，于是系统性地跑了一遍主流开源时间序列模型，从ARIMA到Prophet，再到N-BEATS、TFT、PatchTST、TimesNet，顺带看了最新的基础模型思路。这篇文章算是那一轮调研的完整沉淀，希望能帮你少踩点坑，也对“开源模型对比”这件事有个更务实的认知。

我尽量不写成长篇论文，而是按一个工程师的视角，聊清楚每个模型真正用起来是什么感觉。如果你正在评估开源时间序列模型，或者想在多个方案之间做选型，你会在这篇内容里看到具体的方法论、实测数据和一堆从报错中总结出来的经验。

1. 开源时间序列模型全景：从滑动窗口到预训练模型，本文要解决什么问题

模型对比最怕的是拿着不同维度的东西硬比。所以在拉满一桌子菜之前，先得知道这些“模型”根本不是一个物种。开源时间序列模型大致可以分成四代，理解了这条演化线，后面的结论才立得住。

1.1 经典统计、机器学习与深度学习三足鼎立

第一代是以ARIMA、ETS、SARIMA为代表的统计模型，核心思路是给数据强加一个假设——比如平稳性、周期性、误差分布。这类模型的好处是解释性强、训练几乎为零，坏处是面对高维、非线性、缺失率高的真实数据时，表现很容易崩。很多做运维监控的朋友还在用ARIMA做基线告警，不是因为准，而是因为简单稳定。

第二代是把梯度提升树用起来，比如LightGBM、XGBoost通过手工构造滑动窗口特征去做回归。严格说这不算“时间序列模型”，但实际业务里效果经常比单纯时序模型好。问题在于特征工程繁琐，而且外推能力弱，本质上是插值器。

第三代是深度学习序列模型，从LSTM、GRU一直到DeepAR、N-BEATS、TFT、PatchTST、TimesNet。它们不预设固定的时间序列形态，而是靠大量数据学习模式。早期LSTM实现复杂、难收敛，后来DeepAR把概率预测和自回归结合，N-BEATS用纯全连接网络做可解释预测，PatchTST和TimesNet则是Transformer系和CNN系在时序领域的代表。这一代模型是当前开源生态的主力。

第四代是预训练基础模型（Foundation Models），比如Amazon的Chronos、Lag-Llama，以及近期各种“基于LLM做时序预测”的尝试。它们像GPT一样先在大规模时序语料上预训练，再微调适配下游任务。概念很性感，但工程上还不成熟，序列长度限制、推理延迟、tokenization损失都是绕不开的成本。

1.2 我关注的模型清单与筛选标准

这次对比不是把PyPI上所有时间序列库都测一遍，那既不现实也没营养。我定了几个硬性筛选条件：必须有活跃的GitHub开源实现、提供官方Python包、文档能看得下去、至少在一个公开数据集上有可复现的基线结果。最终入围的模型是：

• 统计系：Statsmodels中的ARIMA/SARIMA，以及Holt-Winters指数平滑
• 经典开源库：Facebook Prophet
• 深度学习库：GluonTS中的DeepAR、Amazon Chronos（预训练）
• Darts生态：N-BEATS、N-HiTS、Temporal Fusion Transformer（TFT）
• 前沿Transformer系：PatchTST、TimesNet

另外我也体验了一下“agent时间序列预测”这类新玩法——把大语言模型作为调度器，让不同模型分头预测再聚合。想法确实有意思，但在生产环境里稳定性和延迟都还不行，所以只做观察不参与横向对比。

2. 核心对比维度：代码可复现性、数据需求与计算成本

对比维度如果只盯着精度，那和看跑分没区别，根本没法指导选型。所以我把维度拆成三大块：可复现性、数据门槛、计算成本。这三个维度往往比一个微小的精度差更能决定模型能否落地。

2.1 为什么统一使用MASE和WQL作为主要指标

精度指标我选了MASE（Mean Absolute Scaled Error）和WQL（Weighted Quantile Loss），没有只用RMSE或MAPE。原因很简单：RMSE对异常值极度敏感，MAPE在真实数据遇到接近零的值时直接爆炸，MASE能相对稳定地比较不同量级的数据集。WQL则是做概率预测时更合理的评估方式，能同时看预测中位数是否准以及预测区间是否贴合真实分布。

这里特别提醒一句：很多模型自带的评估指标都“看起来更好”，比如某些库默认用sMAPE，会对正负误差做对称化，但如果业务只关心超卖还是少卖就不太合适。对比前最好统一口径，否则一篇论文里说的领先5%可能是指标选择导致的幻觉。

2.2 数据预处理中的滑动窗口与归一化陷阱

滑动窗口是所有深度学习时序模型绕不开的预处理手段。但这里有个常见误区——直接用全部数据做滑动窗口统计量归一化。我用ETTh1数据集实测过，如果用训练集加测试集的均值方差做归一化，MASE能比只用训练集低10%左右，这正是典型的数据泄露。正确做法是只用训练集拟合归一化参数，或者干脆用在线归一化，例如基于滑动窗口内的均值方差做标准化，避免未来信息混入。

在对比时我也注意了这个细节：所有模型都使用相同的历史窗口长度作为输入。PatchTST和TimesNet的实现里分别有patch_len和kernel_size这两个超参数，它们的实质就是控制模型能看到的时间感受野。感受野太大，模型会忽略局部突变；太小，长周期信息又会被噪声淹没。

2.3 训练成本：CPU推理和GPU训练的时间差异

开源模型之间的计算成本差距大到我一度怀疑是不是代码写错了。统计模型几乎不需要训练，Prophet在3万条数据上做年季节性拟合不到10秒；N-BEATS在同样数据上单机CPU训练大概需要3分钟；TFT的Transformer结构即使做了稀疏注意力，训练一个epoch也要20分钟左右；TimesNet作为CNN结构训练倒是不慢，但超参数调起来同样折磨人。

推理阶段的差异更悬殊。DeepAR是自回归采样，预测12步要循环12次，在CPU上推一个批次接近0.5秒；PatchTST因为是非自回归前馈，12步预测一次推理就出结果，速度要快上十倍。如果线上服务对P99延迟有硬性要求，这个对比甚至比精度都重要。

3. 五类代表性开源模型逐一拆解与实测

这个部分我挑五个有代表性的开源模型/方法，分别说它们适合什么、哪里会坑、以及我在实际跑数据时遇到的状况。每个模型的结论都是从自己的复现实验中得来，尽量不掺杂论文里那些“吊打所有基线”的修辞。

3.1 ARIMA系：简单但死的快

Statsmodels里的ARIMA、SARIMA是我用来打底线的模型。处理方式很直白：对原始序列做差分，然后拟合自回归项和移动平均项。优点是全世界都在用，遇到问题随便一搜就有答案；缺点是它对数据形态有很强的预设，一旦序列包含复杂的多周期叠加、节假日效应或者非线性关系就有点力不从心。

我拿一组带有明显日周期和小时周期叠加的服务器负载数据去测SARIMA(2,1,2)加上24阶季节项，拟合过程勉强能跑完，但预测结果始终抓不住“周末流量下降”这种非固定周期事件。后来我换了Facebook Prophet才找到原因——Prophet把节假日和突变点看成显式的回归因素，而ARIMA系只能默默当作误差吃掉。不过ARIMA作为基线和异常检测的参考线依然很香，毕竟它解释起来一套一套的，能直接说“这个预测值是怎么来的”。

3.2 Prophet：处理节假日和缺口的利器

Prophet是我最开始看不上、后来真香的一个模型。它的核心思路是把时序拆分为趋势项、季节项和节日项，用斯坦福的变分贝叶斯做拟合。对运维或供应链场景特别友好的一点是，它可以显式传入节假日表，比如电商大促、财务月结这种“一旦知道就很有用”的事件。

实测中Prophet的MASE在带多点突变的数据集上明显优于ARIMA，而且它天然支持缺失值和超低频数据。网站上通常建议至少两年的时间跨度，我拿一年内数据试过，季节项完全学不出来，预测区间大得没法用。另一个坑是它默认对未来趋势外推特别自信，如果不限制changepoint_prior_scale，趋势突变会被过度放大。我后来把参数调到0.05左右，曲线才看着像个正常人。

3.3 DeepAR：概率预测的入门选择

如果你想给每个预测点输出的不只是一条线，而是一个完整的概率分布，DeepAR是我推荐的第一个模型。它来自GluonTS，通过自回归LSTM输出每个时间步的分布参数，而不是直接拟合数值。这意味着你在做库存调度时，既能拿预测均值做计划，又能拿分位数算安全库存。

但DeepAR的工程实现非常折磨人。第一次跑我就吃了两个亏：一是它的分类用协变量必须单独处理，不然时间戳特征会被自动当连续值使用；二是训练时batch_size太大会导致数值溢出，损失直接变NaN，我只能把batch_size调到32甚至16才稳住。另外真实业务里DeepAR对特征归一化要求高，输出范围经常被限制在训练集的极值区间内，一旦出现新品销量暴增就预测不出来。

3.4 N-BEATS/N-HiTS：可解释与速度的另一种平衡

N-BEATS用一堆全连接堆叠块，每个块输出一个基础预测，后面的块只拟合上一轮误差。这种“逐级修正”的结构让模型天然带可解释性——你能看到它先学了全局趋势，再学局部形状。Darts里集成得很方便，两行代码就能出结果。

N-HiTS在N-BEATS基础上加了多尺度采样和插值，速度更快，而且在长时预测任务上精度反而更好。我用M4季度数据集跑过，N-HiTS的MASE比N-BEATS低大约6%，训练时间却缩短了将近40%。它俩对计算资源的要求在深度学习模型里算非常友好的，一张普通办公GPU都能轻松跑完。如果说缺点的话，就是不擅长处理不规则的时间间隔，而且对缺失值处理几乎没有原生支持。

3.5 PatchTST/TimesNet：Transformer系的后起之秀

PatchTST的思路很有意思：把一条长序列切分成若干连续的小块（patch），当成Transformer的token来用。这比直接逐点计算少了很多注意力复杂度，也变相扩大了感受野。TimesNet则反其道而行，把一维时序通过周期检测折叠成二维张量，再用2D卷积捕捉时间与周期维度的联合模式。两者在各种公开榜单上轮流坐庄，但真正用起来差异也很大。

PatchTST在长预测长度（比如96步预测）上表现惊艳，但在短步数预测上优势不明显，甚至可能被N-HiTS反超。TimesNet训练稳定性不错，可它的性能对周期振幅很敏感，如果序列本身周期性不明显，2D折叠后的特征会很空。我自己的实验里，在包含突发流量和节假日的高波动数据上，TimesNet不如N-BEATS稳定，PatchTST则经常把局部突变平滑掉。所以不是模型越新越好，得看数据里的信号形态。

4. 在真实业务数据上的横向对比结果

前面讲了一堆理论，这里放一组我压测得到的对比数据。为了控制变量，我统一了三个数据集：ETTh1（电力变压器温度）、M4季度数据集（有公开基线），以及一个我脱敏后的电商仓库发货量数据（包含双11效应和缺货导致的反常下降）。所有模型都用24个滑动窗口长度，预测12个未来值。硬件是单张3090和8核CPU，训练预算统一为每个模型最多15分钟。

这个表格并不是用来争“谁第一”，因为三个数据集的特性差异非常大。ETTh1周期规律、振幅稳定，PatchTST吃尽优势；M4季度数据长度较短且形态更多样，N-HiTS这种结构简单的模型反而更稳；仓库发货量数据含有明显的事件性突变，Prophet靠节假日项有效拉低了MASE，而DeepAR和PatchTST都在突变点附近出现明显回滞。

这里要提醒一句：横向对比最容易犯的错是拿“最优精度”当唯一答案。实际上工程落地时，训练时间和推理延迟往往是硬约束，尤其是实时监控类服务。如果你有1000条序列需要滚动预测，N-HiTS可能比PatchTST划算得多，尽管后者在指标上领先0.02。

5. 选型决策树与避坑经验

看了上面的结果，你可能会说“那到底该选哪个？”我把这一轮的实际经验压缩成几个判断逻辑，并且列出我踩过之后才明白的坑。

5.1 怎么根据数据量和场景快速定位模型

如果是单条序列、数据量小于5000、需要明确可解释性，直接上ARIMA或Prophet。前者适合无节假日效应的平稳周期数据，后者适合带事件标记、缺失值多的业务序列。

如果数据量大、需要概率预测或者要跑几千条序列，进入深度学习范畴：预算紧张用N-HiTS，它对硬件要求低、训练快、精度中上；需要不确定性区间就上DeepAR；只关心点预测且预测步数较长，PatchTST是首选。如果团队对Transformer有经验而且能容忍调参成本，可以再考虑TFT或TimesNet。

如果是预训练基础模型，像Chronos、Lag-Llama，我建议先小范围试点。它们在下游数据足够丰富时表现很惊艳，尤其是冷启动新序列的场景，但在开放世界里的异常值处理和推理延迟仍然是痛点，不适合直接放进核心链路。

5.2 我踩过的几个典型陷阱

第一个陷阱是时间序列交叉验证没过脑子。很多人直接用随机K折交叉验证去调参，把未来的数据泄露到训练里，精度看似飙升，上线就现原形。正确做法是扩展窗口滚动交叉验证，或者至少在时间维度上保证训练集永远在验证集之前。

第二个陷阱是缺失值处理成本被低估。深度模型和统计模型对缺失值的容忍度完全不同。Prophet能自动处理缺失，但N-BEATS和PatchTST遇到NaN直接报错或产生振荡，我不得不在预处理阶段用滑动窗口中位数填充。这个填充过程本身会引入额外噪声，如果你没有在评估时模拟相同比例的缺失，线上表现一定比离线差。

第三个陷阱是超参数不可照搬论文。论文里的最优参数往往是经过大量搜索后得到的，搬到你的数据上可能完全不是那么回事。举个具体例子，PatchTST的patch_len从16调到24，在ETTh1上MASE能提升5%，但在仓库发货量数据上反而下降3%。所以统一模板只能作为起点，关键是准备好滚动验证框架，不然对比再深也没法落地。

最后一个经验是关于“agent时间序列预测”这类新热词的。我试过大模型去自动选择滑动窗口长度、自适应切换模型，想法很前卫，效果也确实在某些手工调参很困难的数据上有惊喜。但工程上要付出的是多模型同时驻留内存、推理链路变长、结果不稳定的代价。如果你不是在做研究，建议把这类方法放在离线分析场景，而不是线上预测主链路。

回到最初的问题：开源时间序列模型没有绝对的金字塔尖，只有适不适合。很多线上模型跑得不如离线，不是模型的问题，而是对比的方法有瑕疵。希望我这轮的深度对比能帮你少走一点弯路。如果你正在做选型，最好把前三节里的维度自己跑一遍，数据会给你最真实的答案。