Token导航 LogoToken导航

AI 资讯 · 科技行者

650万参数小模型靠改训练代码胜过200M参数TimesFM

更新 2026-10-22科技行者正文 6333字阅读约 20分钟

2026年9月,一篇论文悄悄挂上了arXiv,标题看起来平平无奇:《NanoForecast v0.5:通过训练流程优化实现具有竞争力的时间序列预测》。但如果你仔细看摘要里的数字,会发现一件挺离谱的事:一个只有650万参数的小模型,在好几个基准测试上打赢了参数量是它31倍的200M大模型TimesFM。

而且作者没有改一行架构代码。

同样的网络结构,同样的数据,同样的训练时长,只是修好了训练流程里的三个bug,误差就从3.030降到了1.704,降幅43.8%。这事儿值得琢磨琢磨。

**时间序列预测**:根据历史数据点预测未来数值的任务,比如根据过去一周的电力消耗预测明天的用电量,广泛用于能源管理、金融、供应链等领域。

大模型当道的时代,为什么还需要小模型

先说说背景。这两年时间序列预测领域也卷起了"大模型军备竞赛"。谷歌的TimesFM用了200M参数,在大约1000亿个时间点上做预训练;亚马逊的Chronos把T5架构改造后拿来做时间序列,最大版本堆到了710M参数;还有PatchTST,走的是patch化transformer路线,参数量也在1500万以上。

这些模型确实厉害,但有个共同问题:它们都假设你有GPU集群。训练要GPU,推理往往也要GPU。如果你是一个想在树莓派上跑预测、或者在边缘设备上做实时电力预测的工程师,这些"巨无霸"基本用不上。

这就是NanoForecast团队瞄准的空隙:能不能做一个小到可以在消费级硬件上训练、CPU上就能推理的模型,同时精度还不掉队太多?

**TimesFM**:谷歌研究院开发的时间序列基础模型,200M参数的decoder-only transformer架构,在约1000亿时间点上预训练。

他们没有从头设计新架构,而是拿了自家v0.3版本的老模型(650万参数,MASE 3.030),一头扎进训练代码里找问题。这个思路本身就很有意思:与其死磕"怎么做出更聪明的架构",不如先问一句"我现在这套训练流程,真的没问题吗"。

结果,还真找出三个问题。

问题一:损失函数看错了地方

**MASE**:全称Mean Absolute Scaled Error(平均绝对标度误差),是时间序列预测里常用的评价指标,数值越低说明预测越准,而且这个指标是"尺度无关"的,不同量级的数据集之间可以直接比较分数高低。

第一个bug出在数据管道里。模型内部有个配置开关叫multi_horizon,用来控制是否按每个样本单独指定预测长度。但无论这个开关开还是关,数据管道都会无条件往batch字典里塞一个"horizon"键。

后果是什么?当开关关闭时,训练循环本该只对未来H步(论文里H=48)的预测计算损失,但由于这个多余的键没被正确处理,模型实际上是在对整个上下文长度的输出做反向传播,包括那些模型早就"看见过"的历史数据。

**梯度回传**:神经网络训练中,模型根据预测误差调整参数的过程,误差信号沿着计算图往回传递,告诉每个参数"往哪个方向调整能让预测更准"。

这就好比你请了一位家教来辅导孩子明天的考试范围,结果这位家教却花了大半时间在讲孩子早就学会的旧知识上。孩子每天都在"学习",成绩单看起来也在进步,但真正该补的新内容却被稀释掉了。如果不修这个bug,模型依然会收敛,训练曲线看起来完全正常,这才是最麻烦的地方,因为没人会去怀疑一条看起来在稳步下降的loss曲线。

问题二:形状对不上,梯度走岔路

第二个问题更隐蔽,出在多任务损失函数的计算顺序上。模型除了输出点预测,还要输出五个分位数(p10到p90)来表达不确定性。但代码里,分位数损失的计算发生在"把预测截断到预测长度H"这一步之前。

