状态空间模型 vs Transformer：实用指南

Transformer 不会独占鳌头太久了。我知道这话说得有点满。这些年我们眼看着 Transformer 架构从语言模型一路统治到蛋白质折叠等各个领域。但过去几个月，我在生产负载上拿状态空间模型和 Transformer 基线做了大量对比测试，我确信这个转变是真实的。并不是因为 SSM 全方位更强，它们并没有。而是因为它们能解决 Transformer 从根本上搞不定的特定问题，而且最新一代已经把质量差距缩小到了一定程度，现在无视它们，本身就是一笔技术债。

这不是一篇炒作文章。我会讲清楚状态空间模型到底是什么，Mamba-3 在哪些地方确实有提升，SSM 仍然短板明显的地方在哪里，以及你的团队该如何考虑是否采用。咱们就以同行对同行的方式聊。

规模化之下，Transformer 为什么会撞墙

你肯定已经很熟悉二次方复杂度的问题了。自注意力为长度为 N 的序列计算一个 N×N 的矩阵，所以上下文长度翻一倍，计算量和显存就翻四倍。很长一段时间里，这个问题并不突出，模型跑的是几千个 token，硬件也跟得上。

但那个时代已经过去了。我们现在做的工作负载动辄需要 10 万以上 token 的上下文。代码助手需要看到整个代码仓库，多模态流水线要处理数小时的视频，智能体的对话历史可能跨越好几天。在这种规模下，二次方注意力不只是昂贵，而是一堵墙。

KV 缓存问题更让人头疼。在自回归生成过程中，Transformer 的每一层都要为见过的每个 token 存储键值对。这个缓存每层线性增长，很快就会吃光 GPU 显存。我亲眼见过一个 7B 的 Transformer，在 128K 上下文下光 KV 缓存就占了 40GB 显存。这些显存你原本可以用来做更多请求的批处理，现在却动不了。

标准注意力下的二次方显存增长，使百万 token 级上下文几乎不可行
KV 缓存的增长限制了单张 GPU 能同时服务的用户数，在生产环境中直接推高成本
长上下文 Transformer 推理的能耗越来越难以自圆其说
实时应用（机器人、边缘 AI）需要亚毫秒级的 token 生成速度，而注意力机制做不到
“注意力汇聚”现象会导致超长序列上的质量下降，即便你手头的显存绰绰有余

这些都不是纸上谈兵。去年我合作过的三个团队，正是因为这些问题才认真开始评估替代方案。

状态空间模型到底怎么工作

状态空间模型源自控制理论，几十年来一直用于对动态系统建模。核心思想很简单：它不像注意力那样，为计算每个输出去回看每一个历史 token，而是维护一个压缩的隐藏状态，让它随时间演化。新 token 更新状态，状态再产生输出。就这么简单。

从数学上讲，一个 SSM 由四个矩阵 A、B、C 和 D 定义，它们决定隐藏状态 h 如何响应输入 x 而演化。对连续方程做离散化处理后，就得到一个递推式，推理时计算起来非常简单。

import torch
def ssm_step(A_bar, B_bar, C, D, h, x_t):
"""Single SSM step: O(1) memory, O(1) compute.
Compare this to attention, which needs to look at
every previous token. The SSM just updates its state.
"""
h_new = A_bar @ h + B_bar @ x_t  # Update hidden state
y_t = C @ h_new + D * x_t         # Compute output
return h_new, y_t
def ssm_generate(A_bar, B_bar, C, D, tokens, embed):
"""Autoregressive generation with constant memory.
Whether you've processed 100 tokens or 500,000,
this uses the same amount of memory.
"""
h = torch.zeros(A_bar.shape[0])
outputs = []
for t in tokens:
x_t = embed(t)
h, y_t = ssm_step(A_bar, B_bar, C, D, h, x_t)
outputs.append(y_t)
return torch.stack(outputs)

它的精妙之处直接体现在代码里。无论序列多长，推理时每个 token 的显存和计算开销都是 O(1)。没有 KV 缓存，也没有二次方爆炸。整段历史都被压缩进了隐藏状态向量里。

那坏处是什么？训练时如果按顺序执行这个递推，速度会慢到让人崩溃。诀窍在于，同样的计算可以改写成卷积或并行扫描，而 GPU 处理这些操作非常高效。于是你同时获得了并行训练和递归推理，鱼和熊掌兼得。

从 Mamba 到 Mamba-3：每一代修了什么

早期的 SSM，比如 S4，证明了概念可行，但有一个关键短板：基于内容的推理能力很弱。状态转移矩阵对所有输入都是固定的，所以模型无法根据它实际读到的内容来决定记住什么、忘掉什么。这就好比做笔记时只遵循“每三个词记一个”的规则，你确实能记下一些有用信息，却没法根据什么才重要来调整。

