最佳实践：带有 GPU 的 Cloud Run 工作器池

本页面介绍了使用 Cloud Run 工作器池来处理 AI 工作负载（例如使用您偏好的框架训练大语言模型 [LLM]、进行微调以及对 LLM 执行批量或离线推理）时优化性能的最佳实践。如需创建能够实时执行计算密集型任务或批处理的 Cloud Run 工作器池，您应该：
  • 使用加载速度快且只需进行极少的转换即可获得适合 GPU 的结构的模型，并优化这些模型的加载方式。
  • 使用允许最大、高效、并发执行的配置来减少每秒响应一个目标请求所需的 GPU 数量，同时降低成本。

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

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

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

以下是各方案的比较：

模型位置 部署时间 开发体验 容器启动时间 存储费用
容器映像 慢。包含大型模型的映像需要更长的时间才能导入到 Cloud Run 中。 更改容器映像后，需要重新部署；对于大型映像，重新部署的速度可能会很慢。 取决于模型的大小。对于超大型模型，请使用 Cloud Storage 以获得更可预测的性能，但速度会较慢。 Artifact Registry 中可能有多个副本。
Cloud Storage，使用 Cloud Storage FUSE 卷装载加载 快速。在容器启动期间下载的模型。 设置难度不高，无需更改 Docker 映像。 使用网络优化时快速。不会并行下载。 Cloud Storage 中有一份副本。
Cloud Storage，使用 Google Cloud CLI 命令 gcloud storage cp 或 Cloud Storage API 并发下载，如传输管理器并发下载代码示例所示。 快速。在容器启动期间下载的模型。 设置稍微困难，因为您需要在映像上安装 Google Cloud CLI，或者更新代码以使用 Cloud Storage API。 使用网络优化时快速。Google Cloud CLI 会并行下载模型文件，因此速度比 FUSE 装载更快。 Cloud Storage 中有一份副本。
互联网 快速。在容器启动期间下载的模型。 通常更简单（许多框架都会从中央仓库下载模型）。 通常较差且不可预测：
  • 框架可能会在初始化期间应用模型转换。（您应在构建时执行此操作）。
  • 用于下载模型的模型主机和库可能效率不高。
  • 从互联网下载存在可靠性风险。如果下载目标出现故障，您的工作器池可能无法启动，而下载的底层模型可能会改变，从而降低质量。我们建议您在自己的 Cloud Storage 存储桶中托管。
 取决于模型托管服务提供商。

将模型存储在容器映像中

通过将机器学习模型存储在容器映像中，模型加载将受益于 Cloud Run 优化的容器流式传输基础设施。不过，构建包含机器学习模型的容器映像是一个资源密集型过程，尤其是在处理大型模型时。特别是构建过程可能会因网络吞吐量而受限。使用 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 以及专用 Google 访问通道。

从互联网加载模型

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

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

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

构建时

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

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

部署时

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

  • GPU 工作器池无法自动扩缩。即使 GPU 未运行任何进程，您也需要为 GPU 付费。
  • 工作器池的 CPU 和内存价格不同于服务和作业。不过，GPU SKU 的价格与服务和作业相同。

在运行时

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

在系统设计层面

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