也就是说,分位数头输出的是形状为(批次, H)的张量,但内部却携带着完整上下文长度的激活值。形状不匹配导致的直接后果是分位数分支的梯度流向了错误的维度。

**分位数预测**:不只给出一个确定的预测值,而是给出多个置信水平下的区间估计,比如p10表示"有10%的概率实际值会低于这个数",能帮助使用者判断预测的不确定性有多大。

点预测的精度也跟着受了牵连,因为共享的网络层要同时兼顾两个任务,一个任务的梯度乱了,另一个自然也会被带偏。修复的办法很直接:在计算任何损失项之前,先把点预测和分位数预测、连同对应的目标值,统一截断到H。

问题三:数据增强覆盖面太窄

第三个问题不是bug,更像是"偷懒"。v0.3版本的数据增强只用了三招:加噪声(jitter)、缩放(scaling)、平移(shifting)。在数据集本身固定不变的情况下,这样的增强多样性其实很有限,模型很容易把宝贵的参数容量花在记住某个数据集的"怪癖"上,而不是学到真正能迁移的时序模式。

**数据增强**:在不改变数据本质含义的前提下,对训练样本做一些变换(比如加噪声、翻转、遮挡部分数据),人为扩大训练数据的多样性,让模型学到更普适的规律而不是死记硬背。

v0.5的修复方案是加入了"时间反转"(把序列首尾颠倒过来),再加上随机掩码(mask),一共五种增强手段随机组合使用。这招其实借鉴自同系列的另一个模型Reverso,它本身就用了"翻转等变推理"的设计思路。

这个改动让我想起学外语时候的一个体会。如果你只用一本教材反复刷题,很容易把答案背下来,但换一套题型立刻现原形;而如果同一批词汇你用听力、阅读、写作、口语反复从不同角度接触,真正内化的知识才更扎实。时间反转这一招尤其巧妙,它相当于告诉模型"过去推未来"和"未来推过去"这两种时间流向的模式本质上是相通的,逼着网络学到更本质的结构,而不是死记某个方向上的表面规律。

三个bug加起来,贡献了43.8%的误差下降。论文里专门放了一张对照表,把v0.3和v0.5放在同一套评测协议下直接比较,六个数据集全部下降,其中汇率数据集降幅最猛,达到63.3%。

打赢200M模型的成绩单,以及输掉的地方

修好流程之后,NanoForecast v0.5拿这套650万参数的小模型去对线TimesFM(200M)和PatchTST(1500万+)。

| 数据集 | NanoForecast v0.5 (6.5M) | TimesFM (200M) | PatchTST (15M+) |

|---|---|---|---|

| ETTh1 | **0.676** | 0.705 | 0.781 |

| ETTh2 | **1.110** | 1.360 | 1.467 |

| ETTm1 | **0.287** | 0.545 | 0.488 |

| Exchange | 4.317 | 4.383 | **3.861** |

| Electricity | 2.029 | **0.923** | 1.347 |

| Traffic | 1.805 | **0.765** | 1.379 |

| 总体 | 1.704 | **1.447** | 1.554 |

三个ETT系列数据集(变压器油温预测,分小时和15分钟两种粒度),v0.5全部胜出,而且在ETTm1上的优势相当明显,0.287对0.545,几乎是TimesFM误差的一半。汇率数据集上v0.5也以微弱优势(4.317对4.383)险胜TimesFM,虽然输给了PatchTST。

但在电力(Electricity,321个用户)和交通(Traffic,862个传感器)这两个"高基数"数据集上,v0.5输得比较明显,TimesFM的表现几乎是它的两倍好。作者的解释是这类数据集通道数极多,TimesFM靠海量预训练数据吃到了红利,这是650万参数的小模型很难在同等训练预算下追上的。

这里有个概念值得说一下。

**高基数数据集**:指数据集里包含大量并行的时间序列通道(比如862个交通传感器各自是一条独立序列),模型需要同时理解和区分海量不同模式,对模型容量和预训练规模的要求会显著提高。

