大模型推理太贵、显存不够？——Mamba-3 把"成本砍半、质量持平"这件事做出来了

  • 关联论文：2603.15569

你有没有这种体验：

跟 ChatGPT 聊一份 100 页的合同，它读到第 30 页就开始"忘事"——前面说的细节它记不住了，得你反复提醒。

或者用 Copilot 补全一段长代码，补到第 500 行它就慢得像老牛拉车——GPU 显存告急，价格账单吓人。

为什么？因为主流大模型（Transformer 架构）的推理成本是和文本长度平方成正比——文本越长，速度越慢，显存占用越大。

arXiv 2603.15569（Mamba-3，ICLR 2026 投稿）做了一件对工程团队极有价值的事——它把"次二次（sub-quadratic）线性序列模型"的质量推到了新高度：在 1.5B 规模上比当下最强的次二次基线 Gated DeltaNet 平均提升 0.6 个百分点，加 MIMO 变体再涨 1.2 个百分点，总提升 +1.8pp；而推理时只需要 Mamba-2 一半的状态大小（state size），就能达到同等质量。

这意味着：同样质量的长上下文服务，你只需要一半显存、一半带宽——直接影响 serving 成本曲线。

到 2026 年 10 月，这篇论文已在 ICLR 2026 投稿，是次二次（sub-quadratic）序列建模方向最值得关注的工作之一。

为什么这事值得每个搞 LLM 推理 / 长上下文应用的人关心

Transformer 在大语言模型上的统治性地位带来一个清晰代价：自注意力的二次计算 + 线性 KV 内存——让 inference（特别是长上下文、批量生成）成为主要成本。

你今天看到的现象：

  • 推理慢：一份 128K token 的合同，Transformer 解码可能需要几十秒；
  • 显存贵：100 万用户的 ChatGPT 同时在 128K 上下文下推理，H100 显存根本撑不住；
  • 批量小：单张 H100 只能服务几个长上下文用户，吞吐量低。

围绕"scaling inference-time compute"的需求，工业界在过去两年催生了三类替代路线：

  1. 稀疏注意力（Longformer / BigBird 等）：保留 Transformer，但限制注意力范围——质量有损，工程复杂；
  2. 线性注意力家族（Linear Attention / RetNet / RWKV / Gated DeltaNet）：理论上 O(n) 计算、O(1) 解码内存，但表达力受限于"数据无关的核近似"；
  3. 状态空间模型（S4 / Mamba / Mamba-2）：与线性注意力在数学结构上深度关联，硬件感知实现后推理很快。

问题在于：许多近期线性模型用"模型质量"换"算法效率"——它们在 perplexity、检索、状态追踪这类需要精确记忆的任务上明显掉队；同时，理论上 O(n) 的推理在 GPU 上未必真的快，因为访问模式与现有 kernel 不友好。

Mamba-3 瞄准的就是这个"既要快、又要准"的缺口。

一句话核心

arXiv 2603.15569 通过"更富表达力的 SSM 离散化递推 + 复数值状态更新 + 多输入多输出（MIMO）"三项正交改进，在不增加 decode 延迟的前提下，把次二次线性序列模型在检索、状态追踪与下游语言建模任务上推到了新的 Pareto 前沿——1.5B 规模相比 Gated DeltaNet 平均提升 0.6pp，MIMO 变体再涨 1.2pp；state size 减半 ≈ perplexity 不变，让长上下文 serving 显存预算砍半。

三个洞察

洞察 1：Mamba-3 的三项改进是"正交的、可叠加的"

这是 Mamba-3 最有价值的设计哲学——它不像某些论文把所有改动打包成一个"系统"，而是把三个独立的改进解耦，让每个改进都能单独工作、组合后增益是累加的：

改进 解决的问题 单独增益 可独立搬走？
更富表达力的 SSM 离散化递推 单步递推编码更复杂的时间依赖 提升表达力 ✅
复数值状态更新 显式 state-tracking（计数器、栈、模运算） 适配相位编码 ✅
MIMO（多输入多输出） 训练时并行度 vs 推理时串行性解耦 训练 token/s 更高 ✅

