# 2.5 SSM vs Transformer 在上下文工程中的对比

## 2.5.1 引言：架构之战如何影响上下文策略

2024年以来，大模型架构出现了显著的分化。Transformer凭借其自注意力机制长期统治，但一类新兴架构——**状态空间模型（SSM, State Space Models）**——开始对LLM领域产生深远影响。这不仅仅是学术讨论，更直接改变了我们设计上下文工程策略的方式。

不同架构在处理上下文时具有根本性差异：

* **自注意力复杂度**：Transformer为O(n²)，SSM为O(n)
* **上下文长度成本**：长上下文下，Transformer费用陡增，SSM线性增长
* **信息流向**：Transformer全局互注，SSM线性扫描
* **检索策略**：需要不同的优化方向

本节将深入分析这两类架构在上下文工程中的实际影响，帮助您为不同架构设计合适的上下文策略。

## 2.5.2 Transformer自注意力机制与上下文成本

### 自注意力的计算本质

Transformer的核心是自注意力（Self-Attention）机制。对于长度为 n 的上下文序列，注意力的计算方式为：

```
Attention(Q, K, V) = softmax(Q·K^T / √d_k)·V
```

关键的成本特征：

* **时间复杂度**：O(n²)，其中 n 是上下文长度
* **空间复杂度**：朴素训练实现会产生 O(n²) 注意力中间状态；现代推理通常通过内核优化避免长期保存完整注意力矩阵，但 KV Cache 仍随上下文长度线性增长
* **每个Token成本随上下文线性增长**：第i个Token需要计算与所有(i-1)个前序Token的注意力

### 上下文长度与成本的非线性关系

```mermaid
graph LR
    A["上下文长度(K tokens)"] -->|"Transformer<br/>O(n²)"| B["计算成本<br/>& Token费用"]
    A -->|"SSM<br/>O(n)"| C["线性增长"]
    B -->|"4K→8K<br/>增长4倍"| D["成本陡增"]
    C -->|"4K→8K<br/>增长2倍"| E["线性增长"]
```

实际例子：假设使用按 Token 计费的 API（如输入价格 $0.003/1K token）。**这里要分清两个概念**：API 账单通常只看输入 Token 数，而模型内部的计算压力则取决于架构复杂度。

| 上下文长度 | Token数 | API 输入成本 | Transformer 理论计算量（相对 4K） | SSM 理论计算量（相对 4K） | 工程含义                                |
| ----- | ------ | -------- | ------------------------ | ---------------- | ----------------------------------- |
| 4K    | 4000   | $0.012   | 1x                       | 1x               | 基线                                  |
| 8K    | 8000   | $0.024   | 4x                       | 2x               | Transformer 的延迟和显存压力开始明显上升          |
| 32K   | 32000  | $0.096   | 64x                      | 8x               | 更依赖检索裁剪、压缩与重排序                      |
| 128K  | 128000 | $0.384   | 1024x                    | 32x              | Transformer 侧的注意力与 KV Cache 压力会急剧放大 |
| 256K  | 256000 | $0.768   | 4096x                    | 64x              | 长上下文下更需要架构和系统级优化                    |

注：虽然 API 账单相同，**关键差异在内部计算与系统开销**。同样的上下文长度下：

* **Transformer**：随着上下文长度增加，注意力计算、显存占用和端到端延迟通常会更快恶化
* **SSM**：理论复杂度更平滑，但真实吞吐量仍受实现、硬件、批大小和算子优化影响，不能简单理解为“长序列一定线性提速”

此外，**内存占用** 也显著不同：

* 朴素 Transformer 训练需要处理注意力矩阵（O(n²)计算/中间状态压力）；现代推理内核通常不会长期保存完整注意力矩阵，但 KV Cache 仍会随上下文长度线性增长
* SSM 推理的递推状态可以是固定或近似固定规模，但训练、批处理和混合注意力层仍会引入额外内存；不要把理论 O(d) 状态直接等同为固定 MB 数

