# 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 100秒 $100 ``` 看到趋势了吗？处理长文本的成本增长非常快。 ## 8.1.3.2 内存的代价 不仅时间增长，内存也以平方的方式增长： ``` 内存占用估计（处理单个文本）： 长度 内存 ────────────────── 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 真实的影响：哪些应用受限？ ## 8.1.4.1 受影响的应用场景 ``` ✗ Transformer无法很好处理的任务： 1. 长文档处理 - 处理整本书（几百万字） - 处理完整的法律文件库 - 原因：成本和内存都会爆炸 2. 持久的对话记忆 - 保留完整的对话历史（几千条消息） - 在一个关键字段中应用集合知识 - 原因：历史消息越多，处理越慢 3. 实时信息流处理 - 实时监控日志或数据流 - 持续分析数据而不丢失历史 - 原因：流的长度不断增加 4. 多文档分析 - 同时分析多个长文档 - 比较和综合大量资料 - 原因：总序列长度会非常长 ✓ Transformer仍然很擅长的任务： ├─ 一般的对话 ├─ 代码生成（通常不需要超长上下文） ├─ 摘要和翻译 └─ 大多数日常任务 ``` ## 8.1.5 行业的应对方式 ## 8.1.5.1 现有的解决方案（不太完美） 为了解决这个问题，行业采取了一些变通方案： ``` 方案1：上下文窗口扩展 做法：用更复杂的工程技巧，支持更长的序列 成本：仍然是二次复杂度，只是常数更大 效果：只是延后了问题，没有根本解决 例如： - Claude Opus 4.7 的 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 没有注意力机制，它是如何理解上下文的？（这是我们在下一节要回答的问题） --- # 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/ai_beginner_guide/di-er-bu-fen-he-xin-ji-shu-jie-xi/08_new_architectures/8.1_transformer_limitation.md?ask= ``` 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.