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 的关键。