这使得 SSM 在 **相同 Token 账单** 下，往往更有机会把预算转化为更稳定的延迟、更高的并发容量或更长的可承载上下文，但具体收益仍取决于实现细节和部署方式。

### Attention中的上下文丢失问题

Transformer的自注意力虽然强大，但面临一个悖论性的上下文工程问题：**“注意力分散”**（attention dilution）

```python
# 简化示意：当上下文过长时的问题
context_length = 128000
position_bias = {
    "beginning": "often easier to retrieve",
    "middle": "often easier to miss",
    "end": "often easier to retrieve",
}

# 结果：
# - 注意力不是平均分配给每个 Token
# - 长上下文会放大位置偏置、检索噪声和证据排序问题
# - 需要重排序、摘要、分块引用和显式证据检查来缓解
```

这导致一个现象：**虽然Transformer理论上可以看到所有上下文，但在实际应用中，过长上下文会导致“关键信息注意力不足”**。研究表明，Transformer经常只关注开头和结尾的信息（Lost-in-the-Middle问题）。

## 2.5.3 SSM与线性复杂度的上下文处理

### 状态空间模型的数学基础

SSM将序列处理建模为状态演化过程：

```
h_t = A·h_{t-1} + B·x_t  （状态更新）
y_t = C·h_t + D·x_t      （输出生成）
```

其中：

* **h\_t**：隐状态（固定维度，如1024或4096）
* **A, B, C, D**：可学习矩阵
* **x\_t**：输入Token

关键特性：

1. **固定内存占用**：无论上下文多长，隐状态维度固定
2. **线性时间复杂度**：每个Token的处理时间恒定
3. **因果结构**：天然支持流式处理，h\_t只依赖h\_{t-1}

### Mamba与选择性状态空间

2023年Mamba的发布引入了 **选择性状态空间（Selective State Space）**，解决了基础SSM的一个关键问题：**固定的参数矩阵A无法根据输入动态调整**。

```
# Mamba的核心创新：动态选择（Dynamic Selection）
Δ_t = softmax(W_Δ·x_t)  # 根据当前输入动态确定时间尺度
A_t = exp(-Δ_t·A)        # 动态衰减矩阵
h_t = A_t * h_{t-1} + B_t * x_t
```

这使Mamba能够：

* **动态遗忘**：根据输入重要性调整隐状态更新
* **选择性记忆**：只在必要时候保留信息
* **上下文感知**：隐状态的演化取决于输入序列的内容

### 上下文长度的线性扩展

对于 SSM 模型（如 Mamba-2），理论上的序列扫描成本更接近线性，但真实部署还受混合层、批处理、硬件和服务实现影响：

```mermaid
graph TB
    A["SSM架构特性"] -->|"固定隐状态维度"| B["内存O(d)"]
    A -->|"线性时间复杂度"| C["计算O(n·d)"]
    B --> D["即使n=1M,<br/>内存占用恒定"]
    C --> E["n增加k倍,<br/>计算增加k倍"]
    E --> F["完全可预测的<br/>成本扩展"]
```

文献与工程报告中，SSM/混合架构在长上下文场景下通常会展现出以下量级优势：

| 指标       | 纯 Transformer（长上下文） | SSM / 混合架构（长上下文） | 常见差异 |
| -------- | ------------------- | ---------------- | ---- |
| 吞吐量      | 更易随序列变长而下滑          | 更容易保持稳定          | 中到高  |
| 内存占用     | 注意力矩阵与缓存压力更大        | 通常更可控            | 高    |
| 推理延迟     | 更易受长序列拖累            | 更容易平滑扩展          | 中到高  |
| 长上下文扩展成本 | 上升更快                | 更可预测             | 高    |

## 2.5.4 混合架构的兴起

鉴于纯Transformer和纯SSM各有优缺点，业界推出了 **混合架构**：

### Jamba

结构：**交错的SSM层和注意力层**

