Invalid input. Special characters are not supported.
最近,AI 领域围绕模型“记忆”能力和上下文长度的公告层出不穷。
- Meta 发布了 Llama 4 系列模型,其中的 Maverick 模型支持多达 100 万个词元的上下文窗口,Scout 模型则支持令人乍舌的 1,000 万词元上下文窗口。
- OpenAI 宣布,ChatGPT 现在可以记住之前的聊天内容,让应用程序更加实用。
- 在 GTC 大会上,NVIDIA 发布了用于推理路由和键值缓存管理的 Dynamo 库。
在本博客中,我将回顾这些公告的内容,以及这对于设计“AI 工厂”的系统架构师而言意味着什么。
长上下文是一种优势
大多数用户与大语言模型 (LLM) 交互的方式是:编写查询,然后得到响应。输入和输出的总数就是查询的“上下文窗口”。在聊天用例中,输入和输出的总和通常在 100 到 1,000 个词元范围内。
随着硬件性能的提升,以及支持更大上下文窗口的模型发布,我们发现,这种上下文窗口在某些用例中非常重要。
我每天都会使用编码助手。在需要生成代码时,我希望模型能够理解我已有的代码库。我可以将现有代码添加到生成请求的上下文中,从而满足这一需求。通过使用更多已有代码作为上下文,编码助手可以在更高层次上工作,并从更大程度上更改代码库的架构。
本质上而言,上下文窗口越大,AI 编码助手越智能。
其他用例包括访问电子邮件、SharePoint 网站、医疗记录、法律诉讼等等。显而易见,可供 AI 使用的数据越多,AI 的输出质量越高。
什么是预填充和键值缓存?
现在我们知道了为什么需要更大的上下文窗口,接下来需要了解现代大语言模型中的一个基础概念:键值 (KV) 缓存。
当前市面上的所有主流 LLM 均使用 Transformer 架构,每条推理查询都遵循相同的步骤:
嵌入 -> 预填充 -> 解码 -> 后处理
嵌入阶段包括将文本查询转换为 AI 模型可处理的向量表示。
预填充阶段包括使用模型运行查询(以及同时提供的上下文,例如支持文本或代码行),模型会评估每个子字并生成内部表示,以此处理整个查询。这些表示中包含一组向量,称为键值 (KV) 向量。
解码阶段是模型处理的关键阶段。模型会获取预填充阶段生成的数据,然后生成新的词元(单词),从而完成对查询的响应。预填充阶段生成的键值向量可能会基于每个新生成的词元重新计算,也可能缓存起来,供随后重用。在解码阶段,模型会创建新的键值向量,同时使用之前的向量计算每个新词元。
最后,后处理阶段会获取解码阶段中生成的词元,并将其转换成人类可读的文本。
从以上的详细分步描述中,我们可以得出一个重要结论:大语言模型只有在预填充阶段完成后,才有能力开始生成新的词元。这种限制意味着,如果预填充阶段耗时较长,将直接影响用户的体验。
预填充需要消耗内存和时间
我的同事 Katya Giannios 拥有应用数学博士学位,长期从事推理系统架构的建模工作。我们一起估算了某些场景的预填充时间。

免责声明:这些数字均为估算值;我们将继续在实验室中进行测试,以便更好地了解系统。
该表展示了以下模型配置的推理性能:
- Meta Llama 4 Maverick 模型
- 4,000 亿参数
- FP8 权重
- 最大百万词元上下文窗口
- 运行服务器:NVIDIA DGX B200
- 8 块 NVIDIA B200 GPU
- 1.4TB HBM3E
- 单用户
- 输出 1,000 个词元
为简化计算,我们使用了单用户模式。在多个并发用户情况下,负载和键值缓存大小将会显著增加。
我们发现,模型可轻松处理包含 1 万个词元(甚至更多)的短上下文,预填充阶段可在 1 秒内完成。但是,当上下文长度达到我们设定的最大值时,预填充时间(生成第一个词元的时间)将超过 2 分钟,随后 LLM 才开始输出内容。
如果我们考虑 10 个并发用户的场景,每个用户的上下文为 25 万个词元,此时预填充时间将超过 30 秒,键值缓存总大小将达到 39GB。
这就是长上下文的弊端:计算长上下文的键值耗时过长,将显著影响用户体验。除非我们能缩短预填充时间,否则长上下文很难适用于交互式用例。
为何要重用键值缓存?
回到前面我使用长上下文的示例——AI 编程助手,我们预计后续查询将大量重用之前的上下文。当编程助手为某个类生成方法时,每次查询都会访问基类。
这种情况下,我们不应在每次查询时都生成键值缓存,而应该只生成一次,然后在后续查询中重用键值缓存。这种方法的问题在于键值缓存会占用大量内存。即便新发布的大语言模型进行了相关优化,键值缓存也会很快耗尽 AI 系统中的所有内存。
利用“卸载”技术解决难题!
NVIDIA Dynamo 库提供了一个键值缓存管理器,可以将键值缓存从 GPU 内存迁移到其他可用设备上。管理器还支持键值重用技术,可以将键值缓存转换为由多个会话和用户共享的键值池。在测试中,我们将高达 100 万词元的键值缓存(约 15GB)从 HBM 迁移到了其他设备上,而键值池的大小将远远大于这一容量。
第一类设备是系统内存。我们测试所用的 DGX 服务器支持高达 4TB 的系统内存,与 GPU 间的聚合带宽达 1TB/s。凭借如此高的带宽,将 100 万词元的键值缓存从 CPU 内存加载到 GPU 内存只需 15 毫秒(理想情况下),而重新计算这些键值则需要 2 分钟以上(如前所述)。
时间的大幅缩短是用户的福音!在首次计算上下文后,随后的上下文计算将从 CPU 内存加载缓存,且速度极快,从而实现了交互式用户体验。
尽管如此,CPU 系统内存仍然面临着与 GPU 内存相同的难题:容量有限。
这便引出了第二类设备:DGX 服务器中的本地 NVMe 驱动器。假设我们使用 8 块 PCIe 5.0 NVMe 驱动器(例如美光 9550 高性能 PCIe 5.0 驱动器),下一层设备支持的键值缓存卸载容量可高达 30 TB 至 245 TB,聚合带宽可达 112 GB/s。
虽然存储层的传输速度显著低于系统内存,但加载 100 万词元的键值缓存仅需 140 毫秒。
利用这些卸载和迁移技术,可以缩短生成第一个词元的时间,从而提升用户体验。此外,采用这些技术后,GPU 可将更多时间用于生成输出,而非重复此前做过的工作,因此还能大幅降低总拥有成本 (TCO)。
高性能存储支持长上下文推理
过去几年里,生成式 AI 领域发生了巨大变化。存储系统曾被视为事后的补救措施;而如今,为 AI 系统配置高性能存储,对于打造拥有良好用户体验的智能 AI 而言至关重要。
在去年的 FMS 峰会和今年春季的 GTC 大会上,美光展示了即将推出的 PCIe 6.0 NVMe 驱动器的非凡性能。这些围绕长上下文和键值缓存管理所取得的技术进展表明,为旗舰级 GPU 搭载速度顶尖的 NVMe 闪存,将是成功部署 AI 的关键。