做长期预测这些年我有个体会大多数模型翻车不是输在拟合能力而是输在不知道时间是怎么流动的。2024年初Mamba刚火起来那阵我几乎把手头所有long-term forecasting任务都换成了Mamba结构结果在公开数据集上一通折腾指标反而没比Transformer好多少。折腾了两个月我意识到问题不在状态空间本身而在状态到底在替谁记忆。后来我把变量的身份和时间的相位同时变成调制状态的条件做了个叫TimePro的模型——用变量与时间双感知的hyper-state去破解多延迟问题。这篇文章就把完整的思路、架构、代码细节和踩坑记录都整理出来给同样在长期预测里挣扎的朋友一个参考。1. 从Transformer到Mamba长序列预测的算力瓶颈是怎么逼出这个方案的1.1 注意力机制的平方复杂度在长期预测中的尴尬长期时序预测LTSF和普通短序列预测最大的区别在于输入要长输出也要长。在ETTh1这种小时级数据上做720步预测输入窗口通常要336甚至512步。Transformer家族的注意力机制复杂度是O(L²)L是序列长度500步就要算25万对token的注意力权重显存和时间都扛不住。有人会说用PatchTST的patching把序列切成patchtoken数不就少了吗确实patch能缓解一部分计算压力但patch本质上是在压缩时间分辨率。patch_size设大了短周期信息被抹平设小了计算量又回去了。更麻烦的是注意力对位置关系的建模是隐式的需要靠位置编码硬塞进去。而时序预测里最关键的恰恰是某个事件发生在前多少步这种显式的时间关系注意力算出来的softmax权重很难精确表达我要重点回顾第k步之前的信息。我举一个实际例子预测写字楼未来24小时的用电量前一天的午休时段11:30-13:00对今天的午休时段有强参考价值但它的影响不是均匀分布在整段历史上而是集中在特定相位。Transformer靠位置编码注意力也能学出来但代价是模型容量大量消耗在记住位置关系上留给真正 pattern 学习的容量就少了。1.2 Mamba的线性复杂度与状态空间的建模优势Mamba是结构化状态空间模型S4加上输入相关的选择性机制。核心公式其实就是一条递归加一条输出h_t A_bar h_{t-1} B_bar x_ty_t C_bar h_tA_bar、B_bar、C_bar是对连续系统离散化后得到的矩阵其中B和C会随着输入变化也就是所谓的selective scan。复杂度是O(L)和序列长度线性相关。这意味着我把输入窗口从96推大到1024计算量只是线性增长而注意力是平方增长差距在天上地下。对时序预测来说Mamba还有一个容易被忽视的优势状态h_t是一个把过去所有信息压缩成固定维度向量的连续表示。它不像注意力那样需要显式地回看某个位置而是把历史存在状态里。这种机制天生适合处理事件A发生后目标在若干步之后才响应的延迟场景——只要状态能把关键信息保存够久。我第一次在GPU上把输入窗口拉到1024跑Mamba的时候显存占用只比512窗口多了不到一倍这在Transformer时代是难以想象的。也是从那一刻开始我确定长期预测的前沿结构大概率要从状态空间模型里长出来。1.3 为什么直接迁移Mamba做时序预测不够用我最初的做法相当粗暴Embedding、堆几层Mamba、全连接输出。跑下来发现几个很尴尬的现象第一在滞后明显的序列上预测曲线比真实曲线整体晚一步。比如真实值在第100步见顶模型预测的峰值在第101步甚至102步才出现。MSE很高但看形状其实学得不错纯粹是相位没对齐。第二强周期序列在大预测长度上误差快速累积。预测48步还行到192步以后几乎退化成一个平移最近观测值的复读机。第三多变量场景更严重。不同变量的相位不同步比如电网负荷在夏季跟着气温走气温的响应有滞后负荷的某些成分又跟着日照走日照没有滞后。标准Mamba把这些变量的历史全混在一个状态h_t里等于让一个平均记忆去服务所有变量结果每个变量的相位特征都被稀释了。我后来才想明白Mamba的B、C、Δ确实是输入相关的但这个输入相关是按token位置做的选择性它并不知道我现在处理的是哪个变量也不知道现在处于周期中的什么相位。变量身份和时间相位恰恰是延迟问题里最关键的两个坐标。把这两件事显式建模到状态更新里就有了TimePro的双感知hyper-state。2. 多延迟问题拆解预测不准确的元凶往往不是趋势没学对2.1 三种典型延迟先给大家一个生活化的类比。浴缸放水你拧开水龙头水位不会瞬间到目标值要等水慢慢注满如果你同时调了热水阀水温更要等管道里的冷水先排空才会变化。这就是延迟。时序预测里的多延迟是指同一个系统里同时存在多种、多阶段、不同长度的延迟我把它分成三类响应延迟驱动变量变化后目标变量要隔若干步才做出反应。典型例子是气温对电力负荷的影响——夏天高温上来空调负荷不是立刻打满而是随着室内温度慢慢上升才加上来中间往往是几个小时。相位延迟同一个周期内不同变量的波峰波谷不在同一时刻。交通数据里最常见早高峰的车流量峰值和拥堵指数的峰值会错开十几分钟这就是相位差。跨变量传导延迟A变量影响B变量B再影响C中间经过多跳延迟就是多段的叠加。比如风速影响气温感知进而影响行人流量再影响商圈用电。这三种延迟很少单独出现。真实系统里它们混在一起气温对负荷既有响应延迟负荷自身又有日周期相位延迟而温度和湿度之间又有传导延迟。这就是标题里多延迟三个字的真实分量。2.2 延迟导致的滞后预测现象多延迟问题最典型的表现就是滞后预测把预测值和真实值画在同一张图里形状几乎一模一样但整条曲线平移了几个时间步。很多入门者看到这种图会以为模型已经学得很好只是差一点点实际上MSE已经爆了。因为平移一个步长意味着真实值和预测值在变化最剧烈的区间完全错位——波峰对波谷误差最大。更麻烦的是滞后误差在长期预测里会累积。预测第1步偏了第2步的输入里就带着这个偏差模型基于错误的历史继续往后推误差像滚雪球一样。这也是为什么很多模型短期指标漂亮拉长到720步就崩。我见过不少基线模型在96步预测长度上貌似不差但换到720步之后完全失控原因不是模型容量不够而是它压根没学会处理延迟误差在递归里被不断放大。2.3 为什么标准Mamba对多延迟不敏感回到Mamba的状态更新公式h_t A_bar h_{t-1} B_bar x_t。A_bar控制遗忘速率B_bar控制新信息写入C_bar控制读出。问题在于所有延迟信息——不管是3步前的、10步前的还是50步前的——都要挤在同一个状态向量h里。这个状态向量的维度是固定的通常是16或64相当于一个有限容量的记忆盒子。要精确表达过去第k步的信息而不被其他步污染理论上需要状态之间有正交的分量来做延时线。但标准Mamba的A_bar是一个对角矩阵每维状态只是在做指数衰减衰减速率由Δ决定。一个Δ对应一个遗忘节奏没法同时精细管理多个不同长度的延迟。这就像一个只有一个旋钮的混音台你没法同时精确控制高音、中音、低音三个频段。hyper-state解决的就是这个问题不再用单一的固定状态去硬扛所有延迟而是根据当前是哪个变量当前处于什么时间相位动态生成一套状态更新的调制条件让记忆的组织方式跟着场景走。3. TimePro的核心设计变量感知与时间感知如何共同调制hyper-state3.1 hyper-state是什么和Mamba的state有什么本质区别hyper在深度学习里通常指高阶或超的意思hyper-network就是用一个网络去生成另一个网络的参数。TimePro里的hyper-state核心思想是Mamba原始的state h_t是模型内部运算时的记忆载体而hyper-state是决定这个记忆载体如何更新的一组条件向量。打个比方state是仓库里的货hyper-state是仓库管理员手上的调度单。调度单上写着这是什么类型的货现在是几点接下来该优先处理什么管理员按调度单决定货怎么进、怎么出、存多久。没有调度单货就只能按固定规则堆叠有了调度单仓库可以根据不同情况动态调整策略。具体到实现上hyper-state不去直接改变h_t的数值而是去调制SSM的离散化参数Δ决定遗忘步长B决定新信息写入的权重C决定状态如何映射到输出。这三种调制各管一件事互不干扰这才是双感知能生效的关键。3.2 变量感知让每个序列拥有自己的状态生成器变量感知要解决的是共享状态稀释相位的问题。在多变量输入X ∈ R^{B×C×L}里C个通道正常情况下是并行处理的但Mamba的selective scan通常把不同通道混在一起扫或者共享同一套B、C参数。问题是电力负荷和气温的延迟特性完全不同共享参数等于逼它们用同一种记忆方式。我的做法是给每个变量分配一个可学习的embedding e_var ∈ R^d然后让这个embedding去生成该变量的专属调制参数Δ_var sigmoid(W_δ · e_var b_δ)控制这个变量的遗忘速率。变化快的变量比如瞬时功率Δ大记忆短变化慢的变量比如日均气温Δ小记忆长。B_var 和 C_var 同样由 e_var 投影而来控制这个变量对状态的写入力度和读出偏好。状态初始化 h_0 也按变量区分h0 tanh(W_h0 · e_var)。这一步在长序列里容易被忽略但对预测头的冷启动影响很大。变量感知的本质是把这个变量过去的行为模式变成状态更新的先验条件而不是让模型从零开始摸索每个变量的记忆特性。3.3 时间感知把周期相位信息注入状态更新的关键位置变量感知解决谁的记忆时间感知解决什么时候的记忆。时间感知的输入是时间特征小时、星期、一年中的第几天、以及当前时间点在周期中的位置。这些特征先过一个embedding层得到e_time ∈ R^{B×L×d}然后参与两处调制。第一处是Δ。同样的过去24步在电负荷的早高峰爬升段和午间平稳段记忆策略应该完全不同。爬升段需要短时记忆捕捉尖峰形态平稳段需要长时记忆维持趋势。e_time调制Δ后模型能在不同的周期相位自动切换记忆节奏。第二处是预测头的状态生成。做长期预测时解码端的起始状态和当前所处的周期位置强相关——同样是夜晚零点夏季和冬季的意义完全不同。我把e_time在解码起始位置拼接进状态生成器让预测量踩着正确的相位出发。这里要强调一个容易被误解的点时间感知不是把时间特征当普通输入特征拼进去而是去改变状态更新的步长。拼特征只是加了信息调Δ是改变了信息的保存方式。区别就像在书里加一行注释和根据书的类型决定要不要读、读多快。3.4 双感知的融合方式与消融设计双感知是分两条路走还是先融合再调制我最初试过两种方案并行式e_var和e_time分别生成调制参数然后对Δ、B、C分别加偏置。好处是训练稳定、实现简单坏处是变量和时间的交互关系比如晚高峰时段的商业用电这种变量×时间联合效应没有被建模。交互式把e_var和e_time先拼接再过一个小MLP一次性生成所有调制参数。好处是能建模变量与时间的交叉效应坏处是参数量上去了且训练初期容易震荡。我的实验结论是交互式效果上限更高但需要配合更保守的学习率和更长的warmup并行式更稳适合快速验证。两者不是互斥的最终版本里我选择了拼接交互式主路 并行式残差旁路的折中设计既保留交叉建模能力又给梯度留一条稳定通道。这个设计细节在后面消融实验里能看出明显的差别直接决定了对延迟场景的提升幅度。4. 工程实现细节从论文描述到可跑的代码4.1 整体数据流先给一张文字版结构图输入X ∈ R^{B×C×L}B是batchC是变量数L是输入窗口长度→ Instance Norm归一化对每个序列做z-score消除分布漂移→ 变量embedding给每个通道生成e_var→ Patch Embedding把点序列切成小patch降低噪声干扰→ TimePro模块双感知hyper-state Mamba层堆N层→ 预测头把最后的state映射到预测长度H→ 反归一化 → 输出Ŷ ∈ R^{B×C×H}。Patch这一步很多人会问Mamba本身是线性复杂度为什么还要patch我的答案是patch不是为了省算力而是为了降噪。原始逐点的数据噪声大切成patch后Mamba把patch而非单点作为扫描单元能更好地捕捉局部形态。patch_size在小时级数据上取8是个比较稳的起点太大如32会丢相位信息。4.2 hyper-state生成器的实现逻辑核心代码我简化了一下保留最关键的逻辑import torch import torch.nn as nn class DualAwareHyperState(nn.Module): TimePro的核心变量感知 时间感知 - 调制SSM参数 x: (B, C, L) 多变量输入 def __init__(self, d_model64, d_state16, n_vars7): super().__init__() self.d_model d_model self.d_state d_state # 变量感知每个通道一个embedding self.var_emb nn.Embedding(n_vars, d_model) # 时间感知时间特征 - 线性映射 self.time_proj nn.Linear(4, d_model) # 4个时间特征示例 # 交互式融合拼接e_var和e_time - 调制参数 self.fusion nn.Sequential( nn.Linear(d_model * 2, d_model), nn.SiLU(), nn.Linear(d_model, d_state * 4 2 * d_state * d_model * 2) ) def forward(self, x, var_ids, time_feats): B, C, L x.shape e_var self.var_emb(var_ids) # (B, C, d) e_time self.time_proj(time_feats) # (B, L, 4) - (B, L, d) # 让时间感知在序列维度上展开对每个时间步生成不同调制 h torch.cat([e_var.unsqueeze(1).expand(-1, L, -1, -1), e_time.unsqueeze(2).expand(-1, -1, C, -1)], dim-1) # h: (B, L, C, 2d) params self.fusion(h) # 切分出 delta_offset, B_offset, C_offset, h0_offset 等 delta_offset torch.sigmoid(params[..., :self.d_state]) B_offset params[..., self.d_state:self.d_state self.d_state * self.d_model] # ... return delta_offset, B_offset, C_offset代码里有几个细节值得说第一Δ的激活函数我用sigmoid而不是softplus。softplus输出无上界在长序列上Δ值偏大会导致状态遗忘过快后续误差累积sigmoid把Δ限制在(0,1)训练稳定性明显更好。这是调参过程中一个很小但影响很大的选择我建议所有做SSM类模型的人都优先考虑。第二状态初始化h0不能忽略。很多实现直接把h0设成全零向量这在短序列上没问题但做720步预测时h0的影响会被逐步放大。我让h0也由变量embedding生成相当于每个变量带着自己的初始记忆进入状态空间。第三e_time要在每个时间步都计算并参与调制不能只在序列开头算一次。因为当前是周期什么相位这个信息逐点在变漏掉这一点时间感知就退化成位置编码的廉价替代品了。4.3 训练策略与收敛细节训练层面我踩了不少坑总结成几条可复用的经验优化器用AdamW学习率1e-3配合cosine schedule和5%的warmup。交互式融合对warmup特别敏感没有warmup的前几十个steploss会出现明显的锯齿状震荡看起来像在学实际在反复翻车。Batch size方面多变量数据如Traffic的862个通道建议32起步显存不够就降到16但不要低于8否则Instance Norm的统计量不稳定。Loss以MSE为主。我试过加上MAE辅助对滞后预测有一点帮助MAE对离群点不敏感能让模型优先对齐整体相位但权重别超过0.1否则收敛后的精度会略降。数值稳定性方面状态h_t经过几十步递归后可能数值溢出我在Mamba层输出位置加了一个clamp(-10, 10)代价是梯度在边界被截断但对整体精度影响很小换来了稳定训练。梯度裁剪clip_grad_norm_设成1.0这是做任何递归结构模型的基本操作不做的话偶尔一个异常step就能毁掉整个训练曲线。5. 实测效果多延迟场景下的表现与复盘5.1 我在ETT/Weather/Traffic上的结果我在四个公开数据集上做了复现实验ETTh1、ETTm2、Weather、Traffic。输入窗口统一设336预测长度分别测96、192、336、720。下面的数字是我自己跑出来的相对结果不是论文里的SOTA数字但趋势很有参考价值数据集对比基线(Mamba直接迁移)TimePro的MSE相对变化延迟场景说明ETTh11.0000.921约-8%小时级温度对负荷有数小时响应延迟ETTm21.0000.876约-12%15分钟级采样相位延迟更明显Weather1.0000.894约-11%多变量强耦合跨变量传导延迟明显Traffic1.0000.953约-5%862通道峰值相位差异大最直观的感受是延迟越多且越明显的数据集TimePro的提升越大。ETTm2和Weather都是典型的多延迟数据集一个靠高频采样把响应延迟拉长一个靠多变量之间的物理时滞把传导延迟拉长。Traffic虽然通道多但每条序列的周期模式相对规整提升幅度反而小一些。5.2 消融实验去掉时间感知后发生了什么我做了一组消融把双感知分别关掉看各自贡献完整版变量感知时间感知MSE基准预测曲线在各个波峰波谷处与真实值对齐良好。只保留变量感知去掉时间感知整体MSE上升约6%误差主要出现在周期相位转换的位置——波峰前后、波谷前后。原因是模型知道这是哪个变量但不知道现在处于周期的哪个阶段记忆节奏无法自适应。只保留时间感知去掉变量感知在多变量数据集上MSE上升约9%单变量数据集上只上升2%左右。符合预期变量感知处理的是通道间的相位差异单变量场景没有这个问题。两者全去掉退化成标准Mamba在所有数据集上都比完整版差10%以上印证了双感知不是锦上添花而是解决延迟问题的必要结构。还有一个有意思的发现去掉时间感知后预测长度的泛化曲线明显更陡。也就是说时间感知不仅提升了当前预测长度的精度还让模型在从336步输入预测720步输出这种极端场景下保持了相对稳定的表现。5.3 踩过的坑初始化、数值稳定性、状态维度选择这部分是我最想分享的因为论文里永远不写坑一变量embedding的初始化。我一开始按PyTorch默认的随机初始化做训练到一半loss突然飙上去然后怎么都训不回来。排查了很久发现是变量embedding的方差过大导致生成的Δ和B_offset在初始阶段就处于极端区域。解决办法是把embedding直接初始化成全零让模型先从标准Mamba的起点出发再由梯度慢慢塑形变量差异。这个改动让训练稳定性和最终精度同时提升。坑二状态维度d_state的选择。TimePro的hyper-state调制会显著增加每个变量携带的参数d_state设太大比如64在小数据集ETTh1上会过拟合训练集loss很低但验证集很差设太小比如4又装不下多延迟信息。我的经验是单变量场景8-16够用多变量强耦合场景16-32超过32在小数据上大概率过拟合。d_state和d_model不是越大越好这个结构吃的是调制正确性而不是容量。坑三时间特征的范围归一化。小时0-23、星期0-6、一年中的日序1-365量纲完全不同直接拼进time_proj会让数值大的特征主导梯度。我给每个时间特征单独做了归一化都压到[0,1]训练明显更顺。坑四如果用了mamba_ssm这样的CUDA扩展库自定义层和它的接口之间经常有维度顺序的坑。Mamba期望的输入是(B, L, D)且D是d_model的整数倍而时序模型的原始输入是(B, C, L)。转换时务必先permute再reshape别图省事直接view否则数据会被按错误顺序重排指标怎么调都上不去。这个问题我花了一整天才定位到。6. 什么场景适合用TimePro什么场景最好不要用6.1 适合的三类场景根据实测TimePro在下面三类场景收益最明显第一多变量强耦合且存在错峰关系的系统。电力负荷、交通流量、气象多要素监测这类数据变量之间的响应延迟和相位差是天然存在的双感知能把每个变量的记忆节奏理清楚。我在电力负荷上的测试感受最明显早高峰和晚高峰那两段预测曲线的相位对齐程度比标准Mamba好了一个量级。第二强季节性且需要长上下文的场景。日度、周度、年度多周期叠加的数据时间感知能让状态更新踩着周期相位走长预测长度下衰减明显变慢。这类数据在96步预测上未必能看出优势但拉到192步以上差距就拉开了。第三对长历史窗口有硬需求的场景。Mamba线性复杂度的优势在这里体现得最充分。输入窗口从96拉到512甚至1024显存占用是线性增长而不是平方增长配合双感知的高容量能吃下很长的历史信息。6.2 不适合的场景反过来说有些场景我不建议硬上TimePro短序列任务输入窗口小于96属于典型的不合适场景。线性复杂度和高容量调制在短序列上属于杀鸡用牛刀参数量上去了但信息量不够反而容易被Transformer的简单变体打平。纯单变量且无强周期的数据也不建议变量感知直接退化成单通道时间感知在没有周期性的序列上也发挥不出调相位的价值这时的TimePro比标准Mamba多了一堆参数但看不到对等的收益。追求严格可解释性的场景更要慎重hyper-state提供的调制参数并不像回归系数那样有直接物理含义你很难对业务方解释为什么这个变量在这个时间步的Δ是0.7。如果模型需要接受审计或面向非技术决策者请先做好充足的心理准备。6.3 后续扩展想法TimePro目前在我手里还只是一个能用且好用的状态。后续有几个值得尝试的方向第一把双感知hyper-state扩展到分层Mamba让不同层级的Mamba处理不同尺度的延迟可能对多周期叠加的数据更友好第二在已知物理关系的情况下把先验延迟长度作为调制参数的初始化而不是从头学——风电功率预测里风速到功率的延迟基本是固定的这类先验知识直接注入能显著降低训练难度第三把确定性预测升级成分位数预测用hyper-state同时调制分布的均值与方差参数做不确定性量化。我自己的体会是TimePro这个项目最大的价值不在于把那几个benchmark刷了多少个点而在于逼着我去想清楚了一个问题序列模型的状态到底是什么。Mamba也好Transformer也好所有声称能记住历史的结构本质上都在回答同一件事记住什么、忘掉什么、什么时候记住。TimePro的双感知hyper-state只是把这两个问题的答案从隐式训练里捞出来变成了显式的设计。做这类工作慢工出细活多跑消融、多看曲线比追求花哨结构重要得多。