当前位置：首页 > news >正文

收藏！小白程序员必看：大模型超长上下文深度解析，从限制到突破

news 2026/3/26 18:11:24

一、背景

这篇文章我会给你介绍大模型中非常重要的一个技术指标：上下文长度。我们知道，AI 问答类产品和传统问答类产品，在使用层面上有一个很重要的区别就是上下文，AI 问答产品可以根据上下文进行更加深层次的问答，给我们的感觉就是很智能，很人性化。
前阵子非常火的 AI 问答产品 Kimi，就是以超长上下文著称，比如支持 200 万字长文本输入，一次性输入几本书，可以准确进行内容整理输出；再比如 GPT-4-turbo，支持 128K 上下文长度，还有像 6B，最新版本已经支持 32K 上下文长度。
以前各大厂商在宣传自己的产品的时候，讲的最主要的一方面就是参数规模，现在除了参数规模，还经常提的就是支持的上下文长度，所以业界有人笑称，大模型卷完参数，开始卷上下文了。今年 3 月份，阿里云通义千问已经将上下文长度直接提升至 1000 万字，是 Kimi 的 5 倍，而且免费提供给客户使用，一下子卷到了极致。

二、为什么超长上下文很重要

用 Kimi 所在公司月之暗面（Moonshot）的创始人杨植麟的话说，Lossless long context is everything，杨植麟判断 AI 产品的终极价值是提供个性化的交互，⽽lossless long-context 是实现这⼀点的基础。模型的微调不应该⻓期存在，用户跟模型的交互历史就是最好的个性化过程。
我们知道，在传统计算中有两个核⼼原则：计算是按照顺序逐步进⾏的，每⼀步都有有限的复杂度容量。⼤型语⾔模型可以被看作是进化了的计算实体，所以⼤模型能够达到的最⾼⽔平由两个因素决定：一个是单步骤的容量，即模型在每⼀步中可以处理的信息量，对应参数量；另一个是执⾏的步骤数，也就是模型能够处理的上下⽂⻓度。
目前，大部分大模型研究都集中在增加模型参数量的大小，即增强「单步骤容量」。但是在保持⼀定参数量的同时放大另⼀个维度，即「步骤数」或上下文长度也同样重要。上下文窗口就像⼤模型应用的新「内存」，窗口越大，用户能用它做的事情就越广泛；同时，窗口所能容纳的信息越多，模型在生成下⼀个 token 时可以参考的信息就越多，「幻觉」发生的可能性就越小，生成的信息就越准确。
举几个很实际的例子。
招聘场景，在系统上传 50 份简历，每份简历都是⼀个 PDF⽂档，50 个简历上传之后，提要求，⽐如要具备⼀定的英语⽔平，有⽐较强的技术背景等，智能助⼿在阅读完这 50 份简历之后，⻢上就给出来了 Top5 推荐，最后 Top2 的两个⼈刚好就是最后实际被录⽤的。
再比如打⻋发票整理，直接上传 50 个发票，智能助⼿可以⾃动整理你过去⼀个⽉的⾏程到底是什么样的，直接整理出来⼀个报销⽂档。
⼜或者有好⼏篇英⽂论⽂，你想做⽐较、分析，智能助⼿可以利⽤它的⻓⽂本能⼒，很好地完成任务。

三、为什么会有上下文限制

3.1、计算资源限制

就拿 Transformer 架构来讲，前面文章讲过注意力机制，所有的输入会被切分成一个一个 token，注意力机制就是在预测下一个词的时候，可以计算当前 token 和其他 token 的关系，如果输入序列非常大，切分出来的 token 就多，注意力机制计算的时候，需要的算力就会更大。
Transformer 模型中自注意力机制的计算量。会随着上下文长度的增加呈平方级增长，比如上下文长度增加 32 倍时，计算量实际会增长1000 倍，这意味着如果只是用朴素的方式实现，用户需要等待极其长的时间才能获得反馈，所以如果想要获得快速反馈，那么必须增加算力，这是核心原因。

3.2、内存消耗

随着输入序列长度的增加，模型在每个处理步骤中需要保留更多的中间状态信息。这会显著增加 GPU 或其他处理器的内存需求。在实践中，这个问题限制了模型能够处理的最大序列长度，以适应可用的硬件资源。

3.3、宽带限制

以 1750 亿参数的 GPT-3 为例，目前最高单机配置（80GiB * 8）最多只能支持 64k 上下文长度的推理，超长文本对显存的要求可见⼀般。这带来了极大的显存带宽压力：英伟达 A800 或 H800 的显存带宽高达 2～3TB/s，但面对如此长的上下文，一般方法的生成速度只能达到 2～5tokens/s，使用的时候极其卡顿，体验很糟。

