长上下文窗口扩展(Long Context)

Long Context Window Scaling

长上下文扩展是把 LLM 原生支持的最大输入长度从 4K/8K Token,扩展到 128K、1M 甚至更长的系列技术组合,涵盖 RoPE 外推、YaRN、位置编码修改、KV Cache 优化。

详细解释

Long Context(长上下文扩展) 是 2023 下半年到 2025 年最硬的模型工程仗:2023 年 Llama 2 70B 还是 4K Token(约 3000 中文汉字),读不完一篇 8 页的论文;到 2025 年普通 7B 开源模型都默认 128K(约 10 万字,一本中篇小说),旗舰模型 1M-4M Token(1000 页 A4 文档 / 1 小时代码仓库)。用户的”把一整本 PDF 丢进去提问”的期望被真正满足,RAG 行业甚至出现了”Long Context 会不会替代 RAG?“的讨论(后面 FAQ 回答结论:不会,两者是互补)。

长上下文不是”把 config.max_position_embeddings 从 4096 改成 131072 重启就完事”。模型在 4K 训练时学到的位置编码(RoPE)对”第 4096 个 Token 之后”的位置完全没有见过,直接改配置会导致”过了 4K 之后注意力完全乱了,准确率掉到 20%“。长上下文扩展是一个三层组合拳:位置编码外推 → 继续预训练(SFT / Continued Pretrain 长数据)→ 推理端 KV 显存优化

第一代到第四代:位置编码外推的 5 年发展史

方法年份原理最大安全扩展倍数精度下降代表模型
AIxOS / 线性插值 RoPE(Naive Position Interpolation, NTK-aware)2023 年 Meta Llama 2 同期把原 RoPE 角度 θ 的位置 0…4095 线性”压缩”到更长位置 0…131071,让 4K 的 1 号 Token 对应 128K 的 32 号。8×(4K→32K)~10%Llama 2 32K 社区版
NTK-aware RoPE(按频率分频段压缩)2023 年 6 月社区 / metamorphosis低频长波外推,高频短波内插:长位置对相位不敏感的大波长外推,短波长仍然插值;解决了 PI 压缩后长距离重复率高的问题。16×~32×~5%GPT-4V 内用候选;社区 Qwen-7B-32K
YaRN(Yet another RoPE extensioN method,2309.00071 论文)2023 年 9 月 LMSYS / SGLang 团队在 NTK-aware 基础上再加”温度缩放 + 动态旋转因子 + 截断高频分量”三条公式;第一次让 Llama 2 7B 从 4K → 128K 准确率只下降 2%,不需要任何额外微调16×~64×≤ 2%(当前免费午餐最优解)几乎所有 2024 后发布的开源模型 128K 默认
继续预训练 Long-context P-Tuning / SLiding window(SWA)+ 全量数据2023 年底(Giraffe / LongAlpaca / Yarn)YaRN 初始化后,再用 10% 长文档(书籍/代码/合订本)做 1 epoch 继续预训练;滑动窗口注意力(每步只看最近 4K/8K Token,省算力) 让训练 128K 的成本接近 8K。32×~128×≤ 1%Qwen 2.5 128K、Yi-34B-200K 官方长上下文版
UL2 / 1-Million Token Context(MegaScale)2024-2025把模型改成”Infini-Attention / Recurrent Memory Transformer / 混合注意力(Local+Global)“,让注意力复杂度从 O(N²) 降 O(N log N) 或 O(N)。无限(1M-10M 级别)5% 至 10%(远端记忆会弱化)Gemini 1.5 Pro 1M、Claude 3 Opus 200K、唯元智创 Long-Chat 128K

推理端 KV Cache 与长上下文的矛盾及解决方案

