Transformers 的替代方案，透過維持壓縮的「狀態」來處理序列，而非對所有 token 使用注意力機制。Mamba 是最著名的 SSM 架構。SSMs 的序列長度擴展為線性（與注意力機制的二次方相比），使其在處理非常長的上下文時可能更加高效。
狀態空間模型（SSM）借用了控制理論的數學框架，SSM 已在數十年來用於建模動態系統。核心概念是線性遞歸：模型維持一個隱藏狀態，每個時間步長透過學習到的線性轉換進行更新，然後與當前輸入混合。在連續時間中，這是一個微分方程（dx/dt = Ax + Bu, y = Cx + Du）。離散化後，會得到一個可以逐個 token 處理序列的遞歸，每個步驟更新一個固定大小的狀態。優雅之處在於訓練期間，這個遞歸可以展開成卷積，使其在 GPU 上與注意力一樣可平行化。在推論期間，則切換回遞歸形式，逐個 token 處理，並使用常數記憶體——無需增長的 KV 缓存。
Mamba（Albert Gu 和 Tri Dao，2023）是讓 SSM 在語言任務上與 Transformer 競爭的突破。早期的 SSM 如 S4 和 H3 使用固定狀態轉換矩陣，這限制了其進行基於內容的推理能力——模型無法根據 token 的內容調整處理方式。Mamba 引入選擇性狀態空間，其中 A、B 和 C 矩陣是輸入的函數。這讓模型在每個 token 處決定保留多少資訊與遺忘多少資訊。可以將其視為一種學習到的、可微分的閘控機制，但透過線性遞歸而非注意力進行操作。Mamba-2 後來將此重新表述為結構化狀態空間對偶（SSD），揭示選擇性 SSM 與線性注意力在數學上相關，並透過基於矩陣乘法的演算法實現更快的 GPU 實作。
實際優勢是真實且可衡量的。在推論期間，Transformer 必須為上下文中的每個 token 存儲鍵值對——這個 KV 缓存會隨著序列長度線性增長，是長上下文服務的主要瓶頸。SSM 則無論看到多少 token，都維持固定大小的狀態。對於具有 128K 上下文視窗的模型，這個差異非常巨大：SSM 在生成第 128,001 個 token 時使用的記憶體，與生成第一個 token 時完全相同。在長序列訓練中，透過平行掃描或卷積模式，SSM 的吞吐量會隨著序列長度線性增長，而完整的注意力則呈二次方增長。這些效率提升正是 SSM 對於需要長距離上下文的應用特別有吸引力的原因：文件分析、跨大型倉庫的程式碼生成，以及實時串流中持續到來的 token。
儘管如此，SSM 有真實的限制，而這些限制往往被熱潮所忽略。純粹的 SSM 在需要從上下文早期精確檢索的任務中會遇到困難——即所謂的「 haystack 中的針」問題。Transformer 原則上可以透過注意力權重直接關注任何過去的 token。SSM 必須將相關資訊壓縮到其固定大小的狀態中，如果在首次處理該 token 時未正確優先處理，資訊就會消失。這就是為何混合架構——將 SSM 層與幾個注意力層交錯使用——正逐漸受到關注。Jamba（來自 AI21）和各種研究混合模型已顯示，只要在網路中戰略性地少量使用注意力，就能在保持 SSM 效率的同時，獲得注意力的檢索精確度。
Mamba-3 最新世代進一步透過多輸入多輸出（MIMO）公式和透過旋轉位置編碼的複數狀態來推進架構。遞歸使用梯形積分法則以提高數值穩定性，且架構移除了早期版本用作短距離混合機制的因果卷積層。這些改進並非微小調整——它們改變了計算特性足夠多，需要自訂 Triton 核心才能實現完整效能，而標準的 mamba-ssm PyPI 套件目前尚未包含這些改進。如果你今天正在基於 SSM 進行開發，預期需要比成熟 Transformer 堆疊更接近硬體層面的開發。工具鏈正在追上，但目前生產級 SSM 部署仍處於早期階段。