Mamba 由 Albert Gu 和 Tri Dao 在 2023 年底提出，它用一个巧妙的思路补上了这个短板：让 SSM 的参数依赖于输入。Mamba 不再使用固定的 A、B、C 矩阵，而是把它们计算为当前 token 的函数。模型因此学会有选择地保存相关信息、丢弃噪声。这种“选择性”机制，让 SSM 具备了之前缺失的内容感知能力。

Mamba-2 带来了一个理论上的洞见：结构化 SSM 与线性注意力在数学上是对偶的，也就是状态空间对偶（SSD）框架。这不只是学术上的漂亮结论，它还催生了感知硬件的实现，能更好地利用 GPU 张量核心，显著提升了训练吞吐。

从部署的角度看，Mamba-3 才真正有意思。其中最关键的三项创新是：

多尺度状态追踪：模型同时在多个时间分辨率上维护状态，既能捕捉局部模式，又能覆盖长程依赖，两者都不必牺牲
自适应状态压缩：隐藏状态会根据内容复杂度动态伸缩，遇到复杂推理段落就扩展，面对可预测文本就收缩，在不损失质量的前提下节省算力
改进的初始化与门控机制：大规模训练的稳定性显著提升，当你为一次训练花费数百万美元时，这一点意义重大

Mamba-3 并不是在每个基准上都能打败 Transformer，它也没必要这么做。它在大多数标准评测上质量与 Transformer 相当，而推理算力只需要其中一小部分。对大多数生产负载来说，这正是真正重要的取舍。

线性注意力与 SSM 的殊途同归

还有一条平行的技术路线值得了解。线性注意力从 Transformer 框架内部入手，解决的是同一个效率问题。标准注意力要计算完整的 N×N 矩阵，线性注意力则用可分解的核函数替代 softmax，再重新整理数学形式，从而永远不需要实例化那个二次方矩阵。

# Standard attention: O(N^2 * d)
# score = softmax(Q @ K.T / sqrt(d)) @ V
# Linear attention: O(N * d^2)
# Replace softmax with kernel feature map phi()
# Rearrange: compute K^T @ V first (d×d), then multiply by Q
def linear_attention_step(q_t, running_kv, running_k, k_t, v_t, phi):
"""Incremental linear attention — runs like a recurrence.
This is why SSMs and linear attention are duals:
both compress history into a fixed-size state.
"""
k_feat = phi(k_t)
q_feat = phi(q_t)
running_kv = running_kv + k_feat.unsqueeze(-1) * v_t.unsqueeze(-2)
running_k = running_k + k_feat
y_t = (q_feat @ running_kv) / (q_feat @ running_k + 1e-6)
return y_t, running_kv, running_k

仔细看看这段代码。线性注意力以增量方式运行时，会维护一个运行中的状态，并随每个新 token 更新它。是不是很眼熟？确实如此，它做的事情本质上和 SSM 一样。SSD 框架把这层联系正式化了，这也是近期序列建模研究中最重要的理论洞见之一。

GLA（门控线性注意力）和 RetNet 的一些变体则更进一步，加入了依赖数据的门控，几乎完全模糊了线性注意力与选择性 SSM 之间的界限。实践上的结论是：别把它们看成互相竞争的路线，它们正在收敛。

混合架构：生产环境里真正跑赢的是什么

每次有团队问我要不要转向 SSM，我都会给同一个建议：别走极端。目前效果最好的架构，是把 SSM 层与少量注意力层混在一起的混合架构。不同的计算原语擅长不同的事情，无视这一点，等于把性能白白丢掉。

SSM 层擅长高效地压缩和传播序列信息，而注意力层在精确的、基于内容的检索上依然无可替代，比如“从第 47 页找出能回答这个问题的那一行”。设计良好的混合架构会在 80% 到 90% 的层中使用 SSM，并在最关键的位置点缀注意力层。

Jamba 风格模型：交替使用 Mamba 层与注意力层，并配以 MoE 前馈模块，动态地在高效的 SSM 处理与精确的注意力之间路由
Griffin 系列设计：循环门控线性单元结合局部滑动窗口注意力，用极少的全局注意力就能取得不错的效果
Mamba-注意力混合：大多数层采用 Mamba-3 模块，并在策略性的深度插入全局注意力层，用于全局信息路由
StripedHyena 的后继者：以 NAS 优化的模式交错使用门控卷积、SSM 层和稀疏注意力

数据也印证了这一点。多个独立团队的研究表明，在相同参数量下，SSM 与注意力按 85/15 的比例混合，可以达到纯 Transformer 的质量，同时把推理 FLOPs 降低 40% 到 60%。对于长上下文负载，显存节省更为可观。这已经不是边际改进，而是能把你的 GPU 账单砍掉一半。

生产基准：SSM 在哪里兑现了承诺，又在哪里没有

