30 秒快速回答
长上下文（Long Context） 指的是大语言模型一次能处理的文本长度上限。2023 年初 GPT-4 只有 8K token（约 6000 字），到 2025 年 Gemini 2.5 Pro 已达到 200 万 token（约 150 万字）——相当于一次塞进整本《三体》三部曲。长上下文的核心价值：让 AI 在不丢失信息的前提下，一次性理解超大规模文档、代码库或多轮对话历史。
1. 为什么需要长上下文？—— 真实痛点
举个例子：你想让 AI 帮你分析一个 20 万行的代码仓库，或者总结一份 300 页的 PDF 合同。
| 方案 | 做法 | 问题 |
|---|---|---|
| 短上下文 + 分段 | 把文档切成小块，分批发给 AI | 块与块之间丢失关联，AI 看不到全局结构 |
| RAG 检索 | 只把相关的片段送给 AI | 依赖检索精度，跨段落逻辑链容易断裂 |
| 长上下文直通 | 全文一次性输入 | 信息完整，但计算成本高、速度慢 |
当任务需要跨越多个信息点建立关联时（代码重构、长篇合同审查、论文综述），长上下文的优势无可替代。
2. 核心技术：从 8K 到 200 万 token 怎么做到的？
2.1 RoPE 位置编码与外推
Transformer 本身没有”顺序”概念，靠位置编码告诉模型每个 token 在第几位。
RoPE（旋转位置编码） 是目前主流方案，它将位置信息编码为向量旋转角度。但原始 RoPE 在训练长度之外会”失真”——类比钟表，时针转到 13 点又回到 1 点。
解决方法：位置插值（Position Interpolation）
将超出训练范围的位置”压缩”回已知区间。比如模型训练时最大见过 2048 的位置，要扩展到 8192，就把位置索引按比例缩小：
# 位置插值核心思路（伪代码）
scale_factor = target_length / train_length # 8192 / 2048 = 4
for token_position in range(target_length):
# 把位置坐标"压缩"回训练范围
interpolated_pos = token_position / scale_factor
embedding = rope_embed(interpolated_pos)
YaRN（Yet another RoPE extensioN）等方法在此基础上引入频率分区策略，高频维度少插值、低频维度多插值，大幅提升外推质量。
2.2 KV Cache 压缩：解决内存爆炸
长上下文的最大瓶颈不是计算量，而是显存。原因在于 KV Cache——推理时每生成一个 token，都要保存之前所有 token 的 Key 和 Value 矩阵。
以 Llama 3 70B 为例，100 万 token 的 KV Cache 需要约 512GB 显存。即使是 8 卡 H100 也扛不住。
主流压缩策略：
| 技术 | 原理 | 代表方案 |
|---|---|---|
| KV 量化 | 将 KV 值从 FP16 压缩到 INT8 甚至 INT4 | KIVI、KVQuant |
| 窗口注意力 | 只保留最近的 token 的 KV，远的丢弃 | StreamingLLM |
| 选择性保留 | 根据注意力分数决定保留哪些 KV | H2O、SnapKV |
| 跨层共享 | 相邻层共享同一份 KV Cache | CLA（DeepSeek-V3） |
DeepSeek-V3 的多头潜在注意力（MLA） 是目前 SOTA 方案：将 Key 和 Value 压缩到极低维的潜在空间，推理时按需解压，KV Cache 减少 90% 以上——这也是它能以极低成本服务百万上下文的基础。
2.3 RingAttention：多卡分布式长上下文训练
单卡显存装不下长序列的训练怎么办？
RingAttention 的思路：把序列切成多段，分布到不同 GPU 上。每张卡计算自己那段的自注意力，同时通过环形通信把 KV 块传给下一张卡，形成”伪全局注意力”。
GPU 0: [Token 0-4095] → KV 块 → GPU 1
GPU 1: [Token 4096-8191] → KV 块 → GPU 2
GPU 2: [Token 8192-12287] → KV 块 → GPU 3
GPU 3: [Token 12288-16383] → KV 块 → GPU 0 (环形)
这样 N 张卡的等效上下文长度 = N × 单卡长度，Google 用此方案在 TPU v5p 上训练了 Gemini 的百万级上下文。
3. 2025-2026 主流模型上下文窗口对比
| 模型 | 最大上下文 | 技术亮点 |
|---|---|---|
| Gemini 2.5 Pro | 200 万 token | RingAttention + TPU 分布式 |
| Claude 4 Opus | 200K token | 原生长上下文训练 |
| GPT-5 | 256K token | 分层 KV 压缩 |
| DeepSeek-V3 | 128K token | MLA 注意力（KV 压缩 90%+） |
| Llama 4 Scout | 10M token | iRoPE 位置编码创新 |
| Qwen3 | 256K token | Dual Chunk Attention |
4. 长上下文的实际应用场景
代码库级理解
# 典型用法：一次性分析整个仓库
# 用 Claude Code / Cursor 加载完整项目上下文
# AI 可以跨文件追踪调用链、重构建议、全局 bug 修复
prompt = """
请分析以下整个项目的代码结构和依赖关系：
[整个 src/ 目录的代码，约 150K token]
找出所有循环依赖，并给出重构方案。
"""
长文档处理
- 合同审查：一份 200 页的并购协议，逐条分析风险点，不需要分段
- 论文综述：50 篇论文摘要一次性输入，AI 自动归纳研究趋势、找出矛盾发现
- 会议纪要：8 小时会议转录文本，一次性生成结构化纪要和待办事项
多轮对话记忆
长上下文让 AI 能记住数百轮对话历史而不遗忘。这对客服系统、AI 陪伴、代码协作等场景至关重要——用户不需要反复重复背景信息。
5. 局限与实战建议
不是越长越好：
- “中间丢失”现象：研究表明，模型对长文本开头和结尾关注度高、中间部分关注度低（Lost in the Middle）。关键信息尽量放在开头或结尾
- 成本问题：上下文越长，每次推理消耗的 token 越多，API 费用线性增长
- 延迟：100 万 token 的 prefill 可能需要几十秒
实战建议：
- 能用 RAG 解决的简单查询，不必用长上下文（更省钱）
- 需要全局关联的任务（代码重构、合同分析、多文档对比），长上下文是更优解
- 把最重要的指令和参考信息放在上下文的开头或结尾
- 利用模型的结构化输出能力（如 JSON mode），让 AI 在长文本中提取结构化信息
总结
| 要点 | 一句话 |
|---|---|
| 定义 | 模型单次能处理的 token 上限 |
| 核心突破 | RoPE 外推 + KV Cache 压缩 + 分布式训练 |
| 代表模型 | Gemini 2M、Llama 4 Scout 10M、DeepSeek-V3 128K |
| 适用场景 | 代码库分析、长文档审查、多轮对话 |
| 注意事项 | “中间丢失”效应、成本与延迟权衡 |
延伸阅读建议：
- 如果对 KV Cache 优化感兴趣，可阅读本站《什么是模型量化？把大模型变小的核心技术》
- 如果想了解 RAG 与长上下文的互补关系，推荐《什么是 RAG？一文搞懂检索增强生成》
- 论文推荐：Ring Attention with Blockwise Transformers for Near-Infinite Context（Hao Liu et al., 2023）；YaRN: Efficient Context Window Extension of Large Language Models（Peng et al., 2023） （内容由AI生成，仅供参考）