这一篇是入门认知篇的收官我们要谈一个所有大模型厂商都在卷、所有工程师都被它折磨的东西——上下文窗口Context Window。2020 年 GPT-3 上下文是2K到了 2026 年 Claude Opus 4.7 和 Gemini 2.5 Pro 都已经支持1M——6 年涨了 500 倍。这个数字看起来像是简单的扩参数但工程上每一个数量级的扩展都是一场硬仗。如果你做过相关工作下面这些经历应该不陌生模型号称支持 128K实测放进去 80K 之后就开始失忆同样 32K 上下文对话越长延迟越糟糕——而且不是线性变糟长上下文模式打开后显存吃掉一半并发掉到原来的 1/10同样的大海捞针任务开源模型崩溃闭源模型稳定老板说我们也搞个1M 上下文的应用你想用得起吗这一篇我们就来彻底搞清这套账。读完它你会知道上下文窗口扩展的物理瓶颈是什么业界用什么算法、什么并行、什么工程手段一路推到 1M 的自己部署长上下文服务时最容易踩的几个坑在哪里什么时候该用 1M 上下文什么时候应该用 RAG我们开始。一、上下文窗口为什么是头等大事1.1 一条 6 年涨 500 倍的曲线简单回顾上下文长度的演进史年份代表模型上下文工程意义2019GPT-21K段落级2020GPT-32K短文章2022ChatGPT4K多轮对话2023.3GPT-4 / Claude 18K / 100K文档级2023.7Llama 24K开源仍落后2024.3Claude 3200K长文档 SOTA2024.5GPT-4o128K全面跟进2024.12Gemini 1.5 Pro2M首破 1M2025Claude 4 / DeepSeek V3200K / 128K主流标配2026Claude Opus 4.7 / Qwen 31M/ 1M1M 成主流这条曲线背后是巨大的技术鸿沟——4K 到 32K 是工程优化32K 到 128K 是位置编码革新128K 到 1M 是分布式架构创新。1.2 为什么所有人都在卷上下文工程视角下长上下文价值有三层第 1 层直接消除切分的痛苦短上下文时代所有 LLM 应用都被一个动作折磨chunking切片。处理一份 50 页 PDF切成 100 个 chunk每个塞一点分析 10 万行代码切成 500 个文件块总结一本书分章节循环 prompt切片的代价信息丢失、上下文断裂、结果难拼接。128K 上下文意味着 100 页 PDF 一次性丢进去1M 上下文意味着整本《三体三部曲》一次进整个代码仓库一次进。这是产品形态的根本性升级。第 2 层让 Agent 真正可用第 1 篇我们提到 Agent 是 2026 年大模型的主战场。Agent 的本质特征是多步推理 工具调用 记忆——每一步都会往上下文里塞新信息系统提示 工具定义~5K tokens用户原始请求~1K第 1 步检索结果 ~3K 思考 ~1K第 2 步调用 API 返回 ~5K 思考 ~1K第 N 步...一个跑了 20 步的 Agent上下文很容易突破 100K。短上下文时代 Agent 跑几轮就崩溃1M 上下文是 Agent 走向生产的前提。第 3 层把知识库变成记忆短上下文 向量库 RAG。长上下文 全量灌入 直接记忆。很多场景下长上下文比 RAG 更准——因为没有 chunk 切分、没有检索召回率问题。1.3 工程师面对的真实账本理想很丰满但每多扩 10 倍上下文工程师就要为这个数字埋单上下文单请求 KV Cache (Llama-3-70B, FP16)单卡 H100 能并发请求数4K1.3 GB~3032K10.7 GB~5128K43 GB~11M335 GB跨多卡并发能力骤降是显而易见的但还有更隐蔽的代价第 100 万个 token 处的理解质量远不如第 1000 个prompt 越长首 token 延迟TTFT越大——1M 上下文的 TTFT 可达几十秒跨多卡的长上下文调度难度指数上升下面我们就从这些工程账本背后拆解长上下文到底是怎么卷起来的。二、O(n²) 的诅咒物理上的硬墙2.1 attention 的复杂度公式回忆第 2 篇我们讲过的核心公式注意这一步Q维度[n, d]n 是序列长度d 是隐藏维度维度[d, n]结果[n, n]这是一个n × n 的矩阵。意味着计算复杂度O(n² · d)显存复杂度O(n²)要存这个矩阵做 softmax直观影响——上下文每翻倍attention 部分的算力和显存就涨 4 倍。2.2 实际数字感受我们用 Llama-3-70B 实测FP16单 layer attention 计算量序列长度 nattention 矩阵显存单 layer 计算量 (TFLOPS)4K32 MB0.532K2 GB32128K32 GB5121M2 TB32,000注意 1M 那一行单 layer 的 attention 矩阵就需要2 TB显存——光这一项就远超任何单卡甚至单机的极限。这就是为什么原始 attention根本撑不到 1M。2.3 KV Cache 的指数膨胀除了 attention 矩阵KV Cache 也是大头。第 2 篇推导过的公式KV_cache 2 × batch × seq_len × num_layers × num_kv_heads × head_dim × dtype_size按 Llama-3-70B80 layers, 8 KV heads with GQA, head_dim128, FP16上下文单请求 KV Cache占用估算4K1.3 GB单卡毛毛雨32K10.7 GB单卡可以容纳128K43 GB占满半张 H1001M335 GB超过 4 张 H100这意味着什么在 1M 上下文下光放一个请求的 KV Cache 就要 4 张 H100。你不可能用单卡跑 1M 上下文 并发。2.4 三大瓶颈合一汇总到一张图传统 attention 在长上下文下的三座大山 ┌─────────────────────────────────┐ │ ① Attention 矩阵 O(n²) │ → 显存爆炸 ├─────────────────────────────────┤ │ ② KV Cache O(n) │ → 单请求吃满显卡 ├─────────────────────────────────┤ │ ③ Prefill 计算量 O(n²·d) │ → 首 token 延迟飙升 └─────────────────────────────────┘工业界为了攻破这三座山从四个维度同时发力下面挨个看。三、技术演进四个维度的攻坚3.1 算法维度让 attention 本身变便宜3.1.1 Flash Attention2022IO 优化的奇迹关键洞察传统 attention 慢不是因为计算量而是因为IO 太多。GPU 的 HBM 显存带宽是 3 TB/s看似很快但 attention 中间结果n × n矩阵的读写需要反复访问 HBM——成了真正的瓶颈。Flash Attention 的做法把 Q、K、V分块block-wise加载到 SRAM片上高速缓存比 HBM 快 100 倍在 SRAM 中融合计算 softmax 和加权求和用一种巧妙的在线 softmax算法避免中间矩阵物化效果指标传统 AttentionFlash Attention显存 (n²)32 GB (128K)0.1 GB速度1×2-4×数值精度基线完全一致Flash Attention 现在是所有主流推理框架的默认实现——vLLM、SGLang、TGI 全都基于它。 详见系列第 13 篇Flash Attention 原理与实践。3.1.2 Sliding Window Attention放弃全局视野思路让每个 token 只看附近w个 token不再做全局 attention。复杂度从 O(n²) 降到 O(n·w)。代表模型Mistral 系列w4096、Llama 4 部分层。问题长距离信息丢失。所以现代模型常用局部 全局混合比如每 4 层用一次全局 attention。3.1.3 Sparse Attention选择性看更进一步让 attention 只在某些重要位置激活。代表Longformer、BigBird。现状在 LLM 时代不算主流更多用于特殊任务。3.2 位置编码维度让模型外推到训练长度之外这一维度是过去 3 年长上下文最大的突破之一。问题训练 4K推理 32K 会怎样如果直接用训练长度之外的位置——模型行为崩溃。原因绝对位置编码训练时没见过位置 5000embedding 是随机的相对位置编码位置插值方式没学过3.2.1 ALiBi2021用偏置代替位置思路不用位置编码直接在 attention 分数上加一个距离惩罚——位置越远惩罚越大。优点天然支持外推距离越远惩罚就越大新位置也能算。缺点远距离信息衰减太快不利于真正长上下文理解。现已被 RoPE 路线超越。3.2.2 RoPE2021当下主流思路用旋转矩阵编码相对位置。每个位置m把 Q/K 的每对维度旋转角度m·θ。q_m q_m · R(m·θ) k_n k_n · R(n·θ) q_m · k_n q_m · R((m-n)·θ) · k_n ↑ 天然包含相对位置 m-n优点相对位置 计算高效。缺点直接外推到训练长度之外效果会崩溃高频维度旋转太快。NTK-aware / YaRNRoPE 的外推神器这是让短训练模型用上长上下文的关键。核心思路RoPE 的不同维度对应不同频率长上下文外推时对高频维度做减缓处理外推对低频维度做拉伸处理插值通过混合策略平衡新位置的稳定性和已有学习的保留实际效果Llama-3-8B 原训练 8K用 YaRN 可以外推到 32K-128K效果损失极小。主流玩家YaRN开源主流配合 fine-tuning 可推到 1MLongRoPE微软方案无需训练直接推到 2MNTK-aware Scaling训练时启用效果稳定 详见系列第 15 篇长上下文优化 - YaRN/Ring Attention 详解。3.3 并行维度把上下文拆到多卡当单卡装不下整个 KV Cache 时必须把上下文切分到多张卡上。3.3.1 Ring Attention2023上下文级的分布式 attention思路把序列均匀切分到 N 张 GPU每张 GPU 持有局部 Q、K、VK/V 在卡之间环形传递每张卡轮流和其他卡的 K/V 做 attention通信和计算 overlap效果理论上 N 张卡可以处理 N 倍长的上下文。Google 用 Ring Attention 训练了 Gemini 1.5 Pro 的 2M 上下文。代价通信开销随上下文长度线性增长需要高速互联NVLink / IB。3.3.2 Sequence Parallelism / Context ParallelismSequence Parallelism训练时把激活值按序列维度切分到多卡节省激活显存。Context Parallelism推理时把 KV Cache 按序列维度切分到多卡。这些技术2024 年开始进入主流推理框架——vLLM、SGLang、TensorRT-LLM 都已支持。 详见系列第 20 篇分布式推理 TP/PP/EP/CP。3.4 推理优化维度把每一比特榨干3.4.1 PagedAttentionvLLM 核心问题传统 KV Cache 是连续分配的——为了支持最长序列要预先分配最大显存。结果短请求大量浪费显存碎片化严重并发能力骤降PagedAttention 思路借鉴操作系统的虚拟内存分页——把 KV Cache 按 16 token 一页管理按需分配可以共享。效果吞吐量提升 2-4×显存利用率提升 60%同时支持长短上下文混合并发 详见系列第 11 篇推理加速三板斧。3.4.2 KV Cache 量化把 KV Cache 从 FP16 量化到 INT8 / FP8 / INT4显存直接砍半甚至砍 1/4。实际生产参数量化级别显存精度损失适用场景FP16 (baseline)1×0%默认FP80.5× 1%H100 推荐INT80.5×1-2%生产主流INT40.25×3-5%极限优化3.4.3 KV Cache 卸载Offloading新趋势把不常用的 KV Cache 部分卸载到 CPU 内存 / SSD按需读回 GPU。代表方案vLLM 的 Prefix Caching、SGLang 的 RadixAttention。典型应用长对话中复用历史 KV Cache避免重复 prefill。四、实战部署一个长上下文服务4.1 模型选型不要被「支持 N」骗了模型宣传支持的上下文长度和实际能用好的上下文长度经常不是一回事。判断方法看大海捞针Needle in a Haystack测试——在长文本中藏一句话让模型回答关于这句话的问题。模型标称上下文大海捞针有效范围参考Claude Opus 4.71M全程稳定Gemini 2.5 Pro1M / 2M全程稳定GPT-5400K全程稳定Qwen 3-Max1M800K 以内稳定Llama 3-8B (YaRN 扩)128K64K 以内稳定DeepSeek-V3128K100K 以内稳定经验法则宣传值打 0.5-0.7 折是更保险的可用上下文。4.2 vLLM 配置长上下文示例# 部署 Qwen3-32B 支持 128K 上下文 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-32B-Instruct \ --max-model-len 131072 \ --tensor-parallel-size 2 \ --kv-cache-dtype fp8 \ --enable-prefix-caching \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32几个关键参数解释--max-model-len 131072声明支持 128K--tensor-parallel-size 2双卡张量并行系列第 20 篇详解--kv-cache-dtype fp8KV Cache 量化到 FP8显存砍半--enable-prefix-caching复用历史 prefix 的 KV Cache加速多轮对话--gpu-memory-utilization 0.9留 10% 显存给临时 buffer--max-num-seqs 32最大并发数长上下文下应该降低4.3 长上下文部署的 5 个真实坑4.3.1 坑 1首 token 延迟TTFT爆炸prompt 越长prefill 阶段越慢。1M 上下文的 prefill 可能要 30 秒。对策流式输出 用户侧 loading 动画Prefix Caching多轮对话场景显著改善Chunked PrefillvLLM 高版本支持4.3.2 坑 2并发掉到地板128K 上下文 Llama-3-70B H100 80G最多只能并发 1-2 个请求。对策长短请求分流到不同实例引入 priority queue长请求降级处理短请求走 7B 模型长请求走 70B 模型4.3.3 坑 3质量随长度衰减模型在第 1000K 位置的理解远不如第 1K。常见症状忘记早期指令忽略系统提示中间内容被压缩对长文档某段内容的回答精度下降对策关键指令放在 prompt 开头 结尾两端效应测试你的模型在不同长度的真实表现划定安全区考虑 RAG 短上下文的混合策略4.3.4 坑 4成本曲线非线性API 计费按 token但 prefill 的算力成本随长度平方增长。所以 OpenAI、Anthropic 都对长 prompt 收 prefix caching 折扣——用上 caching 能省 50-90%。自部署时同样要在监控里加 TTFT、吞吐、显存利用率三项关键指标。4.3.5 坑 5上下文超长 → KV Cache 溢出如果用户输入超过--max-model-lenvLLM 会直接拒绝。要在网关层做硬截断 友好提示。五、长上下文 vs RAG永恒的争论随着 1M 上下文普及一个老问题再次浮上水面既然我能把 100 万 token 都丢给模型是不是 RAG 就过时了短答案没有。两者各有适用场景混合使用是趋势。5.1 长上下文的优势零信息丢失不存在 chunk 切分和检索召回率问题跨段推理强模型能在整个文档范围内做关联实现简单直接灌入即可无需 embedding/向量库等基础设施适合一次性任务长文档总结、代码库分析5.2 RAG 的优势成本可控每次只检索几 K不付百万 token 的算力数据可更新向量库可增量更新不需要重新塞 prompt支持海量数据1M 也只是百 MB 文本企业知识库经常是 GB-TB 级可追溯可以告诉用户答案来自哪段延迟低避免长 prompt 的 prefill5.3 选型决策表场景推荐方案理由单份长文档 QA长上下文简单且效果好企业知识库GBRAG长上下文塞不下跨多份文档汇总RAG 长上下文检索召回 → 长上下文整合代码库整体重构长上下文跨文件推理高频客服 / 商品搜索RAG成本可控Agent 多步任务长上下文为主需要保留全程上下文 详见系列第 26 篇RAG 实战 - 从向量数据库到 GraphRAG。5.4 混合策略GraphRAG / Adaptive RAG / Long-Context RAG2025 年后业界的实际做法越来越混合GraphRAG先用 RAG 检索相关文档实体关系图再用长上下文做推理Adaptive RAG根据 query 难度动态决定检索 长上下文比例Long-Context RAG把 RAG 检索结果通常上百 K灌入长上下文模型这是大模型应用层的进化方向——不是长上下文取代 RAG而是两者协同最大化效果。六、结语上下文是新维度的算力读完本文你应该明白上下文窗口从 4K 到 1M每个数量级都是一场硬仗——攻坚发生在算法、位置编码、并行、推理优化四个维度O(n²) 是物理上不可消除的所有技术都在绕它Flash Attention 绕 IO、Ring Attention 绕单卡、量化绕显存工程师选型时别看标称看实测——大海捞针是硬指标1M 上下文不是免费午餐——TTFT、并发、成本曲线都会陡变长上下文不是 RAG 的替代品混合才是未来至此入门认知篇第 1-5 篇完整收官——你应该已经建立起完整的大模型工程心智模型生态全景、架构原理、参数账、token 账、上下文账。接下来我们进入训练与微调篇第 6-10 篇第 6 篇预训练全流程—— 数据、算力、Scaling Law 实战拆解。我们会看到 DeepSeek V3 用 557 万美元做出顶级模型背后的工程细节。后面陆续是 SFT 微调、RLHF / DPO、垂直领域大模型、训练数据工程。如果你是做应用为主的工程师训练篇可以快速浏览重点放在第 11 篇推理优化和第 16 篇 vLLM 部署之后的部署模块。参考文献上下文窗口的秘密从 4K 到 1M 的技术演进