四、如何支持更长上下文

4.1、稀疏注意力机制

稀疏注意力机制是一种优化过的注意力计算方法，使用全连接注意力时，每个元素都会与序列中的其他元素计算注意力关系，而在稀疏注意力机制中，元素只与序列中选择的部分元素建立这种关系。这种选择可以基于预定义的模式，比如局部窗口、固定模式等，也可以是通过学习得到的动态模式。
稀疏注意力机制的主要优势是显著降低了计算复杂度和内存需求，使模型能够高效地处理更长的序列。这一机制特别适合需要模型理解和处理大范围上下文信息的应用。

4.2、滑动窗口

滑动窗口是一种简单的限制方法，用于减少自注意力计算的复杂度。在这种方法中，每个令牌只关注它附近的一小部分令牌。例如，如果设置窗口大小为 5，那么每个令牌只会与它前后两个位置的令牌进行交互（总共 5 个令牌）。这种方法能有效降低计算量，因为它限制了每次计算涉及的令牌数量。
滑动窗口和稀疏注意力都是减少注意力计算的方法，不过二者有区别。
计算复杂度：滑动窗口通过简单地降低每个令牌关注的范围来减少复杂度，而稀疏注意力通过更智能的选择关注点来优化计算。
灵活性：滑动窗口技术相对固定，每个令牌的关注范围是固定的。稀疏注意力则更灵活，可以根据任务的需要调整关注的范围和模式。
实现难度：滑动窗口技术实现起来相对简单，而稀疏注意力可能需要复杂的数据结构和算法，尤其是在动态选择关注点的时候。

4.3、降采样

降采样就比较粗暴了，就是一种数据减少技术，减少输入序列，同时尽量保留重要信息，比如只选择序列中的某些部分单词，或通过合并相邻的元素，来创建一个更短的序列。比如当我们输入一本 20 万字的 PDF 书籍时，通过一定的策略，只取其中我们认为重要的内容，经过处理后，喂给模型的可能只有 2 万字。这样的方法优势劣势都很明显，优势就是可以让模型支持更长的上下文，劣势就是有可能丢失有用的信息，使模型的性能下降。
以上这些方式是比较常见的，不过也有人认为，这些都是解决上下文长度问题的“技术捷径”，牺牲的是模型的性能，因为无论是稀疏注意力、滑动窗口还是降采样，都是主动丢弃不重要的数据，那么在评估不重要的数据过程中，很有可能产生误判，从而影响模型性能。
那究竟什么方法不是捷径呢？在月之暗面披露的关于 Kimi 如何解决上下文长度问题的技术细节中，提到了这样的方式，我们一起来看下。
1、模型训练方面
在传统的 Tensor 并⾏、Data 并⾏、Pipeline 并⾏基础上，增加了多项基于 Seqence 维度的并⾏策略，提升了并⾏效率。利⽤定制版的 Flash Attention、Fuse Cross Entropy、CPU offload 等技术⼤幅度降低了显存压⼒。还使⽤了创新的训练⽅法，针对性地调配了多阶段式训练⽅法，让模型保留基础能力的前提下，逐步激活⻓上下⽂的能⼒。
2、模型推理方面
⽤GQA 替换 MHA：让 KVCache 所占⽤的显存⼤⼩⼤幅度缩⼩。
2Paged attention：保证显存的充分利⽤。
低⽐特量化：通过 W8A8，最多可以把推理速度在上述基础上再提升⼀倍。
MoE & KVCache 裁减：让显存占⽤在上述基础上再下降⼀倍。

五、超长上下文测试的很有趣的例子

在⽂本语料中藏⼊⼀个与⽂本语料不相关的句⼦，比如在整本《西游记》⾥放⼊⼀句只会在《红楼梦》里出现的话，然后看大模型能不能通过自然语言提问的方式，即 Prompt，把这句话准确地提取出来。藏起来的那句话就是“针”，《西游记》就是大海。
国外有一个大模型开发者 Greg Kamradt，在 GPT-4 Trubo（128K）以及 Claude2.1（200K）上进行过测试，效果并不好，Kimi 的工程师用了相同的方法测试，经过几轮的测试，发现效果时好时坏，且有一些规律：效果好坏取决于 Prompt 和内容（即“大海”和“针”），而且并没有强一致的结果。
经过几轮测试，Kimi 的工程师发现，除了大模型本身的长文本记忆能力和指令遵循能力，其实还有两个关键点对结果起了明显作用：⼀是藏在“大海”中的“针”是否完全没有歧义；⼆是向⼤模型提问的 Prompt 写得是否足够明确。