当你想到处理 AI 任务的输入和输出时，图形处理器（GPU（图形处理器））可能是首先浮现在脑海中的主要基础设施组件。但它们只是拼图中的一块。如果没有合适的网络和存储基础设施，即使配备最先进的 GPU，当今的 AI 应用也会运行缓慢且成本高昂到令人望而却步。多年来，这对 AI 训练而言一直如此，而如今对 AI 推理同样如此。

基于大语言模型（LLM（大语言模型））的推理是现代 AI 应用的主要工作负载，它对所有三种基础设施资源（计算、网络和存储）造成了巨大压力，以至于全新的软件能力正在涌现，以支持推理的资源管理和优化。值得注意的例子包括 llm-d、vLLM 和 Dynamo。如果不对预计算的推理产物进行高效管理和复用，你既会让 GPU 因冗余的重复计算而不堪重负，又要等待很长时间才能让 LLM 响应每次查询。

为什么 LLM 推理如此消耗资源？

大多数现代 LLM 基于具有自注意力机制的 Transformer（深度学习中的注意力模型架构） 架构。在推理处理过程中，该架构以大型键（K）和值（V）张量的形式生成大量中间运行时数据。对于每一组有序的输入 token，LLM 会生成多个 K 和 V 张量，并在 GPU 内存中将其作为缓存保存，只要有空间就会一直保留。这些张量随后被模型用于生成下一个输出 token。在 K 和 V 值可以复用的范围内，它们无需重新计算，从而节省大量时间并加速 token 的生成。然而，随着新的输入（或请求）开始涌入，GPU 内存会被填满，旧值需要被丢弃以便为新值腾出空间，这意味着复用先前计算的 KV 数据的能力受限于 LLM 推理服务能够方便保留的数据量。

为了直观感受这些数据可能变得多么庞大，我们的实验表明，对于流行的 Llama3-70B 模型，128K 输入 token（一种常见的上下文窗口大小）的 KV 缓存大小约为 40GB，在使用四块 NVIDIA H100 GPU 时，首 token 延迟（TTFT）约为 19 秒。如果你仅限于将这些数据存储在 GPU 内存中，很快就会耗尽空间。解决这一问题正是 llm-d 和 Dynamo 等新项目的部分动机，这些项目最初专注于——除其他事项外——通过 CPU RAM 为 GPU 内存增加新的容量层级，并将其与 KV 缓存感知路由相结合。当然，即使使用 CPU RAM，面对上述数据速率和规模也会很快被填满。此外，当涉及跨推理服务器集群的全局优化时，持久化数据以及跨推理实例共享 KV 值的能力变得越来越有价值。这就是为什么我们相信正确的解决方案涉及一个高性能存储层级（高带宽和低延迟，并增强缓存和局部性感知），它可以为 KV 缓存复用提供几乎无限的容量，同时为 AI 推理提供更低的首次 token 延迟、高可用性以及这一重要数据类型的持久化。

由 IBM Storage Scale 驱动的 AI 推理加速

IBM Storage Scale 的设计使其非常适合为 KV 数据提供持久化空间（从几 TB 到数百 PB），为几乎无限数量的活跃用户和智能体会话存储数据。在 AI 推理解决方案中添加 Scale 层级可实现数百甚至数千台 GPU 服务器之间的 KV 缓存共享。在一台 GPU 上生成的 KV 缓存可以被整个集群中的任何其他 GPU 立即使用，从而减少整体冗余计算。IBM Storage Scale 还能提供可预测的低延迟和高吞吐量，这是许多推理用例提供交互式用户体验所必需的。最后，分层、配额管理、故障处理、扩展和访问控制等企业级功能可随时用于这种新型数据。其中许多能力最初是为了处理典型 HPC 部署极其严苛的性能要求而开发的。得益于与 vLLM 和 llm-d 等框架的软件集成，用户可以在生产环境中开箱即用地获得这些优势，实现大规模下最先进的 AI 推理成本和性能。

图 1 展示了使用 IBM Storage Scale 和 llm-d 的参考推理部署。在内部，llm-d 利用推理引擎 vLLM，后者在每台 GPU 服务器上独立运行以执行推理计算。为了将 KV 张量作为文件存储在文件系统中，llm-d/vLLM 使用具有内置文件系统连接器的缓存管理组件，如 LMCache。更具体地说，LMCache 需要基本的文件系统接口，以及可选的跨集群分布式文件共享，而 IBM Storage Scale 开箱即用地支持这些。因此，要利用 IBM Storage Scale，管理员只需在 GPU 服务器上挂载 Storage Scale 文件系统，并将文件系统连接器指向它即可。

结果

为了展示 IBM Storage Scale 作为 AI 推理加速器的强大能力，我们使用 Llama3-70B 进行了一项实验，由 vLLM 提供服务，运行在四块 H100 GPU 上，将 KV 缓存卸载到 CPU DRAM 或 IBM Storage Scale。结果如图 2 所示。实验证实了一些直觉判断，例如，存储和复用 KV 数据最快的方式（除了将其保留在有限的 GPU 内存中）是将其缓存到同一节点内的 CPU DRAM 中。对于 128k 上下文的输入大小，缓存到 DRAM（相对于重新计算）的加速比为 23.6 倍。

接下来是令人兴奋的部分：当你将 IBM Storage Scale 添加为 KV 缓存层级时，你将获得上述所有好处，包括跨整个 vLLM 推理实例集群的分布式共享，以及相对于重新计算 8-12 倍的首 token 延迟加速，绝对性能接近 CPU RAM 缓存（1.6 秒 vs 0.8 秒）。加速比的具体值取决于文件系统中 KV 数据的新近程度（或“热度”）。添加这一存储层级意味着你可以在大规模下满足严格的延迟预期（TTFT 为 2 秒或更少，而非 19 秒），并将 GPU 用于更高价值的操作，如 token 生成，而非 KV 缓存预填充。也许更重要的是，该解决方案与熟悉的推理服务（如此处的 llm-d）原生集成，这意味着我们在提供服务运营商最小化软件复杂度的同时实现了这些收益。

下一步

通过 KVCache 卸载进行 AI 推理为存储系统引入了一系列新需求，既需要高带宽，又需要低延迟访问，这在大多数存储解决方案中很难同时实现。IBM Storage Scale 独特地结合了性能（每个构建块 300 GB/s、1300 万 IOPS，亚微秒级延迟）、可扩展性（10 万+ 节点）、多功能性（加速 AI 训练和推理、HPC、分析和数据库）以及企业级就绪能力，提供了难以匹敌的价值主张。我们才刚刚开始触及高性能存储如何加速分布式推理的表面。我们看到了通过将这项工作与内容感知存储等解决方案相结合来交付更大价值的机会，将企业数据洞察时间从数小时和数天缩短到数秒。请继续关注这一点，因为还有更多内容即将到来！

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：IBM Research Blog

原创地址：https://research.ibm.com/blog/accelerating-ai-inference-with-ibm-storage-scale