> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/ai_beginner_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/ai_beginner_guide/di-er-bu-fen-he-xin-ji-shu-jie-xi/08_new_architectures/8.1_transformer_limitation.md). # 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 很强大，但它有一个隐藏的数学问题，只有在处理非常长的序列时才会显现： ## 8.1.2.1 什么是二次复杂度？ ``` 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 单位计算 看到问题了吗？随着序列长度增加，计算量以平方增长！ ``` ## 8.1.2.2 用生活中的例子理解 想象一个会议： ``` 场景1：5个人的会议 - 每个人需要听其他4个人说话 - 如果建一个“谁关注谁”的矩阵：5×5 = 25 个格子 - 如果不算自己关注自己：5×4 = 20 次有方向的互动 - 管理起来还可以 场景2：100个人的会议 - 每个人需要听其他99个人说话 - 注意力矩阵：100×100 = 10,000 个格子 - 开始变得很混乱 场景3：1,000,000个人的"会议" - 注意力矩阵：1,000,000×1,000,000 个格子 - 完全不可能！ 这就是Transformer处理长文本时的情况。 ``` ## 8.1.3 影响：为什么这很重要？ ## 8.1.3.1 速度的代价 ``` 处理不同长度文本的时间： 长度 处理时间 成本（相对） ───────────────────────────── 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 50秒 $100 ``` 看到趋势了吗？处理长文本的成本增长非常快。 ## 8.1.3.2 内存的代价 显存这一侧则要分开看。**计算量**随长度平方增长，所以长文本又慢又贵；但**显存**的大头并不是那张 N×N 的注意力矩阵——现代实现会分块计算、不把它整个写进显存。真正占显存的是 **KV Cache**（模型为已经读过的每个 token 保存的“记忆”），它随长度**线性**增长。 本书 6.6.2 有一整节讲 KV Cache 为什么是「吞噬显存的怪兽」，8.6 讲的 MLA 也正是冲着压缩它去的。 这就是为什么百万 token 的窗口在今天能跑起来，但依然很贵——贵在平方增长的**算力**，以及线性增长却基数很大的 **KV Cache**。 ## 8.1.4 真实的影响：哪些应用受限？ ## 8.1.4.1 受影响的应用场景 ``` ✗ Transformer无法很好处理的任务： 1. 长文档处理 - 处理整本书（几百万字） - 处理完整的法律文件库 - 原因：成本和内存都会爆炸 2. 持久的对话记忆 - 保留完整的对话历史（几千条消息） - 在一个关键字段中应用集合知识 - 原因：历史消息越多，处理越慢 3. 实时信息流处理 - 实时监控日志或数据流 - 持续分析数据而不丢失历史 - 原因：流的长度不断增加 4. 多文档分析 - 同时分析多个长文档 - 比较和综合大量资料 - 原因：总序列长度会非常长 ✓ Transformer仍然很擅长的任务： ├─ 一般的对话 ├─ 代码生成（通常不需要超长上下文） ├─ 摘要和翻译 └─ 大多数日常任务 ``` ## 8.1.5 行业的应对方式 ## 8.1.5.1 现有的解决方案（不太完美） 为了解决这个问题，行业采取了一些变通方案： ``` 方案1：上下文窗口扩展 做法：用更复杂的工程技巧，支持更长的序列 成本：仍然是二次复杂度，只是常数更大 效果：只是延后了问题，没有根本解决 例如： - Claude Opus 5.5 的 1M token 窗口 - GPT-5.5 的 1M token 窗口 - 这些仍然很昂贵，而且有上限 方案2：检索增强生成（RAG） 做法：不是把所有文本都给模型，而是只检索相关部分 成本：降低了Transformer需要处理的序列长度 效果：有用，但不够灵活 方案3：信息压缩 做法：把长文本先压缩成摘要，再给模型 成本：损失信息，可能遗漏重要细节 效果：是权衡，但不完美 ``` ## 8.1.6 新的解决方案：状态空间模型 ## 8.1.6.1 核心思想 这就是为什么一个新的想法变得引人注目： > **与其扩展注意力机制，不如放弃它，用完全不同的方法。** 这个新方法就是 **状态空间模型**（State Space Models，SSM）。 ``` Transformer vs SSM： Transformer： 复杂度：O(N²) 内存：O(N²) 特点：每个token都与所有其他token互动 问题：长序列时爆炸 SSM： 复杂度：O(N) ← 线性！ 内存：O(N) ← 线性！ 特点：维护一个"状态"，处理每个token时更新 优点：长序列也可以处理 ``` ## 8.1.6.2 简单类比：记忆的方式 想象两个人在看一部电影： ``` 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 没有注意力机制，它是如何理解上下文的？（这是我们在下一节要回答的问题）