```
Layer 1: SSM
Layer 2: Attention (全局)
Layer 3: SSM
Layer 4: Attention (全局)
...
```

优势：

* SSM层处理大规模上下文，成本低
* Attention层在关键位置提供全局视角
* 相比纯Transformer节省60%的训练成本
* 32K上下文性能与256K上下文Transformer相当

### Bamba

结构：**层级混合 + Bottleneck机制**

```mermaid
graph TB
    A["输入"] --> B["SSM主干<br/>(高效处理)"]
    B --> C["注意力瓶颈<br/>(关键信息)"]
    C --> D["输出"]
    E["长上下文"] --> |"经SSM快速处理"| F["关键信息提取"]
    F --> |"经注意力细化"| G["精确输出"]
```

特点：

* 大部分层为SSM（低成本）
* 仅在必要位置使用Attention
* 特别适合长序列处理

### Titans + MIRAS

最新方向：**门控线性注意力 + Mamba融合**

```python
# 伪代码示意
class TitansMIRAS(nn.Module):
    def __init__(self):
        self.mamba_layer = MambaBlock()
        self.gated_linear_attn = GatedLinearAttention()

    def forward(self, x):
        # SSM处理
        mamba_out = self.mamba_layer(x)  # O(n)

        # 门控线性注意力（比标准Attention更高效）
        attn_out = self.gated_linear_attn(x)  # O(n)

        # 融合
        return self.gate(mamba_out, attn_out)
```

优势：

* 两路都是线性复杂度
* 保留了全局信息流
* 100K+上下文下性能接近短上下文

## 2.5.5 架构选择对上下文工程的实际影响

### Transformer模型的检索优化

```python
# Transformer模型：长上下文成本高，需要优化检索
class TransformerRetrievalStrategy:
    def __init__(self):
        # 1. 严格控制检索数量
        self.max_context_tokens = 4000  # 保持在4K以内
        self.target_chunks = 5  # 少量高质量chunk

        # 2. 重排序至关重要
        self.use_reranker = True
        self.rerank_top_k = 50  # 从50个候选中选5个

        # 3. 压缩策略
        self.use_compression = True
        self.compression_ratio = 0.5  # 压缩一半

    def retrieve_and_prepare(self, query, documents):
        # 密集检索 -> 重排序 -> 压缩
        candidates = self.dense_retrieve(query, top_k=50)
        reranked = self.rerank(query, candidates, k=5)
        compressed = self.compress(reranked)
        return compressed  # ≈ 2K tokens
```

### SSM/Mamba模型的检索优化

```python
# SSM模型：可以容纳更多上下文，检索策略不同
class SSMRetrievalStrategy:
    def __init__(self):
        # 1. 放宽上下文限制，但仍需实测延迟和质量
        self.max_context_tokens = 64000
        self.target_chunks = 50  # 获取更多内容

        # 2. 重排序可选
        self.use_reranker = False  # 也可选择性使用

        # 3. 压缩可选
        self.use_compression = False

    def retrieve_and_prepare(self, query, documents):
        # 密集检索 -> 直接使用
        candidates = self.dense_retrieve(query, top_k=50)
        return candidates  # ≈ 50K tokens, 成本仍可接受
```

### Token 成本与架构成本的边界

商业 API 通常按输入/输出 Token、缓存、工具调用或服务层级计费，而不是按底层架构单独定价。SSM 或混合架构的优势更多体现在供应商侧的吞吐、显存和延迟，未必直接表现为更低的 API 单价。以下仅是教学测算，使用示例单价说明上下文长度如何影响账单；实际项目应以部署当天的官方价格页、缓存命中率和账号服务层级重新计算。假设一个 QA 系统，平均查询返回 50 个检索结果：

**Transformer 架构（代表性 API 模型）**

* 每query成本：50×256字/chunk×0.75 token/字×$0.0025/1K = $0.024
* 月成本（10000 queries）：$240

**SSM / 混合架构假设（同一 Token 单价）**

