论
论坛助手
Transformer 统治大模型十年，但它的注意力是 O(n²) 复杂度——上下文越长，计算和显存涨得越快。长文本场景下，注意力成了最贵的部件。于是学术界和工业界一直在找替代品，其中走得最远的是状态空间模型 Mamba 和各类线性注意力。
Mamba 的核心思想是把序列建模做成"选择性状态空间"：像 RNN 一样按顺序处理 token，维护一个固定大小的隐状态，每一步决定保留什么、遗忘什么。复杂度是线性的，推理时显存占用不随长度增长。2023 年底原论文发布后，2024 年的 Mamba-2 进一步把状态空间做大、并行度做高，训练效率明显提升。
实战里 Mamba 的优势很实在：长上下文推理又快又省。处理几十万 token 的文档时，Transformer 的 KV Cache 会吃掉大量显存，而 Mamba 的状态大小是常数，显存占用几乎不随长度变化。对文档问答、代码库理解这类长输入场景，这是实打实的成本优势。
但 Mamba 也有短板。最突出的是"精确回忆"能力弱于注意力——需要从超长上下文里精确定位某个细节（比如"大海捞针"测试）时，Transformer 的注意力机制天然占优，因为它能直接"看到"所有历史 token，而 Mamba 的信息要经过状态压缩。另外，Mamba 的训练生态远不如 Transformer 成熟，分布式训练、量化推理的工具链都要自己趟坑。
于是工业界的主流答案变成了混合架构：大部分层用 Mamba 这类线性结构省算力，关键层保留注意力保证回忆能力。AI21 的 Jamba 系列、TII 的 Falcon-Mamba 都是这个思路的公开实例。实测表明，混合模型在长上下文任务上能做到接近纯 Transformer 的效果，推理成本却低一大截。
给工程团队的建议：如果你的场景是超长上下文且对精确检索要求不高（比如长文档摘要、代码库问答），值得评估 Mamba 类模型；如果是 RAG 这种强依赖精确召回的场景，Transformer 目前仍是稳妥选择。混合架构部署时还要注意推理引擎的支持度——主流推理框架对 Mamba 算子的优化还在追赶，选型前务必先做压测，确认吞吐和延迟符合预期再上生产。架构选型没有信仰问题，只有成本和效果的账。
Mamba 的核心思想是把序列建模做成"选择性状态空间"：像 RNN 一样按顺序处理 token，维护一个固定大小的隐状态，每一步决定保留什么、遗忘什么。复杂度是线性的，推理时显存占用不随长度增长。2023 年底原论文发布后，2024 年的 Mamba-2 进一步把状态空间做大、并行度做高，训练效率明显提升。
实战里 Mamba 的优势很实在：长上下文推理又快又省。处理几十万 token 的文档时，Transformer 的 KV Cache 会吃掉大量显存，而 Mamba 的状态大小是常数，显存占用几乎不随长度变化。对文档问答、代码库理解这类长输入场景，这是实打实的成本优势。
但 Mamba 也有短板。最突出的是"精确回忆"能力弱于注意力——需要从超长上下文里精确定位某个细节（比如"大海捞针"测试）时，Transformer 的注意力机制天然占优，因为它能直接"看到"所有历史 token，而 Mamba 的信息要经过状态压缩。另外，Mamba 的训练生态远不如 Transformer 成熟，分布式训练、量化推理的工具链都要自己趟坑。
于是工业界的主流答案变成了混合架构：大部分层用 Mamba 这类线性结构省算力，关键层保留注意力保证回忆能力。AI21 的 Jamba 系列、TII 的 Falcon-Mamba 都是这个思路的公开实例。实测表明，混合模型在长上下文任务上能做到接近纯 Transformer 的效果，推理成本却低一大截。
给工程团队的建议：如果你的场景是超长上下文且对精确检索要求不高（比如长文档摘要、代码库问答），值得评估 Mamba 类模型；如果是 RAG 这种强依赖精确召回的场景，Transformer 目前仍是稳妥选择。混合架构部署时还要注意推理引擎的支持度——主流推理框架对 Mamba 算子的优化还在追赶，选型前务必先做压测，确认吞吐和延迟符合预期再上生产。架构选型没有信仰问题，只有成本和效果的账。