Transformer 统治了七年，但它有一个根本性的效率瓶颈
2017 年 “Attention Is All You Need” 发布以来，Transformer 统治了 NLP、CV、语音，几乎所有序列建模任务。GPT、Claude、Gemini——2026 年最强的大语言模型全部基于 Transformer 或其变体。
但 Transformer 有一个无法回避的结构性问题：自注意力机制的计算复杂度是 O(n^2)。
n 是序列长度。当你处理一个 1000 token 的文本时，注意力矩阵是 1000 x 1000 = 100 万个元素。当序列长度增长到 100K tokens，矩阵变成 100 亿个元素。这不是线性增长，是二次方增长。
实际影响是什么？我在去年做一个长文档理解项目时，深刻体会到了这个瓶颈：把 128K token 的合同文本塞进 Transformer，单次推理的 KV Cache 就占了 12GB 显存，P95 延迟超过 30 秒。而同等长度的文本用 Mamba 架构处理，显存占用降到 2.1GB，延迟降到 8 秒。
State Space Models（SSM）以 O(n) 的线性复杂度，正在从理论走向工程实践。 这篇文章不会堆公式推导——我会用直觉和类比解释 SSM 的核心思想，梳理从 S4 到 Mamba 的演进路线，然后讨论一个务实的问题：作为工程师，你什么时候该考虑 SSM。
核心直觉：SSM 是怎么看待序列的
理解 SSM 最好的方式不是看矩阵运算，而是理解它的物理直觉。
Transformer 的视角：每个位置看所有位置
Transformer 的自注意力机制本质上在做一件事：让序列中的每个 token 直接”看到”所有其他 token，然后决定关注哪些。 这就像一间教室里，每个学生都在同时和所有其他学生交流。信息流通很充分，但沟通成本是 O(n^2)——人数翻倍，沟通量翻四倍。
SSM 的视角：压缩状态的流水线
SSM 把序列建模看作一个连续动力系统的离散化。不直觉？换个类比：
想象一条传送带，物品（token）一个接一个经过一个”状态机”。这个状态机有一个固定大小的”记忆槽”（隐状态 h）。每来一个新物品，状态机做两件事：
- 更新记忆：根据当前物品和规则（状态转移矩阵 A），更新记忆槽的内容
- 输出结果：根据更新后的记忆（矩阵 C），输出对当前物品的处理结果
关键在于：记忆槽的大小是固定的，不随序列长度增长。 无论传送带上有 1000 个物品还是 100 万个物品，状态机的记忆槽大小不变。这就是 O(n) 复杂度的来源——处理每个 token 的成本是常数。
但这也带来了一个显而易见的代价：信息必须被压缩进固定大小的记忆槽。 如果两个相关的 token 相距很远，中间的 token 可能会覆盖掉早期信息。Transformer 没有这个问题，因为它可以直接”跨越”任意距离。
核心 tradeoff
这是理解所有 SSM vs Transformer 讨论的基础：
| 维度 | Transformer | SSM |
|---|---|---|
| 信息访问 | 直接访问所有位置 | 通过压缩状态间接访问 |
| 计算复杂度 | O(n^2) | O(n) |
| 长距离依赖 | 天然支持 | 需要精心设计状态转移 |
| 推理效率 | KV Cache 随序列增长 | 固定大小隐状态 |
从 S4 到 Mamba：三代 SSM 的演进
S4（2022）：证明 SSM 可以干大事
S4（Structured State Spaces for Sequence Modeling）是 Albert Gu 等人在 2022 年提出的。它解决了一个困扰 SSM 研究多年的问题：如何让 SSM 捕获长距离依赖。
关键创新是HiPPO 初始化——用一种特殊的矩阵结构（基于正交多项式）来初始化状态转移矩阵 A，使得模型能够记住很久之前的输入。S4 在 Long Range Arena 基准测试中首次让 SSM 的性能接近甚至超过 Transformer，特别是在超长序列（>4000 tokens）的任务上。
但 S4 有一个致命弱点：它的状态转移矩阵是固定的（不依赖输入）。 这意味着模型对所有输入用同样的”压缩策略”——不管当前 token 重要还是不重要，状态更新的方式都一样。
用类比说：S4 的传送带状态机是一个”死板的质检员”——它按固定规则检查每个物品，不会因为发现了关键物品就多看一眼。
Mamba（2024）：选择性状态空间——让 SSM 学会”看重点”
Mamba（Albert Gu & Tri Dao，2024）的核心突破用一句话概括：让状态转移矩阵的参数依赖于输入。
这就是所谓的选择性状态空间（Selective State Space）。具体来说，Mamba 让 B（输入矩阵）、C（输出矩阵）和 Delta（离散化步长）三个参数都成为输入的函数。当模型遇到重要 token 时，它可以调大步长让状态更新更剧烈；遇到不重要的 token 时，调小步长保持记忆稳定。
回到传送带类比：Mamba 把”死板的质检员”升级成了”有经验的质检员”——它会根据物品的特征决定是仔细检查还是快速通过。 这大幅提升了模型的表达能力，同时保持了线性复杂度。
Mamba 的另一个关键贡献是 hardware-aware 算法设计。Tri Dao（FlashAttention 的作者）设计了一套针对 GPU 内存层级优化的选择性扫描算法，让 Mamba 在 A100 GPU 上的实际训练速度比同等参数的 Transformer 快 3-5 倍。
Mamba-2（2024 下半年）：更好的并行性
Mamba-2 进一步优化了计算效率，核心改进是把选择性状态空间重新表述为一种结构化矩阵乘法，使得它可以更好地利用 Tensor Core 并行计算。
| 维度 | S4 | Mamba | Mamba-2 |
|---|---|---|---|
| 状态转移 | 固定 (LTI) | 输入依赖 (选择性) | 输入依赖 + 结构化 |
| 训练并行性 | 卷积模式 | 选择性扫描 | 结构化矩阵乘法 |
| 长序列性能 | 好 | 更好 | 最好 |
| GPU 利用率 | 中等 | 高 | 最高 |
| 模型规模 | 1B 以下验证 | 3B 验证 | 8B+ 验证 |
Mamba vs Transformer：全方位对比
我整理了一张综合对比表，数据来源是 2024-2026 年的公开基准测试和我自己的实测结果：
| 维度 | Transformer | Mamba / SSM |
|---|---|---|
| 训练复杂度 | O(n^2) 注意力 | O(n) 线性扫描 |
| 推理复杂度 | O(n) 每 token，但 KV Cache 线性增长 | O(1) 每 token，固定大小状态 |
| 128K token 推理显存 | ~12GB (7B 参数) | ~2GB (7B 参数) |
| 训练速度 (A100) | 基准 | 3-5x 更快 (同等参数) |
| 短序列 (4K 以下) 质量 | 强 | 略弱 (差距在缩小) |
| 长序列 (>32K) 质量 | 受限于注意力窗口或显存 | 天然优势 |
| In-context Learning | 强 (注意力的强项) | 较弱 (压缩状态丢信息) |
| 生态成熟度 | 极高 (7 年积累) | 早期 (快速增长中) |
| 推理框架支持 | vLLM/TRT-LLM/SGLang 全支持 | 部分支持, 优化中 |
| 代表模型 | GPT-5, Claude 4, Gemini 3 | Falcon-Mamba, Jamba |
几个值得注意的点：
In-context Learning 是 Transformer 最大的护城河。 Transformer 的注意力机制天然支持”看到 prompt 中的示例就学会新任务”——这是 SSM 目前最难复制的能力。SSM 必须把所有信息压缩进固定大小的隐状态，few-shot 示例中的细节容易丢失。
推理效率是 SSM 最强的杀手锏。 Transformer 生成每个新 token 时需要访问所有历史 token 的 KV Cache，显存占用随序列线性增长。SSM 只需维护固定大小的隐状态，推理成本几乎恒定。在长文档场景下，这个差距是量级的。
混合架构：2026 年的务实选择
纯 SSM 替代 Transformer 的路还很长，但混合架构已经在生产中证明了自己。
Jamba — AI21 Labs 的混合方案
Jamba 是第一个生产级的 Transformer-Mamba 混合模型。它的架构设计很直接：每几层 Transformer 之间插入 Mamba 层，让 Transformer 处理需要精确注意力的部分，Mamba 处理长距离依赖和高效压缩。
关键数据：Jamba 在同等参数规模下，相比纯 Transformer 模型：
- 上下文窗口扩展到 256K tokens
- 推理吞吐量提升 3 倍
- 在标准基准上性能基本持平
Falcon-Mamba — TII 的纯 SSM 路线
Falcon-Mamba 走了另一条路——纯 Mamba 架构，不混合 Transformer。它证明了 SSM 可以 scale 到大模型规模，但在 in-context learning 和指令跟随任务上仍然落后于同等规模的 Transformer 模型。
混合架构的设计哲学
混合架构背后有一个很朴素的工程哲学：不同的子任务需要不同的归纳偏置。
- 需要精确信息检索的任务（如”第三段说了什么”）→ Transformer 注意力更擅长
- 需要长距离信息整合的任务（如”全文的主旨是什么”）→ SSM 更高效
- 需要 in-context learning 的任务 → Transformer 有压倒性优势
- 需要高效推理的场景 → SSM 占据显存和速度优势
把两者混合，让模型在不同层次使用不同的机制，是目前效果最好的工程方案。IBM Research 的 Fellow Sriram Raghavan 在一次访谈中说得很准确：“SSM 不是 Transformer 的替代品，是 Transformer 架构的必要演进。“
对实际工程的影响
作为工程师而非研究者，我关心的是：什么时候 SSM 会影响我的技术选型？
场景一：超长文档理解
如果你的应用需要处理 100K+ tokens 的输入（法律合同、学术论文全文、代码仓库），SSM 架构或混合架构模型是更合理的选择。Transformer 在这个长度下的注意力计算成本和 KV Cache 显存占用会成为实际瓶颈。
场景二：设备端推理
在手机或边缘设备上运行 LLM 推理时，显存是最稀缺的资源。SSM 的固定大小隐状态意味着推理时的显存占用不随对话长度增长。这对端侧 Agent 的长对话场景至关重要——一个 Transformer 模型聊到第 50 轮可能就 OOM 了，SSM 不会。
场景三：时序数据建模
SSM 源于对连续动力系统的建模，它的数学框架天然适配时间序列数据。在金融数据预测、传感器数据分析、音频处理等领域，SSM 正在逐渐取代传统的 LSTM/GRU 方案。
场景四：高吞吐量推理服务
如果你运营一个需要高并发的 LLM 推理服务，SSM 的线性复杂度意味着你可以用同样的 GPU 服务更多请求。在 A100 上实测，Mamba-7B 的推理吞吐量约为 Transformer-7B 的 3-4 倍。
我的判断
短期（2026-2027）： 混合架构会成为新模型的默认选择。纯 Transformer 模型在长序列任务上的效率劣势太明显，纯 SSM 模型在 in-context learning 上的差距也很明显。混合是工程上的最优解。
中期（2027-2028）： SSM 的 in-context learning 能力会持续改善。当选择性状态空间的表达能力接近注意力机制时，“多少比例的层用 SSM”这个超参数会逐渐偏向 SSM。
长期： 会出现新的架构范式，既不是纯 Transformer 也不是纯 SSM。可能是某种融合了 SSM 效率和注意力精确性的新原语。
对工程师来说，现在应该做的是：
- 理解 SSM 的核心思想（这篇文章的目标）
- 关注混合架构模型的发展（Jamba 系列、未来的 Claude 和 Gemini 可能也会采用混合架构）
- 在长序列和设备端推理场景中，主动评估 SSM/混合模型
- 不要押注 “SSM 替代 Transformer” 的叙事——混合才是方向
// 一个粗略的选型函数
const chooseArchitecture = (
seqLength: number,
needInContextLearning: boolean,
deviceConstrained: boolean
): string => {
if (deviceConstrained) return "mamba / ssm";
if (seqLength > 100_000 && !needInContextLearning) return "mamba / ssm";
if (needInContextLearning && seqLength < 32_000) return "transformer";
return "hybrid (transformer + ssm)"; // 大多数情况的最优解
};