「Attention is All You Need」から9年、その「All」が少しずつ揺らぎ始めた。
Transformerのスケール問題と、SSMが取るアプローチ
Transformer（大規模言語モデルの基盤アーキテクチャ）は、自己注意機構でトークン数nに対してO(n²)の計算量を消費する。8Kトークンなら問題ないが、64Kになると計算コストは理論上64倍に膨らむ。MoEや拡張コンテキストといった近年の改良はこの根本特性を変えていない——言わば「パッチ」だ。
2026年3月にリリースされたMamba-3（CMU・Princeton・Cartesia AI・Together AI共同開発）はState Space Model（SSM）を採用し、O(n)でシーケンスを処理する。入力依存のゲーティングにより、どの情報を「状態」として保持するかを動的に選択する設計で、長コンテキストで特に効いてくる。
flowchart LR
In[入力トークン列] --> TF[Transformer]
In --> SSM[Mamba-3 SSM]
In --> DLM[Diffusion LLM]
TF --> R1[短文安定・エコシステム成熟]
SSM --> R2[64Kで7倍安・FTは手間]
DLM --> R3[高速並列生成・品質要検証]
style TF fill:#7f8c8d,color:#fff
style SSM fill:#2980b9,color:#fff
style DLM fill:#e67e22,color:#fff
コスト試算が変わる：長文パイプラインなら数字を出し直す価値がある
実測ではMamba-3 7Bは同等サイズのTransformerに対して、8Kコンテキストで約1.5倍、64Kコンテキストで約7倍安く動く。長文ドキュメント要約やRAGで大きなチャンクを扱うパイプラインでは、モデル選択が直接月次コストに響く。「小さく分割してTransformerで処理」から「大きなウィンドウでSSMに任せる」に変えると、RAGのチャンク戦略ごと再設計できる可能性がある。
「7倍安い」が罠になる：エコシステム格差という隠れコスト
現時点でSSMの最大のボトルネックはエコシステムの未成熟さだ。LlamaならLoRAで数時間のファインチューニングが完結するが、Mamba-3の同等作業はまだ手順が多い。vLLMやQLoRAなどのデプロイツールのサポートも限定的で、移行・運用コストを含めたROIが正になるかはユースケース次第になる。
Diffusion LLMも「並列デコーディング」という設計は速さを約束するが、トークン間の依存関係を無視する構造が品質劣化を招くケースが確認されている（ICLR 2026発表のParallelBench）。コード生成など順序依存のタスクでは特に注意が要る。
自分のパイプライン、処理コンテキストは本当に短い？
今Transformerを使っているプロジェクトで、実際に処理しているドキュメントの平均トークン数を計測したことはあるか。8K以下ならSSMへの切替メリットは薄い。だが64K超が常態なら、Mamba-3のコストシミュレーションを一度走らせてみると、設計判断の材料が変わるかもしれない。
参考: MIT Technology Review: These startups are chasing the next big thing in LLMs