Mamba这个名字做序列建模的人应该都不陌生。2024年它几乎成了“Transformer替代者”话题里曝光率最高的模型之一各种论文都在往Mamba上靠。但做时间序列预测的人心里大概率会有一个更务实的疑问Mamba的声势再大真的对时序预测有效吗这篇论文的标题恰好就问出了这个问题——Is Mamba Effective for Time Series Forecasting?这篇论文不是 Mamba 的宣传稿而是一次系统性的评估。作者团队在多个真实数据集上把 Mamba 和几类有代表性的预测模型放在同一个框架下做了对比还专门设计了三组敏感性实验回答三个非常关键的问题位置信息对 Mamba 到底有多重要状态维度设置影响有多大训练长度和推理长度不一致时它还靠不靠谱如果你正在做时间序列预测或者正考虑把 Mamba 引进自己的模型里这篇论文值得花时间细读。它能帮你避开不少隐形的坑也能让你更清醒地意识到一件事Mamba 的“线性复杂度优势”和“对时间序列有效”根本是两回事。1. 这篇论文到底在回答什么问题1.1 Mamba 凭什么被拿来和 Transformer 比先花半分钟聊背景。Transformer 在时序预测上的主要问题来自自注意力机制序列越长注意力矩阵越大计算复杂度是平方级增长。虽然 PatchTST 这类工作通过“切 patch 再跑注意力”降低了 token 数量但本质上还是在吃注意力。Mamba 的思路完全不同。它属于状态空间模型SSM核心操作是“选择性扫描”每个输入 token 经过一个隐藏状态更新。可以用一个极其简化的公式来理解h_t A h_{t-1} B x_t y_t C h_t其中 A、B、C 不是固定的权重而是根据输入动态生成的所以叫“选择性”。直观地说它像一个边走边记笔记的人只把当前最重要的信息写进脑子里不需要回头翻所有走过的路。计算复杂度和序列长度线性相关跟 Transformer 的 O(N²) 自注意力相比确实有吸引力。有人可能会想语言模型里 Mamba 表现不错时序预测不也是序列任务吗换个壳子应该也强。这个想法的漏洞在于时间序列和文本有几个本质差异。文本有明确的词法和语法结构时间序列的“信号”却分散在幅度、频率、趋势、噪声里文本的 token 是离散符号时序数据是连续数值文本任务通常有大规模预训练时序预测大多是从零开始训练。这些差异决定了 Mamba 在 NLP 里的优势未必能简单复制到时序任务上。论文要做的就是把这类理所当然的假设一条条拿去实测。1.2 论文的实验设计思路论文的实验设计很清晰就两条线。第一条线是“对比”。作者把 Mamba 拆成三种配置原始 Mamba、加入位置嵌入的 MambaMambaPE、以及一个增强版本 S-Mamba线性映射 Mamba 块 残差连接。然后拿它们和多个有代表性的基线比包括线性模型、PatchTST、iTransformer 等在多组真实数据集上做评估。第二条线是“剖析”。论文不满足于报告谁赢了而是专门设计了位置敏感性、数值敏感性、长度敏感性三组实验去解释“为什么这个模型会赢在什么条件下会输”。这种“先 PK再拆解”的思路本身就是很好的论文模板。很多人做实验只关心最终排名忽略了结论成立的条件而这篇论文最有价值的地方恰恰就是那些条件。2. 模型配置与评估设置2.1 数据集与预处理论文用了多个公开数据集基本覆盖了常见的时序场景ETT 系列电力变压器温度有 1 小时和 15 分钟两种粒度、Electricity电力负荷、Traffic交通占用率、Exchange汇率、Weather气象、Solar-Energy太阳能等。这些数据集有周期性强弱之分、通道数多少之分、噪声水平高低之分预测长度一般取 96、192、336、720 这几个档位属于长时预测任务比较标准的设置。为什么选这些数据集因为它们干净、公开、对比公平而且跨度够大。从 15 分钟颗粒度的 ETT 到 1 小时颗粒度的 Weather再到带大量相关通道的 Traffic基本把时序预测里最常见的形态都覆盖了。这里有一个容易被忽略的点数据集通道数差异极大。比如 ETTh1 只有 7 个通道Traffic 却有 862 个通道。通道数的差异会影响模型对“跨通道依赖”的建模方式也会直接影响 Mamba 以 token 方式处理输入时的效率和效果。数据集特点与 Mamba 评估相关的点ETTh1 / ETTm1变压器油温周期性强适合观察位置敏感性和周期特征Electricity电力负荷通道多趋势 周期高通道数下对多变量建模能力Traffic交通占用率通道数多大规模通道、强周期模式Exchange汇率非平稳性强数值尺度变化对模型的冲击Weather气象多通道噪声多多尺度模式混合Solar-Energy太阳能功率夜间接近零动态范围大2.2 基线模型与实现细节论文选择基线的标准是“代表不同类型”而不是“所有能跑的模型都来一遍”。几个关键基线刚好代表四条技术路线DLinear / NLinear极简线性层。它们在近两年证明了“复杂模型在时序预测上没那么神”是很好的参考基准。PatchTST基于 Transformer用 patch 降低 token 数量在长时预测上表现出色。iTransformerTransformer 的改进版把注意力的维度从时间步换到变量维度专门强化多变量相关性建模。Mamba 这边论文用了三种设置一是“裸 Mamba”直接把 patch 后的 token 序列喂给 Mamba 层不加任何位置信息二是“Mamba PE”在 patch token 上加入可学习位置编码三是“S-Mamba”先做线性投影再进 Mamba 块用残差连接最后通过线性层把隐藏表示映射到预测窗口。这里有一个需要特别留意的细节Mamba 在架构上天然不依赖绝对位置编码因为它通过顺序扫描隐性记住了输入次序。但时序预测里的“位置”不只是顺序它还承载着“离预测点越近的信息越重要”这种先验知识。所以位置编码在时序任务里不是可有可无的装饰论文后面的敏感性实验会专门证明这一点。2.3 评价指标与统计口径论文使用 MSE 和 MAE 两个常规指标最终结论基于“平均排名”。平均排名的含义是在每个数据集、每个预测长度下把模型按 MSE 从小到大排序再取所有配置下的平均名次。这样做比只看一两个数据集更能反映整体稳定性也避免“在某个数据集上刷出极低 MSE其他数据集全部崩掉”的情况。这里值得多说一句公平性。时序预测论文的对比很容易不公平不同模型的参数量不一样patch 长度不一样训练轮数不一样。论文采用统一复现框架把各模型的 patch 长度、batch size、学习率等尽量对齐同时保留每个模型的最佳配置搜索。这种处理方式很务实。完全统一所有超参反而会误伤某些模型完全自由搜索又会让对比失去意义。按“保持兼容 小范围搜索”来平衡是比较合理的实验策略。3. 三组敏感性实验Mamba 到底稳不稳3.1 位置敏感性把输入 token 顺序打乱会怎样我读这篇论文时觉得最有趣的实验就是位置敏感性。做法很简单把输入序列切成 patch 后随机打乱 patch 之间的顺序再喂给模型做预测。如果模型的预测结果没有明显变化说明它对顺序信息不敏感如果预测结果大幅恶化说明顺序信息很重要。结果非常明确打乱顺序后Mamba 的性能明显下降尤其是单变量预测。这说明“Mamba 不需要位置编码”这个说法在时间序列任务上要打折扣。Mamba 虽然通过递归扫描记住了顺序但它对“哪个 token 离预测点更近”这种重要性权重的建模仍然需要额外位置信号的配合。加入位置嵌入之后Mamba 在单变量场景的预测误差明显降低。而在多变量高通道数据集上位置编码的作用会弱一些因为多变量场景的主要增益来自跨通道交互而不是时间顺序本身的编码。实操上的启发是如果你的数据通道少、序列长度中等直接使用“裸 Mamba”可能有风险建议加上可学习位置编码或者直接使用 S-Mamba 这种带线性投影的结构。3.2 数值敏感性状态维度与数值精度第二个敏感性实验盯的是 Mamba 的核心参数——状态维度也就是状态空间模型里隐藏状态向量的维度一般用 d_state 表示。论文实验表明提高 d_state 通常能带来一致的性能提升。原因不难理解更大的状态空间可以记住更多历史模式相当于把“小笔记本”换成“更厚的笔记本”。但代价同样现实。更大的 d_state 会让计算量和显存占用上升训练速度明显下降。结合论文的观察和复现经验在常规长序列数据集上d_state 设为 16 到 32 之间是性价比比较高的区间再往上涨对精度的边际收益就很低效率损失却不小。另一个容易踩坑的点是数值精度。Mamba 的实现依赖顺序扫描里面的矩阵运算是逐时间步递推的无法像 Transformer 那样把整条序列的注意力一起并行。在 fp16 或 bf16 混合精度训练下长序列的误差累积会更明显可能出现 loss 不降、预测输出全部变成常数的现象。我在复现时就遇到过类似情况。解决办法是让关键层维持 fp32或者直接使用带融合内核的实现不要用朴素的循环版本去做长序列实验。3.3 数据长度敏感性训练短预测长还灵吗长时预测里经常出现“训练时用的历史窗口比较短推理时却要处理更长的输入”的情况。论文专门测了长度外推固定一个训练输入长度测试时改成更长或更短的输入长度观察哪些模型能扛住。结果很直接Mamba 对这种长度不匹配非常敏感。训练长度和推理长度一致时性能正常一旦推理时把输入序列拉长误差显著上升不如线性模型和 Transformer 那样有一定外推能力。用一句话概括这个现象Mamba 的状态容量在设计时就适配了训练时的序列长度遇到更长的输入状态会被“撑破”没法自然延展。这个结论直接影响使用场景选择。如果你的生产环境里历史窗口经常变化Mamba 可能需要重新训练或者要在输入侧做额外处理。反之如果训练推理阶段的输入长度和预测长度都是固定的这个缺点就不再是问题长序列场景反而能发挥它的复杂度优势。4. 结果综述与关键结论4.1 总体取胜平均第一但不是全面碾压论文报告了各模型在多个数据集、多个预测长度下的 MSE / MAE 与平均排名。大致来看S-Mamba 在总平均排名上是最好的MambaPE 次之裸 Mamba 也能排到中上但优势在不同的数据集上并不一致。我按论文代表性结果整理了一张粗略对比表数字是约值具体以原文为准数据集 / 预测长度DLinearPatchTSTiTransformerS-MambaETTh1-720 MSE0.430.410.390.39Electricity-96 MSE0.200.190.170.17Traffic-96 MSE0.420.390.370.36单看这个表可能觉得差距不大但趋势是对的Mamba尤其是 S-Mamba在多数长序列预测任务上能拿到靠前的名次优势主要体现在 720 这种长预测长度上。在 96 这种短预测长度上它和 iTransformer 的差距经常很小甚至偶尔会输给 DLinear 这类线性模型。一个更值得关注的细节是“胜出幅度”不够大。很多数据集上 S-Mamba 只比第二名低 0.005 左右的 MSE这种差距在工程上基本等于没有。所以 Mamba 的现实定位不是“完全碾压 Transformer”而是“在长序列、大复杂度场景下线性复杂度给了它更好的性价比”。4.2 摘要级别的三大操作建议论文把实验经验浓缩成了三个实操建议可以直接抄作业使用更小的 patch 长度。PatchTST 默认 patch_len 是 16但在 Mamba 上减小到 8 甚至 4 往往能带来明显提升。原因是更小的 patch 让 Mamba 能更细致地感知局部数值变化而 Mamba 不像 Transformer 那样必须靠大 patch 来节省注意力开销它天然就便宜。适当增大状态维度 d_state。从默认的 8 或 16 提升到 32能改善预测性能但别无限提升要注意算力成本和训练速度。单变量预测务必加位置编码。多变量场景可以优先考虑 S-Mamba 的结构用线性投影来补足 Mamba 对输入分布的感知能力。这三条建议操作成本几乎为零。很多人做 Mamba 时序预测时默认沿用 Transformer 的那套参数结果效果不好就归咎于模型实际上只是超参没有适配。4.3 和其他热点工作的关系论文还顺带讨论了一个经常引发争议的话题为什么有些人报告 Mamba 在时序预测上不如线性模型核心在于“token 化”方式。如果你把完整的原始序列直接塞给 Mamba它会很难捕捉局部模式如果你像 PatchTST 一样先把序列切成 patch再进入模型Mamba 才能真正发挥线性扫描的优势。甚至可以说Mamba 的 patch 策略比 Transformer 更关键。这个观点和不少社区复现失败的案例是吻合的。很多人换模型效果差问题不出在 Mamba 本身而是输入格式压根没有设计对。论文把“tokenization is critical”这个结论摆到台面上对后续研究有很强的指导意义。5. 论文没讲透的部分和我的复现体会5.1 训练开销并没有想象中便宜读论文之前我对 Mamba 的印象是“注意力是线性的所以一定很快”。但实际复现后我发现Mamba 的“快”主要体现在理论复杂度上不等于训练时间一定短。由于它的扫描机制是逐时间步递推的无法像 Transformer 这样充分利用高度并行的矩阵乘法在 GPU 上的实际吞吐收益要打折扣。官方实现里用了融合内核之后才真正跑起来如果只依赖原生 PyTorch 循环实现长序列训练往往会非常痛苦。所以我的建议是如果只是做基线对比而不是为了验证 Mamba 理论本身最好直接用官方提供的融合实现别自己造轮子。否则你会在数值稳定性和算子优化上浪费大量时间而这些并不是时序建模问题的核心。5.2 位置编码加在哪里论文没有统一答案论文验证了“加位置编码对单变量有效”但没有给出非常细粒度的结论是加在 patch 输入上、加在 Mamba 每层内部、还是只加在输出头不同实现里做法并不统一。我自己复现时倾向于在 patch embedding 之后加一个可学习位置编码效果稳定且实现简单。还有一个很少被提到的话题多变量预测中位置编码是通道共享还是通道独立。如果每个通道共享同一套位置编码参数少、稳定性好如果通道独立表达力更强但参数量成倍增加容易过拟合。论文没有花篇幅展开这个对比但根据经验通道共享版本在大多数数据集上已经够用。5.3 复现结果与官方数字的常见偏差只要做过复现实验大家都懂官方报告的数字很难 100% 复现。硬件环境、数据加载顺序、随机种子、甚至不同 CUDA 内核在 GPU 上产生微小浮点差异都会导致结果波动。在我复现的过程中S-Mamba 的 MSE 和论文报告的数字基本能对上但偏差在 ±0.01 以内。这个量级放在短预测长度上会直接改变排名顺序。所以不要用“复现到小数点后三位一致”来验证论文而应该关注趋势是否一致Mamba 在长序列上是否整体更好、位置敏感性是否出现、patch 长度减小是否改善预测。趋势一致论文的价值就已经得到验证。6. 实操建议把论文结论用到自己的时序项目里6.1 一个可以直接跑的 S-Mamba 骨架基于 mamba-ssm 库我整理了一个极简 S-Mamba 模块用于说明核心结构不是完整训练代码import torch import torch.nn as nn from mamba_ssm import Mamba class S_MambaBlock(nn.Module): def __init__(self, d_model, d_state16, d_conv4, expand2): super().__init__() self.norm nn.LayerNorm(d_model) self.mamba Mamba( d_modeld_model, d_stated_state, d_convd_conv, expandexpand, ) self.linear nn.Linear(d_model, d_model) def forward(self, x): # x: [B, C, N, d_model] B批次, C通道, Ntoken数 B, C, N, D x.shape x x.view(B * C, N, D) out self.mamba(self.norm(x)) x out self.linear(out) return out.view(B, C, N, D)这段代码展示了 S-Mamba 的核心逻辑先 LayerNorm再进 Mamba残差连接后过线性层。实际做预测时你需要先把原始序列 patch 化再把每个通道看成独立的“样本”喂进去最后把最后一层 token 的表示映射到预测长度。整体流程很像 PatchTST但中间的 Transformer Encoder 换成了 Mamba。6.2 参数选择速查我结合论文和复现经验整理了一个快速配置表可以作为项目起点参数推荐值说明patch_len4 ~ 8比 Transformer 常用值更小Mamba 对局部细节更敏感stride1 ~ 4步长越小 token 越多注意控制输入 token 总数d_state16 ~ 32越大记忆越强代价是速度和显存d_conv4局部卷积核宽度一般不用调expand2控制内部隐藏扩展默认 2 即可位置编码单变量用 PE多变量可选单变量收益明显训练精度fp32 或混合精度 关键层 fp32长序列谨慎使用纯 fp16注意这张表是通用起点不是铁律。不同数据集的最佳值会有偏移建议在核心配置附近做小范围搜索。6.3 什么时候别用 Mamba论文读完后我个人对“Mamba 是否有效”的回答是有条件地有效而不是无条件地有效。如果遇到下面几种情况Mamba 未必是首选。第一短序列短预测比如输入 48 步预测 12 步。这种场景下 Transformer 和线性模型的差距不大Mamba 的复杂度优势根本体现不出来反而增加了部署成本。第二需要动态改变历史窗口长度。Mamba 对长度不匹配很敏感推理时随便改输入长度效果可能断崖式下跌。第三算力非常有限只能做 CPU 推理或部署在低功耗设备上。Mamba 的状态扫描算子通常依赖 GPU 生态的优化库在 CPU 上性能远不如预期。第四团队对 Mamba 的算子体系不熟悉也没有时间调数值稳定性问题那先别在核心业务上冒险等周边生态更成熟再说。反过来如果你要做超长历史上下文预测输入长度达到几千甚至上万同时预测窗口也长Mamba 是值得认真对待的选手。这种场景下 Transformer 的平方复杂度会带来很高的推理成本Mamba 的线性扫描会从容很多。7. 两个复现期容易踩的隐藏坑7.1 融合内核与 torch.compile 的冲突平时用 PyTorch 的人可能习惯直接用 torch.compile 来加速训练。但 Mamba 的官方融合内核和 torch.compile 的图优化有时并不兼容可能在运行时报错或者性能反而下降。我建议在使用官方融合实现时先用普通模式跑通一个最小样例再决定是否打开编译优化。如果确实需要加速可以先编译数据加载和 loss 部分把 Mamba 层的编译单独隔开这样风险最低。7.2 padding 对状态更新的污染Mamba 对批次里不同样本的长度非常敏感。如果你的数据加载逻辑里有变长序列并且通过 padding 到固定长度来对齐 batch需要特别注意pad 部分的输入值不要设置成和真实数据分布相近的数否则 Mamba 会把它当作有效信号继续更新状态导致预测被污染。更稳妥的做法是在 padding 的位置对应设置一个 mask避免状态更新操作覆盖到无效 token。这两个坑不算大但在复现和二次开发时出现频率很高。论文本身不会写这类工程细节只有亲手跑过一轮才会意识到“模型有效”和“能顺利复现”之间还隔着不少实现层面的功课。