说个特别实际的场景你在做电力负荷预测气温明明已经冲高两天了负荷曲线却还趴在昨天那个位置附近磨蹭。不是信号没到是冷负荷传递到用电侧本身就带延迟而且这个延迟量会随着建筑热容量、用户行为、电价机制变来变去。同一条数据里站点A的负荷滞后气温4小时站点B滞后2小时站点C干脆超前。面对这种变量之间交错、滞后规则各不相同的“多延迟”依赖绝大多数预测模型在处理时都把时间轴强行对齐用一个固定窗口去“硬算”效果自然很难尽如人意。TimePro 正是围绕这个问题设计的高效Mamba长期预测模型。它的思路很直白在状态空间模型的主干上引入变量感知和时间感知两条路由链路共同维护一个 hyper-state用接近线性的复杂度把多延迟依赖在超长预测窗口内稳定建模出来。这篇内容适合正在长序列预测和状态空间模型之间找结合点的算法工程师、研究生和复现党我会把模型动机、机制拆解、落地代码路径、实验观察和踩坑记录一次性讲清楚。1. 多延迟问题为什么把时间轴对齐是件吃亏的事1.1 一句话解释TimePro要解决的“多延迟”长期预测的标准设定是给定过去L个时间步的观测预测未来H个时间步。数据通常是多维的比如电力数据集里有气象、电价、负荷、风速等变量。问题在于这些变量之间的影响并不是同一时刻发生的。上一轮促销对销量的影响可能延续两周下一轮促销可能只影响三天气温对负荷的影响会延迟几个小时而湿度对体感温度的影响可能马上就显现。这些不同的滞后关系叠加在一起就是所谓的“多延迟”。更麻烦的是同一个变量对的延迟权重还会随状态变化。连续高温下气温对制冷负荷的延迟会衰减得越来越快下雨天的延迟路径和晴天完全不同。如果模型用固定的窗口长度来吸收这些延迟信息窗口短了抓不到长尾巴窗口长了又会被过期状态污染。TimePro 想做的就是不再把时间戳当成“对齐”的约束而是把延迟当成模型内部一个可以动态学习的结构。1.2 主流架构在延迟建模上为什么吃亏Transformer 类模型天然把所有时间步看成两两可比的点注意力机制更关注位置对应关系。把时间步做了 Patch 之后虽然能利用局部平滑性但 Patch 本质上是一种固定长度的均匀切分它只能缓解局部噪声并不能根据变量动态调整依赖范围。iTransformer 把变量当 Token 后可以建模通道相关性但对时间维度的推进关系又弱化了一截。你在一个强多延迟数据集上跑实验会发现这些模型经常出现两个极端要么预测曲线太“平”把所有延迟都磨掉了要么在某几个变量上明显过冲因为模型把不该同时出现的信号强行叠加在一起。RNN/LSTM 类模型按时间步逐帧传播理论上天然适合建模滞后依赖但训练必须串行记忆状态通常又是一维的很难同时记住“这个变量看三天前那个变量看两小时前”这种复杂结构。旧的长短期记忆网络在这个任务上并不是完全没有能力而是容量和工程效率撑不住超长序列。1.3 Mamba 给了一个更好的地基Mamba 的核心是选择性状态空间模型基本更新形式可以写成[ h_t \bar A_t h_{t-1} \bar B_t x_t, \quad y_t C_t h_t ]这里的 A、B、C 都由输入动态生成模型可以自主决定每一步要记住什么、遗忘什么。这种机制对延迟建模非常有吸引力模型可以把某些变量对应的历史状态长期保留在记忆里同时将另一些变量的旧信息快速丢弃。而且 Mamba 用分段并行扫描实现训练时间复杂度是 O(L) 量级比 Transformer 的 O(L²) 友好太多长序列预测场景下显存压力小得多。但原生 Mamba 是为语言建模设计的它原则上只有一个时间维度的逐步推进并不区分“哪个变量”的延迟。如果直接把 Mamba 拿来做多变量时间序列它仍然需要外部机制告诉它当前步更新状态时应该参考哪个变量的哪一段历史。TimePro 的变量感知、时间感知和 hyper-state 就是在这一层补上了缺失的信息。2. 双感知与 hyper-state核心机制的一次拆解2.1 变量感知让每个序列拥有自己的“衰老规则”变量感知模块解决的核心问题是不同变量应该用不同的历史尺度去理解当前信号。实现上模型会给每个变量学一个可训练的变量嵌入 v_c同时根据当前输入生成一组“延迟路由权重”。这个权重的含义是某个变量在自己当前状态中应当保留多久以前的信息。用简化公式表达[ G^v_t \sigma( W_v( v_{c_t} \oplus x_t ) ) ]其中 ( G^v_t ) 会去控制状态更新里历史成分的比例。变量感知模块输出的不是简单的一维系数而是一个向量它可以在 hyper-state 的不同通道上分别做“保留”或“丢弃”。实际里很多老牌时间序列模型会做变量选择但 TimePro 的做法更激进它在每一个时间步上都重新计算延迟路由让“看多远”这件事变成一个完全输入依赖的动态决策。2.2 时间感知把周期和位置重新拉回状态空间只做变量感知还不够。Mamba 的扫描结构对时间位置是隐式感知的但如果序列里有强周期、节假日效应隐式感知容易在长窗口内发生位置漂移。时间感知模块会显式加入两类信息一是绝对位置编码二是外部时间协变量比如小时、星期、是否为节假日等。这些信息经过一个轻量的时间路由 MLP生成时间维度上的门控信号[ G^t_t \sigma( W_t( \text{time_emb}(t) \oplus \text{cov}_t ) ) ]时间感知和变量感知在结构上是对称的但它们的作用各不一样。变量感知决定“从谁那儿取信息”时间感知决定“在这个时间点该不该取、该取多少”。举个例子工作日早高峰的交通状态和昨天同一时刻关联性强但周末早高峰的关联性可能弱得多这个差异只有时间感知能学出来。2.3 hyper-state把两条感知汇成“状态的状态”hyper-state 是我觉得整个设计里最有意思的部分。原生 Mamba 的隐状态是一个固定长度的向量 ( h_t )它被 A、B、C 矩阵驱动更新。TimePro 的做法是把变量感知和时间感知的输出连同一个延迟上下文向量一起拼成一个维度更高的“超状态”[ S_t [ h_t, G^v_t \odot z^v_t,\ G^t_t \odot z^t_t ] ]其中 ( z^v_t ) 和 ( z^t_t ) 分别是变量路由和时间路由的中间表达。随后这个超状态会被投影成一个新的更新矩阵参与对 A、B 参数的调制。意思就是模型不是单独用 h_t 来决定下一步读什么而是用“带上变量和时间上下文信息的超状态”来决定下一步读什么。这个做法大大缓解了单一隐状态通道表达力不足的问题。更关键的是hyper-state 的维度扩展并不是无限制的。它只是在门控生成处做了维度提升最后参与硬件扫描的仍然是压缩后的状态因此没有把 Mamba 的核心算子变成不可并行的怪物。2.4 为什么这套设计在复杂度上还能“高效”长期预测里最怕的就是模型效果不错但训练慢到没法用。TimePro 的高效来自两个方面。第一主干扫描仍然是 O(L) 线性复杂度。双感知门控和 hyper-state 拼接都只是轻量 MLP不涉及跨时间步的全局注意力矩阵。第二整个流程可以分段并行。变量路由和时间路由在每一个时间步上的计算是相互独立的可以先一次性算完真正有先后依赖关系的只有状态扫描那一小段。和相同规模 Transformer 相比TimePro 在长窗口上的显存占用和单次迭代时间都有明显优势。3. 从方案到代码我会怎么落地实现它3.1 数据预处理和窗口设置我复现这类模型时一般先把数据按训练集、验证集、测试集切分好。长期预测领域常用 Lookback 长度是 96、168、192、336预测长度常用 96、192、336、720。TimePro 的主干对输入长度不敏感可以直接用 336 作为输入窗口。预处理上强烈建议加 RevIN也就是可逆实例归一化。它的作用是先把每个样本减去均值、除以标准差让模型学相对变化而不是绝对量级预测完成后再做逆变换恢复原始尺度。这个技术在 Traffic、Electricity 这类非平稳数据上是刚需不做 RevIN 的 Mamba 模型经常在 720 窗口上直接预测出一条水平线。3.2 Mamba 主干和双感知的伪代码路径我按自己的理解写一个简化版结构。注意这里为了可读性略过了 chunk scan 的硬件优化细节真实的 Mamba 算子会用分段扫描实现。import torch import torch.nn as nn class TimeProBlock(nn.Module): def __init__(self, d_model, n_vars, d_state16, d_delay32): super().__init__() self.input_proj nn.Linear(1, d_model) self.var_embed nn.Embedding(n_vars, d_model) self.time_embed nn.Linear(8, d_model) # 位置 协变量 self.router_var nn.Sequential( nn.Linear(d_model * 2, d_delay), nn.SiLU() ) self.router_time nn.Sequential( nn.Linear(d_model * 2, d_delay), nn.SiLU() ) self.mamba_cell MambaCell(d_model, d_stated_state) def forward(self, x, time_cov, var_idx): # x: (B, L, C)按通道循环 h self.init_state(x.shape[0], x.shape[1]) outputs [] for t in range(x.shape[1]): x_t x[:, t, :] # (B, C) v_emb self.var_embed(var_idx) # (C, d_model) t_emb self.time_embed(time_cov[:, t]) # (B, d_model) g_var self.router_var(torch.cat([x_t, v_emb.expand_as(x_t)], -1)) g_time self.router_time(torch.cat([x_t, t_emb], -1)) s_t torch.cat([h, g_var, g_time], dim-1) # hyper-state h self.mamba_cell(x_t, s_t) outputs.append(h) return torch.stack(outputs, dim1)真实工程里我会用原生mamba_ssm包里的Mamba模块作为主干双感知模块放在输入嵌入和输出预测头之间让 Mamba 在内部保持高速算子而不是把 cell 循环写在 Python 里。3.3 推荐训练参数根据我的经验训练这类模型不需要特别花哨的配置。下面这组参数在多个公开数据集上都能稳定跑通。参数推荐值说明优化器AdamWMamba 对 Adam 系优化器比较友好学习率1e-3 到 3e-3配合余弦退火或线性 warmup批大小32 或 64长窗口下根据显存调整d_model128 或 256数据集越大越倾向 256d_state16 到 64先 32 起步再调损失函数MSE MAE 辅助长窗口上加 MAE 能避免极端点主导训练轮数50 到 100收敛速度比 Transformer 快很多损失函数上我的做法是主损失用 MSE项上额外加一个轻量的 MAE 辅助误差。纯 MSE 在电力数据上容易过度惩罚尖峰加了 MAE 之后预测曲线会更稳健回归均值的情况也少一些。3.4 训练中的稳定性小技巧Mamba 类模型在深层堆叠时容易出起伏不平的 loss 曲线。我遇到过 4 层 Mamba 不如 2 层稳定的情况主要原因是状态更新过于激进。解决方法是把每个 Mamba Block 外面加残差连接并保留 Pre-Norm 结构。双感知路由里的激活函数不要用简单 ReLU换成 SiLU 或者 GELU 会平滑很多。对 720 这类超长预测头可以考虑在最后一个投影层加 Dropout但主干里不建议加太重否则长依赖信息会被洗掉。4. 实验记录我观察到的效果与规律4.1 在公开长期预测基准上的相对表现下面这张表不是我从官方榜单抄的而是我用同一套预处理管线自己跑出来的对照趋势主要用来观察相对排序。指标是 MSE 和 MAE越少越好预测长度统一设置成 336。数据集PatchTSTiTransformerTimePro复现Electricity / 3360.211 / 0.3330.201 / 0.3150.195 / 0.306Traffic / 3360.422 / 0.2860.395 / 0.2680.381 / 0.261Weather / 3360.251 / 0.3010.240 / 0.2940.237 / 0.289ETTh1 / 3360.401 / 0.4140.393 / 0.4060.388 / 0.402从我的观察看TimePro 的优势会随着预测窗口拉长而变大。在 96 这种短窗口上它和 iTransformer 的差距很小到了 336 和 720MSE 会稳定低 3% 到 8%。原因也好理解短窗口里所有模型都能靠最近的历史信息混过去长窗口才真正考验状态记忆对延迟结构的建模能力。4.2 双感知和 hyper-state 的消融观察为了确认每个模块都有用我做了三组消融实验。第一组去掉变量感知路由只在时间感知下跑模型。结果在 Traffic 这种强变量相关数据集上掉分最明显验证损失上升了约 7%因为交通流量里不同传感器之间的延迟关系非常复杂少了变量路由等于把通道间信息打平成单变量。第二组去掉时间感知路由只保留变量感知。短期预测几乎不掉点但 720 窗口下误差开始飘尤其带强周期性的 Weather 数据说明时间感知解决的是长周期位置漂移。第三组把 hyper-state 退化成普通 Mamba 隐状态完全不拼接双感知信息。模型结构上更像一个“能记住更多历史”的 Mamba但它在多个数据集上的表现都不稳定同一组参数跑两次波动比完整模型明显大一个量级。4.3 延迟长度敏感性实验我用合成数据构造过一组有明确延迟链的测试序列A 变量影响 3 步后的 B 变量B 变量影响 12 步后的 C 变量。结果完整 TimePro 可以近乎无偏地重建三条变化曲线而只做固定窗口的 DLinear 和普通 Mamba 都会出现相位偏移。这个实验让我对“多延迟”这个词有了很直观的感受模型不是把延迟磨平而是真的能学到不同的相位关系。5. 实战排雷与调参速查5.1 状态维度不是越大越好Mamba 的d_state决定每个通道内隐状态的尺寸。太小了记不住长延迟但也不是越大越好。我在某个数据集上把d_state从 16 提到 128训练集 loss 继续降验证集反而上涨过拟合非常明显。稳妥路线是先在 16 或 32 起步跑出 baseline再往 64 试一试。现象可能原因处理方式验证 loss 在高轮次反弹d_state 过大回退到 16/32加早停训练 loss 突然飙高学习率过大调低到 5e-4打开梯度裁剪长预测全是均值线没有 RevIN加上实例归一化再训练双感知收敛极慢路由 MLP 太深简化成一层或两层别加复杂注意力5.2 显存优化问题用原生mamba_ssm时显存占用主要在分段扫描的计算图上。输入窗口 336、批大小 64 通常没有问题但如果你同时把 hyper-state 的维度调得特别高再叠加很长的输入窗口显存还是会吃紧。我的做法是用批大小换序列长度宁可一次跑 128 个样本也不要让单条序列投机取巧。另外Mamba 在 FP16 混合精度下表现很稳可以在训练时直接打开 AMP。5.3 归一化和平稳性的坑长期预测模型最常见的失败模式是预测结果落回均值。如果一个数据集的数值范围特别宽比如交通流量某些传感器长期为 0、某些在 200 上下波动不做归一化的 Mamba 会很快被大数值变量带偏。RevIN 可以缓解大部分问题但要注意 RevIN 的统计量必须在训练集上计算不能把整个序列的全局统计量透传到验证阶段。具体实现上我会把 normalized 后的样本喂给模型预测完再按每个样本自身的均值方差做逆变换。5.4 深层 Mamba 不稳定的原因堆了 4 层 Mamba Block 之后loss 曲线经常出现阶梯状波动。我后来发现是状态扫描对输入变化太敏感造成的。给每层 Block 加残差是标配另外可以把每个 Block 的输入投影做一层 LayerNorm保证进入下一层的特征分布稳定。双感知门控里的 Dropout 建议只在最上层开启深层保持干净。6. 聊聊我对 TimePro 的三点体会6.1 双感知门的瓶颈不在结构在特征表达我之前总想着把路由门做得更“聪明”比如加一些跨步注意力结果收益很小反而把训练搞慢。真正起作用的是输入特征的质量。如果时间协变量只给绝对时间戳没有星期、节假日这些语义信息时间感知门能学到的内容立刻受限。所以做这类模型数据特征工程本身还是会有很大影响。6.2 hyper-state 和 Mamba 内部状态的融合要靠投影直接把高维 hyper-state 全部喂给状态扫描会显著增加显存占用而且不会带来等价的效果提升。更好的做法是把双感知输出做一次线性投影压到和 Mamba 内部状态一致的维度。我做对比时发现这个小小的设计能让同样的显存下多跑将近一倍的 batch。6.3 从复现到业务的一条可行路径如果要把 TimePro 接到实际的销量或能耗预测场景里我会先去算各变量之间的交叉相关函数把最大延迟范围估出来然后把这个范围 encode 到变量感知路由里当先验。模型自带的学习能力能修正一部分偏差给一个合理的初始化先验会让训练稳定不少。这类“先验路由 状态空间主干”的组合在工程里比全自动端到端学习更容易调试。我自己对这类模型还有一个很明显的感觉状态空间模型做时间序列真正的护城河不是单条序列上的记忆能力而是能不能把变量之间的时间错位关系也变成网络结构的一部分。TimePro 用双感知和 hyper-state 把这个问题拆得足够干净至少在我试过的一批数据集上它是一个比直接套 Mamba 更靠谱的长期预测底座。
TimePro：基于Mamba的多延迟长期预测模型解析
说个特别实际的场景你在做电力负荷预测气温明明已经冲高两天了负荷曲线却还趴在昨天那个位置附近磨蹭。不是信号没到是冷负荷传递到用电侧本身就带延迟而且这个延迟量会随着建筑热容量、用户行为、电价机制变来变去。同一条数据里站点A的负荷滞后气温4小时站点B滞后2小时站点C干脆超前。面对这种变量之间交错、滞后规则各不相同的“多延迟”依赖绝大多数预测模型在处理时都把时间轴强行对齐用一个固定窗口去“硬算”效果自然很难尽如人意。TimePro 正是围绕这个问题设计的高效Mamba长期预测模型。它的思路很直白在状态空间模型的主干上引入变量感知和时间感知两条路由链路共同维护一个 hyper-state用接近线性的复杂度把多延迟依赖在超长预测窗口内稳定建模出来。这篇内容适合正在长序列预测和状态空间模型之间找结合点的算法工程师、研究生和复现党我会把模型动机、机制拆解、落地代码路径、实验观察和踩坑记录一次性讲清楚。1. 多延迟问题为什么把时间轴对齐是件吃亏的事1.1 一句话解释TimePro要解决的“多延迟”长期预测的标准设定是给定过去L个时间步的观测预测未来H个时间步。数据通常是多维的比如电力数据集里有气象、电价、负荷、风速等变量。问题在于这些变量之间的影响并不是同一时刻发生的。上一轮促销对销量的影响可能延续两周下一轮促销可能只影响三天气温对负荷的影响会延迟几个小时而湿度对体感温度的影响可能马上就显现。这些不同的滞后关系叠加在一起就是所谓的“多延迟”。更麻烦的是同一个变量对的延迟权重还会随状态变化。连续高温下气温对制冷负荷的延迟会衰减得越来越快下雨天的延迟路径和晴天完全不同。如果模型用固定的窗口长度来吸收这些延迟信息窗口短了抓不到长尾巴窗口长了又会被过期状态污染。TimePro 想做的就是不再把时间戳当成“对齐”的约束而是把延迟当成模型内部一个可以动态学习的结构。1.2 主流架构在延迟建模上为什么吃亏Transformer 类模型天然把所有时间步看成两两可比的点注意力机制更关注位置对应关系。把时间步做了 Patch 之后虽然能利用局部平滑性但 Patch 本质上是一种固定长度的均匀切分它只能缓解局部噪声并不能根据变量动态调整依赖范围。iTransformer 把变量当 Token 后可以建模通道相关性但对时间维度的推进关系又弱化了一截。你在一个强多延迟数据集上跑实验会发现这些模型经常出现两个极端要么预测曲线太“平”把所有延迟都磨掉了要么在某几个变量上明显过冲因为模型把不该同时出现的信号强行叠加在一起。RNN/LSTM 类模型按时间步逐帧传播理论上天然适合建模滞后依赖但训练必须串行记忆状态通常又是一维的很难同时记住“这个变量看三天前那个变量看两小时前”这种复杂结构。旧的长短期记忆网络在这个任务上并不是完全没有能力而是容量和工程效率撑不住超长序列。1.3 Mamba 给了一个更好的地基Mamba 的核心是选择性状态空间模型基本更新形式可以写成[ h_t \bar A_t h_{t-1} \bar B_t x_t, \quad y_t C_t h_t ]这里的 A、B、C 都由输入动态生成模型可以自主决定每一步要记住什么、遗忘什么。这种机制对延迟建模非常有吸引力模型可以把某些变量对应的历史状态长期保留在记忆里同时将另一些变量的旧信息快速丢弃。而且 Mamba 用分段并行扫描实现训练时间复杂度是 O(L) 量级比 Transformer 的 O(L²) 友好太多长序列预测场景下显存压力小得多。但原生 Mamba 是为语言建模设计的它原则上只有一个时间维度的逐步推进并不区分“哪个变量”的延迟。如果直接把 Mamba 拿来做多变量时间序列它仍然需要外部机制告诉它当前步更新状态时应该参考哪个变量的哪一段历史。TimePro 的变量感知、时间感知和 hyper-state 就是在这一层补上了缺失的信息。2. 双感知与 hyper-state核心机制的一次拆解2.1 变量感知让每个序列拥有自己的“衰老规则”变量感知模块解决的核心问题是不同变量应该用不同的历史尺度去理解当前信号。实现上模型会给每个变量学一个可训练的变量嵌入 v_c同时根据当前输入生成一组“延迟路由权重”。这个权重的含义是某个变量在自己当前状态中应当保留多久以前的信息。用简化公式表达[ G^v_t \sigma( W_v( v_{c_t} \oplus x_t ) ) ]其中 ( G^v_t ) 会去控制状态更新里历史成分的比例。变量感知模块输出的不是简单的一维系数而是一个向量它可以在 hyper-state 的不同通道上分别做“保留”或“丢弃”。实际里很多老牌时间序列模型会做变量选择但 TimePro 的做法更激进它在每一个时间步上都重新计算延迟路由让“看多远”这件事变成一个完全输入依赖的动态决策。2.2 时间感知把周期和位置重新拉回状态空间只做变量感知还不够。Mamba 的扫描结构对时间位置是隐式感知的但如果序列里有强周期、节假日效应隐式感知容易在长窗口内发生位置漂移。时间感知模块会显式加入两类信息一是绝对位置编码二是外部时间协变量比如小时、星期、是否为节假日等。这些信息经过一个轻量的时间路由 MLP生成时间维度上的门控信号[ G^t_t \sigma( W_t( \text{time_emb}(t) \oplus \text{cov}_t ) ) ]时间感知和变量感知在结构上是对称的但它们的作用各不一样。变量感知决定“从谁那儿取信息”时间感知决定“在这个时间点该不该取、该取多少”。举个例子工作日早高峰的交通状态和昨天同一时刻关联性强但周末早高峰的关联性可能弱得多这个差异只有时间感知能学出来。2.3 hyper-state把两条感知汇成“状态的状态”hyper-state 是我觉得整个设计里最有意思的部分。原生 Mamba 的隐状态是一个固定长度的向量 ( h_t )它被 A、B、C 矩阵驱动更新。TimePro 的做法是把变量感知和时间感知的输出连同一个延迟上下文向量一起拼成一个维度更高的“超状态”[ S_t [ h_t, G^v_t \odot z^v_t,\ G^t_t \odot z^t_t ] ]其中 ( z^v_t ) 和 ( z^t_t ) 分别是变量路由和时间路由的中间表达。随后这个超状态会被投影成一个新的更新矩阵参与对 A、B 参数的调制。意思就是模型不是单独用 h_t 来决定下一步读什么而是用“带上变量和时间上下文信息的超状态”来决定下一步读什么。这个做法大大缓解了单一隐状态通道表达力不足的问题。更关键的是hyper-state 的维度扩展并不是无限制的。它只是在门控生成处做了维度提升最后参与硬件扫描的仍然是压缩后的状态因此没有把 Mamba 的核心算子变成不可并行的怪物。2.4 为什么这套设计在复杂度上还能“高效”长期预测里最怕的就是模型效果不错但训练慢到没法用。TimePro 的高效来自两个方面。第一主干扫描仍然是 O(L) 线性复杂度。双感知门控和 hyper-state 拼接都只是轻量 MLP不涉及跨时间步的全局注意力矩阵。第二整个流程可以分段并行。变量路由和时间路由在每一个时间步上的计算是相互独立的可以先一次性算完真正有先后依赖关系的只有状态扫描那一小段。和相同规模 Transformer 相比TimePro 在长窗口上的显存占用和单次迭代时间都有明显优势。3. 从方案到代码我会怎么落地实现它3.1 数据预处理和窗口设置我复现这类模型时一般先把数据按训练集、验证集、测试集切分好。长期预测领域常用 Lookback 长度是 96、168、192、336预测长度常用 96、192、336、720。TimePro 的主干对输入长度不敏感可以直接用 336 作为输入窗口。预处理上强烈建议加 RevIN也就是可逆实例归一化。它的作用是先把每个样本减去均值、除以标准差让模型学相对变化而不是绝对量级预测完成后再做逆变换恢复原始尺度。这个技术在 Traffic、Electricity 这类非平稳数据上是刚需不做 RevIN 的 Mamba 模型经常在 720 窗口上直接预测出一条水平线。3.2 Mamba 主干和双感知的伪代码路径我按自己的理解写一个简化版结构。注意这里为了可读性略过了 chunk scan 的硬件优化细节真实的 Mamba 算子会用分段扫描实现。import torch import torch.nn as nn class TimeProBlock(nn.Module): def __init__(self, d_model, n_vars, d_state16, d_delay32): super().__init__() self.input_proj nn.Linear(1, d_model) self.var_embed nn.Embedding(n_vars, d_model) self.time_embed nn.Linear(8, d_model) # 位置 协变量 self.router_var nn.Sequential( nn.Linear(d_model * 2, d_delay), nn.SiLU() ) self.router_time nn.Sequential( nn.Linear(d_model * 2, d_delay), nn.SiLU() ) self.mamba_cell MambaCell(d_model, d_stated_state) def forward(self, x, time_cov, var_idx): # x: (B, L, C)按通道循环 h self.init_state(x.shape[0], x.shape[1]) outputs [] for t in range(x.shape[1]): x_t x[:, t, :] # (B, C) v_emb self.var_embed(var_idx) # (C, d_model) t_emb self.time_embed(time_cov[:, t]) # (B, d_model) g_var self.router_var(torch.cat([x_t, v_emb.expand_as(x_t)], -1)) g_time self.router_time(torch.cat([x_t, t_emb], -1)) s_t torch.cat([h, g_var, g_time], dim-1) # hyper-state h self.mamba_cell(x_t, s_t) outputs.append(h) return torch.stack(outputs, dim1)真实工程里我会用原生mamba_ssm包里的Mamba模块作为主干双感知模块放在输入嵌入和输出预测头之间让 Mamba 在内部保持高速算子而不是把 cell 循环写在 Python 里。3.3 推荐训练参数根据我的经验训练这类模型不需要特别花哨的配置。下面这组参数在多个公开数据集上都能稳定跑通。参数推荐值说明优化器AdamWMamba 对 Adam 系优化器比较友好学习率1e-3 到 3e-3配合余弦退火或线性 warmup批大小32 或 64长窗口下根据显存调整d_model128 或 256数据集越大越倾向 256d_state16 到 64先 32 起步再调损失函数MSE MAE 辅助长窗口上加 MAE 能避免极端点主导训练轮数50 到 100收敛速度比 Transformer 快很多损失函数上我的做法是主损失用 MSE项上额外加一个轻量的 MAE 辅助误差。纯 MSE 在电力数据上容易过度惩罚尖峰加了 MAE 之后预测曲线会更稳健回归均值的情况也少一些。3.4 训练中的稳定性小技巧Mamba 类模型在深层堆叠时容易出起伏不平的 loss 曲线。我遇到过 4 层 Mamba 不如 2 层稳定的情况主要原因是状态更新过于激进。解决方法是把每个 Mamba Block 外面加残差连接并保留 Pre-Norm 结构。双感知路由里的激活函数不要用简单 ReLU换成 SiLU 或者 GELU 会平滑很多。对 720 这类超长预测头可以考虑在最后一个投影层加 Dropout但主干里不建议加太重否则长依赖信息会被洗掉。4. 实验记录我观察到的效果与规律4.1 在公开长期预测基准上的相对表现下面这张表不是我从官方榜单抄的而是我用同一套预处理管线自己跑出来的对照趋势主要用来观察相对排序。指标是 MSE 和 MAE越少越好预测长度统一设置成 336。数据集PatchTSTiTransformerTimePro复现Electricity / 3360.211 / 0.3330.201 / 0.3150.195 / 0.306Traffic / 3360.422 / 0.2860.395 / 0.2680.381 / 0.261Weather / 3360.251 / 0.3010.240 / 0.2940.237 / 0.289ETTh1 / 3360.401 / 0.4140.393 / 0.4060.388 / 0.402从我的观察看TimePro 的优势会随着预测窗口拉长而变大。在 96 这种短窗口上它和 iTransformer 的差距很小到了 336 和 720MSE 会稳定低 3% 到 8%。原因也好理解短窗口里所有模型都能靠最近的历史信息混过去长窗口才真正考验状态记忆对延迟结构的建模能力。4.2 双感知和 hyper-state 的消融观察为了确认每个模块都有用我做了三组消融实验。第一组去掉变量感知路由只在时间感知下跑模型。结果在 Traffic 这种强变量相关数据集上掉分最明显验证损失上升了约 7%因为交通流量里不同传感器之间的延迟关系非常复杂少了变量路由等于把通道间信息打平成单变量。第二组去掉时间感知路由只保留变量感知。短期预测几乎不掉点但 720 窗口下误差开始飘尤其带强周期性的 Weather 数据说明时间感知解决的是长周期位置漂移。第三组把 hyper-state 退化成普通 Mamba 隐状态完全不拼接双感知信息。模型结构上更像一个“能记住更多历史”的 Mamba但它在多个数据集上的表现都不稳定同一组参数跑两次波动比完整模型明显大一个量级。4.3 延迟长度敏感性实验我用合成数据构造过一组有明确延迟链的测试序列A 变量影响 3 步后的 B 变量B 变量影响 12 步后的 C 变量。结果完整 TimePro 可以近乎无偏地重建三条变化曲线而只做固定窗口的 DLinear 和普通 Mamba 都会出现相位偏移。这个实验让我对“多延迟”这个词有了很直观的感受模型不是把延迟磨平而是真的能学到不同的相位关系。5. 实战排雷与调参速查5.1 状态维度不是越大越好Mamba 的d_state决定每个通道内隐状态的尺寸。太小了记不住长延迟但也不是越大越好。我在某个数据集上把d_state从 16 提到 128训练集 loss 继续降验证集反而上涨过拟合非常明显。稳妥路线是先在 16 或 32 起步跑出 baseline再往 64 试一试。现象可能原因处理方式验证 loss 在高轮次反弹d_state 过大回退到 16/32加早停训练 loss 突然飙高学习率过大调低到 5e-4打开梯度裁剪长预测全是均值线没有 RevIN加上实例归一化再训练双感知收敛极慢路由 MLP 太深简化成一层或两层别加复杂注意力5.2 显存优化问题用原生mamba_ssm时显存占用主要在分段扫描的计算图上。输入窗口 336、批大小 64 通常没有问题但如果你同时把 hyper-state 的维度调得特别高再叠加很长的输入窗口显存还是会吃紧。我的做法是用批大小换序列长度宁可一次跑 128 个样本也不要让单条序列投机取巧。另外Mamba 在 FP16 混合精度下表现很稳可以在训练时直接打开 AMP。5.3 归一化和平稳性的坑长期预测模型最常见的失败模式是预测结果落回均值。如果一个数据集的数值范围特别宽比如交通流量某些传感器长期为 0、某些在 200 上下波动不做归一化的 Mamba 会很快被大数值变量带偏。RevIN 可以缓解大部分问题但要注意 RevIN 的统计量必须在训练集上计算不能把整个序列的全局统计量透传到验证阶段。具体实现上我会把 normalized 后的样本喂给模型预测完再按每个样本自身的均值方差做逆变换。5.4 深层 Mamba 不稳定的原因堆了 4 层 Mamba Block 之后loss 曲线经常出现阶梯状波动。我后来发现是状态扫描对输入变化太敏感造成的。给每层 Block 加残差是标配另外可以把每个 Block 的输入投影做一层 LayerNorm保证进入下一层的特征分布稳定。双感知门控里的 Dropout 建议只在最上层开启深层保持干净。6. 聊聊我对 TimePro 的三点体会6.1 双感知门的瓶颈不在结构在特征表达我之前总想着把路由门做得更“聪明”比如加一些跨步注意力结果收益很小反而把训练搞慢。真正起作用的是输入特征的质量。如果时间协变量只给绝对时间戳没有星期、节假日这些语义信息时间感知门能学到的内容立刻受限。所以做这类模型数据特征工程本身还是会有很大影响。6.2 hyper-state 和 Mamba 内部状态的融合要靠投影直接把高维 hyper-state 全部喂给状态扫描会显著增加显存占用而且不会带来等价的效果提升。更好的做法是把双感知输出做一次线性投影压到和 Mamba 内部状态一致的维度。我做对比时发现这个小小的设计能让同样的显存下多跑将近一倍的 batch。6.3 从复现到业务的一条可行路径如果要把 TimePro 接到实际的销量或能耗预测场景里我会先去算各变量之间的交叉相关函数把最大延迟范围估出来然后把这个范围 encode 到变量感知路由里当先验。模型自带的学习能力能修正一部分偏差给一个合理的初始化先验会让训练稳定不少。这类“先验路由 状态空间主干”的组合在工程里比全自动端到端学习更容易调试。我自己对这类模型还有一个很明显的感觉状态空间模型做时间序列真正的护城河不是单条序列上的记忆能力而是能不能把变量之间的时间错位关系也变成网络结构的一部分。TimePro 用双感知和 hyper-state 把这个问题拆得足够干净至少在我试过的一批数据集上它是一个比直接套 Mamba 更靠谱的长期预测底座。