SSM

为什么需要 SSM？——状态空间模型第一课：从 RNN 与 Transformer 的痛点，到状态空间模型的数学骨架 如果你已经了解了 RNN 和 Transformer 的基本原理，那么这篇文章要回答的核心问题只有一个：在 RNN 和 Transformer 已经统治序列建模的今天，我们为什么还需要一种新的架构——状态空间模型（State Space Model, SSM）？ 我们会先看清两位"前辈"各自的结构性缺陷，然后一步步揭开 SSM 的数学面纱，把它的骨架、直觉、与 RNN 的对应关系彻底讲清楚。 一、课程导论：为什么需要 SSM？ 1. RNN 的痛点：传话游戏的困境 RNN（包括 LSTM/GRU）的核心是隐藏状态的逐步递推：$h_t = f(h_{t-1}, x_t)$。这个看似简单的结构有两个难以克服的缺陷。 计算上的痛：串行诅咒。 因为 $h_t$ 强依赖于 $h_{t-1}$，你无法并行计算序列中不同时间步的状态——必须先算出 $t-1$ 时刻，才能算 $t$ 时刻。GPU 是为大规模并行矩阵乘法而生的硬件，RNN 的这种串行依赖让硬件的并行能力无处施展，训练效率极低。 记忆上的痛：长程依赖。 就像玩"传话游戏"，信息每传递一次就会有损耗。即使有 LSTM 的门控机制，当序列长度达到几千甚至上万时，梯度消失或爆炸问题依然会让模型"忘记"开头的信息。 2. Transformer 的痛点：全班互相对答案的代价 Transformer 用自注意力机制（Self-Attention）彻底解决了长程依赖和并行计算问题，代价是计算所有 token 之间的两两相关性 $QK^\top$。注意力机制的计算复杂度和显存占用是序列长度 $L$ 的平方级 $O(L^2)$。 直觉上感受一下这个平方增长的威力：序列长度为 10 时，需要计算 100 次关联；长度变成 1000 时，计算量直接暴增到 1,000,000 次。当上下文窗口扩展到 128K 甚至 1M 时，显存会溢出（OOM），算力成本极其高昂。 ...