
本文是【LLM架构管窥 ◆ 系列小文】的第3篇。

【LLM架构管窥 ◆ 系列小文】旨在快速盘点LLM架构特点、特别是局限性，为后续【基于SDD的AI编程最佳实践】提供必要的认知准备。

---

### 引言

为什么模型会有“幻觉”、为什么长文本推理慢、为什么有些模型号称“百万字长文本”却记不住细节？

上下文窗口（Context Window）大小直接决定了大语言模型（LLM）能够同时处理和关联的信息量，成为衡量模型性能的关键指标。早期模型如GPT-3的4K token窗口或LLaMA的8K token窗口，使模型在处理长文档、复杂对话时频繁出现“失忆”现象。尽管技术发展使得上下文长度从数K扩展到数百万token，但根本性瓶颈并未消失。
![上下文 引言.jpg](https://developer.qcloudimg.com/http-save/yehe-11563618/da941f4f95228a2bab41612a9ee42d2b.jpg)

---

### 一、 上下文窗口：不是容器，是“循环缓冲区”

内容方面：上下文窗口不是一个只装“用户提问”的静态容器，而是一个**循环缓冲区**。已用窗口 = 系统提示 + 历史对话 + 当前问题 + 模型已生成的回答。

动态过程：这意味着在多轮对话中，模型的每一次回答都会占用窗口空间。一旦总长度超标，最早的信息（通常是对话开头的指令或背景）会被“挤出去”或截断，导致**强制性遗忘**。

<div align="center"><img src="https://developer.qcloudimg.com/http-save/yehe-11563618/ac1ed6d666b288ed40953e27d8b7abb0.jpg" width="80%"></div>


---

### 二、 上下文窗口的五重瓶颈

标称窗口 ≠ 有效上下文 (Effective Context)

**我们看到的参数，不代表模型真正的能力**厂商宣传的“128k 窗口”是**理论最大值**（Theoretical Max），而非**有效利用值**（Effective Use）。

上下文窗口是一个受限于硬件、算法和认知偏差的“有损耗工作区”，其实际可用的智能上限远低于标称长度。
这也是为什么在实际工程中，我们更倾向于用 RAG（检索增强）而不是硬塞长文本的原因。

* **现实瓶颈**：
  * 受限于显存，你可能跑不到 128k 就 OOM（显存溢出）了；
  * 受限于“Lost in the Middle”，模型可能根本找不到藏在深处的信息；
  * 受限于稀疏化，模型可能只“看”了个大概。

| 维度 | 瓶颈 | 一句话解释 |
| :--- | :--- | :--- |
| **物理层** | **KV Cache / 显存** | 上下文越长，显存爆炸，推理越慢。 |
| **算法层** | **注意力机制 $O(N^2)$** | 计算量随长度呈平方级增长，是速度瓶颈。 |
| **算法层** | **Lost in Middle 现象** | 模型对窗口中间的信息记忆力最差。 |
| **模型层** | **位置编码越界** | RoPE位置编码通过旋转角度来编码位置信息，角度值固定的。 |
| **工程层** | **有损处理** | 使用稀疏注意力与压缩，意味着长文本某些细节丢失。 |
| **应用层** | **有限增强** | 窗口有限，通常只把RAG (检索增强)的部分片段塞进上下文。 |

<div align="center"><img src="https://developer.qcloudimg.com/http-save/yehe-11563618/be4fc7ac379e758eaf1eeb18228c4792.png" width="60%"></div>


#### 1. 硬件瓶颈：KV Cache 与显存爆炸

* 显存占用随上下文长度**线性增长**。
  * LLM 会把之前计算过的 hidden states 存到显存里，这叫 KV Cache。
  * 处理 8k 上下文可能只需 16GB 显存；
  * 处理 100k 上下文可能需要几百 GB 显存（远超普通消费级显卡极限）。
  * 这是工程落地的**物理硬墙**，决定了长文本推理的成本极高。


#### **2. 算法瓶颈：注意力机制的 $O(N^2)$ 计算复杂度**
*   **问题**：Transformer 的核心是“自注意力机制”，即每个字都要和窗口内所有其他字计算一遍相关性。如果上下文长度从 $N$ 变成 $2N$，计算量不是翻倍，而是变成 **4倍**。
*   **后果**：长文本的**推理延迟（Latency）**极高，导致用户等待时间急剧增加，实时交互变得困难。



#### **3. 算法缺陷：Lost in Middle 现象**
这是一个著名的实验结论：并不是窗口里的所有信息都被平等对待。

模型对**开头**（系统提示）和**结尾**（最近输入）最敏感，而对窗口**正中间**的信息极易忽略。这是一种先天的注意力缺陷。

即便你有 100k 窗口，把关键信息藏在第 50k 的位置，模型也可能“看漏”。


#### 4. 模型容量：位置编码（Positional Encoding）的极限

模型怎么知道“我爱你”和“你爱我”的区别？靠位置编码（如 RoPE, ALiBi）。

RoPE位置编码通过旋转角度来编码位置信息，每个位置的旋转角度是固定的。当模型在训练时只见过0-4096的位置，意味着它只学习过这些位置对应的旋转角度分布。当输入第4097个位置时，这个位置对应的旋转角度是模型从未见过的，模型无法正确理解这个位置信息，导致位置编码失效，这时，注意力分数会出现剧烈震荡，可能从正常范围突然飙升到8000甚至更高，导致注意力计算出现灾难性问题。



#### **5. 有损处理：稀疏注意力与压缩**

为了突破 $O(N^2)$ 的算力限制，很多长文本模型采用“稀疏注意力”（只看部分关键字）或“分层压缩”（把前面的内容压缩成摘要）。

这是**效率与精度的权衡**，长文本往往伴随着细节丢失。



#### **6. 有限增强：有容量限制的RAG增强**  

这是一个核心的工程现实：尽管检索系统能获取海量相关信息，但大模型的**上下文窗口存在硬性容量限制**。因此，RAG系统无法将全部检索结果直接塞入上下文，必须进行**精细化筛选和压缩**。  

本质上，RAG在容量限制下的增强是一种**权衡艺术**——在信息完整性与模型可处理性之间寻找最优解。

例如，当用户查询某本书的特定情节时，系统会通过向量检索定位到书中与问题最匹配的段落（如第50-100页的章节），而非将整本书的300页内容全部输入模型。




---

### 三、 未来方向

#### 1、 长上下文窗口的瓶颈突破并非单一技术维度所能解决

当前技术虽已支持百万级token处理，但实际应用中超过1M的序列长度可能因性能衰减而失去实用价值。

长上下文窗口的瓶颈突破并非单一技术维度所能解决，而是需要架构创新、训练策略、硬件优化和工程实现的协同演进。

* 有人认为，未来突破方向将围绕“动态稀疏+智能预测”的注意力机制、软硬件深度协同适配、任务导向的动态长度调整等方向展开。

* 有人认为，真正的目标并非“无限长上下文”，而是实现“按需适配的高效长上下文能力”，在扩展窗口的同时保障性能稳定与成本可控。


#### 2、 AI编程领域，SDD（规范驱动开发）也是为了避免 上下文窗口瓶颈

SDD方法的如下手段，的确是回避LLM上下文瓶颈“大坑”的有效举措，解决LLM幻觉与瞎猜，提高代码生成的可预测性：
* 提供具体化的requirement、design等方面的spec
* 提供tasks约定更小的LLM工作步骤


【LLM架构管窥 ◆ 系列小文】旨在快速盘点LLM架构特点、特别是局限性，为后续【基于SDD的AI编程最佳实践】提供必要的认知准备。

LLM架构瓶颈管窥：Transformer架构的上下文窗口瓶颈

上下文窗口（Context Window）大小直接决定了大语言模型（LLM）能够同时处理和关联的信息量，尽管技术发展使得上下文长度从数K扩展到数百万token，但架构瓶颈并未消失。

人工智能

架构设计

算法

本文深入解析大语言模型(LLM)上下文窗口的6大瓶颈：显存爆炸、O(N²)计算复杂度、Lost in Middle现象、位置编码极限、稀疏注意力导致细节丢失、RAG容量限制。揭示百万token长文本处理背后的技术挑战，为AI开发者提供关键认知。

容器

2026新春采购季

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

LLM架构瓶颈管窥：Transformer架构的上下文窗口瓶颈-腾讯云开发者社区-腾讯云

LLM架构瓶颈管窥：Transformer架构的上下文窗口瓶颈

LLM架构瓶颈管窥：Transformer架构的上下文窗口瓶颈

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