LLM 上下文背后的真正工程

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

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

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

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

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

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

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

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

此外，标准 GPU 内存分配通常遭受严重的碎片化 [ 3 ]。当为最大序列长度连续预分配内存时，60% 到 80% 的 GPU 内存最终被浪费。

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

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

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

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

这里的标准承载者是 PagedAttention [ 3 ]。它将 KV 缓存分成可以非连续存储的小物理块。查找表将逻辑令牌映射到物理页面，将内存浪费从 60% 以上减少到 4% 以下。

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

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

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

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

一个主要例子是多头潜在注意力（MLA） [ 9 ]，用于 DeepSeek-V2/V3 模型。MLA 在推理期间将 key 和 value 矩阵投影到低秩潜在子空间中。与标准多头注意力（MHA） [ 10 ] 相比，这将 KV 缓存占用压缩了惊人的 93.3%。

作为架构低秩投影的补充，量化技术如 KIVI [ 11 ] 对每个通道的 keys 和每个令牌的 values 应用非对称 2 位量化，在不牺牲准确性的情况下大幅降低内存需求。

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

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

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

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

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

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

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

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

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

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

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

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

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