长上下文最大的工程敌人是 KV Cache 显存爆炸:一个请求 128K Token 的历史,70B BF16 模型单机 KV Cache 就是 128K × 2KB ≈ 256MB,一张 A100-80G 同时只能服务 300 个用户,QPS 极低。三条主流解法现在都已经是推理框架标配:

  1. KV Cache 量化(FP8 / INT4 KV):vLLM 的 FP8 KV、SGLang 的 INT4 KV Cache 两种实现,把每 Token 2KB 压到每 Token 0.3 至 0.5 KB,同一张卡服务用户数 4x 至 6x,精度几乎没有下降(注意力对 KV 的数值误差鲁棒性极强)。
  2. Page-Attention / Paged KV Cache(vLLM 的 PagedAttention)+ RadixAttention(SGLang):KB 级 KV 分页管理 + 相同前缀共享,多用户共用的 System Prompt / RAG 背景段一份 KV 全用户共用。
  3. Infini-Attention / StreamingLLM(Attention Sink):StreamingLLM 2023 MIT & Meta 论文发现”注意力对前 4 个 Token 有特殊依赖(叫 Sink Tokens)“,只要保留最近 2048 Token + 前 4 Token,模型输出就不会崩;配合 128K 长上下文时可以”窗口化”推理,历史 KV 超过窗口就丢进 CPU offload 向量库。

唯元智创 平台上的 128K 长对话模型默认组合:YaRN 外推 + 继续预训练 1 epoch 长数据 + FP8 KV Cache + RadixAttention,实测 4 张 A100-80G 集群下 128K 上下文 QPS 能做到 180(同配置 2023 年 10 月版本只能做到 25 QPS,整整 7x 提升)。

常见问题

Long Context 真的能取代 RAG 吗?我直接把 1000 页 PDF 全塞进去不就完了?
不能。2023 Stanford 的 Lost in the Middle 论文 + 2025 年多家独立评测都验证了:哪怕模型支持 1M 上下文,把答案放中间 1/3 位置时,准确率仍然会从 90% 掉到 40% 至 50%。原因是注意力是局部偏置的:模型对开头(Recent/Start)和结尾(Recent/End)的内容记得最牢,长文档中间最容易丢。正确的 2025 架构是 “Long Context + RAG + Context Compression 三层结合”:先 RAG 粗检索 50 条 chunk → Context Compression 压到 Top-3 关键章节(保留章节标题树结构)→ 再把压缩后的 3 段 + 全局目录送进 128K Long Context 窗口。这样”检索准 + 格式不丢 + 长链路推理能连起来”,三个最强点都吃到了,比纯 Long Context 或纯 RAG 的准确率再 +8 至 12 个百分点。
128K 上下文的 API 是按 128K 每次计费吗?会不会特别贵?
计费是按”你实际喂进去的 Token 数 + 实际输出的 Token 数”,不是按最大窗口大小!(和 4K 模型窗口你只送了 500 字,不会按 4K 收钱一个逻辑。)比如喂了 8000 Token 的历史 + 3000 Token 的文档片段,即使窗口支持 128K,也只收 1.1 万输入 Token 的费用 + 输出费用。但要注意:长上下文模型(32K/128K)的”每百万 Token 单价”通常比同尺寸短上下文模型贵 15% 至 50%,因为它训练/推理都更贵(FP8 KV + FlashAttention 降成本后,差价已经从 2 倍缩小到 1.2 倍了)。正确做法是:8K 以内的普通对话走短上下文便宜模型,超过 8K 自动路由到长上下文贵模型,按任务分桶是最好的成本策略。
YaRN 已经能免费做 128K 了,还要不要做长语料继续预训练?
看你业务需要的是”能装下”还是”装下后真读懂了”。YaRN 保证”能装下去 + 位置编码不崩”,但模型训练数据里没见过超过 4K 的长依赖关系(比如第 2 页的伏笔在第 60 页被引用这种长距依赖),模型会”装得下但读不懂远距”。典型对比:YaRN 128K 无继续预训练 → 32K 位置的 needle in a haystack(大海捞针)任务准确率 60%;同模型用 128K 长语料(书籍/合订代码仓库)继续预训练 1 epoch → 同任务准确率 92%。成本对比:继续预训练 7B 模型 128K 数据 1 epoch 约 ¥8000 至 15000(8×A100 跑 24 小时)。结论:如果你只是”装下 30 页合同偶尔问几个开头的条款”,YaRN 够用,不用继续训;如果你要做”跨 200 页财报数字勾稽关系检查”(典型长距依赖),必须加一步长语料继续预训练才好用。