AI 大模型窗口上下文进化史: 4K还不够？2K 饭量的 LLM如何一步步成为 10M大胃王的！上下文长度的增加是 L

上下文长度的增加是 LLM 的一个显著发展趋势。过去几年，几种长上下文语言模型陆续问世，包括

GPT-4 （32k 上下文）、
MosaicML 的 MPT （65k 上下文）、
Anthropic 的 Claude （100k 上下文）等。
基于Llama3.1-Instruct打造的UltraLong-8B模型 (4M上下文)
Gemini 1.5 Pro (稳定运行 1M上下文,极限 10M上下文)

扩大 Transformer 的上下文长度是一个挑战，因为其核心的注意力层在时间复杂度和空间复杂度与输入序列长度的平方成正比,那么核心注意力真的是 LLM 能够成为大胃王的拦路虎么?

答案是 "是",但不是最大的拦路虎

长上下文运行的问题在于缺少长预训练数据，而不是二次注意力。

在实际应用中，将已有的基础LLM（通常上下文窗口较小，比如4K或8K）微调得到上千、甚至十万级上下文窗口的超长上下文模型，已经成为主流做法。之所以先训练一个小窗口模型再进行扩展，主要是因为训练成本、硬件资源和数据规模的限制：从零开始训练一个本身就具备大上下文能力的巨型模型，几乎在算力和时间上难以承受。而在已有预训练模型基础上，只需在保持原有权重的同时，通过有限的额外训练（常见方式包括位置编码插值Position Interpolation、相对位置编码RoPE扩展等），即可在原有语义能力之上显著提升上下文输入长度。这种“先小后大”的分步策略兼顾了资源利用效率与最终效果，也便于对已有大规模模型体系进行增量式改进

什么是上下文窗口及其重要性

上下文窗口的定义

上下文窗口（Context Window）是指在一次推理（inference）过程中，模型所能同时“看到”的输入标记（token）序列的最大长度。通俗地说，就是模型的“短期记忆”范围，决定它可以在一次回答或生成过程中参考多少已出现的文本内容

扩展上下文窗口的价值

更长文本的处理能力：超长上下文允许模型一次性处理更大篇幅的文档，比如整本书、完整法律合同、长篇会议记录等，从而提升对长文档的摘要、检索、推理等能力
保持对话历史的连贯性：在多轮对话场景中，长窗口能保留更多前文信息，减少模型丢失上下文细节的风险，提升对话连贯性和准确性
多示例few-shot/chain-of-thought：在同一次推理中插入更多示例或链式思考(prompt chain-of-thought)，更易得到高质量答案；在原来窗口限制下，往往不得不拆分为多次查询，影响效果和效率[bdtechtalks.com]

然而，训练一个原生具备超长上下文能力的Model需要巨量计算资源，因为注意力机制（Attention）的计算复杂度通常随着序列长度呈二次增长，且相应的位置编码、判别能力都需在预训练阶段逐步学习。如果直接从头开始训练一个具有128K或更大窗口的模型，往往需在GPU/TPU集群上进行数周乃至数月的训练，耗费成本极高。因此，业界更倾向于先训练小窗口基础模型，再做针对性微调，在“保持已有语言理解能力”的基础上完成上下文窗口扩展

为什么先使用较小窗口的基础模型再微调

为什么会有这两个训练阶段呢？共有两种可能：（1）由于注意力层的二次复杂性，使用长上下文进行训练在计算上太过昂贵；（2）预训练阶段缺乏长序列数据。

长序列数据的缺乏,巧妇难为无米之炊

常见预训练数据集（如 GitHub 和 CommonCrawl ）中序列长度的分布情况。有趣的是，超 80% 的预训练示例（无论是网页文档还是代码文件）包含的词元数都少于 2K 。另一方面，少数长文件对词元数产生了不成比例的影响（尤其是对源代码的影响），其中超 30-50% 的词元来自超 8K 个词元的文件

综合上述观察结果，可以得出结论：虽然使用 16-32K 上下文窗口进行预训练是可行 的， 但个别文档的词元分布并不适合这种方法。主要问题在于，传统的预训练方法将来自随机文件的词元打包到了上下文窗口中，这导致 16-32K 的词元窗口中包含了许多不相关的文档。假设在预训练期间， LLM 能受益于更具意义的长上下文，本文认为可利用元数据创建更长的预训练数据，例如通过超链接连接网页文档，以及通过代码库结构连接代码文件

资源与效率考量

1. 预训练成本巨大

