总览
本章节范围：大模型长上下文（128K 及以上）的算法、架构、训练、推理技术，讲"模型如何能看长、如何学会长、如何跑得起长"。 目标读者：希望系统理解长上下文部署的工程师与决策者。 不含：互联通信视角的展开（CP / PD 分离 / 超节点拓扑等），统一沉淀在
docs/interconnect/，见 互联视角索引。
名词定义
本章节所有子文档默认这些名词已定义。子文档只解释本文新引入的名词，不再重复。
| 名词 | 定义 |
|---|---|
| 上下文窗口 (Context Window) | 模型一次推理中能处理的最大 token 数。当前主流"长上下文"的下限通常指 128K，先进模型达 1M-10M |
| Prefill | 推理第一阶段，并行处理输入 prompt 的全部 token 生成首 token，attention 计算量随序列长度 $n$ 呈 $O(n^2)$ |
| Decode | 推理后续阶段，逐 token 自回归生成，每步需读取全量 KVCache，显存带宽密集 |
| KVCache | Key/Value 缓存，存历史 token 的 attention key/value，避免重算；显存占用随序列长度线性增长 |
| TTFT (Time To First Token) | 首 token 延迟，prefill 主导 |
| TPOT (Time Per Output Token) | 单 token 生成延迟，decode 主导，与 KVCache 读取量正相关 |
| 算术强度 (Arithmetic Intensity) | FLOP / Byte 比值，决定负载落在 roofline 的算力区还是访存区 |
| 位置编码 (Positional Encoding) | 给 token 注入序列位置信息的机制；RoPE / ALiBi 等为常见实现 |
| 外推 (Extrapolation) | 让短上下文训练的模型在推理时处理更长序列的能力 |
| 注意力机制变体 (Attention Variant) | 偏离原版 dense softmax attention 的设计：稀疏 / 滑窗 / 线性 / 状态空间 (SSM) 等 |
| 架构层 KV 压缩 | 在模型架构上降低 KV 体积的方法（GQA / MQA / MLA），训练时定型，与推理时动态压缩区分 |
| RAG (Retrieval-Augmented Generation) | 检索增强生成，长上下文的常见替代或互补方案 |
| Agent | 多轮、多工具调用、长会话的智能体工作负载，是长上下文需求的主要驱动之一 |
@tbl-longctx-overview-glossary 长上下文章节共享名词表
领域主矛盾与技术全景
长上下文的几乎所有技术，都在回应同一个矛盾：KVCache 随序列长度线性膨胀，单卡显存放不下。 本章每一篇文档，都是对这个矛盾某一环的应对。这个矛盾派生出一条因果链：
- 序列变长，两道墙同时升高：attention 计算量 $O(n^2)$（算力墙），KVCache 显存 $O(n)$（显存墙）。
- 显存墙是部署侧的第一性约束：KV 放不下 → 三条出路 —— 压缩（架构层 GQA/MQA/MLA、推理层量化/驱逐）、卸载（CPU/SSD）、切分（多卡）。
- 切分把显存问题转成通信问题：KV 跨卡后，attention 的 all-gather 与 KV 跨芯流量随 $n$ 放大，互联带宽（而非算力）成新瓶颈 → 超节点高带宽域是当前最优解。
下图把各技术挂到这条派生链上 —— 每个节点是对某一道墙或某一条出路的回应，箭头表示"派生 / 出路"，虚线表示"辅助 / 验证"，后缀标注详解文档编号。主矛盾的完整推导见 02-第一性挑战。
按问题导航
带着你的问题进来 —— 每个子问题对应一类技术和它的详解文档，不必从头顺读。
| 子问题 | 解药技术 | 核心取舍 | 详见 |
|---|---|---|---|
| 模型根本看不到这么长 | 位置编码外推（RoPE / NTK-aware / YaRN） | 外推距离 vs 精度衰减 | 03-位置编码与外推 |
| attention $O(n^2)$ 算不动 | 稀疏 / 线性 / SSM (Mamba) | 复杂度降低 vs 质量损失 | 04-注意力机制变体 |
| KV 体积太大（架构层） | GQA / MQA / MLA | 体积压缩 vs 表达力 | 05-KVCache 架构压缩 |
| KV 放不下（推理层） | 量化 / 驱逐 / offload / PagedAttention | 显存换精度或延迟 | 07-推理 - KV 管理 |
| 相同前缀被反复算 | prefix caching / RadixAttention | 命中率依赖请求前缀分布 | 07-推理 - KV 管理 |
| 输入里有大量低信息量内容 | 输入压缩（LLMLingua 硬删 / 软 token 编码） | 压缩比 vs 信息损失 | 10-上下文压缩 |
| 单卡放不下，被迫切多卡 | 上下文并行 CP / SP / Ring Attention | 显存降低 vs 互联通信上升 | interconnect 05 / 上下文并行 |
| 切分后通信成瓶颈 | 超节点高带宽域（NVL72） | 带宽提升 vs 成本 | interconnect 02 / NVL72 |
| prefill 与 decode 互相干扰 | chunked prefill / PD 分离 | 平滑尖峰 vs 调度复杂度 | 08-推理 - 调度优化、interconnect 10 |
| 模型"学会"用长依赖 | 渐进扩展训练 / 长数据合成 | 训练成本 vs 长程能力 | 06-训练侧 |
| 长上下文到底做得怎样 | RULER / NIAH / ∞Bench | 宣称长度 ≠ 有效长度 | 09-评测与现状 |
| 外部知识太大塞不进窗口、要实时更新 | RAG 或 RAG × 长上下文混合 | 准确率 vs 成本/更新 | 11-RAG 与长上下文 |
@tbl-longctx-overview-nav 按问题导航：子问题、解药技术、核心取舍、详解文档
背景：需求与模型现状
长上下文的业务驱动主要有四类，按出现时序：
| 场景 | 长上下文承担的角色 | 典型上下文规模 |
|---|---|---|
| 长文档理解 | 一次性读入整本书 / 财报 / 法律合同 | 50K-500K |
| 代码库级编程 | 整仓库 / 多文件代码理解、跨文件重构 | 100K-1M |
| 检索增强 （RAG 互补） | 把多文档检索结果拼接进 context，省去精排 | 数十 K |
| Agent 与长会话 | 多轮工具调用、长任务记忆、思维链累积 | 100K-数 M |
@tbl-longctx-overview-usecase 长上下文的四类业务驱动
与 RAG 的关系：长上下文不是 RAG 的替代品，而是搭档。RAG 解决"信息海量、按需检索"，长上下文解决"已检索内容如何被模型一次性消化"。
业界从 2K 起步，2023 年内推到 128K，2024-2025 年达到 1M+，2025-2026 年部分先进模型宣称 10M。
| 时期 | 代表模型 | 上下文规模 |
|---|---|---|
| 2020 - 2022 | GPT-3 / LLaMA 1 | 2K - 4K |
| 2023 | GPT-4 / Claude 2 / LLaMA 2 | 8K - 128K |
| 2024 | Claude 3 / GPT-4 Turbo / LLaMA 3.1 | 128K - 200K |
| 2024 中 | Gemini 1.5 Pro / DeepSeek-V2 | 1M / 128K |
| 2025 | Gemini 2.0 / Claude 3.5+ / GPT-4.1 / Qwen2.5-Turbo | 1M - 2M |
| 2025-2026 | 部分研究模型 （Gemini 系列宣称） | 10M+ |
@tbl-longctx-overview-evolution 主流模型上下文规模演进（截至 2026 初）
数据可信度提示：上表为业界趋势示意，具体模型上下文长度以官方文档为准；"宣称"上下文不等同于"有效"上下文，后者需以 RULER / NIAH 等评测衡量（→ 09-评测与现状）。
互联视角索引
分工原则：本章讲"长上下文这件事本身"（模型层、训练层、推理算法层）；它的系统与互联视角（并行切分通信、推理服务化、超节点拓扑、集合通信原语）统一沉淀在 docs/interconnect/，本节按主题分组作主索引，避免重写。
并行策略与单序列切分
| 链接 | 长上下文相关性 |
|---|---|
| 05-LLM 并行通信 / 序列并行 (Megatron SP) | TP 组内序列切分，与长上下文并行互补 |
| 05-LLM 并行通信 / 上下文并行 (CP / Ring / Ulysses) | 长上下文必备：把单序列摊到多卡，attention 跨卡协同 |
| 05-LLM 并行通信 / 专家并行 (EP) | MoE 模型长上下文部署时与 CP 并存的通信源 |
| 05-LLM 并行通信 / 计算通信 overlap | CP 的环形 K/V 传递如何与 attention 计算 overlap |
@tbl-longctx-overview-link-parallel 并行策略相关 interconnect 文档
推理服务化与 KV 跨节点
| 链接 | 长上下文相关性 |
|---|---|
| 09-推理服务化通信 / 总览 | PD 分离生态与长上下文部署的连接点 |
| 10 / PD 分离原理 | 长上下文加剧 prefill/decode 错配的应对 |
| 10 / Mooncake (KV-centric) | KV 中心调度，长上下文场景的代表实现 |
| 10 / SGLang PD | 开源 PD 实现 |
| 10 / NVIDIA Dynamo | 企业级 PD 框架 |
| 10 / KV 跨节点传输瓶颈 | RTT-bound vs BW-bound 的临界点分析 |
| 10 / Cache-aware 调度 | Prefix caching 的调度落地 |
| 10 / Reasoning 推理通信 | 长思维链下 decode 通信特征 |
@tbl-longctx-overview-link-serving 推理服务化相关 interconnect 文档
超节点与拓扑
| 链接 | 长上下文相关性 |
|---|---|
| 02-网络拓扑 / NVL72 | 大 scale-up 域作统一显存池，承载长 KV |
| 02-网络拓扑 / 总览 | 拓扑族在长上下文大流量下的适配性 |
@tbl-longctx-overview-link-topo 拓扑相关 interconnect 文档
集合通信底层
| 链接 | 长上下文相关性 |
|---|---|
| 04-集合通信 / all-gather | Ring Attention 中 K/V 环形传递的底层原语 |
| 04-集合通信 / all-to-all | DeepSpeed-Ulysses CP 实现的核心原语 |
@tbl-longctx-overview-link-cc 集合通信相关 interconnect 文档
代表模型分析
| 链接 | 长上下文相关性 |
|---|---|
| 07-前沿模型追踪 / DeepSeek-V4 / MHC | Multi-head 共享 KV，架构层 KV 压缩的工业案例 |
| 07-前沿模型追踪 / DeepSeek-V4 / Attention | MLA 在 V4 上的实现细节 |
@tbl-longctx-overview-link-deepseek DeepSeek 案例相关文档