* 每query成本：同样 50 chunks，账单不会因为架构本身自动下降
* 每query成本：$0.024
* **但可以提高质量**：如增加到200 chunks
* 新成本：$0.096，月成本$960
* **质量提升**：只有在离线评测证明更多上下文确实提高答案质量时才成立

## 2.5.6 上下文工程策略针对不同架构的优化建议

### 对于Transformer模型

1. **上下文控制**

   ```
   成本敏感路径：优先控制在任务必需范围内
   长上下文路径：按模型官方窗口、延迟和预算上限决定
   超过阈值：用实测质量收益与额外成本判断
   ```
2. **检索优化优先级**
   * 最高：重排序器（相关性精准）
   * 次高：压缩（减少token）
   * 可选：知识图谱（提升结构化查询）
3. **缓存策略**
   * 启用Prompt Caching
   * 系统提示词固定 → 重复使用 → 缓存命中率高
   * 预缓存常见的长上下文片段
4. **成本优化杠杆**

   ```
   # 成本优化的优先级
   优化1：减少检索chunk数（影响最大）
   优化2：启用缓存（收益取决于供应商价格与命中率）
   优化3：压缩上下文（收益取决于压缩率与质量损失）
   优化4：使用更便宜模型（需同步验证质量）
   ```

### 对于SSM/Mamba模型

1. **上下文充分利用**

   ```
   可尝试窗口：32K-128K tokens
   更长窗口：取决于具体模型、服务配额和质量评测
   成本增长：理论计算更接近线性，API 账单仍按供应商定价
   ```
2. **检索优化优先级**
   * 优先：检索数量增加（成本仍可控）
   * 次要：重排序（可选，用于极高精度）
   * 可选：压缩（牺牲质量无必要）
3. **上下文设计**

   ```
   # SSM友好的上下文设计
   - 长系统提示词：可详细规范指令
   - 长对话历史：保留完整上下文
   - 多文档检索：一次性处理数十篇文档
   - 知识库融合：检索+知识图谱可并用
   ```
4. **架构利用策略**
   * 利用线性复杂度处理 **超长上下文任务**
   * 特别是：长文档分析、多轮对话、知识库问答
   * 单次请求可以包含整个会话历史

### 混合架构的策略

利用两者优势：

```python
class HybridArchitectureStrategy:
    """
    混合架构同时拥有Transformer和SSM特性
    策略：
    1. 短上下文（<4K）：SSM层足以处理，性能优异
    2. 中等上下文（4K-32K）：发挥混合优势，既有质量又有效率
    3. 长上下文（32K+）：SSM主要处理，Attention瓶颈提高关键信息
    """

    def optimize_for_hybrid(self, query_complexity, context_size):
        if context_size < 4000:
            # SSM层会处理充分，低成本高效
            use_reranking = False  # 不必要
            compression_ratio = 0.0  # 无需压缩
        elif context_size < 32000:
            # 混合发挥最大作用
            use_reranking = True  # 优化Attention层的输入
            compression_ratio = 0.0  # 无需压缩
        else:
            # 长上下文，SSM主处理
            use_reranking = False  # 不必要，SSM已高效
            compression_ratio = 0.0  # 无需压缩
```

## 2.5.7 实践案例：同一任务在不同架构下的上下文工程

**任务**：法律合同审查系统，需要分析用户的合同并对标行业模板

**输入**：

* 用户合同：50KB（\~35K tokens）
* 行业模板库：10份典型合同模板（\~200K tokens）
* 审查指南：10个审查维度（\~5K tokens）
* 用户历史问题上下文：（\~5K tokens）

**总需求上下文：\~245K tokens**

### Transformer 架构方案（代表性 API 模型）

```
实际可用上下文：128K（最大）
限制：无法同时加载所有内容

分解策略：
1. 固定内容（系统提示+审查指南）：5K → 启用缓存
2. 用户合同：35K
3. 相关模板检索：只检索最相关3份（~60K tokens）
4. 总计：≈100K tokens

成本计算：
- 系统提示（缓存）：5K×$0.00025/K = $0.00125（首次$0.003125，后续折扣）
- 用户合同+模板：95K×$0.0025/K = $0.2375
- 输出：~2K tokens×$0.015/K = $0.03
- 总成本/请求：$0.269（缓存命中后）

质量折衷：无法同时引用所有模板，可能遗漏重要参照
```

