使用 Google Kubernetes Engine (GKE) 上的 GPU 自动扩缩大语言模型 (LLM) 推理工作负载的最佳实践


本最佳实践指南向您展示了可用的指标以及如何选择合适的指标来为 GKE 上的推理工作负载设置 Pod 横向自动扩缩器 (HPA)。HPA 是确保模型服务器随负载进行适当扩缩的一种有效方法。微调 HPA 设置是使预配的硬件费用与流量需求保持一致的主要方法,以实现推理服务器性能目标。

如需查看有关如何实现这些最佳实践的示例,请参阅使用 GKE 为 GPU 上的 LLM 工作负载配置自动扩缩

目标

本指南适用于关注使用 GPU 和 Kubernetes 来优化 LLM 工作负载的生成式 AI 客户、新 GKE 用户或现有 GKE 用户、机器学习工程师和 LLMOps (DevOps) 工程师。

阅读本指南后,您应该能够:

  • 了解 LLM 推理的自动扩缩指标。
  • 在考虑要自动扩缩的指标时,请了解整体利弊。

LLM 推断的自动扩缩指标概览

GKE 上提供以下指标:

服务器指标

TGI、vLLM 和 NVIDIA Triton 等热门 LLM 推理服务器会发出特定于工作负载的性能指标。GKE 可以根据这些服务器级指标简化工作负载的爬取和自动扩缩。您可以使用这些指标来深入了解性能指标,例如批次大小、队列大小和解码延迟时间。

根据这些指标,您可以直接针对最相关的性能指标进行自动扩缩。自动扩缩的关键服务器级指标包括:

  • 队列大小:服务器队列中等待处理的请求数。使用队列大小以在一定目标延迟时间阈值范围内最大限度地提高吞吐量并最大限度地降低费用。如需了解详情,请参阅相关的最佳实践部分。
  • 批次大小:正在进行推断的请求数。使用批次大小可达到比队列大小更低的目标延迟时间阈值。如需了解详情,请参阅相关的最佳实践部分。

这些指标通常能够灵活应对性能和流量波动,因此是在各种 GPU 硬件设置中自动扩缩的可靠起点。

GPU 指标

GPU 会发出各种使用情况和性能指标,为任何基于 GPU 的任务提供与工作负载无关的自动扩缩功能,包括推断缺少自定义指标的工作负载。如需了解如何设置 DCGM 收集,请参阅配置 DCGM 收集

GKE 的常见 GPU 指标包括:

GPU 指标 用法 限制
GPU 利用率 (DCGM_FI_DEV_GPU_UTIL) 测量工作周期,即 GPU 处于活跃状态的时间。 不测量 GPU 处于活跃状态时正在执行的工作量。这使得很难将基于推断的性能指标(例如延迟时间和吞吐量)映射到 GPU 利用率阈值。
GPU 内存用量 (DCGM_FI_DEV_FB_USED) 测量给定时间点的 GPU 内存使用量。这对于实现 GPU 内存动态分配的工作负载非常有用。 对于预分配 GPU 内存或永不释放内存的工作负载(例如在 TGI 和 vLLM 上运行的工作负载),此指标仅适用于扩容,不会在流量减少时缩容。

CPU 指标

在 GKE 中,HPA 开箱即用,支持基于 CPU 和内存的自动扩缩。对于在 CPU 上运行的工作负载,CPU 和内存利用率指标通常是主要的自动扩缩指标。

对于在 GPU 上运行的推理工作负载,我们不建议将 CPU 和内存利用率作为衡量作业消耗的资源量的唯一指标,因为推理工作负载主要依赖于 GPU 资源。因此,单独使用 CPU 指标进行自动扩缩可能会导致性能欠佳和费用不合理。

选择自动扩缩指标的注意事项

请考虑以下注意事项和最佳实践,以选择在 GKE 上自动扩缩的最佳指标,以满足推理工作负载性能目标。

最佳实践:使用队列大小在一定的目标延迟时间阈值范围内最大限度地提高吞吐量并最大限度地降低费用

在优化吞吐量和费用时,以及使用模型服务器的最大批次大小的最大吞吐量可以实现延迟时间目标时,我们建议队列大小自动扩缩。