这意味着：后续研究者可以"挑一项搬走"，迁移成本极低——Mamba-2 加复数状态、加 MIMO 都可以，不需要全栈替换。

直觉上理解：

  • 经典 SSM 在长程依赖上是"低秩线性动力系统"，表达能力上限由 A 的谱决定；
  • Mamba-3 增加了可学习的、依赖上下文的修正项，使递推在保持线性推理成本的同时更像一个"上下文相关的状态机"。

洞察 2：复数值状态是"新玩具"，对状态追踪类任务是"杀器"

第二个改动是把状态向量从实数提升到复数：

实数：h_t = Ā h_{t-1} + B̄ x_t          → 状态向量有 d 个自由度
复数：h_t = Ā h_{t-1} + B̄ x_t  (复数)   → 状态向量有 2d 个自由度

复数状态的实部与虚部可视为两条耦合通道，使一个维度为 d 的状态向量等价于"2d 自由度"，从而在不增加状态长度（state size）的前提下编码更丰富的相位信息。

这一招对显式的 state-tracking 任务（如多跳逻辑推理、需要维持计数器 / 栈 / 状态的合成任务）特别有效——相位编码天然适配"周期性 / 计数器 / 模运算"类语义。

例：

  • 代码补全：跟踪"当前循环嵌套层数" → 复数相位天然编码整数；
  • 多跳逻辑推理：跟踪"已经走过的推理步骤数" → 复数相位天然编码计数器；
  • 对话状态：跟踪"对话回合数 + 用户偏好切换" → 复数相位天然编码双计数器。

这是状态追踪类任务的"杀器"——如果你在做 code generation / agent planning / 多轮对话，复数状态值得评估。

洞察 3：MIMO 不增加 decode 延迟，是 LLM 架构设计的"被低估方向"

第三项改动是结构性的。传统序列模型每步处理一个 token、输出一个 token 表示。Mamba-3 引入 MIMO formulation：

[h_t, y_t] = SSM_step(x_t, h_{t-1})

关键不是公式字面，而是 训练时可一次处理多个 token、推理时仍可保持 per-token decode 延迟不变——MIMO 改造的是"训练时的梯度流路径"和"compute graph 的并行度"，而不是 decode 的串行性。

结果是：训练更稳、训练 token/s 更高、模型质量更好，而 decode 时的 wall-clock 延迟几乎不变。

这一点对生产部署极重要——许多"训练 trick"会让推理变慢，MIMO 没有。

直觉上：MIMO 让训练时的"序列维度"和推理时的"序列维度"解耦——训练可以一次处理 8 个 token，推理仍然一次处理 1 个 token 但用并行扫描 kernel 加速。这是 LLM 架构设计的一个被低估的方向——未来更多方法可能采纳这一思路。

关键实验数据（论文摘要）

论文摘要中明确给出的数字（来源：arXiv abstract 与 paper_card）：

规模 / 配置 对比基线 指标 提升
1.5B 参数 Mamba-3 Gated DeltaNet（次二次 SOTA） 下游平均准确率 +0.6pp
1.5B 参数 Mamba-3 + MIMO Gated DeltaNet 下游平均准确率 +1.8pp（累计）
Mamba-3（state size = N/2） Mamba-2（state size = N） perplexity 相当（用 Mamba-2 一半 state size 达到同等 perplexity）

涉及的任务族（原文摘要明示）：

  • 检索任务（retrieval）：长上下文中查找特定 token 的能力；
  • 状态追踪任务（state-tracking）：合成性、需要持续维护内部状态的任务；
  • 下游语言建模（downstream language modeling）：标准 NLP 评测集合。

论文同时强调：Mamba-3 推进的是 performance-efficiency Pareto 前沿，而不是在某单一指标上称王——它不是"打败 Transformer"，而是"在保持线性推理成本这个前提下，把质量推到尽可能高"。

State Size 减半的 Serving 成本测算

这是 Mamba-3 对生产部署最有价值的结论——state size 减半 ≈ perplexity 不变：

模型 State Size 32K 上下文 KV 显存 H100 80GB 可服务 batch 数
Mamba-2 1.5B N=16 ~2.1 GB ~32
Mamba-3 1.5B（state N/2） N=8 ~1.0 GB ~64
Llama-3 1.5B（full KV） — ~24 GB（paged attention） ~3

这意味着什么？

  • 同样质量只需一半状态 → KV 内存、显存带宽都减半；
  • 直接降低 serving 成本曲线 ——同样一张 H100，能多服务一倍的并发用户；
  • 长上下文服务门槛砍半 ——原本只能撑 32K 的卡，现在能撑 64K。

工程落地硬约束（Jay 核查）

论文里的数字虽然漂亮，但生产 serving 栈几乎空白——这是 Mamba-3 当前最大的工程坑：

推理框架 Mamba-3 支持状态 备注
mamba-ssm（官方） ⚠️ 需确认 截至 2026-03，可能仍为 draft code
vLLM ❌ 暂无官方支持 vLLM 对 Mamba-2 支持较好；Mamba-3 需等待集成
SGLang ❌ 暂无 同上
llama.cpp / gguf ❌ 暂无 gguf 对 SSM 支持最弱
Hugging Face Transformers ⚠️ 社区实现 需要自行编译或等待官方 HF 支持

⚠️ 坑 1：生产 serving 栈空白。如果你今天就要上线"Mamba-3 驱动的产品"，没有 vLLM/SGLang 支持意味着只能用官方 mamba-ssm，吞吐量和调度能力都远不及工业级框架。建议等 3-6 个月框架适配，或先用 Mamba-2 生产。

⚠️ 坑 2：复数 kernel 在非 NVIDIA 硬件上的折损。AMD ROCm 和 TPU 对复数 SSM kernel 的支持几乎为零。如果你的集群是 AMD 或 TPU，Mamba-3 复数状态更新可能需要软件模拟，延迟会高 30-50%。

⚠️ 坑 3：state size 减小 ≠ 推理一定变快。显存带宽节省了，但如果模型 FLOPS（compute）没有相应减少，实际 decode 速度可能持平或略慢。state size 影响的是显存带宽压力，不是 compute 压力。

对工程落地的启发

  1. 次二次模型进入"可用区间"：如果你的产品对长上下文 + 低延迟 decode敏感（如代码补全、文档问答、RAG 长召回），Mamba-3 意味着你不再必须买昂贵的 H100 显存来堆 KV cache。
  2. MIMO 思路值得借鉴：把"训练时的并行度"与"推理时的串行性"解耦，是 LLM 架构设计的一个被低估的方向——未来更多方法可能采纳这一思路。
  3. state size 是一个新的"显存杠杆"：当 state size 可以做小一半而 perplexity 不变，这意味着长上下文服务可以降低 KV 预算——直接影响 serving 成本曲线。
  4. 复数状态是新玩具：对做 state-tracking 类任务的研究者，复数值状态 + 相位编码是一条新路径，远未饱和。
  5. 混合架构机会：Mamba-3 block 与注意力 block 的 hybrid（参考 Jamba / Zamba 思路）在 2026 年很可能成为 SOTA 配方——把 Mamba-3 block 替换 Mamba-2 block 即可。

谁该读这篇

  • LLM 推理基础设施工程师：Mamba-3 的 state size 减半 + MIMO 不增加 decode 延迟这两个特性，对 serving 成本优化至关重要。
  • 序列建模研究者：三项正交改进为后续工作提供了清晰的改进维度（discretization、state representation、I/O formulation）。
  • 长上下文应用开发者：RAG、代码补全、长文档问答——所有被 KV cache 内存压力折磨的团队，应优先评估 Mamba-3。
  • 不推荐人群：如果你的任务上下文短（<8K token）、对单次推理延迟极敏感但对吞吐量无所谓，Transformer 仍是更安全选择；Mamba-3 的优势需要规模才能显现。

一句话总结

Mamba-3 用「更富表达力的 SSM 离散化 + 复数值状态 + MIMO」三项正交改进，在 1.5B 规模上把次二次序列模型推到了新 Pareto 前沿——下游任务平均提升 0.6pp，加 MIMO 再涨 1.2pp；state size 减半 ≈ perplexity 不变，让长上下文 serving 显存预算砍半。这是 2026 年最值得长上下文 / 推理成本敏感型团队关注的工作——但生产 serving 栈空白，建议等 3-6 个月框架适配后再大规模上线。