我想把数字说具体一点，因为笼统的效率宣称对做部署决策的人没有任何用处。

推理吞吐：一个 8B 参数的 Mamba-3 模型，不管上下文是 1K 还是 50 万 token，生成速度基本一致。而同等规模的 Transformer 会随着 KV 缓存增长而逐步变慢。在 50 万上下文下，SSM 模型每张 GPU 的吞吐高出 5 到 8 倍。这不是理论值，是我亲自测出来的。

并发用户数：没有 KV 缓存，SSM 模型能同时服务的请求数大幅增加。在一张 A100 上，Transformer 在 32K 上下文下大约能扛住 8 路并发流，而同等的 SSM 模型可以处理 30 路以上。对于大规模运行推理的人来说，这个数字会改变成本账。

训练速度：这方面的提升就比较温和了。在 H100 集群上，Mamba-3 的训练吞吐大约是同等 Transformer 的 1.4 倍。序列越长，差距越大：超过 32K token 时，SSM 训练速度快 2 到 3 倍，因为它完全避开了二次方注意力。

但在局限性上，我必须说实话。对于需要从长上下文中精确逐字回忆的任务，比如“第 4382 行的确切报错信息是什么？”，纯 SSM 依然表现不佳。固定大小的压缩状态是一种有损表示，而注意力可以直接回看原始 token。这正是混合架构有效的原因：注意力层负责 SSM 做不了的检索工作。

SSM 仍然不足的地方

对于剩下的差距，我想保持清醒的判断。基于不完整的信息就采用一种新架构，是浪费半年时间的好办法。

上下文学习：Transformer 在根据提示中的少样本示例调整行为方面依然更强。SSM 也能做，但可靠性较差。如果你的应用严重依赖带示例的提示工程，纯 SSM 会让你失望。
生态成熟度：Transformer 的工具链经过了多年优化。SSM 专用的算子内核、推理服务基础设施和微调库进步很快，但还没有达到同等水平。要预留额外的集成时间。
70B 以上的扩展性未知：Mamba-3 在最多 70B 参数范围内的扩展曲线表现良好，但在 200B 以上的前沿规模上我们没有可靠数据。SSM 的扩展规律在极大规模下是否成立，目前确实无从判断。
微调技术：面向 Transformer 的 LoRA 和 QLoRA 已经很成熟，但把它们应用到 SSM 架构上需要不同的方法，最佳实践仍在摸索中。
硬件不匹配：当前 GPU 是为注意力偏爱的矩阵乘法优化的。SSM 严重依赖并行扫描，它在现代硬件上运行得还算可以，但并不是 GPU 当初设计时所围绕的核心操作。

这些都不是致命问题，它们是有已知解决路径的工程问题。但它们确实存在，应该纳入你的时间规划。

实践建议：何时采用，以及如何起步

我在多个生产负载上评估 SSM 之后，给团队提建议时用的是下面这个框架。

如果你的负载经常涉及长上下文推理（经常超过 32K token）、高并发需求，或对延迟敏感的边缘部署，就应该积极采用。投资回报是可观且立竿见影的。建议从 Jamba 或 Griffin 系列这类混合架构入手，而不是直接上纯 SSM，你能拿到大部分效率收益，风险却小得多。

如果你的负载以短上下文为主，并且严重依赖上下文学习，同时没有推理成本压力，那就先观望。这种场景下 Transformer 依然占优，生态也更成熟。

在决定之前，先分析你实际的推理负载，中位上下文长度和并发用户数是关键变量
从混合架构开始，而不是纯 SSM，风险更低，而且仍能带来 40% 到 60% 的推理成本下降
在你的具体任务上做基准测试：SSM 擅长摘要和长程推理，但在精确检索上落后
现在就搭建架构对比的基础设施，你需要衡量的是延迟、吞吐、显存和每次查询的成本，而不仅仅是准确率
每季度跟踪一次 SSM 工具链的生态进展，它的进步速度足够快，今天不切实际的东西，三个月后可能就已经可以上生产了

架构格局正在分化，这是好事

一统天下的单一架构时代正在落幕。我们正走向一个团队根据具体约束去选择计算原语，比如全注意力、线性注意力、选择性 SSM、门控卷积，并把它们组合起来的世界。成熟的工程学科一向如此。你不会用钢材盖所有建筑，而是根据要承受的载荷选择材料。

Transformer 并没有死。对许多负载而言，它依然是最经过验证的架构，未来几年还会支撑许多关键的 AI 系统。但它在前沿序列建模上的垄断地位已经结束了。SSM 和混合架构已经赢得了作为一等生产工具的位置，而不再只是研究上的小众玩意儿。

对于我们这些在构建真实系统的人来说，架构选项越多，意味着针对具体问题的工具就越好用。这不是需要害怕的颠覆，而是值得利用的工程杠杆。