- Transformer 的局限与 SSM 的兴起背景
- Mamba:Selective State Space Model
- Mamba-2:State Space Duality
- 架构层面的差异比较
- 实测基准测试:差异出现在哪里
- 按工作负载路由:不只选一个
- 迁移到生产环境时的注意事项
- 实战故障排查
- 用于选型的决策框架
- 参考资料

Transformer 的局限与 SSM 的兴起背景
Transformer(Vaswani 等,2017,arxiv:1706.03762)通过 self-attention 机制,直接对序列内所有位置之间的关系进行建模。这一设计在并行训练和捕捉长距离依赖上具有革命性意义,但也背负着根本性的计算成本问题。
- 时间复杂度:self-attention 相对序列长度 L 需要 O(L^2) 的运算量。
- 内存复杂度:KV cache 随层数 x 头数 x 序列长度成比例增长。
- 推理成本:在自回归(autoregressive)生成时,每个 token 都要参照完整的 KV cache。
序列长度从 4K、8K 增长到 128K、1M 时,这一成本不是线性增长,而是二次方增长。这正是 subquadratic 架构研究变得活跃的背景。
Structured State Space Models(S4,Gu 等,2021,arxiv:2111.00396)是一种通过对连续时间系统离散化来对序列建模的方法。它能以 O(L) 的时间复杂度处理长序列,但早期的 SSM 基于内容的(content-based)推理能力较弱,在语言建模上追不上 Transformer。
Mamba:Selective State Space Model
Mamba(Gu & Dao,2023,arxiv:2312.00752)是解决了 SSM 核心局限的模型。与现有 SSM 无论输入如何都套用相同 dynamics 不同,Mamba 会根据输入动态调节 SSM 参数(B、C、delta)。这正是「selective」state space 的含义。
把主要技术贡献整理如下。
Selection Mechanism:SSM 参数成为输入的函数。由此可以根据输入内容,决定把哪些信息写入 state、忽略哪些信息。如果说 Transformer 的 attention 是「看过所有位置后求加权和」的方式,那么 Mamba 的 selection 就是「对写入 state 的信息做输入输出门控」的方式。
Hardware-aware Algorithm:引入 selection 之后,就无法再使用现有 SSM 那种高效的 convolution 运算。Mamba 用针对 GPU SRAM 利用率优化的 scan 算法解决了这个问题,相当于把 FlashAttention(Dao 等,2022)的设计理念应用到了 SSM 上。
Simplified Architecture:不使用 attention,也不使用 MLP,仅用 selective SSM 模块构成整个架构,在减少层数的同时仍能维持性能。
Mamba-2:State Space Duality
Mamba-2(Dao & Gu,2024,arxiv:2405.21060)证明了 SSM 与 attention 在数学上属于同一系(semi-separable matrix),并利用这一 duality 提出了快 2-8 倍的算法。
这一结果在实务上的含义不小。SSM 与 Transformer 并非「完全不同的范式」,而是同一运算空间中的不同点,这意味着混合架构拥有理论依据。实际上,也出现了像 Jamba(AI21,2024)这样混用 Mamba 层与 attention 层的模型。
架构层面的差异比较
| 特性 | Transformer | Mamba (SSM) |
|---|---|---|
| 核心运算 | self-attention (Q、K、V 内积) | selective state space (依赖输入的门控) |
| 时间复杂度 (训练) | O(L^2 * d) | O(L _ d _ N),N 为 state 维度 |
| 时间复杂度 (推理/单 token) | O(L * d),参照 KV cache | O(d * N),参照固定大小的 state |
| 内存 (推理) | KV cache: O(L _ d _ layers) | hidden state: O(d _ N _ layers),与 L 无关 |
| 并行训练 | 高 (attention 矩阵运算) | 高 (parallel scan) |
| 长距离依赖 | 直接建模 (参照所有位置) | 通过 state 间接传递 |
| 生态成熟度 | 非常高 (CUDA、TensorRT、vLLM 等) | 早期阶段 (mamba-ssm 包) |
| in-context learning | 强 (few-shot 学习的基础) | 相对较弱 (研究进行中) |
实测基准测试:差异出现在哪里
引用基准测试数字时有一点需要注意。论文中的基准测试,是在特定硬件、特定实现、特定数据集下得出的结果。如果不亲自测量,就不能指望在自己的环境中得到相同的结果。
下面是一个用于在自有工作负载上比较这两种架构的基准测试框架。
"""
Mamba vs Transformer 实测基准测试运行器。
在受控环境下,针对同一组输入,测量两个模型的延迟、吞吐量、内存与质量。
"""
import time
import torch
import json
from dataclasses import dataclass, asdict
from pathlib import Path
@dataclass
class BenchmarkResult:
model_name: str
sequence_length: int
batch_size: int
# 性能指标
ttft_ms: float # Time to First Token
tps: float # Tokens per Second (生成)
total_latency_ms: float # 整体响应延迟
# 资源指标
peak_vram_gb: float
avg_vram_gb: float
# 质量指标 (单独评估)
quality_score: float = 0.0
class ModelBenchmarker:
def __init__(self, model, tokenizer, model_name: str):
self.model = model
self.tokenizer = tokenizer
self.model_name = model_name
@torch.no_grad()
def measure_generation(
self,
prompt: str,
max_new_tokens: int = 256,
) -> BenchmarkResult:
"""测量单条 prompt 的生成性能。"""
input_ids = self.tokenizer.encode(prompt, return_tensors="pt")
input_ids = input_ids.to(self.model.device)
seq_len = input_ids.shape[1]
torch.cuda.reset_peak_memory_stats()
# 测量 TTFT:到生成第一个 token 为止的时间
start = time.perf_counter()
outputs = self.model.generate(
input_ids,
max_new_tokens=1,
do_sample=False,
)
ttft = (time.perf_counter() - start) * 1000
# 测量整体生成
torch.cuda.synchronize()
start = time.perf_counter()
outputs = self.model.generate(
input_ids,
max_new_tokens=max_new_tokens,
do_sample=False,
)
total_time = (time.perf_counter() - start) * 1000
generated_tokens = outputs.shape[1] - seq_len
tps = generated_tokens / (total_time / 1000) if total_time > 0 else 0
peak_vram = torch.cuda.max_memory_allocated() / (1024**3)
current_vram = torch.cuda.memory_allocated() / (1024**3)
return BenchmarkResult(
model_name=self.model_name,
sequence_length=seq_len,
batch_size=1,
ttft_ms=round(ttft, 2),
tps=round(tps, 2),
total_latency_ms=round(total_time, 2),
peak_vram_gb=round(peak_vram, 3),
avg_vram_gb=round(current_vram, 3),
)
def run_suite(
self,
prompts: list[str],
max_new_tokens: int = 256,
) -> list[BenchmarkResult]:
"""对多条 prompt 执行基准测试并返回结果。"""
results = []
for prompt in prompts:
# 清理 GPU 缓存,最小化测量之间的相互干扰
torch.cuda.empty_cache()
result = self.measure_generation(prompt, max_new_tokens)
results.append(result)
return results
def compare_models(
results_a: list[BenchmarkResult],
results_b: list[BenchmarkResult],
) -> dict:
"""比较汇总两个模型的基准测试结果。"""
def avg(lst, field):
values = [getattr(r, field) for r in lst]
return sum(values) / len(values) if values else 0
return {
"model_a": results_a[0].model_name if results_a else "unknown",
"model_b": results_b[0].model_name if results_b else "unknown",
"ttft_ratio": avg(results_b, "ttft_ms") / max(avg(results_a, "ttft_ms"), 0.01),
"tps_ratio": avg(results_b, "tps") / max(avg(results_a, "tps"), 0.01),
"vram_ratio": avg(results_b, "peak_vram_gb") / max(avg(results_a, "peak_vram_gb"), 0.01),
"note": "ratio > 1 means model_b uses more of the metric than model_a",
}
按工作负载路由:不只选一个
在实务中最现实的策略,不是「只选一个」,而是根据请求特征做路由。
"""
根据请求特征,在 Transformer/Mamba 模型之间做动态路由的服务。
从简单的序列长度阈值开始,再基于质量反馈逐步改进路由策略。
"""
from dataclasses import dataclass
from enum import Enum
from typing import Protocol
class ModelType(Enum):
TRANSFORMER = "transformer"
MAMBA = "mamba"
@dataclass
class RoutingDecision:
model: ModelType
reason: str
confidence: float # 0.0 ~ 1.0
@dataclass
class RequestFeatures:
sequence_length: int
task_type: str # "chat", "summarization", "retrieval", "coding"
latency_budget_ms: int
gpu_memory_gb: float
requires_in_context_learning: bool = False
class ModelRouter:
"""基于规则的模型路由器。
初期采用显式规则起步,再根据 A/B 测试结果逐步更新规则。
"""
# 序列长度阈值:超过这个值时 Mamba 在 VRAM 上更高效
LONG_CONTEXT_THRESHOLD = 32_000
# 序列非常短时,Transformer 的开销可以忽略不计
SHORT_CONTEXT_THRESHOLD = 2_000
def route(self, features: RequestFeatures) -> RoutingDecision:
# 规则 1:需要 in-context learning 时选 Transformer
if features.requires_in_context_learning:
return RoutingDecision(
model=ModelType.TRANSFORMER,
reason="In-context learning requires attention mechanism",
confidence=0.9,
)
# 规则 2:长序列 + GPU 内存有限 -> Mamba
if (features.sequence_length > self.LONG_CONTEXT_THRESHOLD
and features.gpu_memory_gb <= 24):
return RoutingDecision(
model=ModelType.MAMBA,
reason=f"Seq len {features.sequence_length} exceeds {self.LONG_CONTEXT_THRESHOLD} "
f"with only {features.gpu_memory_gb}GB VRAM",
confidence=0.85,
)
# 规则 3:长序列 + 充足 GPU -> 按任务类型判断
if features.sequence_length > self.LONG_CONTEXT_THRESHOLD:
if features.task_type in ("summarization", "retrieval"):
return RoutingDecision(
model=ModelType.MAMBA,
reason="Long-context summarization/retrieval benefits from linear scaling",
confidence=0.7,
)
# 规则 4:序列较短时,利用 Transformer 生态系统的优势
if features.sequence_length < self.SHORT_CONTEXT_THRESHOLD:
return RoutingDecision(
model=ModelType.TRANSFORMER,
reason="Short sequences: Transformer ecosystem (vLLM, TensorRT) is more optimized",
confidence=0.8,
)
# 默认值:Transformer(生态成熟度更有优势)
return RoutingDecision(
model=ModelType.TRANSFORMER,
reason="Default: Transformer ecosystem maturity",
confidence=0.5,
)
迁移到生产环境时的注意事项
分词器兼容性
更换模型时容易被忽视的一点,是分词器(tokenizer)的差异。同一段文本,会因模型不同而被切分成不同数量的 token,因此成本估算、长度限制、prompt 设计都会受到影响。
def compare_tokenization(text: str, tokenizer_a, tokenizer_b) -> dict:
"""比较两个分词器的切分差异。
用于在更换模型之前,预先掌握 token 数量差异
对成本和质量造成的影响。
"""
tokens_a = tokenizer_a.encode(text)
tokens_b = tokenizer_b.encode(text)
return {
"text_length_chars": len(text),
"tokenizer_a_count": len(tokens_a),
"tokenizer_b_count": len(tokens_b),
"token_ratio": len(tokens_b) / len(tokens_a) if tokens_a else 0,
"cost_impact": f"Model B uses {len(tokens_b)/len(tokens_a)*100:.1f}% tokens vs Model A"
if tokens_a else "N/A",
# 韩语等非拉丁文字文本中差异较大
"sample_tokens_a": tokenizer_a.convert_ids_to_tokens(tokens_a[:20]),
"sample_tokens_b": tokenizer_b.convert_ids_to_tokens(tokens_b[:20]),
}
内核/驱动更新引发的回归
Mamba 的 custom CUDA kernel 对驱动版本很敏感。NVIDIA 驱动更新之后,有时性能会发生变化,甚至 kernel 会直接失败。
# 在 CI 中自动化模型回归测试的 GitHub Actions 示例
name: model-regression-gate
on:
pull_request:
paths:
- 'requirements*.txt'
- 'Dockerfile*'
- 'configs/model_*.yaml'
schedule:
- cron: '0 6 * * 1' # 每周一 06:00 UTC
jobs:
regression-test:
runs-on: [self-hosted, gpu, a100]
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: pip install -r requirements-inference.txt
- name: Run quality benchmark
run: |
python scripts/benchmark.py \
--models transformer,mamba \
--suite production_sample \
--output results/regression_$(date +%Y%m%d).json
- name: Check quality gate
run: |
python scripts/check_regression.py \
--results results/regression_$(date +%Y%m%d).json \
--min-quality 0.82 \
--max-p95-latency-ms 900 \
--max-vram-gb 24
- name: Upload results
if: always()
uses: actions/upload-artifact@v4
with:
name: regression-results
path: results/
实战故障排查
OOM:长上下文导致内存不足
症状:torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 4.00 GiB
原因分析:Transformer 处理 128K 上下文时,光是 KV cache 就要消耗数十 GB。举例来说,若是 70B 模型、80 层、64 个 head、head_dim=128,则:80 * 64 * 128K * 128 * 2(K,V) * 2(fp16) = 约 167GB
应对方案:
- chunked prefill:把输入按 chunk 拆分、依次处理。对应 vLLM 的
enable_chunked_prefill=True选项。 - KV cache quantization:把 KV cache 从 FP16 量化为 INT8/INT4。vLLM 0.4+ 起支持。
- 改用 Mamba:同样的输入下,由于 Mamba 的 state 大小与序列长度无关,可能不会发生 OOM。不过必须做质量验证。
基准测试与实际服务性能的落差
症状:论文/基准测试中 Mamba 快了 5 倍,但在实际服务中和 Transformer 的差距却很小。
原因分析:
- 基准测试是在 batch_size=1、最优序列长度下测得的,而实际服务并发请求多、序列长度也各不相同。
- Transformer 有 vLLM、TensorRT-LLM 等高度优化的 serving 框架,而 Mamba 目前还缺少这种水平的 serving 基础设施。
- continuous batching、paged attention 等 Transformer 专属的优化,大幅提升了 serving 效率。
应对方案:不使用 synthetic benchmark,而是用从实际 production log 中提取出的请求分布重新跑一次基准测试,把并发请求数、序列长度分布、batch size 都对齐到和实际服务一致。
延迟离散度骤增
症状:p50 正常,但 p99 却飙升到平时的 5 倍。
原因分析:在 GPU 集群中与其他工作负载共享 GPU 时,compute preemption 会引发间歇性延迟。尤其 Mamba 的 custom kernel 对 SM(Streaming Multiprocessor) 的占用率较高,因此对干扰更敏感。
应对方案:
- 把 inference 工作负载分离到专用 GPU 节点(MIG 或 dedicated node pool)。
- 设置并发请求上限(max concurrency),让 GPU utilization 不超过 95%。
- 设置 p99 延迟告警,超过阈值时自动把请求路由到其他节点。
用于选型的决策框架
最终的选择不取决于技术优劣,而是工作负载与组织状况的函数。
[开始]
|
v
序列长度是否主要在 32K 以上? ──No──> 维持 Transformer
| (生态优势压倒性)
Yes
|
v
GPU 内存是否充足 (>=80GB)? ──Yes──> Transformer + chunked prefill
| (若质量保证优先)
No
|
v
in-context learning 是否是核心需求? ──Yes──> Transformer (小模型 + 长上下文)
| 或 Jamba 这样的混合架构
No
|
v
质量要求是否达到「Transformer 水准」? ──Yes──> 混合架构 (Mamba + Attention layers)
|
No (可接受少量质量折衷)
|
v
引入 Mamba 后用 A/B 测试验证
参考资料
- Vaswani 等,《Attention Is All You Need》,2017 -- arxiv:1706.03762
- Gu & Dao,《Mamba: Linear-Time Sequence Modeling with Selective State Spaces》,2023 -- arxiv:2312.00752
- Dao & Gu,《Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality》,2024 -- arxiv:2405.21060
- Gu 等,《Efficiently Modeling Long Sequences with Structured State Spaces (S4)》,2021 -- arxiv:2111.00396
- Dao 等,《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》,2022 -- arxiv:2205.14135
- Mamba GitHub repository -- github.com/state-spaces/mamba
- vLLM documentation -- docs.vllm.ai
- PyTorch MultiheadAttention -- pytorch.org/docs
测验
-
Mamba 的「selective」与既有 SSM 相区分的核心差异是什么? 答案:||既有 SSM 无论输入如何都套用相同的 dynamics(A、B、C 矩阵),而 Mamba 会根据输入动态调节 B、C、delta 参数。这使得基于内容的推理(content-based reasoning)成为可能。||
-
Transformer 推理时 KV cache 的内存复杂度是? 答案:||O(L x d x layers x 2)。随序列长度(L)呈线性增长。在 128K 上下文的 70B 模型上,仅 KV cache 就可能消耗 100GB 以上。||
-
Mamba-2 的 State Space Duality 在实务上意味着什么? 答案:||它表明 SSM 与 attention 是同一数学结构(semi-separable matrix)的不同形态,为混合 Mamba 层与 attention 层的混合架构提供了理论依据。||
-
在短序列(2K 以下)中,也存在 Mamba 更有利的情况吗? 答案:||几乎没有。序列短时,Transformer 的 O(L^2) 成本可以忽略不计,而 vLLM/TensorRT 等高度优化的 serving 基础设施远比 Mamba 成熟。Mamba 的优势体现在长序列上。||
-
更换模型时若忽视分词器差异,会产生什么问题? 答案:||同一文本的 token 数量会发生变化,导致成本估算出现偏差,max_tokens 限制的实际效果也会改变,prompt 中 few-shot 示例的位置/占比可能偏离原意。尤其在韩语等非拉丁语言中,差异会更大。||
-
基准测试中 Mamba 快了 5 倍,但实际服务中差距很小,原因是什么? 答案:||基准测试是在 batch_size=1、最优条件下测得的,而实际服务应用了 continuous batching、paged attention 等 Transformer 专属的 serving 优化,Mamba 目前还缺少这种水平的 serving 基础设施。||
-
同时运营两个模型时,作为路由标准最实用的第一个变量是什么? 答案:||序列长度。把 32K 以上的长上下文路由给 Mamba、短上下文路由给 Transformer,是最简单有效的起点。||
-
GPU 驱动更新后 Mamba 性能下降时,应该最先确认的是什么? 答案:||Mamba 的 custom CUDA kernel 兼容性。需要确认 mamba-ssm 包是否针对新驱动/CUDA 版本做了 recompile,以及 kernel launch configuration 在新 GPU 架构上是否正常工作。||
현재 단락 (1/298)
Transformer(Vaswani 等,2017,[arxiv:1706.03762](https://arxiv.org/abs/1706.03762))通过 self-attention 机制...