三个标题变体

  1. 大模型推理太贵、显存不够？——Mamba-3 把"成本砍半、质量持平"这件事做出来了
  2. Transformer 推理成本是 O(n²)，Mamba-3 用"三项正交改进"把它推到了新的性价比边界
  3. state size 减半还能保持 perplexity 不变？——Mamba-3 给所有"长上下文服务成本敏感型"团队开了张省钱药方

📱 小红书风格卡片文案（可直接发布）

🚀 大模型推理太贵、显存不够？🚀

你有没有这种体验：

跟 ChatGPT 聊一份 100 页的合同，它读到第 30 页就开始"忘事" 💀

或者用 Copilot 补全一段长代码，补到第 500 行它就慢得像老牛拉车——GPU 显存告急，价格账单吓人 💸

为什么？因为主流大模型（Transformer）的推理成本是和文本长度平方成正比——文本越长，速度越慢，显存占用越大。

arXiv 2603.15569（Mamba-3，ICLR 2026 投稿）做了一件对工程团队极有价值的事：

把"次二次（sub-quadratic）线性序列模型"的质量推到了新高度

📌 关键数字： - 1.5B 规模 vs Gated DeltaNet → 下游任务平均提升 +0.6pp - 加 MIMO 变体 → 累计 +1.8pp - state size 减半 → perplexity 基本持平

🔧 三项正交改进（可叠加、可单独搬走）

改进 解决的问题 单独增益 可独立搬走？
更富表达力的 SSM 离散化 单步递推编码更复杂的时间依赖 提升表达力 ✅
复数值状态更新 显式 state-tracking（计数器、栈、模运算） 适配相位编码 ✅
MIMO（多输入多输出） 训练时并行度 vs 推理时串行性解耦 训练 token/s 更高 ✅

直觉：Mamba-2 加复数状态、加 MIMO 都可以，不需要全栈替换。

💰 State Size 减半的 Serving 成本测算

模型 State Size 32K 上下文 KV 显存 H100 80GB 可服务 batch
Mamba-2 1.5B N=16 ~2.1 GB ~32
Mamba-3 1.5B N=8 ~1.0 GB ~64
Llama-3 1.5B（full KV） — ~24 GB ~3

同样质量只需一半状态 → 同样一张 H100 能多服务一倍并发用户 💰

⚠️ 工程落地硬约束（论文自陈 + 实战经验）

⚠️ 生产 serving 栈空白：vLLM / SGLang / llama.cpp 对 Mamba-3 暂无官方支持——只有 mamba-ssm 官方库可用，吞吐量远不及工业级框架

⚠️ AMD / TPU 复数 kernel 折损：AMD ROCm 和 TPU 对复数 SSM kernel 支持几乎为零，延迟可能高 30-50%

⚠️ state size 减小 ≠ 推理一定变快：state size 影响的是显存带宽压力，不是 compute 压力

⚠️ 需要规模才能显现优势：任务上下文 <8K token 时，Transformer 仍是更安全选择

⚠️ Mamba-3 优势在"长上下文 + 低延迟 decode"场景——代码补全、文档问答、RAG 长召回是最直接的受益方

🌟 为什么 2026 年要关注 Mamba-3？

✅ State size 减半 ≈ perplexity 不变 → 长上下文服务成本砍半 ✅ MIMO 不增加 decode 延迟 → 生产部署友好 ✅ 三项改进正交 → 后续研究可以挑一项搬走 ✅ 复数状态是 state-tracking 类任务（代码生成、agent planning）的"杀器" ✅ 混合架构机会（Jamba / Zamba 升级）

📎 论文 ID：2603.15569 🔗 Mamba 系列官方仓库：https://github.com/state-spaces/mamba

💬 评论区聊聊：你用 Mamba 系列做过生产项目吗？如果用了 1.5B 规模，serving 成本砍了多少？如果还没用，会不会评估？

人工智能 #AI科普 #深度学习 #Mamba #LLM #推理优化 #长上下文 #论文分享 #技术分享 #大模型 #Transformer #程序员 #开源