从零开始预训练一个大规模Transformer模型（如上千亿参数、上下文窗口128K），需要充足的海量文本数据、高性能集群以及漫长训练周期。相较之下，先训练一个4K或8K上下文的基础模型，成本显著更低，且模型已基本具备了语言理解、生成能力，可作为后续扩展的“基座”

下面我们基于数据集的数据分布,分析一下 .

从图中可以看出， C4 和 RefinedWeb 中有相当大一部分的文件都相对较短，其中超 95% 的文件包含的词元不足 2K 。因此，将上下文窗口扩展到 2K 以上，只能为其中 5% 的文件捕获更长的上下文！

然而，你可能会认为，我们关心的是每个区间内的词元数量而不是文件数量。确实，当我们观察下图中的词元数量时，情况略有不同。在 RefinedWeb 中，将近 45% 的词元来自超 2K 个词元的文件。因此，将上下文长度增加到 2K 以上，对于 45 ％的词元来说可能仍然是有益的。至于剩余的 55%，我们会将来自随机文件的词元连接到上下文窗口中。我认为，这对模型的帮助不大，甚至可能影响模型性能。

如果我们将上下文窗口扩展到 8K，那么几乎有 80 ％的词元可以完全适应上下文窗口，换言之，只有 20% 的词元可能会从超 8K 的更长上下文中受益,其他github 数据集结论类似,因此现有训练的数据集,预训练的上下文过大会产生负面效果

2. 增量扩展更灵活

一旦有新的硬件或技术（如更高效的注意力实现、稀疏化技术、低秩近似LoRA扩展等）涌现，就可以在现有基础模型上做针对性微调，而无须完全重头训练。例如，长窗口微调时只修正模型的位置信息表示，不改动大部分Transformer权重，因此迭代速度更快，资源消耗更小。

3. 可迁移已有生态

许多下游应用、检索增强生成(RAG)管道、插件体系等已经围绕4K/8K模型进行优化，直接替换成一个全新128K窗口模型兼容性和适配成本太高；通过微调升级上下文窗口，可以保留绝大部分下游管道配置，只需少量改动即可无缝衔接

模型稳定性与泛化能力

先优化语言理解与生成：基础模型微调通常已在大规模网页、书籍、对话等数据上进行长时间预训练，已形成较好的“通用”语言表示；若直接训练超长上下文模型，无法确保每个位置都得到充分学习，可能导致模型在某些长度段表现不稳定。分阶段先训练小窗口、再扩展，能够保证基础能力稳健继承
防止过拟合极长序列：在预训练阶段若直接使用过长序列，可能过度依赖某些长序列特征，反而会削弱模型对中短文本的泛化能力；而先后分步训练更易控制训练分布，避免出现“只能处理极长上下文”但对常用窗口表现退化的情况

微调后上下文窗口扩展的技术原理

在现有基础模型上扩展上下文窗口的核心思路是调整模型的位置信息表示（Position Embeddings 或相对位置编码RoPE） ，同时保证已有Transformer层的权重尽可能保持不变。以下列举最常见的几种方法：

1. 位置编码插值（Position Interpolation）

原理概述：如果基础模型使用的是绝对位置编码（Absolute Positional Embeddings），其通常将位置索引(1,2,…,L)映射为L×d的Embedding矩阵。若要扩展到更长序列（例如原来L=4K，目标L′=8K或16K），可以通过插值(interpolation)的方式，将原有4K的Embedding中间插入新位置。例如，将原本index=1对应的编码复制到index=1；把原本index=4K的编码复制到index=8K；中间通过双线性插值(interpolate)生成2520到5000位置的编码

具体实现：假设原位置编码矩阵为P∈ℝ^{L×d}，新长度为L′，则新位置编码矩阵P′可按下式计算：

