8.1 Transformer 的二次复杂度问题

为什么“所有的大模型都用 Transformer”这句话不再完全正确

8.1.1 Transformer 曾经是完美的

2017 年“Attention is All You Need”论文发表时，Transformer 看起来是一个优雅的解决方案。相比之前的 RNN（递归神经网络），它有一个关键优势：

RNN的问题：
序列处理 → 一个token一个token处理
           └─ 必须等待前面的token处理完
           └─ 无法并行化

Transformer的优势：
注意力机制 → 所有token可以同时看到彼此
             └─ 可以并行处理
             └─ 训练速度大幅提升

这就是为什么 Transformer 能够支撑更大的模型规模。更大的模型需要更快的训练，而 Transformer 的并行性正好满足这个需求。

8.1.2 问题显露：二次复杂度

虽然 Transformer 很强大，但它有一个隐藏的数学问题，只有在处理非常长的序列时才会显现：

什么是二次复杂度？

Transformer的注意力机制工作方式：

对于每一个token，它需要：
1. 计算这个token与所有其他token的相似度
2. 这涉及一个名为"注意力矩阵"的计算

如果序列中有N个token：
- 注意力矩阵大小：N × N
- 计算复杂度：O(N²)

例子：
100 token → 100×100 = 10,000 单位计算
1,000 token → 1,000×1,000 = 1,000,000 单位计算
10,000 token → 10,000×10,000 = 100,000,000 单位计算

看到问题了吗？随着序列长度增加，计算量以平方增长！

用生活中的例子理解

想象一个会议：

场景1：5个人的会议
- 每个人需要听其他4个人说话
- 每对人之间的沟通：5×5 = 25次互动
- 管理起来还可以

场景2：100个人的会议
- 每个人需要听其他99个人说话
- 每对人之间的沟通：100×100 = 10,000次互动
- 开始变得很混乱

场景3：1,000,000个人的"会议"
- 每对人之间的沟通：1,000,000×1,000,000次
- 完全不可能！

这就是Transformer处理长文本时的情况。

8.1.3 影响：为什么这很重要？

速度的代价

处理不同长度文本的时间：

长度        处理时间      成本（相对）
─────────────────────────────
2K token    0.5秒        $0.01
4K token    1秒          $0.04
8K token    2秒          $0.16
16K token   4秒          $0.64
100K token  25秒         $25
200K token  100秒        $100

看到趋势了吗？处理长文本的成本增长非常快。

内存的代价

不仅时间增长，内存也以平方的方式增长：

内存占用估计（处理单个文本）：

长度         内存
──────────────────
4K token     1 GB
8K token     4 GB
16K token    16 GB
32K token    64 GB
100K token   625 GB（无法实现！）
200K token   2.5 TB（完全不可能！）

这就是为什么即使是最强大的 GPU，也无法处理超级长的序列。

8.1.4 真实的影响：哪些应用受限？

受影响的应用场景

✗ Transformer无法很好处理的任务：

1. 长文档处理
   - 处理整本书（几百万字）
   - 处理完整的法律文件库
   - 原因：成本和内存都会爆炸

2. 持久的对话记忆
   - 保留完整的对话历史（几千条消息）
   - 在一个关键字段中应用集合知识
   - 原因：历史消息越多，处理越慢

3. 实时信息流处理
   - 实时监控日志或数据流
   - 持续分析数据而不丢失历史
   - 原因：流的长度不断增加

4. 多文档分析
   - 同时分析多个长文档
   - 比较和综合大量资料
   - 原因：总序列长度会非常长

✓ Transformer仍然很擅长的任务：
├─ 一般的对话
├─ 代码生成（通常不需要超长上下文）
├─ 摘要和翻译
└─ 大多数日常任务

8.1.5 行业的应对方式

现有的解决方案（不太完美）

为了解决这个问题，行业采取了一些变通方案：

方案1：上下文窗口扩展
做法：用更复杂的工程技巧，支持更长的序列
成本：仍然是二次复杂度，只是常数更大
效果：只是延后了问题，没有根本解决

例如：
- Claude 3的200K token窗口
- GPT-4o的128K token窗口
- 这些仍然很昂贵，而且有上限

方案2：检索增强生成（RAG）
做法：不是把所有文本都给模型，而是只检索相关部分
成本：降低了Transformer需要处理的序列长度
效果：有用，但不够灵活

方案3：信息压缩
做法：把长文本先压缩成摘要，再给模型
成本：损失信息，可能遗漏重要细节
效果：是权衡，但不完美

8.1.6 新的解决方案：状态空间模型

这就是为什么一个新的想法变得引人注目：

与其扩展注意力机制，不如放弃它，用完全不同的方法。

这个新方法就是 状态空间模型（State Space Models，SSM）。

Transformer vs SSM：

Transformer：
复杂度：O(N²)
内存：O(N²)
特点：每个token都与所有其他token互动
问题：长序列时爆炸

SSM：
复杂度：O(N)  ← 线性！
内存：O(N)    ← 线性！
特点：维护一个"状态"，处理每个token时更新
优点：长序列也可以处理

简单类比：记忆的方式

想象两个人在看一部电影：

Transformer的方式：
观看者必须记住电影中的每一帧，
然后计算每一帧与所有其他帧的关系。
看100分钟的电影 = 144,000帧 × 144,000帧的比较
= 完全不可能！

SSM的方式：
观看者只需要维护对"当前故事状态"的理解。
看到新的一幕时，更新理解。
看完了，就有了完整的故事理解。
随着电影长度增加，需要的处理量线性增加。

8.1.7 本节小结

Transformer 的二次复杂度是其根本的数学限制：

• 处理长序列时，时间和内存成平方增长

• 这限制了许多实际应用

• 为了解决这个问题，新的架构（SSM）被开发出来

这不是说 Transformer“坏”——它在当前的任务上仍然很好。而是说它不是所有问题的最优解。

就像飞机不是所有交通工具中最快的（火箭比它快），但对大多数出行来说仍然是最好的选择。现在，新的“火箭”（SSM 架构）出现了，针对特定的问题（长序列处理）。

8.1.8 思考题

1. 如果你要处理一部 100 万字的小说，用 Transformer 和 SSM 分别需要多少计算资源？

2. 二次复杂度是 Transformer 的根本性问题吗？还是可以通过工程优化来解决？

3. 如果 SSM 没有注意力机制，它是如何理解上下文的？（这是我们在下一节要回答的问题）