通俗版
O(N²) 有多严重，用数字感受一下
Transformer 注意力计算复杂度是 O(N²)。
- 1K token：100 万次运算
- 1M token：1 万亿次运算
从 1K 到 1M，token 数量乘以 1000，但计算量乘以了 100 万。
标准实现的训练内存也会遇到 O(N²) 的注意力矩阵——反向传播需要保留相关中间量。128K context 的单个 FP16 注意力矩阵按 128K × 128K × 2 字节估算约为 32 GB。FlashAttention 一类实现可以通过分块计算避免完整落下这张矩阵、显著降低实际显存，但不会改变全局注意力两两配对的计算规模。
Mamba 的"固定大小状态"
Mamba 的思路：维护一个固定大小的"压缩状态"，新信息来了就更新这个状态，旧信息被选择性地"遗忘"。就像你记读书笔记，不把原文抄下来，而是不断更新你的理解摘要——摘要永远是固定大小的，不管原书有多厚。
结果：处理长度为 N 的整段序列时，总计算量和训练内存随 N 线性增长；做自回归推理时，每一步只维护固定大小的递推状态，不需要像 KV Cache 那样随历史长度继续增长。也就是 整段处理 O(N)，单步推理状态 O(1)，不能写成总计算量与上下文长度无关。
关键创新叫"选择性"：丢什么、留什么，不是固定的，而是由当前输入动态决定。模型会学到：这个信息很重要，要强写入状态；那个信息是噪声，让它快速衰减。LSTM 的门控同样依赖当前输入和历史状态；Mamba 的区别不在于“只有它会按输入决定遗忘”，而在于把输入相关的选择机制放进状态空间模型，并配合硬件友好的并行扫描，在长序列上兼顾表达能力和吞吐。
它丢弃了什么
状态大小固定，意味着早期的具体细节会逐渐被"压缩"，最终消失。如果你在一段 100K token 的文档里，第 1 个 token 是一个重要的名字，Mamba 需要把这个名字压缩保存在固定大小的状态里，同时还要处理后续 99999 个 token。在足够长的序列后，这个名字可能已经被后来的信息稀释掉了。
而 Transformer 用 KV Cache，理论上每个历史 token 的精确信息都在。这是 Mamba 和 Transformer 在"精确细节检索"能力上的根本差距。
还没完全替代 Transformer
目前主流趋势是"混合架构"——大部分层用 Mamba 处理局部信息，少数关键层用 Attention 做精确的长距离检索（比如 Jamba：约 80-90% 的层用 Mamba，10-20% 用 Attention）。两者互补，而不是完全替代。
进阶版
SSM 的递推公式直觉
状态空间模型的工作方式：维护一个内部状态向量 h，每次读入一个新 token x，按以下规则更新：
- 新状态 = A × 旧状态 + B × 当前输入（A 控制旧信息保留多少，B 控制新信息写入多少）
- 输出 = C × 新状态（C 控制从状态里读出什么信息）
Mamba 的"选择性"体现在：A、B、C 这三个矩阵不是固定的，而是由当前输入 x 经过一个小网络计算出来的，让模型可以根据输入内容动态调整"记忆策略"。
端侧的优势
端侧最大的约束是内存。Transformer 的 KV Cache 随对话长度线性增长——一个 100 轮的长对话，KV Cache 可能占满整个设备内存预算。Mamba 的状态大小固定，第 100 轮和第 1 轮占的内存完全一样。端侧长期对话助手这类场景特别吃这套。
截至 2026 年初，端侧主流模型仍然是 Transformer 架构，但 Falcon Mamba 1B、Zamba2-2.7B 等已经在测试 Mamba 端侧适配，只是量化工具链和 Metal/NPU 优化还不如 Transformer 成熟。