最佳实践：在 Cloud Run 上使用 GPU 进行 AI 推理

本页面介绍了使用带有 GPU 的 Cloud Run 服务进行 AI 推理时优化性能的最佳实践，重点关注大语言模型 (LLM)。

您需要构建和部署一个 Cloud Run 服务，该服务能够实时响应扩缩事件。这意味着您需要：

• 使用加载速度快且只需进行极少转换即可获得适合 GPU 的结构的模型，并优化其加载方式。
• 使用允许最大、高效、并发执行的配置来减少每秒响应一个目标请求所需的 GPU 数量，同时降低成本。

在 Cloud Run 上加载大型机器学习模型的推荐方法

Google 建议您在容器映像中存储机器学习模型，或者优化从 Cloud Storage 加载模型。

存储和加载机器学习模型的权衡

以下是各个选项的比较：

将模型存储在容器映像中

将机器学习模型存储在部署到 Cloud Run 的容器映像中可受益于 Cloud Run 的内置容器映像流式传输优化，无需额外的网络优化即可最大限度地缩短文件加载时间。

构建包含机器学习模型的容器可能需要一段时间才能完成。如果使用 Cloud Build，您可以将 Cloud Build 配置为使用更大的机器来加快构建速度。为此，请使用 build 配置文件通过以下步骤构建映像：

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'IMAGE', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'IMAGE']
images:
- IMAGE
options:
 machineType: 'E2_HIGHCPU_32'
 diskSizeGb: '500'
 

如果包含模型的层在映像之间有所不同（不同的哈希值），则可以为每个映像创建一个模型副本。如果您的模型层在每个映像上都是唯一的，那么可能会有额外的 Artifact Registry 费用，因为每个映像可能有一个模型副本。

将模型存储在 Cloud Storage 中

如需在从 Cloud Storage 加载机器学习模型时优化机器学习模型加载（无论是使用 Cloud Storage 卷装载还是直接使用 Cloud Storage API 或命令行），您都必须使用出站流量设置值设为 all-traffic 的直接 VPC 以及 Private Service Connect。

从互联网加载模型

如需优化从互联网加载机器学习模型的性能，请通过 VPC 网络路由所有流量，并将出站流量设置值设为 all-traffic，然后设置 Cloud NAT 以高带宽访问公共互联网。

构建、部署、运行时和系统设计注意事项

以下部分介绍了构建、部署、运行时和系统设计的注意事项。

在构建时

以下列表显示了您在规划构建时需要注意的事项：

• 选择合适的基础映像。您应从 Deep Learning Containers 或 NVIDIA 容器注册表中针对您所使用的机器学习框架的映像入手。这些映像安装了最新的性能相关软件包。我们不建议创建自定义映像。
• 选择 4 位量化模型以最大限度地提高并发性，除非您能够证明它们会影响结果质量。量化可生成体积更小、速度更快的模型，从而减少提供模型所需的 GPU 内存量，并可提高运行时的并行性。理想情况下，模型应在目标位深度进行训练，而不是向下量化到该位深度。
• 选择加载速度较快的模型格式（例如 GGUF），以最大限度地缩短容器启动时间。这些格式可以更准确地反映目标量化类型，并且在加载到 GPU 上时需要更少的转换。出于安全考虑，请勿使用 pickle 格式的检查点。
• 在构建时创建和预热 LLM 缓存。构建 Docker 映像时，在构建机器上启动 LLM。启用提示缓存并提供常见或示例提示，以帮助预热缓存以供实际使用。保存它生成的输出，以便在运行时加载。
• 保存您在构建时生成的专属推理模型。与加载效率较低的存储模型以及在容器启动时应用量化等转换相比，这样可以节省大量时间。

部署时

1. 请确保在 Cloud Run 中准确设置服务并发性。
2. 根据您的配置调整启动探测。

启动探测确定容器是否已启动并已准备好接受流量。配置启动探测时，请考虑以下要点：

