时间序列预测在运维监控、销量预估、库存调度这些场景里几乎是绕不开的一环。过去几年开源生态里冒出来一大批时间序列模型从经典统计模型到深度学习方法从单变量到多变量从轻量级到预训练大规模模型选择面宽到让人有点不知道怎么下手。我前阵子正好要为一个内部项目做技术选型于是系统性地跑了一遍主流开源时间序列模型从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 TransformerTFT前沿Transformer系PatchTST、TimesNet另外我也体验了一下“agent时间序列预测”这类新玩法——把大语言模型作为调度器让不同模型分头预测再聚合。想法确实有意思但在生产环境里稳定性和延迟都还不行所以只做观察不参与横向对比。2. 核心对比维度代码可复现性、数据需求与计算成本对比维度如果只盯着精度那和看跑分没区别根本没法指导选型。所以我把维度拆成三大块可复现性、数据门槛、计算成本。这三个维度往往比一个微小的精度差更能决定模型能否落地。2.1 为什么统一使用MASE和WQL作为主要指标精度指标我选了MASEMean Absolute Scaled Error和WQLWeighted 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/TimesNetTransformer系的后起之秀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 (MASE)M4季度 (MASE)仓库发货量 (MASE)单序列GPU训练时间CPU推理12步耗时SARIMA0.5230.4180.68900.03sProphet0.4820.4300.5712s0.08sDeepAR0.4410.3950.548240s0.52sN-BEATS0.4150.3720.502120s0.05sN-HiTS0.3970.3550.48980s0.04sPatchTST0.3780.3490.531300s0.03sTimesNet0.3910.3610.504180s0.05s这个表格并不是用来争“谁第一”因为三个数据集的特性差异非常大。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时间序列预测”这类新热词的。我试过大模型去自动选择滑动窗口长度、自适应切换模型想法很前卫效果也确实在某些手工调参很困难的数据上有惊喜。但工程上要付出的是多模型同时驻留内存、推理链路变长、结果不稳定的代价。如果你不是在做研究建议把这类方法放在离线分析场景而不是线上预测主链路。回到最初的问题开源时间序列模型没有绝对的金字塔尖只有适不适合。很多线上模型跑得不如离线不是模型的问题而是对比的方法有瑕疵。希望我这轮的深度对比能帮你少走一点弯路。如果你正在做选型最好把前三节里的维度自己跑一遍数据会给你最真实的答案。