评估红帽 OpenShift AI 上的 LLM 推理性能

过去一年中，生成式人工智能（AI）的格局发生了急剧变化。随着生成式大语言模型（LLM）的能力日益增强，越来越多的企业开始考虑利用 LLM 来满足业务需求。由于运行 LLM 对算力要求极高，因此为了有效利用底层硬件（尤其是 GPU）并实现成本效益，将 LLM 部署在高性能且可靠的平台上至关重要。

我们在红帽 OpenShift AI 所附带的模型服务堆栈上部署了 Llama-2 模型并进行了性能测试，本文介绍了其中所用的方法和取得的结果。红帽 OpenShift AI 是一个灵活且可扩展的 MLOps 平台，可用于构建、部署和管理 AI 应用。该平台采用开源技术构建，能提供值得信赖且运维一致的功能，助力团队进行实验、供应模型和交付创新应用。

模型服务堆栈

模型服务软件堆栈基于 KServe、OpenShift Serverless 和 OpenShift 服务网格。为了运行 Llama-2 模型，我们还使用了 Caikit 和文本生成推理服务器（TGIS），但 OpenShift AI 也支持 OpenVINO，并提供以模块化方式使用其他自定义运行时的功能。NVIDIA GPU Operator 用于管理和公开 GPU，供文本生成推理服务器（TGIS）容器使用。

图 1：KServe/Caikit/TGIS 堆栈中组件和用户工作流之间的交互

KServe 利用 OpenShift Serverless 和 OpenShift 服务网格，为 AI 模型推理提供了众多前沿的服务功能。这些组件隐藏了有关网络、服务配置、自动扩展和健康检查等用于生产模型服务的复杂性。

借助 Caikit 工具包，用户可以通过一系列对开发人员友好的 API 来管理模型。Caikit 提供了标准的 gRPC（远程过程调用）和 HTTP 接口，可用于查询各种不同的基础模型。它可将请求转发到推理服务 TGIS。

TGIS 是 Hugging Face 文本生成推理服务工具包的一个早期分支。它提供了多项重要功能来优化服务 LLM 的性能，例如连续批处理、动态批处理、张量并行（模型分片）、PyTorch 2 编译支持等。

NVIDIA GPU Operator 可以自动管理在 OpenShift 中置备和使用 NVIDIA GPU 所需的各种软件组件。其中包括驱动程序容器、设备插件、数据中心 GPU 管理器（DCGM）指标导出器等。借助 DCGM 指标导出器，我们可以使用 OpenShift 监测 Prometheus 实例来分析 GPU 指标，例如内存利用率和流式多处理器（SM）利用率等。

大语言模型的性能测试方法

为了评估大语言模型的性能，我们要关注延迟和吞吐量等经典测量指标。然而，对于针对 LLM 的请求，端到端延迟可能会因多种因素而呈现出显著差异。最重要的方面是输出长度，这取决于 LLM 一次生成一个词元的文本生成方式。因此，我们主要根据每个词元的延迟或“每个输出词元的时间”（TPOT）来衡量延迟。

词元（token）是代表单词或子单词字符串的文本单元。当大语言模型处理文本时，首先会将文本转换为词元。用于将文本对应至词元的确切方案因模型而异。词元采用数字表示形式，排列在馈入到模型中和从模型中输出的向量中。

影响总请求延迟的另一个因素是“预填充”时间，即模型生成第一个新词元之前处理输入提示词词元所需的时间。影响总请求延迟的第三个重要因素是排队时间。如果推理服务因为硬件限制（如 GPU 内存）而无法足够快地处理请求，不能跟上传入的负载，则一些请求需要在队列中等待处理。由于这些因素的影响，“首个词元生成时间”（TTFT）是衡量 LLM 性能的一个常用指标。TTFT 尤其适用于聊天机器人等用例，在这些用例中，词元在生成的同时被流传输并显示出来。

与延迟类似，如果使用每秒请求数来衡量吞吐量，则吞吐量会根据请求中生成的词元数量而有很大差异。因此，我们根据查询模型的所有用户每秒钟所生成词元的总数来衡量总体吞吐量。

利用 llm-load-test 进行负载测试

我们创建了一个名为 llm-load-test 的开源工具，用于加载在 OpenShift AI 模型服务堆栈上运行的测试模型。它是用 Python 编写的，并在内部使用了一个名为 ghz 的 gRPC 负载测试工具。我们对 ghz 进行了分叉，以便添加相应的功能来在测试输出中保存每个请求的响应和工作程序线程 ID。

除了 ghz 中提供的功能外，llm-load-test 还允许我们并行运行多个 ghz 进程，并在每个实例中以随机顺序处理输入数据集。这样，我们就能模拟许多不同的用户在同时使用不同的提示词来查询模型。另外，llm-load-test 也可以在实验后将结果直接上传到 S3 存储桶，并为该运行批次的输出对象添加相应的元数据标签。

输入数据集

您可以使用 JSON 文件，在 llm-load-test 中为负载测试配置输入提示词。我们从 OpenOrca 数据集中选择了一个包含 32 个输入的数据集，其具有不同的输入/输出长度，可使我们运行实验来生成这篇博客文章中分享的结果。在我们的测试数据中，最长的输入是 1688 个词元，而最长的输出则是 377 个词元。图 2 显示了测试数据集中输入/输出长度的分布情况。

图 2：测试数据集的词元长度。

在真实场景中测试 TGIS 的连续批处理和动态批处理功能时，混合使用不同的输入和输出大小非常重要。最近的模型已开始支持 4k+ 超长上下文，这对于诸如检索增强生成（RAG）等用例尤为重要。因此，我们打算增加负载测试数据集的大小，以便将来包含更大的输入长度。

