Ch10 LLM架构修订于 二〇二六年七月二日

长上下文 (Long Context) — 深度解析

概述

长上下文 (Long Context) 是指大语言模型 (LLM) 能够一次处理的最大 token 数量,即上下文窗口 (Context Window) 的大小。2026 年,主流模型已普遍支持 128K1M+ tokens 的上下文窗口,部分模型甚至达到 2M10M tokens。

Long context is one of the most important frontiers in LLM research. Extending the context window from 4K to 1M+ tokens has profound implications for document understanding, codebase analysis, and multi-turn conversations, but it also introduces significant technical challenges.

上下文窗口演进

年份模型上下文长度关键技术
2018GPT-1512学习位置编码
2019GPT-21,024绝对位置编码
2020GPT-32,048稀疏注意力
2022GPT-3.54,096—
2023GPT-48K / 32K / 128KRoPE + 微调
2023Claude 2100K—
2024GPT-4 Turbo128K—
2024Claude 3200K—
2024Gemini 1.5 Pro1M (实验 10M)RingAttention
2025Claude 4200K—
2025Gemini 2.5 Pro1M—
2026主流开源模型128K~1MYaRN / RoPE 扩展

核心技术挑战

1. 注意力机制的二次复杂度

标准 Self-Attention 的时间复杂度和空间复杂度均为 O(n^2),其中 n 是序列长度。

Attention(Q, K, V) = softmax(QK^T / √d_k) · V

Q, K, V shape: (batch, n, d)
QK^T shape: (batch, n, n)  ← 这就是 O(n^2) 的来源

当 n = 128K 时,QK^T 矩阵有 163 亿个元素;当 n = 1M 时,这个数字膨胀到 1 万亿。直接计算在硬件上不可行。

2. KV Cache 的内存瓶颈

在自回归生成时,每个 token 都需要和之前所有 token 的 KV 对做注意力计算。KV Cache 存储所有历史 token 的 Key 和 Value 向量:

KV Cache 内存 = 2 × n_layers × n × d_model × dtype_bytes

示例: LLaMA-70B, n=128K, bf16:
= 2 × 80 × 128,000 × 8,192 × 2 bytes
= 335 GB  ← 仅 KV Cache 就超过大多数 GPU 内存

3. 位置编码的外推 (Extrapolation)

训练时使用短序列 (如 4K),推理时需要扩展到长序列 (如 128K),位置编码需要良好的外推能力。

  • RoPE (Rotary Position Embedding): 通过旋转矩阵编码相对位置,是当前主流方案
  • ALiBi: 直接在注意力分数上加线性偏置,天然支持外推
  • YaRN: 在 RoPE 基础上对不同频率维度做不同缩放,实现更好的外推

4. 训练数据难题

长上下文训练需要大量长文档数据,但互联网上真正的长文档 (如整本书) 相对稀缺。常见的做法:

  • 将多个短文档拼接模拟长文档
  • 使用合成数据 (如让 LLM 生成连贯的长文本)
  • 逐步增加训练序列长度 (从 4K → 8K → 16K → …)

长上下文使用策略

放前面还是放后面?“Lost in the Middle” 问题

研究 (Liu et al., 2023) 表明,LLM 对长上下文中不同位置的关注度不是均匀的:

注意力分布 (相对位置):
Beginning:  ████████████  (高)
Middle:      ████          (低) ← "Lost in the Middle"
End:         ████████████  (高)

策略:

  • 最重要的信息放在开头 (System Prompt) 或结尾 (最后一条消息)
  • 中间位置的信息容易被忽略,重要内容不要放在中间
  • 必要时在末尾重复关键信息

上下文压缩 (Context Compression)

当文档超过上下文窗口时:

  • RAG 检索: 只将最相关的 chunk 放入上下文
  • 摘要压缩: 先用短摘要过滤,再对相关部分展开
  • Prompt Compression: 使用 LLMLingua 等工具压缩 Prompt
  • 上下文缓存: 对重复使用的长文档利用 API 的缓存功能

什么时候需要长上下文?

场景是否需要长上下文替代方案
分析整本书/长篇报告是分章节 RAG
代码库级别的理解与重构是文件级 RAG + 摘要
多轮对话 (100+轮)是对话摘要压缩
多文档比较分析是逐文档分析后汇总
单篇论文/短文档否直接放入上下文
简单问答否RAG 检索 3-5 个 chunk
翻译任务否分段翻译
日常对话否默认上下文足够

几种主流长上下文方案

RingAttention (Google DeepMind)

  • 将序列分块在多个设备上环形传递
  • 每步每个设备计算局部的注意力并传递 KV 块
  • 实现了设备数量与序列长度的线性扩展

FlashAttention (Stanford)

  • 通过分块计算和重计算策略,减少 HBM 读写次数
  • 时间复杂度仍是 O(n^2),但实际速度提升显著
  • FlashAttention-3 (2024) 进一步优化,支持 FP8 和 Hopper 架构

Mamba / SSM (状态空间模型)

  • 完全替代 Attention 机制,使用选择性状态空间模型
  • 推理时间复杂度 O(n),训练效率高
  • 在长序列任务上表现出色,但某些任务不如 Transformer

2026 年趋势

  • 10M+ 上下文窗口 已成为研究前沿
  • 混合架构: 短期记忆 (Attention) + 长期记忆 (SSM / 外部存储)
  • Agentic Context Management: 智能体自动管理上下文,决定什么信息保留、什么丢弃
  • Context-Aware Tokenization: 根据上下文动态调整 token 边界
  • 长上下文的评测基准: Needle-in-a-Haystack 等基准成为标配

相关笔记

来源

关联13

知识图谱

局部图谱 · 点节点跳转