本文档简要介绍了在 GKE 上运行推理工作负载的最佳实践。
本文档适用于希望将 GPU 和 TPU 等加速器与 Kubernetes 和 GKE 搭配使用来采用最佳实践以处理推理工作负载的数据管理员、运维人员和开发者。如需详细了解常见角色，请参阅常见的 GKE Enterprise 用户角色和任务。
准备在 GKE 上提供推理服务
本部分介绍了在准备部署推理工作负载时应遵循的基础最佳实践。这些实践包括分析使用场景、选择模型和选择加速器。
分析推理使用场景的特征
在部署推理工作负载之前，分析特定要求。此分析有助于您做出在性能、费用和可靠性之间取得平衡的架构决策。了解您的使用场景有助于您选择合适的模型、加速器和配置，以实现服务等级目标 (SLO)。
为了指导您的分析，请评估工作负载的以下关键维度：
- 定义性能和延迟要求：确定应用的延迟和吞吐量的 SLO。要定义的关键指标包括每秒请求数 (RPS)、响应延迟时间、输入和输出 token 长度以及前缀缓存命中率。 如需了解详情，请参阅推理性能指标。
- 评估模型要求和规模：所选模型的特征直接影响您的基础设施需求。考虑模型支持的上下文长度上限，并将其与工作负载所需的上下文长度进行比较。如果您的使用场景不需要上下文长度上限，降低上下文长度上限可以释放加速器内存，以获得更大的 KV 缓存，从而可能提高吞吐量。
- 确定费用和业务限制：预算和业务目标是设计可持续且经济高效的推理服务的关键因素。为输入和输出定义目标每百万个 token 费用，并为此工作负载定义每月总预算。确定您的优化目标，例如性价比、最低延迟时间或最高吞吐量，以及您的应用是否可以容忍可变延迟。
为推理使用场景选择合适的模型
选择合适的模型会直接影响推理应用的性能、费用和可行性。如需选择最佳模型，请根据以下条件评估候选模型：
- 任务和模态对齐：根据模型指定的任务和支持的模态评估模型。针对特定任务优化的模型几乎总是比更通用的模型表现更好。
- 技术特征：模型的架构和数据类型精度（例如 FP16、FP8 和 FP4）是决定其资源需求和性能的关键因素。此评估有助于您确定是否需要应用量化技术。检查模型权重的支持精度，确保框架支持，并验证模型支持的上下文长度上限。
- 性能和成本效益：如需做出数据驱动型决策，请使用公开提供的基准测试和您自己的内部测试来比较入围模型。使用 Chatbot Arena 等排行榜比较模型，并评估每个模型在目标硬件上的每百万个 token 费用。
对模型应用量化
量化是一种通过减少模型内存占用量来优化推理工作负载的技术。它将模型的权重、激活和键值 (KV) 缓存从高精度浮点格式（例如 FP16、FP32 和 FP64）转换为低精度格式（例如 FP8 和 FP4）。这种内存减少可以显著提高性能和成本效益。
量化可减少模型的内存占用空间，从而减少数据传输开销，并释放内存以用于更大的 KV 缓存。
如需有效地将量化应用于模型，请遵循以下建议：
- 评估准确率权衡：量化有时会导致模型准确率降低。在评估量化的准确性权衡时，考虑 8 位量化通常只会导致极小的准确性损失。相比之下，4 位量化最多可将加速器内存要求降低四倍，但与 8 位量化相比，它也可能会导致更大的准确性损失。评估量化模型在特定使用场景中的性能，以确保准确率仍处于可接受的范围内。如需评估准确率损失，您可以使用 OpenCompass 和 Language Model Evaluation Harness 等工具。
- 评估硬件加速支持：为了充分利用量化，请使用可为量化模型所使用的数据格式提供硬件加速的加速器。例如：
- NVIDIA H100 GPU 为 FP8 和 FP16 操作提供硬件加速。
- NVIDIA B200 GPU 为 FP4、FP8 和 FP16 操作提供硬件加速。
- Cloud TPU v5p 为 FP8 操作提供硬件加速。
- 检查是否存在预量化模型：在自行量化模型之前，检查 Hugging Face 等公共模型库。理想情况下，应找到以较低精度进行原生训练的模型，因为这样可以带来性能优势，而不会因训练后量化而可能损失准确率。
- 使用量化库：如果没有预量化模型，请使用库自行执行量化。vLLM 等推理服务器支持运行已通过各种技术进行量化的模型。您可以使用 llm-compressor 等工具将量化技术应用于未量化的模型。
- 考虑 KV 缓存量化：除了量化模型权重之外，您还可以量化 KV 缓存。此技术可进一步减少运行时 KV 缓存所需的内存，从而可以提高性能。
如需了解详情，请参阅在 GPU 上优化 LLM 推理工作负载。
选择合适的加速器
选择合适的加速器会直接影响推理服务的性能、费用和用户体验。最佳选择取决于对模型内存要求、性能目标和预算的分析。
如需为您的特定使用场景选择合适的加速器，请按照以下步骤操作：
计算内存需求：首先，计算加载和运行模型所需的加速器内存下限。总内存是模型权重所需的内存、推理引擎开销、中间激活和 KV 缓存的总和。
如需估算所需内存，请使用以下等式：
\[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]
等式中的各项如下：
- 模型权重：模型参数的大小。
- 开销：推理服务器和其他系统开销的缓冲区，通常为 1-2 GB。
- 激活：模型执行期间中间激活所需的内存。
- 每个批次的 KV 缓存：单个序列的 KV 缓存所需的内存，该内存会随上下文长度和模型配置而扩缩。
- 批次大小：推理引擎将并发处理的序列 (
max_num_sequences) 数量。
示例：计算 Gemma 3 的加速器内存要求
如需计算部署一个具有 270 亿参数的 Gemma 3 模型（精度为 BF16）以用于文本生成使用场景所需的加速器内存，您可以使用以下值。
如需查看此计算的互动式演示，请参阅我的模型需要多少 VRAM？Colab 笔记本
- 输入：
- 模型权重：54 GB
- 批次大小 (
max_num_sequences)：1 - 平均输入长度：1,500 个 token
- 平均输出长度：200 个 token
- 推理引擎开销：1 GB（估算值）
- KV 缓存数据类型大小：2（对于 BF16）
- KV 向量：2 个（一个用于键，一个用于值）
- Gemma 3 27B 指令调优模型的模型配置：
hidden_size：5,376intermediate_size：21,504num_attention_heads：32num_hidden_layers：62num_key_value_heads：16
- 内存计算：
sequence_length=avg_input_length+avg_output_length= 1,500 + 200 = 1,700 个 tokenpytorch_activation_peak_memory= (max_num_sequences*sequence_length* (18 *hidden_size+ 4 *intermediate_size)) / (1000^3) = ~0.31 GB（估算值）。head_dims=hidden_size/num_attention_heads= 5376 / 32 = 168kv_cache_memory_per_batch= (kv_vectors*max_num_sequences*sequence_length*num_key_value_heads*head_dims*num_hidden_layers*kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1.13 GB- 所需的加速器内存 =
Model weights+Overhead+Activations+KV cache per batch= 54 + 1 + 0.31 + 1.13 = ~56.44 GB
部署模型所需的加速器内存总量估计约为 57 GB。
评估加速器选项：估算内存要求后，评估 GKE 上可用的 GPU 和 TPU 选项。
除了加速器内存量之外，在评估时还要考虑以下模型要求：
- 对于需要多个加速器的模型，请检查是否支持高速连接（例如 NVLINK 和 GPUDirect），以减少通信延迟时间。
- 对于量化模型，请使用可为低精度数据类型（例如 FP8 和 FP4）提供原生硬件加速的加速器，以获得最佳性能优势。
您的选择需要在这些功能、性能、费用和可用性之间进行权衡。
按使用场景推荐的加速器
提示：如需根据服务性能基准测试和费用分析获取最新的加速器建议，您还可以使用 GKE 推理快速入门工具。如需了解详情，请参阅 GKE 推理快速入门文档。 为了帮助您为工作负载选择合适的加速器，下表总结了常见推理使用场景中最合适的选项。这些使用场景的定义如下：
- 小型模型推理：适用于参数不超过数十亿的模型，计算负载限制在单个主机上。
- 单主机大型模型推理：适用于参数数量在数百亿到数千亿之间的模型，其中计算负载在单个宿主机上的多个加速器之间共享。
- 多主机大型模型推理：适用于参数数量从数千亿到数万亿的模型，其中计算负载在多台宿主机上的多个加速器之间共享。
使用场景 推荐的加速器 机器系列 主要特征 小型模型推理 NVIDIA L4 G2 经济实惠的小型模型选项（每个 GPU 24 GB 内存）。 NVIDIA RTX Pro 6000 G4 对于参数少于 300 亿的模型和图片生成任务，性价比高（每个 GPU 96 GB 内存）。支持直接 GPU 点对点通信，因此非常适合单主机多 GPU 推理。 TPU v5e - 针对成本效益进行了优化。 TPU v6e - 为 Transformer 模型和文生图模型提供最高价值。 单主机大型模型推理 NVIDIA A100 A2 适用于可容纳在单个节点（总内存高达 640 GB）上的大多数模型。 NVIDIA H100 A3 非常适合可在单一节点上运行的推理工作负载（总内存高达 640 GB）。 NVIDIA B200 A4 面向可装载在单个节点上的高要求模型的未来保障型选项（总内存高达 1,440 GB）。 TPU v4 - 在费用与性能之间取得良好平衡。 TPU v5p - 一种高性能选项，可满足要求苛刻的工作负载。 多主机大型模型推理 NVIDIA H200 A3 Ultra 适合大型内存密集型模型（总内存高达 1,128 GB）。 NVIDIA B200 / GB200 A4 / A4X 适用于要求最严苛、计算密集型和受网络限制的工作负载。A4X 机器使用基于 Arm 的 CPU，如果工作负载使用特定于 x86 的功能或优化，则可能需要重构工作负载（除了简单的容器重建之外的代码更改）。 TPU v5e - 针对大中型 LLM 服务在成本效益和性能方面进行了优化。 TPU v5p - 一种高性能选项，适用于需要大规模并行化的多主机推理。 TPU v6e - 针对 Transformer、文生图和 CNN 服务进行了优化。 示例：为 260 GB 模型选择加速器
假设您需要部署一个模型，该模型需要 260 GB 的加速器总内存（200 GB 用于模型，50 GB 用于 KV 缓存，10 GB 用于开销）。
仅从内存需求来看，您可以排除 NVIDIA L4 GPU，因为最大的 G2 机器最多提供 192 GB 的加速器内存。此外，由于 L4 GPU 不支持加速器之间的高速低延迟连接，因此将工作负载分配到多个节点上并不是实现所需性能的可行方案。
如果您想避免重构 x86-64 工作负载（即不必修改代码即可在其他类型的处理器上运行），则还需要排除使用基于 Arm 的 CPU 的 NVIDIA GB200 和 GB300 加速器。
这样，您将有以下选项：
- NVIDIA A100
- NVIDIA RTX Pro 6000
- NVIDIA H100
- NVIDIA H200
- NVIDIA B200
所有这些加速器都有足够的内存。接下来，您需要评估这些功能在目标区域中的可用性。假设您发现某个特定区域中仅提供 NVIDIA A100 和 NVIDIA H100 GPU。在比较这两种方案的性价比后，您可能会选择 NVIDIA H100 来处理工作负载。
选择推理分布策略：如果模型过大而无法在单个加速器上运行，请根据工作负载的要求选择分布策略。
首先，根据硬件拓扑选择分布策略：
- 单个加速器：如果您的模型适合单个加速器，这是最简单且推荐的方法。
- 单节点、多加速器：如果您的模型适合使用具有多个加速器的单个节点，您可以使用张量并行处理将模型分布到该节点上的加速器中。
- 多节点、多加速器：如果模型太大而无法放在单个节点上，您可以结合使用张量并行处理和流水线并行处理，将其分布到多个节点上。
如需实现这些策略，您可以使用以下并行处理技术：
张量并行处理：此技术可将模型层分片到多个加速器上。在具有 NVLINK 或直接点对点 PCIe 等高速互连的单个节点中，它的效果非常好，但需要加速器之间进行大量通信。
示例：张量并行处理
例如，假设您需要部署一个具有 1,090 亿参数的模型。在默认 BF16（16 位）精度下，将模型的权重加载到加速器内存大约需要 113 GB。单个 NVIDIA H100 GPU 提供 80 GB 内存。因此，即使不考虑其他内存要求（例如 KV 缓存），您也需要至少两个 NVIDIA H100 GPU 才能加载模型，并使用 2 的张量并行处理大小。
流水线并行处理：此技术可将模型层按顺序分区到多个节点。它非常适合在多主机部署中将模型分布到多个节点，并且与张量并行处理相比，模型等级之间的通信更少。
示例：混合并行处理（张量和流水线）
对于参数超过 6,000 亿的超大型模型，内存需求可能会超过 1.1 TB。在包含两个
a3-megagpu-8g节点（每个节点有 8 个 NVIDIA H100 GPU）的场景中，集群的总加速器内存为 1.28 TB。如需运行该模型，您可以实现一种混合策略：在每个节点内使用 8 向张量并行处理，在两个节点之间使用 2 向流水线并行处理。模型将分为两个阶段，前一半层位于第一个节点上，后一半层位于第二个节点上。当请求到达时，第一个节点会处理该请求，并通过网络将中间数据发送到第二个节点，由第二个节点完成计算。
如需详细了解如何为单模型副本选择分布式推理策略，请参阅 vLLM 文档中的并行处理和扩缩。
选择加速器优化机器类型：根据您选择的加速器和所需的数量，选择提供这些资源的机器类型。每种机器类型都提供 vCPU、系统内存和网络带宽的特定组合，这些因素也会影响工作负载的性能。例如，如果您需要 16 个 NVIDIA H100 GPU，则应选择
a3-megagpu-16g机器类型。运行您自己的基准测试：推理工作负载的性能高度依赖于您的特定使用场景。运行您自己的基准测试来验证您的选择并微调配置。
优化推理服务器的配置
如需在部署推理工作负载时实现最佳性能，我们建议您进行基准测试和调优的循环：
- 首先，请参阅 GKE 推理快速入门，获取针对您的使用场景优化的基准 Kubernetes 配置。
- 运行基准测试以捕获基准吞吐量和延迟时间指标。
- 调整推理服务器的配置。
- 再次运行基准测试，并比较结果以验证您的更改。
以下建议基于 vLLM 推理服务器，但这些原则也适用于其他服务器。如需详细了解所有可用设置，请参阅 vLLM 优化和调优文档：
- 配置并行处理：
- 张量并行处理 (
tensor_parallel_size)：将此值设置为单个节点上的加速器数量，以对工作负载进行分片。例如，设置tensor_parallel_size=4会将工作负载分布到 4 个加速器上。请注意，增加此值可能会导致过多的同步开销。 - 流水线并行处理 (
pipeline_parallel_size)：将其设置为您要将模型分布到的节点数。例如，如果您要跨 2 个节点进行部署，每个节点有 8 个加速器，则应设置tensor_parallel_size=8和pipeline_parallel_size=2。增加此值可能会导致延迟时间增加。
- 张量并行处理 (
- 调整 KV 缓存 (
gpu_memory_utilization)：此参数用于控制为模型权重、激活和 KV 缓存预留的 GPU 内存百分比。值越大，KV 缓存大小越大，吞吐量也越高。我们建议您将此值设置为介于0.9和0.95之间的值。如果您遇到内存不足 (OOM) 错误，请降低此值。 - 配置上下文长度上限 (
max_model_len)：为了减小 KV 缓存大小和内存要求，您可以设置比模型默认值更低的上下文长度上限。这样一来，您就可以使用更小、更经济实惠的 GPU。 例如，如果您的使用场景仅需要 4 万个 token 的上下文，但模型的默认值为 25.6 万，则将max_model_len设置为 4 万个将释放内存以用于更大的 KV 缓存，从而可能提高吞吐量。 - 配置并发请求数（
max_num_batched_tokens、max_num_seqs）：调整 vLLM 并发处理的请求数上限，以避免在 KV 缓存空间不足时发生抢占。较低的max_num_batched_tokens和max_num_seqs值可减少内存需求，而较高的值可能会提高吞吐量，但有出现 OOM 错误的风险。为了找到最佳值，我们建议运行性能实验，并观察 vLLM 导出的 Prometheus 指标中的抢占请求数。
如需了解详情，请参阅以下资源：
- 如需深入了解如何调整这些参数，请参阅 vLLM 性能调优：xPU 推理配置终极指南。
- 如需详细了解模型内存优化，请参阅使用 GKE 上的 GPU 优化大语言模型推理的最佳实践。
- 如需查看可部署的完整示例，请参阅 GKE 推理参考实现。
针对延迟和可用性进行优化
为确保推理服务既能快速响应又可靠，您必须优化以降低启动延迟并提高资源可用性。
优化推理工作负载冷启动延迟
最大限度地缩短推理工作负载的启动时间对于提高成本效益和改善用户体验至关重要。低冷启动延迟可让集群快速扩容以满足需求，确保服务响应迅速，同时最大限度地减少昂贵的过度预配需求。
优化 Pod 启动时间
Pod 准备就绪所需的时间在很大程度上取决于拉取容器映像和下载模型权重所需的时间。如需同时优化这两者，请考虑以下策略：
使用优化的数据加载器加快模型加载速度：您用于存储和加载模型权重的方法对启动时间有重大影响。对于 vLLM 0.10.2 版及更高版本，建议的方法是使用 Run:ai Model Streamer 通过直接从 Cloud Cloud Storage 存储桶中流式传输模型来加载模型。
如果流式传输器不适合您的使用场景，您可以使用 Cloud Storage FUSE 装载 Cloud Storage 存储桶，并通过启用分层命名空间及使用并行下载和预取等技术来调整其性能。如需详细了解这些技术，请参阅优化适用于 GKE 的 Cloud Storage FUSE CSI 驱动程序的性能。无论哪种情况，我们都建议您使用 Anywhere Cache 为存储桶创建高性能的可用区级读取缓存，并启用统一存储桶级访问权限，以统一控制对存储桶的访问权限。
如果您已使用 Managed Lustre 为训练工作负载提供高性能文件存储，也可以使用它来加载模型权重以进行推理。如果数据局部性和 POSIX 兼容性至关重要，此方法可提供低延迟访问。
启用映像流式传输：为了缩短拉取容器映像所需的时间，请在 GKE 集群上启用映像流式传输。借助映像流式传输，容器可以在整个映像下载之前启动，从而大幅缩短 Pod 启动时间。
启用快速启动节点
对于需要快速扩缩的工作负载，您可以利用 GKE 中的快速启动节点。快速启动节点是预初始化的硬件资源，其启动时间比标准节点短得多。如果您的集群满足要求，GKE 会自动启用快速启动节点。
规划容量并最大限度提高加速器的可获取性
GPU 和 TPU 等高需求加速器的可用性可能有限，因此主动制定容量规划策略至关重要。
规划和预留容量
高需求加速器的可用性可能有限，因此制定积极主动的容量规划策略至关重要。为确保您能访问所需的资源，请遵循以下建议：
确定容量基准和高峰处理能力：规划需要预留的基准加速器容量。要预留的容量取决于您的使用场景。例如，您可以为对延迟零容忍的关键工作负载预留 100% 的所需容量，也可以预留某个百分位（例如第 90 或第 95 百分位），并按需获取剩余容量来处理高峰。
预留基准容量：如需获取高保障的资源，请创建预留。 您可以根据自己的需求选择预留类型。例如，如需在特定的未来时间范围内预留加速器等需求量大的资源，您可以在日历模式下创建未来预留。
为高峰时期编排容量：对于超出基准预留的需求，您可以使用按需容量、Spot 虚拟机或动态工作负载调度器 (DWS) 等其他容量类型，来实施后备策略。您可以使用自定义计算类来定义预配不同容量类型的优先级顺序，从而自动执行此后备策略。
享受折扣价格：对于基准容量，购买承诺使用折扣 (CUD)，以换取一年或三年期承诺，从而享受大幅折扣价格。
如果您的工作负载可以容忍获取容量方面的延迟，请将动态工作负载调度器与灵活启动预配模式搭配使用
对于可以容忍在获取容量方面存在一些延迟的工作负载，采用灵活启动预配模式的动态工作负载调度器 (DWS) 是一种以折扣价获取加速器的选项。 借助 DWS，您可以将容量请求排队最多七天。
将 DWS 与灵活启动预配模式搭配使用时，我们建议您执行以下操作：
- 将其纳入自定义计算类：使用自定义计算类将 DWS 定义为获取容量的优先级后备策略的一部分。
- 设置运行时长上限：
maxRunDurationSeconds参数用于设置通过 DWS 请求的节点的运行时长上限。将此值设置为低于默认值 7 天的值，可以提高获取所请求节点的几率。 - 启用节点回收：为防止工作负载出现停机情况，请启用节点回收。此功能会在旧节点过期之前开始预配新节点，从而确保过渡更加顺畅。
- 最大限度地减少中断：为最大限度地减少因节点逐出和升级而造成的中断，请配置维护窗口和排除项、停用节点自动修复，并充分利用短期升级策略。
使用自定义计算类
自定义计算类 (CCC) 是一项 GKE 功能，可让您为工作负载定义基础设施配置的优先级列表。CCC 提供旨在提高加速器可获取性的关键功能：
- 后备计算优先级：您可以定义配置的优先级列表。如果在扩容事件期间首选选项不可用，自动扩缩器会自动回退到列表中的下一个选项，从而显著提高成功获取容量的可能性。
- 主动迁移到优先级更高的节点：配置此功能后，GKE 会在优先级更高的配置可用时，自动将以优先级较低的配置运行的节点替换为优先级更高的配置中的节点。这有助于确保您的 Pod 最终在最优先（通常也是最具成本效益）的节点上运行。
借助自定义计算类 (CCC)，您可以创建用于获取节点的后备策略。此策略使用不同容量类型（例如按需虚拟机、Spot 虚拟机或预留）的优先列表。其中每种容量类型的可用性级别各不相同：
- 预留：为获取容量提供最高级别的保障。使用具有 CCC 的预留时，请考虑其限制。例如，某些预留类型会限制您可以预留的机器类型或可以请求的机器数量上限。
- 按需：标准预配模型，可提供灵活性，但可能会受到需求量较高的资源的区域级容量限制。
- Spot 虚拟机：使用备用容量可以降低成本，但可能会被抢占。发生抢占事件时，GKE 会尽力为受影响的 Pod 提供最长 30 秒的正常终止时长。为了充分利用此功能，请通过实现检查点和重试机制，使工作负载能够容忍抢占事件。
- 动态工作负载调度器 (DWS)：可让您以折扣价将稀缺资源请求加入队列。此功能非常适合可容忍容量获取延迟的工作负载。
优先级列表的顺序应根据您的主要目标是最大限度地缩短延迟时间还是优化成本而变化。例如，您可以根据不同的工作负载要求配置以下优先级列表：
| 优先级 | 低延迟工作负载 | 费用优化型（容忍延迟）工作负载 |
|---|---|---|
| 1 | 预留（先是特定预留，然后是任何预留） | 预留（先是特定预留，然后是任何预留） |
| 2 | 按需 | Spot 虚拟机 |
| 3 | Spot 虚拟机 | 动态工作负载调度器 |
| 4 | 动态工作负载调度器 | 按需 |
对于低延迟使用场景，按需容量的优先级高于预留容量，因为按需容量会快速报告容量不足的情况，从而使 CCC 能够快速回退到下一个选项。
对于经过费用优化的使用场景，在预留之后，系统会优先考虑使用 Spot 虚拟机和采用灵活启动的 DWS，以利用较低的费用。按需容量用作最终的后备方案。
配置 GKE 集群和节点池的位置政策
集群自动扩缩器的位置政策可控制 GKE 在扩容事件期间如何在可用区之间分布节点。使用自定义计算类时，此设置尤为重要，因为它决定了集群自动扩缩器在应用 CCC 的优先级列表之前会考虑哪些可用区。
为了提高获取加速器的几率，请根据工作负载的要求配置位置政策：
location-policy=ANY：优先获取容量，而不是在各个可用区中均匀分布节点。当您的 CCC 包含 Spot 虚拟机或可用性可变的机器类型时，此设置尤为重要，因为ANY允许集群自动扩缩器选择最有可能满足 CCC 优先节点类型的可用区。您还可以使用此设置来优先使用未使用的预留。使用此政策时，我们建议您从num-nodes=0开始，以便集群自动扩缩器在查找容量时具有最大的灵活性。location-policy=BALANCED：尝试在所有可用区中均匀分布节点。如果您的工作负载使用容易获取的资源，并且您希望保持可用区冗余以实现高可用性，请使用此政策。
您可以在创建或更新节点池时配置此设置。
针对效率和费用进行优化
通过仔细监控加速器并智能扩缩工作负载，您可以大幅减少浪费并降低运营成本。
观察加速器和推理服务器
全面的可观测性策略对于了解推理工作负载的性能和利用率至关重要。GKE 提供了一套工具，可帮助您监控加速器和推理服务器：
- 监控 NVIDIA GPU 的 DCGM 指标：如需监控 NVIDIA GPU 的健康状况和性能，请将 GKE 配置为将 NVIDIA 数据中心 GPU 管理器 (DCGM) 指标发送到 Cloud Monitoring。
- 启用自动应用监控：如需简化推理服务器的监控流程，请在 GKE 中启用自动应用监控。
- 使用 OpenTelemetry 对工作负载进行插桩：对于自动应用监控不支持的工作负载，请使用 OpenTelemetry 收集自定义指标和跟踪记录。
自动扩缩 Pod
为确保推理工作负载能够动态适应需求变化，请使用 Pod 横向自动扩缩器 (HPA) 来自动扩缩 Pod 数量。对于推理工作负载，务必要根据直接反映推理服务器负载的指标（而非标准 CPU 或内存指标）来做出扩缩决策。
如需为推理工作负载配置自动扩缩，我们建议您执行以下操作：
根据推理感知型指标配置 HPA：为获得最佳性能，请将 HPA 配置为根据推理服务器的指标进行扩缩。最佳指标取决于您是针对低延迟还是高吞吐量进行优化。
对于延迟敏感型工作负载，您有两个主要选项：
- KV 缓存利用率（例如
vllm:gpu_cache_usage_perc）：此指标通常是即将出现延迟高峰的最佳指标。 KV 缓存的高利用率表明推理引擎已接近容量上限。HPA 可以使用此信号来抢先添加副本，从而保持稳定的用户体验。 - 正在运行的请求数（批次大小）（例如
vllm:num_requests_running）：此指标与延迟时间直接相关，因为批次大小越小，延迟时间通常越短。不过，使用它进行自动扩缩可能具有挑战性，因为最大限度地提高吞吐量取决于传入请求的大小。您可能需要选择低于最大可能批次大小的值，以确保 HPA 能够适当扩容。
- KV 缓存利用率（例如
对于对吞吐量敏感的工作负载，请根据队列大小（例如
vllm:num_requests_waiting）进行扩缩。此指标可直接衡量工作积压情况，是一种将处理能力与传入需求匹配的简单方法。由于此指标仅考虑等待中的请求，而不考虑当前正在处理的请求，因此与基于批次大小进行扩缩相比，它可能无法实现尽可能低的延迟。
设置副本数下限：为确保持续可用性和基准用户体验，请始终为推理部署设置副本数下限。
启用性能 HPA 配置文件：在 GKE 1.33 版或更高版本中，符合条件的集群默认启用性能 HPA 配置文件，以缩短 HPA 的反应时间。
如需了解详情，请参阅为 GPU 上的 LLM 工作负载配置 HPA 和在 TPU 上自动扩缩 LLM 推理工作负载。
让数据更靠近工作负载
工作负载加载数据（例如模型权重）所需的时间可能会成为延迟的重要来源。通过将数据迁移到更靠近计算资源的位置，您可以缩短数据传输时间并提高整体性能。
- 使用 Anywhere Cache 创建可用区级读取缓存：如果您使用 Cloud Storage 来存储 AI/机器学习工作负载的数据，请启用 Anywhere Cache。Anywhere Cache 可为您的 Cloud Storage 存储桶创建高性能的可用区级读取缓存。
- 在本地 SSD 上缓存经常访问的数据：对于需要以极低延迟访问临时数据的工作负载，请使用本地 SSD 作为高性能缓存。使用本地 SSD 作为低延迟的临时存储空间来保存常用数据，有助于大幅缩短加速器等待 I/O 操作完成的时间，从而减少加速器等昂贵资源的空闲时间。请注意，并非所有机器系列都支持本地 SSD，这可能会影响您选择的加速器。
- 使用 GKE 数据缓存管理缓存：对于经常从永久性磁盘读取数据的工作负载，请启用 GKE 数据缓存。GKE 数据缓存使用本地 SSD 为永久性磁盘创建托管式高性能缓存。对于大多数生产工作负载，我们建议使用
Writethrough模式，通过将数据同步写入缓存和底层永久性磁盘来防止数据丢失。
针对高级扩缩架构进行优化
为了满足大规模或全球分布式应用的需求，您可以采用高级扩缩架构来提升性能、可靠性和流量管理。
使用 GKE 推理网关进行负载均衡流量
对于单个集群中的推理工作负载，我们建议使用 GKE 推理网关。推理网关是一种 AI 感知型负载均衡器，可监控推理指标，以便将请求路由到最佳端点。此功能可提高性能和加速器利用率。
使用 GKE 推理网关时，我们建议您遵循以下最佳实践：
- 将服务 Pod 分组到
InferencePool中：为每个提供推理工作负载服务的 Pod 组定义一个InferencePool。如需了解详情，请参阅自定义 GKE 推理网关配置。 - 多路复用延迟关键型工作负载：定义
InferenceObjectives以指定模型的部署属性，例如名称和优先级。GKE 推理网关会优先处理优先级较高的工作负载，让您可以在流量繁重期间多路复用对延迟时间要求严格和能够容忍延迟时间的工作负载，并实现负载卸除政策。 - 使用模型感知路由：如需根据请求正文中的模型名称来路由请求，请使用基于正文的路由。使用基于正文的路由时，确保后端具有高可用性。 如果扩展程序不可用，网关将返回错误，从而防止请求错误地路由。
- 允许网关自动分配流量：GKE 推理网关通过监控
InferencePool中推理服务器的关键指标（例如 KV 缓存利用率、队列长度和前缀缓存索引）来智能地路由流量。与传统方法相比，此实时负载均衡可优化加速器利用率、缩短尾延迟时间并提高总体吞吐量。 - 与 Apigee 和 Model Armor 集成：为了增强安全性和管理，请与 Apigee 集成以进行 API 管理，并与 Model Armor 集成以进行安全检查。
在多个节点上部署推理工作负载
对于无法在单个节点上运行的超大型模型，您需要将推理工作负载分布到多个节点。这需要一种可最大限度减少节点间通信延迟的架构，并确保分布式工作负载的所有组件都作为单个单元进行管理。
请考虑以下最佳做法：
最大限度地提高加速器网络带宽和吞吐量：当工作负载分布在多个节点上时，网络会成为关键的性能因素。为了最大限度地减少节点间通信延迟，请使用 NVIDIA GPUDirect 等高性能网络技术。您可以根据集群规模和工作负载所需的通信强度，从以下选项中进行选择：
- GPUDirect-TCPX：适用于在 A3 High 上运行的各种多节点推理工作负载。
- GPUDirect-TCPXO：可提供更高的分流和更高的带宽，从而提升性能，与标准 TCPX 相比，这对于大型集群更有利，并且可在 A3 Mega 机器上运行。
- GPUDirect RDMA：通过允许不同节点上的 GPU 之间直接进行内存访问（绕过 CPU），提供最高的节点间带宽和最低的延迟，最适合 A3 Ultra 和 A4 机器上要求最苛刻的大规模推理场景。
有关详情，请参阅：
为了验证多节点网络配置是否按预期运行，我们建议您使用 NVIDIA Collective Communications Library (NCCL) 等工具运行测试。
使用 LeaderWorkerSet 管理分布式工作负载：部署有状态的分布式工作负载（例如多节点推理服务）时，必须将其所有组件作为单个单元进行管理。为此，请使用 LeaderWorkerSet，这是一种 Kubernetes 原生 API，可让您将一组相关的 Pod 作为单个实体进行管理。LeaderWorkerSet 可确保集中的所有 Pod 一起创建和删除，这对于维护分布式工作负载的完整性至关重要。
使用紧凑布置将节点放置在彼此靠近的物理位置：分布式工作负载中节点之间的物理距离会对节点间网络延迟时间产生重大影响。为了最大限度地缩短此延迟时间，请为 GKE 节点池使用紧凑布置政策。紧凑布置政策会指示 GKE 将节点池中的节点放置在可用区内尽可能靠近的物理位置。
跨多个区域部署推理工作负载
对于需要高可用性和低延迟的全球分布式应用，跨多个区域部署推理工作负载是一项关键的最佳实践。多区域架构有助于提高可靠性、提升加速器可获取性、缩短用户感觉到的延迟，并满足特定位置的监管要求。
如需有效部署和管理多区域推理服务，请遵循以下建议：
- 在您已预留容量或预计需要容量来处理峰值负载的多个区域中预配 GKE 集群。
- 为模型权重选择合适的存储策略。如需优化运营效率，请创建多区域 Cloud Storage 存储桶。为了优化成本，请在每个区域中创建一个区域级存储桶，并复制模型权重。
- 使用 Anywhere Cache 为 Cloud Storage 存储桶创建可用区级读取缓存，以减少网络延迟和数据出站流量费用。
最佳做法摘要
下表总结了本文档中建议的最佳做法。
| 主题 | 任务 |
|---|---|
| 部署和配置 |
|
| 冷启动延迟 |
|
| 容量规划和加速器可获取性 |
|
| 资源和加速器效率 |
|
| 负载均衡 |
|
| 多节点部署 |
|
| 多区域部署 |
|
后续步骤
- 请参阅 GKE 推理参考架构。