论文里还算了一个"效率比"指标,用MASE的倒数除以参数量(单位百万),v0.5是0.090,PatchTST是0.043,TimesFM只有0.0035。换句话说,按每百万参数创造的精度产出来看,v0.5比TimesFM高26倍。这倒不是说小模型全面碾压大模型,而是说明"用对地方"这件事本身有巨大的价值。就像一把瑞士军刀打不过专业厨具套装的每一把刀,但装进背包出门野营,瑞士军刀的性价比谁都比不了。

架构没变,变的是训练这条流水线

既然v0.5赢的关键不在架构,那架构长什么样也值得说说,毕竟这是"底子"。

NanoForecast系列源自一个叫Reverso的模型家族,核心是把长卷积(LongConv)和一种叫DeltaNet的线性时间循环层交错堆叠。每层还有一个门控MLP,三种组件通过一个学习出来的路由器加权组合。

**DeltaNet**:一种线性时间的循环神经网络层,用"delta规则"更新内部的矩阵状态,可以理解成模型带着一个不断被修正的记忆矩阵,每来一个新的时间步就更新一次,而不需要像传统注意力机制那样把整个历史都重新算一遍。

这个设计最大的好处是支持流式推理。DeltaNet的矩阵状态可以在多次调用之间持续保存,模型不需要把完整历史重新喂一遍才能做新的预测。论文测出来一个流式更新只要19.1毫秒,跟完整推理的19.5毫秒几乎没有差别。

这就好比传统的窗口式模型是那种每次都要把过去几个月的账本翻出来重新算一遍的会计,而DeltaNet则像一个随时记账的会计,新的一笔交易进来,他只需要在原有账本上做一次增量更新,不用把整本账重新算一遍。如果没有这种状态持久化的设计,每来一个新数据点就要把过去512个时间步全部重新跑一遍前向传播,边缘设备的电池和算力根本扛不住。

整个模型只有8层,隐藏维度96,输入窗口切成大小为8的patch,配合一个可学习的频率嵌入(告诉模型这是小时级数据还是天级数据)。输出头一次前向传播能产出四样东西:点预测、五档分位数(强制保证单调性,p10永远小于等于p25小于等于p50)、趋势季节残差分解,还有一个基于重建误差的异常分数。

小模型的软肋:不确定性估计不太准

修好训练流程也不是万能药。论文很坦诚地报告了一个副作用:分位数校准出了问题。

理论上,p10到p90这个80%的置信区间应该覆盖80%的真实值。但v0.5实测出来只覆盖了51.3%,区间明显偏窄。反倒是有bug的v0.3版本覆盖率是90.3%,看起来更"准",但那其实是巧合,因为v0.3整体预测精度更差,误差大反而让区间显得更宽松。

作者给出的建议是,v0.5的分位数目前只能当作"相对不确定性"的参考,比如告诉你"这一步比那一步更没把握",但不能拿来做严格意义上的概率校准。中间预测(p50)本身不受这个问题影响,因为MASE指标算的就是p50。

这个取舍其实挺真实的,工程上很难同时把点预测精度和区间校准都做到最优,尤其是在参数量被死死限制在650万这个量级的情况下。

部署这件事,作者做得挺完整

除了跑分,NanoForecast团队还把整条部署链路开源了。ONNX导出后FP32版本27.9MB,INT8量化能压到9.2MB。在苹果M4芯片的CPU上,用ONNX Runtime跑一次推理只要10.7毫秒,原生PyTorch是19.5毫秒。

**ONNX**:一种跨框架的模型格式标准,可以把用PyTorch等框架训练好的模型转换成一种通用格式,方便部署到不同硬件和运行环境里,通常还能带来推理速度的提升。

训练端也很克制,用一块免费的Google Colab T4显卡,12小时左右能训完一轮,跟动辄需要几十块A100训练数周的大模型完全不是一个数量级的投入。代码、checkpoint、评测框架全部按Apache 2.0协议开源,还配了FastAPI服务端、Docker镜像和一个可以直接在浏览器里玩的Gradio演示页面。

