技术深度解析
上下文窗口问题的核心，源于Transformer架构的注意力机制。在标准的自回归Transformer中，模型需要计算序列中每个token与其他所有token之间的注意力分数。这一操作的计算复杂度相对于序列长度（n）呈二次方增长（O(n²)）。在实际部署中，模型使用键值（KV）缓存来存储已计算过的先前token的表征，以避免在生成过程中重复计算。该缓存随上下文长度线性增长，但其管理却成为内存和延迟的主要瓶颈。
将上下文扩展到128K token或更多，必须解决KV缓存爆炸式增长的问题。一个拥有128K上下文、典型隐藏维度的700亿参数模型，其KV缓存可能超过40GB GPU内存——远超单个高端GPU的容量。这迫使开发者采用复杂的模型并行和内存卸载策略，大幅增加了成本和延迟。
目前，业界正在探索多种技术路径：
1. 稀疏与流式注意力：这些方法并非关注所有token，而是选择一个子集。滑动窗口注意力（如Mistral AI的模型所用）将每个token的注意力限制在固定的局部窗口内。分块注意力将序列分块处理。谷歌的BigBird则结合了全局、局部和随机注意力模式，以实现线性复杂度。
2. 循环与状态化架构：这类方法旨在将过去的上下文压缩为固定大小的状态。据称，DeepMind拥有100万token上下文的Gemini 1.5 Pro采用了新颖的混合专家（MoE）架构和高效的注意力机制。RWKV（Receptance Weighted Key Value）是一种受RNN启发的开源架构，具备线性扩展能力，因其高效性而备受关注（GitHub: `BlinkDL/RWKV-LM`，约1万星标）。微软的LongNet则通过使用膨胀注意力来指数级扩大感受野，从而将上下文扩展到10亿token。
3. KV缓存压缩与量化：诸如H2O（Heavy-Hitter Oracle）和StreamingLLM等技术，能够识别并仅保留'最重要'的KV对（例如初始指令、最近的token）。对缓存进行激进的4位甚至2位量化，可将内存占用减少4-8倍，尽管可能带来精度损失。
4. 外部记忆系统：受检索增强生成（RAG）启发，像MemGPT（GitHub: `cpacker/MemGPT`，约7千星标）这样的系统创建了分层记忆架构。大语言模型管理一个较小的工作上下文，但可以调用向量数据库来获取相关的过去信息，从而模拟出大得多的上下文。
| 技术 | 上下文长度 | 核心创新 | 计算复杂度 | 主要权衡 |
|---|---|---|---|---|
| 标准Transformer | ~8K-32K | 完全注意力 | O(n²) | 超出限制后成本过高 |
| 滑动窗口（Mistral） | ~128K | 仅局部注意力 | O(n*w)，w为窗口大小 | 失去长程依赖关系 |
| StreamingLLM | ~1M+ | 保留初始及最近token的KV缓存 | ~O(n) | 可能丢失中间上下文信息 |
| 循环架构（RWKV） | 理论上无限 | 通过RNN状态实现线性化注意力 | O(n) | 在某些任务上难以匹配Transformer的质量 |
| 外部记忆（MemGPT） | 效果上无限 | 类似操作系统的向量数据库分页 | O(1)上下文 + 检索成本 | 增加系统复杂性，存在检索延迟 |
数据启示：上表揭示了一个清晰的权衡边界：要实现更长的上下文，就必须牺牲完美的记忆召回（通过稀疏化/压缩）、架构的纯粹性（超越纯Transformer），或系统的简洁性（增加外部记忆）。没有一种方法占据绝对优势；最优解决方案很可能取决于具体应用场景。
关键参与者与案例研究
竞争格局由秉持不同技术和产品理念的实验室所定义。
Anthropic 始终将上下文长度作为核心差异化优势。Claude 3.5 Sonnet支持20万token上下文，该公司还发布了关于'长上下文提示'的研究，强调将长上下文能力产品化，用于文档分析和长内容创作。
Google DeepMind的Gemini 1.5 Pro 代表了迄今为止最大胆的宣称，其在视频、音频和代码数据集上展示了100万token的上下文窗口。据传，其技术秘诀在于结合了高效的MoE Transformer与新颖的注意力机制，使其能够处理相当于1小时视频或11小时音频的内容。
OpenAI 则采取了更为审慎、以产品为中心的策略。GPT-4 Turbo的128K上下文虽然可观，但并非业界领先。相反，OpenAI引入了自定义指令和持久性的ChatGPT记忆（一项用户可控、选择加入的功能）作为务实的解决方案。这通过赋予模型针对每个用户的、有限的持久记忆，绕过了无限上下文带来的技术成本，同时满足了用户对连续性和个性化的核心需求。