队列大小与请求延迟时间直接相关。传入请求在处理之前会在模型服务器中排入队列,因此此队列时间会增加整体延迟时间。队列大小是负载峰值的敏感指标,因为增加的负载会快速填充队列。

基于队列大小的自动扩缩可在负载下扩容,并在队列为空时缩容,从而最大限度地缩短队列时间。此方法相对容易实现,并且在很大程度上与工作负载无关,因为队列大小与请求大小、模型或硬件无关。

如果要在遵循模型服务器配置的同时最大限度地提高吞吐量,请考虑专注于队列大小。队列大小跟踪待处理,而不是正在处理的请求。vLLM 和 TGI 使用连续批处理,这样可以最大限度地提高并发请求数量,并在批量空间可用时保持队列较低。当批量空间受限时,队列会明显增大,因此请使用增长点作为启动扩容的信号。通过将队列大小自动扩缩与优化的批量吞吐量相结合,您可以最大限度地提高请求吞吐量。

确定 HPA 的最佳队列大小阈值

请注意 HPA 容忍,这默认为目标值周围的 0.1 无操作范围,用于抑制振荡。

如需选择正确的队列大小阈值,请从 3 到 5 之间的值开始,然后逐渐增加,直到请求达到首选延迟时间。使用 locust-load-inference 工具进行测试。对于低于 10 的阈值,请微调 HPA 扩容设置以处理流量峰值。

您还可以创建 Cloud Monitoring 自定义信息中心来直观呈现指标行为。

限制

队列大小不会直接控制并发请求,因此其阈值不保证延迟时间低于批次大小上限。如需解决此问题,您可以手动减小最大批次大小或根据批次大小自动扩缩

最佳实践:使用批次大小可达到比队列大小更低的目标延迟时间阈值

如果您的工作负载对延迟时间敏感,并且基于队列的扩缩不够快,无法满足您的要求,我们建议您选择基于批次大小的自动扩缩。

批次大小与传入请求的吞吐量和延迟时间直接相关。批次大小是负载峰值的良好指标,因为负载增加会导致向现有批次添加更多请求,从而导致批次大小较大。一般来说,批次大小越大,延迟时间就越长。批次大小自动扩缩可确保工作负载扩容以同时并行处理的最大请求数,并在并行处理的请求较少时缩容。

如果队列大小已满足您的延迟时间目标,请优先考虑自动扩缩。这样可以最大限度地提高吞吐量和成本效益。但是,批次大小对于延迟时间敏感型工作负载很有用。较大的批次大小会增加吞吐量,但也会增加延迟时间,因为某些请求的预填充阶段会中断连续批处理模型服务器中其他请求的解码阶段。您可以监控批次大小模式,并使用自动扩缩在负载峰值期间最大限度地减少并发请求。

如果您的模型服务器允许,我们建议您自定义最大批次大小作为额外的调整机制。您还可以将它与基于队列的自动扩缩结合使用。

确定 HPA 的最佳批次大小阈值

请注意 HPA 容忍,这默认为目标值周围的 0.1 无操作范围,用于抑制振荡。

要选择正确的批次大小阈值,请实验性增加服务器上的负载,并观察批次大小达到峰值的位置。我们还建议使用 locust-load-inference 工具进行测试。确定最大批次大小后,将初始目标值设置为略低于此上限,并减小此值,直到达到首选延迟时间。

您还可以创建 Cloud Monitoring 自定义信息中心来直观呈现指标行为。

限制

根据批次大小自动扩缩虽然有助于控制延迟时间,但存在限制。不同的请求大小和硬件限制使找到合适的批次大小阈值变得困难。

最佳实践:优化 HPA 配置

我们建议您设置以下 HPA 配置选项:

  • 稳定期:使用此 HPA 配置选项可防止由于指标波动而导致副本数量快速发生变化。默认值为 5 分钟表示缩容(避免过早缩容),0 表示扩容(确保响应速度)。根据工作负载的波动性和您偏好的响应能力调整该值。
  • 扩缩政策:使用此 HPA 配置选项可微调扩容和缩容行为。您可以设置“Pod”政策限制以指定每个时间单位更改的副本的绝对数量,并设置“百分比”政策限制以指定单位时间的变化百分比。

如需详细了解这些选项,请参阅开源 Kubernetes 文档中的 Pod 横向自动扩缩

后续步骤