AWS 上 OpenShift AI 的 llama-2 性能结果

以下性能测量结果是使用 AWS 上所安装的自助式安装程序置备基础架构（IPI）OpenShift 集群收集的。我们安装了 OpenShift AI Operator，还创建了 ServingRuntime 和 InferenceService 对象，以便能够通过 Kserve、Caikit 和 TGIS 为模型提供服务。

下方的表 1 总结了对模型和 AWS 实例类型的四种组合进行测试的结果：

表 1：测试配置的摘要。

在每个配置中，我们使用 llm-load-test 和不同数量的并发线程（下图中的并发参数），运行了几次为时四分钟的负载测试。在每次测试中，每个并发线程持续在收到上一请求的应答后立即发送一个请求。

下方的图 3 是一个实验的可视化示例，其图表显示了测试期间内每个请求的总延迟。每个圆点的颜色代表词元长度，因此您可以直观地看到词元长度与总体请求输出的相关程度。

图 3：负载测试期间所有请求的总延迟。

我们解析了 TGIS 日志，以获取每个请求的总延迟，并通过将负载测试期间所生成的词元总数除以测试持续时间（240 秒）来计算吞吐量。

图 4 显示了在使用多种负载测试并发设置对 g5.2xlarge 实例上的 llama-2-7b 进行负载测试时所测得的延迟和吞吐量。从中可以看到，吞吐量随着负载测试并发数的增多而增大，一直到约 20 个线程为止。由于 g5.2xlarge 实例的 GPU 内存限制，TGIS 无法在一个批次中一次放入超过约 20 个请求（取决于请求的输入/输出长度）。

图 4：g5.2xlarge 上 Llama-2-7b 的延迟和吞吐量摘要。

图 5 中的图表显示了在 g5.12xlarge 实例上对 llama-2-13B 进行负载测试时所测得的延迟和吞吐量。从中可以看到，每个词元的最短延迟起初低于在 g5.2xlarge 上运行的 7B 模型；同时，尽管模型规模更大且实例采用相同类型的 GPU，其吞吐量仍能良好地扩展到至少 30 个并发请求。这是因为，使用张量并行将模型分散到 4 个 GPU 上具有显著的性能优势。

图 5：g5.12xlarge 上 Llama-2-13b 的延迟和吞吐量摘要。

图 6 显示了在 g5.48xlarge 实例上对 llama-2-70b 进行负载测试时所测得的延迟和吞吐量。从中可以看到，每个词元的延迟全面高于之前的配置。诸如 llama-2-70B 等模型具有很高的硬件要求。8 个 A10G GPU 总共有 192GB 的 VRAM，其中大部分 VRAM 仅用于将 70B 参数以 16 位精度加载到内存中（70 B*16 位 = ~140 GB）。根据性能要求，可能需要更多的算力，例如 p4d.24xlarge 实例。

图 6：g5.48xlarge 上 Llama-2-70b 的延迟和吞吐量摘要。

图 7 显示了在 p4d.24xlarge 实例上对 llama-2-70b 进行负载测试时所测得的延迟和吞吐量。与 g5.48xlarge 实例相比，在这个实例中，可以为相同数量的用户保持低得多的延迟。即使并发数达到 30，吞吐量也会随着负载测试并发数的增加而继续扩大。

图 7：p4d.24xlarge 上 Llama-2-70b 的延迟和吞吐量摘要。

成本计算

我们可以利用测得的吞吐量和实例类型成本来估算生成一百万个词元的成本。下表总结了这些估算值，其中使用了我们在负载并发数为 10 的情况下收集到的结果所测得的吞吐量。

表 2：每种配置的结果摘要，成本以每百万个词元为单位计算。

今后的工作

以上结果只是我们在红帽 AI 平台性能和规模（PSAP）团队中所进行的测试的一小部分缩影。除了对 OpenShift AI 的其他方面展开性能测试外，我们也在积极地继续对模型服务堆栈进行性能和可扩展性分析。我们希望在未来进行更多分享，包括对其他模型进行测试的结果，以及根据流量自动扩展模型副本数的测试结果等。

我们将继续推进 llm-load-test 的开发，并有望在不久的将来为其添加一些功能，例如：

• 用于测量流传输请求的 time-to-first-token 和 time-per-output-token 的功能。
• 用于查询不同 API 背后的模型的可插拔/模块化接口，包括 HTTP 和 gRPC 接口。
• 用于验证模型是否已加载并且正常响应的预热阶段和功能。
• 更为复杂的负载模式，如随机泊松到达率。

结论

我们对 OpenShift AI 上运行的 Llama-2 模型进行了性能测试，大致了解了在多种配置中运行 LLM 所涉及的延迟、吞吐量和成本权衡。例如，对于 7B 模型来说，g5.2xlarge 实例最具成本效益，但由于张量并行可带来显著的延迟和吞吐量提升，在某些用例中升级到 g5.12xlarge 实例可能会更加有益。运行更大的模型应该会产生质量更高的输出，但需要更多的 GPU 内存，而这会带来更高的成本。

OpenShift AI 提供了一个性能高、适应性强的模型服务解决方案，可帮助企业有效应对生成式大语言模型的部署复杂性。无论您要优先考虑的是模型质量、延迟、吞吐量还是成本，该平台都能灵活满足您多种多样的要求。如需针对您的特定用例探索这些优势，请尝试在 OpenShift AI 上部署您选择的模型。