这套完整的开源链路某种程度上比跑分数字更有价值,因为一个只有论文里的表格、没有可复现代码的研究,读者永远无法验证它是不是真的。

这项研究提醒我们的事

这篇论文最有意思的地方,其实不是它打赢了TimesFM,而是它提出的那个问题:学术界发表的那些"架构创新"带来的提升,到底有多少其实是训练流程里悄悄修好的bug在起作用?

这不是空穴来风的质疑。论文作者自己就说,这三个bug"不是这个模型独有的",任何用了多任务损失、复杂数据增强、混合语料的训练流程都可能藏着类似的坑。而且最要命的是,这些bug不会让训练崩掉,loss曲线看起来完全正常,只有拿来跟"修复后"的版本对比,才会发现原来差了这么多。

这跟我们平时调试代码的经验其实很像。一段逻辑错误的代码往往不会直接报错崩溃,它会安静地跑出一个"看起来还行"的结果,你甚至可能因为结果不算太离谱就没有深挖。真正的坑往往藏在那些"能跑,但跑得不对"的地方。

论文里提到三篇未来可以进一步验证这个思路的方向。一个是把同样修好的训练流程用在参数量适度扩大(但仍控制在2000万以内)的模型上,看能不能在电力和交通这类高基数数据集上追上TimesFM;另一个是把更多基线模型(比如Chronos-T5-large、Moirai、Lag-Llama)纳入同一套评测协议,因为目前很多论文之间的比较其实用的是不同的评测口径,根本不是苹果对苹果的对比;第三个方向是把ONNX模型真的部署到树莓派这类边缘硬件上实测,而不只是停留在M4笔记本芯片上的CPU测试。

写在后面

读完这篇论文最触动我的一点,是它选择公开三个具体的bug细节,而不是笼统地说"我们优化了训练流程"。损失截断的顺序、张量形状对齐、数据增强的覆盖范围,每一个都写清楚了"观察到什么现象"、"造成了什么后果"、"怎么修的"。这种颗粒度的透明在AI论文里其实并不常见,大部分工作要么藏着掖着细节,要么用一句"we carefully tuned the training pipeline"就带过去了。

还有一个细节值得单独说说:v0.5的最佳checkpoint出现在第51个epoch,而v0.3的最佳checkpoint在第147个epoch。同样跑200个epoch,修好bug后的模型收敛得更快,用更少的训练步数就找到了更好的解。这从侧面印证了那三个bug确实在浪费训练信号,不是简单的"训练更久就能弥补"的问题。

这篇论文没有解决的问题也很明显:高基数数据集上的差距、分位数校准的偏差、只用了一个随机种子没有报告方差。但正是这种不回避短板的写法,让整篇论文的可信度反而更高了。

一个问题留给自己:如果连一篇专门讨论"训练流程bug"的论文,最后自己的分位数校准也出了问题,那我们平时读到的那些大模型技术报告里,还藏着多少类似的、连作者自己都没意识到的坑?

Q&A

Q1:NanoForecast v0.5是什么?

A:它是一个只有650万参数的时间序列预测模型,通过修复训练流程里的三个bug(损失范围处理、张量形状对齐、数据增强覆盖不足),在不改架构的情况下把误差降低了43.8%,并在多个基准上打赢了参数量31倍于它的TimesFM。

Q2:NanoForecast v0.5在哪些数据集上表现更好,哪些更差?

A:它在ETTh1、ETTh2、ETTm1三个变压器温度数据集和汇率数据集上胜过TimesFM,但在电力和交通这两个高基数(通道数很多)数据集上明显落后,TimesFM靠海量预训练数据占了优势。

Q3:NanoForecast v0.5能在普通电脑上跑吗?

A:可以。训练只需要一块免费的Google Colab T4显卡跑约12小时,推理完全不需要GPU,在苹果M4芯片CPU上单次预测只要19.5毫秒,转成ONNX格式后还能压缩到9.2MB,能装进边缘设备。

资讯来源:由AI资讯编辑整理自互联网公开内容,版权归原作者所有,未经许可,不得转载。