> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# LLM 上下文背后的真正工程
- URL: https://www.hubwiz.com/blog/the-real-engineering-behind-llm-context/
- Published: 2026-08-27T13:58:20.000Z
- Updated: 2026-08-27T13:58:20.000Z
- Description: 为什么将整个代码库转储到提示中会在生产中崩溃
- Author: admin
- Tags: LLM, #Import 2026-10-14 14:41

当模型提供商首次宣布上下文窗口达到 100 万，然后是 200 万或 400 万令牌时，感觉就像魔法一样。我记得当时想我们可能永远不需要担心提示分块 \[ [1](https://arxiv.org/abs/2403.02310?ref=hubwiz.com) \] 或上下文截断 \[ [2](https://arxiv.org/abs/2404.10830?ref=hubwiz.com) \] 了。只需将整个代码库或整个书籍库转储到提示中，让 LLM 来处理，对吧？

不幸的是，生产现实很快给了我们一盆冷水。处理数百万令牌不仅极其昂贵；它还会将推理速度拖慢到爬行速度，并降低模型实际检索埋藏在大量上下文负载中间的关键细节的能力。

在这篇博客中，我们将探讨当 LLM 处理上下文时，底层真正发生了什么。我将带您了解主要的内存瓶颈、四种核心的基于论文支持的上下文管理类型，以及当今流行的模型和框架如何在生产中解决这些挑战。

## 1、为什么上下文如此昂贵

要理解为什么上下文管理如此关键，我们首先需要了解大型语言模型如何处理推理。推理发生在两个不同的阶段：

- *预填充阶段* \[ [3](https://arxiv.org/abs/2309.06180?ref=hubwiz.com) \]，模型摄取整个输入提示
- *解码阶段*，模型自回归地逐个生成输出令牌。

在解码期间，为了避免在每个步骤重新计算过去的键和值向量，系统将其缓存在 GPU 内存中。这被称为**键值（KV）缓存** \[ [4](https://arxiv.org/abs/1911.02150?ref=hubwiz.com) \]。虽然这加快了计算速度，但它创建了巨大的内存占用，随着序列长度和批处理大小线性增长。

图 2 描述了预填充和解码阶段。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-MMJHXdfOmS3Y9nRWIJA-tw.png)

例如，服务一个 1750 亿参数的模型，批处理大小为 128，序列长度为 2,048 个令牌，仅 KV 缓存就需要大约 950 GB 的显存。这比模型权重本身的静态内存占用还要多得多！

此外，标准 GPU 内存分配通常遭受严重的*碎片化* \[ [3](https://arxiv.org/abs/2309.06180?ref=hubwiz.com) \]。当为最大序列长度连续预分配内存时，60% 到 80% 的 GPU 内存最终被浪费。

因此，内存带宽，而不是原始计算能力，成为生产 LLM 部署的主要瓶颈。

## 2、四种核心的上下文管理类型

根据我的经验，我发现现代上下文管理框架分为**四种核心技术类型**，以及专门的网络传输协议。在图 3 中，您可以查看四种类型。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-5BqgjPe_aSXaH7todW0yfA.png)

让我们在接下来的部分中分解每种类型的工作原理。

### 类型 1：虚拟化和系统分页

从操作系统的虚拟内存中汲取灵感，这种方法将逻辑提示序列与物理 GPU 内存布局解耦。

这里的标准承载者是 *PagedAttention* \[ [3](https://arxiv.org/abs/2309.06180?ref=hubwiz.com) \]。它将 KV 缓存分成可以非连续存储的小物理块。查找表将逻辑令牌映射到物理页面，将内存浪费从 60% 以上减少到 4% 以下。

更进一步，*SGLang 的 RadixAttention* \[ [5](https://arxiv.org/abs/2312.07104?ref=hubwiz.com) \] 在分层基数树数据结构中管理缓存的提示块。当多个请求共享系统指令或少样本示例时，SGLang 立即重用现有的 KV 缓存块，将初始首个令牌时间（TTFT）降低到接近零。

### 类型 2：算法稀疏性和注意力汇聚

你知道吗，在长提示中，只有不到 3% 的注意力头在任何给定时刻是活跃的？稀疏性技术正是利用了这一现象。

- *StreamingLLM* \[ [6](https://arxiv.org/abs/2309.17453?ref=hubwiz.com) \] 发现了"*注意力汇聚*"的概念。通过永久保留最初的 4 个初始令牌以及最近令牌的滑动窗口，模型可以无限期地继续生成文本，而不会出现内存溢出或 Softmax 崩溃。
- *DuoAttention* \[ [7](https://arxiv.org/abs/2410.10819?ref=hubwiz.com) \] 将注意力头分为"*检索头*"（需要完整的长程注意力）和"*流式头*"（只需要局部上下文）。通过压缩流式头，它将 KV 内存减少高达 2.55 倍，同时在单个 80GB GPU 上容纳 330 万个令牌。
- *MInference 1.0* \[ [8](https://arxiv.org/abs/2407.02490?ref=hubwiz.com) \] 专注于加速 100 万+令牌提示的预填充阶段。它使用自定义 Triton GPU 内核搜索特定的空间稀疏模式（A 形、垂直斜线和块稀疏），消除高达 95% 的注意力 FLOPs，并将预填充速度提高 10 倍。

### 类型 3：潜在和时间张量压缩

与其保持高维向量，张量压缩直接减少 KV 表示的数学占用。

一个主要例子是*多头潜在注意力（MLA）* \[ [9](https://arxiv.org/abs/2405.04434?ref=hubwiz.com) \]，用于 DeepSeek-V2/V3 模型。*MLA* 在推理期间将 `key` 和 `value` 矩阵投影到低秩潜在子空间中。与标准*多头注意力（MHA）* \[ [10](https://arxiv.org/abs/1706.03762?ref=hubwiz.com) \] 相比，这将 KV 缓存占用压缩了惊人的 93.3%。

作为架构低秩投影的补充，量化技术如 *KIVI* \[ [11](https://arxiv.org/abs/2402.02750?ref=hubwiz.com) \] 对每个通道的 `keys` 和每个令牌的 `values` 应用非对称 2 位量化，在不牺牲准确性的情况下大幅降低内存需求。

### 类型 4：上游提示蒸馏

如果我们能在上下文到达目标 LLM 之前就压缩它呢？这就是上游提示压缩的目标。

像 *LLMLingua-2* \[ [12](https://arxiv.org/abs/2403.12968?ref=hubwiz.com) \] 这样的框架使用小型快速模型（如微调的 BERT 变体）来评估令牌信息熵。它将提示压缩视为令牌分类问题，在将负载发送到昂贵的黑盒 API（如 GPT-4o）之前丢弃低信息和重复的令牌。这可产生高达 20 倍的压缩，同时降低成本和延迟。

## 3、长上下文 vs. RAG

我从工程团队听到的一个常见问题是：

> **"既然模型现在支持 100 万个令牌，我们还需要 RAG 吗？"**

简短的回答是**是的**。最近的学术基准（如 LaRA）表明，扩展上下文窗口会引入严重的噪声饱和。当关键信息位于大型上下文窗口的中间 30% 到 70% 时，模型准确性会急剧下降，这种现象被称为\*\*"***在中间丢失***"\*\*。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Wljajv2n_ahJS0wbRYBTAw.png)

研究强调了 *RAG vs. 长上下文*辩论中的几个关键细微差别：

1. **128k 逆转阈值：**在中等长度（低于 32k 令牌）下，原生*长上下文*模型通过捕获文档分块会破坏的多跳关系而优于 RAG。然而，超过 128k 令牌后，噪声饱和导致*长上下文*准确性下降，让干净的 *RAG* 管道以 +3.68% 重新获得领先。
2. **硬负样本脆弱性：**虽然 RAG 过滤掉噪声，但它仍然容易受到"硬负样本"的影响，即检索到的段落在语义上看起来相关，但包含事实误导性信息。
3. *混合解决方案（自路由）：*结合两种世界最有效的方法是*自路由架构*\*\*。该框架使用轻量级自反思将简单的事实查询路由到廉价的 RAG 管道，同时将复杂的多文档推理任务委托给完整的长上下文 LLM。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-T6gPpC7syhAZm1BpM92UbA.png)

## 4、框架

那么，您的应用程序应该选择哪种上下文管理策略？根据我的经验，下表建议针对特定用例使用哪种技术：

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-khNnbGucLkm-JLUGOoYGQw.png)

## 5、结束语

当我们退后一步审视整个领域时，一个清晰的教训浮现出来：

> 有效的上下文管理是一门软件工程和系统设计学科，而不仅仅是等待更大的硬件上下文窗口的问题

在不优化的情况下将上下文窗口从 32k 扩展到 100 万个令牌，就像在爆胎的汽车上安装更大的油箱一样。硬件收益很快被二次注意力成本、内存碎片化和检索退化所吞噬。

通过应用虚拟内存分页、动态注意力稀疏性、潜在压缩和混合 RAG 路由，我们可以构建不仅更快、更便宜，而且更善于从嘈杂数据中提取真正信号的 AI 架构。

---

原文链接：[Beyond the 1-Million Token Illusion: The Real Engineering Behind LLM Context](https://medium.com/@ferneutron/beyond-the-1-million-token-illusion-the-real-engineering-behind-llm-context-e5df7fcbf431?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处