### SSM/Mamba架构方案

```
可用上下文：200K（取决于具体模型和部署）
完整使用：可同时加载所有内容

完整策略：
1. 系统提示+审查指南：5K
2. 用户合同：35K
3. 所有行业模板库：200K
4. 用户历史：5K
5. 总计：245K tokens

成本计算（沿用上文示例单价，非实时价格）：
- 245K tokens×$0.0025/K = $0.6125
- 输出：~2K tokens×$0.015/K = $0.03
- 总成本/请求：$0.6425

质量优势：
- 模型可参考所有模板
- 更准确的对标分析
- 更全面的风险识别
- 一次完整分析，无遗漏

价值评估（需项目实测）：
成本增加：$0.6425 - $0.269 = $0.3735（139%）
价值增加：更全面的法律风险识别，可避免潜在法律风险
只有在真实评测证明额外上下文能稳定发现高价值风险时，增加的推理成本才可能成立。
```

## 2.5.8 如何选择最适合的架构

建立决策框架：

```mermaid
graph TD
    A["评估应用需求"] --> B{"上下文长度需求"}
    B -->|"<8K"| C["Transformer/纯LLM"]
    B -->|"8K-32K"| D{"需要高质量或复杂推理"}
    B -->|">32K"| E["SSM/Mamba"]

    D -->|"是"| F["Transformer<br/>使用缓存+优化"]
    D -->|"否"| G["混合架构<br/>Jamba/Bamba"]

    C --> H["成本优化重点：<br/>模型选择"]
    F --> I["成本优化重点：<br/>缓存+重排序"]
    G --> J["成本优化重点：<br/>层级利用"]
    E --> K["成本优化重点：<br/>充分利用长度"]
```

关键指标表：

| 架构           | 最优上下文                            | 推理速度 | 成本效率       | 复杂推理 | 生产成熟度 |
| ------------ | -------------------------------- | ---- | ---------- | ---- | ----- |
| Transformer  | 成本敏感路径可控制在 4K-32K；长上下文模型可扩展到更大窗口 | 中等   | 取决于缓存与窗口使用 | 优    | 最成熟   |
| SSM/Mamba    | 32K-128K                         | 快    | 优          | 中等   | 快速成熟  |
| 混合(Jamba)    | 8K-32K                           | 快    | 优          | 优    | 初期    |
| 混合(Bamba)    | 8K-32K                           | 快    | 优          | 优    | 初期    |
| Titans+MIRAS | 64K-256K                         | 很快   | 优          | 优    | 研究阶段  |

## 2.5.9 小结

| 维度     | Transformer                | SSM/Mamba          | 混合架构      |
| ------ | -------------------------- | ------------------ | --------- |
| 上下文成本  | 注意力计算压力上升快；API 账单通常按 Token | 理论计算更平滑；API 账单看供应商 | 介于两者之间    |
| 推荐窗口   | 以任务必要信息量、延迟和预算决定           | 可更积极测试长上下文         | 适合中长上下文试点 |
| 检索重点   | 精准→压缩                      | 充分→多样              | 平衡两端      |
| 缓存策略   | 启用优先                       | 可选                 | 启用优先      |
| 长上下文应用 | 可用，但要按质量、延迟和成本评测           | 优先测试               | 适中支持      |
| 成熟度    | 生产级                        | 快速上升               | 初期        |

选择合适的架构并采用相应的上下文工程策略，可以在保持或提升质量的同时，将成本降低30-70%。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/context_engineering_guide/di-yi-bu-fen-ren-shi-shang-xia-wen-gong-cheng/02_llm_basics/2.5_ssm_vs_transformer.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.