• 充足的启动时间：为容器（包括模型）留出足够的时间来完全初始化和加载。
• 模型就绪性验证：将探测配置为仅在应用准备好处理请求时通过。大多数服务引擎会在模型加载到 GPU 显存时自动实现这一点，从而防止过早发出请求。

请注意，Ollama 可以在加载模型之前打开 TCP 端口。解决方法：

• 预加载模型：如需了解如何在启动期间预加载模型，请参阅 Ollama 文档。

在运行时

• 主动管理支持的上下文长度。您支持的上下文窗口越小，您可以支持并行运行的查询就越多。具体实现方法取决于框架。
• 使用您在构建时生成的 LLM 缓存。提供您在构建期间生成提示和前缀缓存时使用的相同标志。
• 从您刚刚编写的已保存模型加载。如需了解如何加载模型，请参阅存储和加载模型的权衡。
• 如果您的框架支持量化键值对缓存，请考虑使用。这样可以减少每个查询的内存要求，并允许配置更多并行性。但是，这也会影响质量。
• 调整为模型权重、激活和键值对缓存预留的 GPU 内存量。设置尽可能高的值，但不会发生内存不足的错误。
• 在服务代码中正确配置并发性。确保您的服务代码已配置为与您的 Cloud Run 服务并发性设置配合使用。
• 检查您的框架是否提供了任何用于提升容器启动性能的选项（例如，使用模型加载并行化）。

在系统设计层面

• 在适当的情况下添加语义缓存。在某些情况下，缓存整个查询和响应可能是限制常见查询费用的绝佳方式。
• 控制序言中的方差。提示缓存仅在按顺序包含提示时才有用。缓存实际上进行前缀缓存。在序列中插入或修改意味着它们未缓存或仅部分存在。

自动扩缩和 GPU

Cloud Run 会根据 CPU 利用率和请求并发等因素自动扩缩每个修订版本的实例数。但是，Cloud Run 不会根据 GPU 利用率自动扩缩实例数。

对于具有 GPU 的修订版本，如果修订版本的 CPU 使用率不高，则 Cloud Run 会将请求并发横向扩容。如需针对请求并发实现最佳扩缩，您必须设置每个实例的并发请求数上限最佳值，如下一部分所述。

每个实例的并发请求数上限

每个实例的并发请求数上限设置用于控制 Cloud Run 一次向单个实例发送的请求数上限。您必须调整并发，使其与每个实例中的代码能够以良好性能处理的并发数上限相匹配。

最大并发数和 AI 工作负载

在每个实例的 GPU 上运行 AI 推理工作负载时，代码能够以良好性能处理的最大并发度取决于具体框架和实现细节。以下各项会影响您设置最佳并发请求数上限设置的方式：

• 加载到 GPU 上的模型实例数
• 每个模型的并行查询数
• 使用批处理
• 特定的批处理配置参数
• 非 GPU 工作量

如果并发请求数上限设置得过高，则请求最终可能会在实例内等待访问 GPU，从而导致延迟时间增加。如果将最大并发请求数设置得过低，GPU 可能未得到充分利用，导致 Cloud Run 扩缩的实例数超出必要值。

为 AI 工作负载配置并发请求数上限的经验法则如下：

(Number of model instances * parallel queries per model) + (number of model instances * ideal batch size)

例如，假设某个实例将 3 个模型实例加载到 GPU 上，并且每个模型实例可以处理 4 个并行查询。理想的批量大小也是 4，因为这是每个模型实例可以处理的并行查询数量。根据经验法则，您可以将并发请求数上限 24 设置为：(3 * 4) + (3 * 4)。

请注意，此公式只是一个经验法则。理想的并发请求数上限设置取决于实现的具体细节。为了实现实际最佳性能，我们建议您使用不同的并发请求数上限设置对服务进行负载测试，以评估哪个方案性能最佳。

吞吐量、延迟时间与费用权衡

如需了解并发请求数上限对吞吐量、延迟时间和费用的影响，请参阅吞吐量、延迟时间与费用权衡。请注意，所有使用 GPU 的 Cloud Run 服务始终分配 CPU。