$P^{'}[i]= \text{Interp}(i \times \frac{L}{L′}, P)$

其中Interp为双线性或双三次插值方法，实现成本较低且在训练初期无需额外向量重训练

优缺点：该方法无需修改Transformer参数，仅需在微调时初始化新位置编码即可；但插值过程会造成边缘位置编码与原训练分布不完全对齐，可能需要在微调阶段额外使用长序列数据进行权重微调，以恢复长序列表现

2. 相对位置编码RoPE扩展（Rotary Position Embeddings）

RoPE原理：RoPE通过对Query和Key的向量空间施加旋转矩阵，将位置关联编码在旋转角度中，实现了相对位置不变性，且不需要显式存储绝对位置Embedding矩阵。原始RoPE只能支持到一个固定最大距离(max_position)；若要扩展，就需要调整旋转频率参数(frequency)或在原有旋转基础上添加新的频率bucket。
扩展方式：常见做法是比例缩放频率，即给定原始频率f(i)=θ^i（θ为常数），将其扩展为 $f′(i)=θ′^i$ ，其中 $θ′=θ^{L/L′}$ ，使得当新的序列位置 $i′=L′$ 时，对应的 $θ′^i$ 能与原来的θ^L对齐；这样在不改变核心RoPE计算逻辑的前提下，实现了“长距离旋转编码”的兼容性
训练与微调：在扩展后，通常会用长序列数据对扩展后的RoPE参数进行进一步微调，并且也会使用新的长序列样本让模型适应更大窗口。因为RoPE本身对长距离token的相对位置敏感度有限，还需配合注意力(Long-Range Attention)以及缓存(KEY/VALUES分段缓存)实现更长窗口处理

3. LoRA/Low-Rank微调（结合扩充上下文）

LoRA思路简介：LoRA（Low-Rank Adaptation）技术只对Transformer中的某些权重矩阵（如Q、K、V）添加低秩分解更新，而冻结剩余大部分权重，实现参数高效微调。由于不需要对所有参数进行更新，微调成本和显存占用大幅降低。
长上下文结合机制：在已完成位置编码插值或RoPE扩展后，使用LoRA只对部分层的投影矩阵进行微调，使得模型能在长序列(input up to L′)时保持语言理解与注意力分配能力。这样，当长文本输入时，QKV投影层经过微调，更能兼容扩展后的RoPE，保证对长距离token之间的注意力分配更加合理

4. 分块注意力与稀疏注意力（Sparse/Memory-Efficient Attention）

背景：传统自注意力(Scaled Dot-Product Attention)在序列长度N时计算复杂度为 $O(N^2)$ ，长序列时计算、内存消耗迅速爆炸。故业界提出分块(blockwise)、滑动窗口(local attention)、稀疏(sparse)或线性化(Linear Attention)机制，用于支持更长输入。
微调扩展上下文时的作用：当仅对位置编码进行插值/扩展后，如果不改变注意力计算，理论上仍会陷入 $O(N^2)$ 困局。因此，实践中常会结合 滑动窗口+全局token聚合（Global tokens） 、分层注意力(Hierarchical Attention) 等机制，将长序列分为若干小块并跨块进行信息汇总，从而在微调阶段使模型具备近似线性或亚二次的计算特性，实现长窗口[together.ai]
示例：Together AI在其文章中提到，他们在扩展上下文时结合了Local Attention + Dilated Convolution，先使模型在窗口内部进行局部注意，再通过一定的采样合并策略保证全局信息流通。这使他们的模型在32K窗口下推理速度仅比8K窗口慢约1.5倍，而非理论上的 $(32/8)^2=16$ 倍

基于Demo的具体演示 Llama 2 → Llama 3（4K/8K → 128K）

Llama 2 原生窗口：Llama 2在标准版本中使用4K或8K上下文（基于模型大小不同有所区分），其位置编码采用相对RoPE机制。
Llama 3 窗口扩展目标：Llama 3宣布支持128K上下文窗口，这意味着其相对位置编码需扩展到能够表达距今128K位置的旋转角度，同时Transformer层需在长距离注意力下保持稳定性。根据Meta官方博客介绍，Llama 3主要通过以下技术实现扩展：
- RoPE频率缩放（Frequency Scaling） ：将原RoPE的频率参数θ由 Llama 2 的max_pos 更新为 Llama 3 的max_pos=128K，通过插值方式计算新的旋转参数；
- Hybrid Attention：在标准自注意力基础上，Llama 3引入了Block-Sparse Attention，先将长序列划分若干长度为2048的小块，在每块内使用全局注意力（Global Pooling）配合跨块采样，在全局层面使用低秩全局token（例如[CLS]）聚合信息；
- 长序列预训练与微调：Meta在预训练阶段追加了大量长度≥64K的文档段落，让模型在实际微调中已经习惯了长文本注意力分配。最后在微调时，使用包含数十万条 ≥64K 长度的样本进行参数微调，确保微调后模型在128K窗口下能够保持解码质量（如长文档摘要、长篇对话等

以下为示例demo 代码:

import torch
from transformers import LlamaForCausalLM, LlamaConfig

# 1. 加载Llama 2 7B基础模型
config = LlamaConfig.from_pretrained("meta-llama/Llama-2-7b")
model = LlamaForCausalLM.from_pretrained("meta-llama/Llama-2-7b", config=config)

# 2. 用比例方式扩展RoPE频率
old_max_pos = config.max_position_embeddings  # e.g., 4096
new_max_pos = 131072
# 2.1 读取原RoPE参数（模型内部存储一般在 model.model.layers[].self_attn.rotary_emb）
for layer in model.model.layers:
    layer.self_attn.rotary_emb.max_position_embeddings = new_max_pos
    layer.self_attn.rotary_emb.scale = (old_max_pos / new_max_pos)
# 3. 修改config和tokenizer，保证输入长度限制同步
config.max_position_embeddings = new_max_pos
model.config = config

# 4. 结合分块注意力实现（此处简化为标记调用自己的LongSelfAttention实现）
#    假设我们有一个LongSelfAttention模块，替代原来的标准SelfAttention
for i, layer in enumerate(model.model.layers):
    layer.self_attn = LongSelfAttention(
        hidden_size=layer.self_attn.hidden_size,
        num_heads=layer.self_attn.num_heads,
        block_size=2048,  # 分块之后的Local Attention块大小
        global_k=256,     # 全局token数量
        rotary_scale=layer.self_attn.rotary_emb.scale,
    )
# 5. 进行超长语料微调（此处省略具体训练循环）

微调后窗口扩展的优势与挑战

优势

快速复用基础能力：微调策略让新模型直接继承了原模型的语言生成能力与知识储备，只需少量长样本训练，即可获得超长上下文推理能力，效率远高于从头预训练
生态兼容性好：大多数下游框架如LangChain、LlamaIndex等仅需将模型调用中的max_length参数改成对应新值，无需改造底层计算图，用户可以直接使用超长上下文接口[together.ai]
硬件成本可控：在扩展上下文时结合分块/稀疏注意力，使得推理成本从O(N^2)降至近O(N⋅logN)或O(N)，即使输入长度从8K到128K，也只略微增长，而非平方级增长；显卡显存占用提升有限，方便部署

挑战

长序列中梯度消失与注意力衰减：当输入超过数万token时，模型初始对远距离token的注意力权重可能非常小，微调过程中需要让这些权重得到增强，否则长距离信息无法有效传递。这需要在训练时混合不同长度的样本，让模型自适应
硬件带宽与内存瓶颈：尽管分块注意力可以降低计算复杂度，但长序列必然带来更大显存占用、更多KV缓存，因此对GPU/TPU显存、带宽提出了较高要求。在一些边缘设备上部署超长上下文模型面临挑战，需使用分布式推理或模型量化等手段
微调数据获取难：高质量的超长文本标签数据有限，若仅使用自然长文档（如书籍、报告）进行微调，可能与实际下游任务存在领域差异，导致微调效果无法最大化；因此常需同时引入任务相关的长上下文样本（如对话、日志、代码仓库等）

结论

为何从小窗口微调再扩展？ 主要源于预训练成本、硬件资源和兼容性等多方面考量：先得到一个“4K/8K窗口”的基础模型，再通过位置编码插值、RoPE频率缩放、分块/稀疏注意力等技术，在微调阶段将窗口扩展至16K、32K、128K乃至百万级，既能保持原有语义能力，又能显著提升长文本处理能力，资源利用更高效
技术实现核心在于位置编码和注意力机制：通过插值或频率缩放让模型“理解”更长序列的相对或绝对位置，同时借助分块/稀疏注意力降低计算复杂度，再结合LoRA等高效微调方法节约显存和训练时间，实现超长上下文能力
Demo演示说明了典型流程：无论是Meta的Llama 2→Llama 3，还是GPT-3.5/4 4K→32K，通过相似的插值/扩展+混合注意力+长序列微调步骤，都能在几天或几周的额外训练中，将已有4K上下文模型升级为支持数十万token超长上下文模型。
优势与挑战并存：微调后超长上下文模型在长文本摘要、检索增强生成（RAG）、全文问答、多示例few-shot等任务中大幅提升性能，但需要在训练数据、硬件成本与长序列注意力稳定性方面投入更多关注

综上所述，将小窗口基础LLM微调为超长上下文模型，是当前兼顾资源、效果与生态兼容的最佳实践。通过位置编码插值、RoPE频率扩展、分块/稀疏注意力等技术手段，再配合高效微调方法（如LoRA），可以显著扩展模型的“记忆”范围，并且在实际应用中获得更连贯、准确的生成效果

最后我们放一个 2025 年两阶段最新实践产出: 4M 上下文的的Paper

参考资料: