跳转至正文

Google Kubernetes Engine (GKE) 上的 llm-d

本文档介绍了如何配置 GKE 集群，以使用 llm-d 运行高性能 LLM 推理。

先决条件​

llm-d 在 GKE 上已通过以下配置测试

  • 机器类型：A3, A4, ct5p, ct5lp, ct6e
  • 版本：GKE 1.33.4+

对于最佳实践路径，我们特别推荐以下机器类型

路径GPUTPU
推理调度使用 Hopper 或更新代际 (A3 或更新) 的大型模型 (13B+)
使用 Ampere、L4 或更新代际 (A2, G2 或更新) 的小型或高度量化模型 (1-7B)		ct5e (v5e) 或更新代际
Prefill / Decode 分离 (Disaggregation)支持 RDMA 的机器类型 (A3U, A4 或更新)ct6e (v6e) 或更新代际
广泛专家并行支持 RDMA 的机器类型 (A3U, A4 或更新)即将推出
分层前缀缓存 (Tiered Prefix Cache)分层前缀缓存可以与上述其他最佳实践路径结合使用。
如果运行 Prefill/Decode 分离或宽专家并行 (Wide Expert Parallelism)，请分别遵循其相应指南。
否则，请遵循“推理调度”指南。		即将推出

集群配置​

GCP 集群应配置以下设置

对于 A3 机器，如果您计划利用 Prefill/Decode 分离，请部署集群并使用 TCPX 配置高性能网络。

对于 A3 Ultra、A4 和 A4X 机器，请按照创建带 GPU 的 AI 优化 GKE 集群的步骤操作，并启用 GPUDirect RDMA。

对于所有 TPU 机器，请参考 GKE 中的 TPU 文档。

我们建议启用 Google 托管 Prometheus 和自动应用监控，以便为集群上部署的 vLLM 启用自动指标收集和仪表板。

工作负载配置​

GPU​

在 GKE 工作负载 Pod 上配置 RDMA 支持​

GCP 通过 RoCE 在 A3 Ultra+ GPU 主机上提供 CX-7 支持。

需要使用快速节点间网络进行 P/D 分离或宽专家并行的模型服务器需要在工作负载 Pod 上请求 RDMA 资源。集群创建指南介绍了访问 RDMA 设备所需的 Pod 修改（例如 针对 A3 Ultra / A4）。

此外，利用结合 NVIDIA NVSHMEM 的 DeepEP 的专家并行部署，其 Pod 需要以 privileged: true 运行以执行 GPU 发起的 RDMA 连接，或者通过手动安装 GPU 驱动程序在 NVIDIA 内核设置中启用 PeerMappingOverride=1。

注意：虽然 GDRCopy 允许 CPU 发起的 RDMA 连接，但目前我们尚未测量到此配置的优势，因此建议使用默认的 GPU 发起设置。您可以通过在容器上设置 NVSHMEM_DISABLE_GDRCOPY=1 环境变量来禁用 NVSHMEM 初始化中的 GDRCopy 警告。

确保具有 RDMA 的 Pod 副本的 网络拓扑感知调度​

选择适当的节点选择器，以确保多主机副本都位于同一个网络架构中。对于许多部署，您的 A3 Ultra 或更新的预留将位于单个可用区内。这可确保可达性，但可能无法达到所需的聚合吞吐量。

在支持 RDMA 的 GKE 节点上，cloud.google.com/gce-topology-block 标签可识别位于同一快速网络中的机器，并可用作高级编排的基础，将多主机副本中的 Pod 分组到同一个 RDMA 网络中。

GKE 建议为多主机训练和推理工作负载使用 结合 Kueue 和 LeaderWorkerSet 的拓扑感知调度 (TAS)。

对于较小规模的专家并行部署（2 或 4 节点副本），我们尚未观察到要求副本中所有节点都在同一个 cloud.google.com/gce-topology-subblock 中的显著优势。我们建议设置 Pod 亲和性规则，将所有 Pod 放置在同一个 cloud.google.com/gce-topology-block 中。

  affinity:
    podAffinity:
      # Subblock affinity cannot guarantee all pods in the replica
      # are in the same subblock, but is better than random spreading
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 2
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: vllm-deepseek-ep
          matchLabelKeys:
          - component
          topologyKey: cloud.google.com/gce-topology-block
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: vllm-deepseek-ep
          matchLabelKeys:
          - component
          topologyKey: cloud.google.com/gce-topology-subblock

已知问题​

GKE 上的 vLLM 0.10.0 出现 Undetected platform​

GKE 托管的 GPU 驱动程序会自动将配置的节点 CUDA 驱动程序挂载到 /usr/local/nvidia。像 vLLM 这样的 CUDA 应用程序必须在其 LD_LIBRARY_PATH 中包含 /usr/local/nvidia，否则它们将无法找到必要的 CUDA 库。

在 vLLM 中，这会导致启动失败并显示以下日志

INFO 05-28 14:02:21 [__init__.py:247] No platform detected, vLLM is running on UnspecifiedPlatform
...
INFO 05-28 14:02:26 [config.py:1909] Disabled the custom all-reduce kernel because it is not supported on current platform.
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/local/lib/python3.12/dist-packages/vllm/entrypoints/openai/api_server.py", line 1372, in <module>
    parser = make_arg_parser(parser)
  File "/usr/local/lib/python3.12/dist-packages/vllm/entrypoints/openai/cli_args.py", line 246, in make_arg_parser
    parser = AsyncEngineArgs.add_cli_args(parser)
  File "/usr/local/lib/python3.12/dist-packages/vllm/engine/arg_utils.py", line 1565, in add_cli_args
    parser = EngineArgs.add_cli_args(parser)
  File "/usr/local/lib/python3.12/dist-packages/vllm/engine/arg_utils.py", line 825, in add_cli_args
    vllm_kwargs = get_kwargs(VllmConfig)
  File "/usr/local/lib/python3.12/dist-packages/vllm/engine/arg_utils.py", line 174, in get_kwargs
    default = field.default_factory()
  File "<string>", line 4, in __init__
  File "/usr/local/lib/python3.12/dist-packages/vllm/config.py", line 2245, in __post_init__
    raise RuntimeError(
RuntimeError: Failed to infer device type, please set the environment variable `VLLM_LOGGING_LEVEL=DEBUG` to turn on verbose logging to help debug the issue.

此问题的根本原因是，用作 vLLM 容器镜像基础的 CUDA 12.8 和 12.9 NVIDIA Docker 镜像将安装的 CUDA 驱动程序位置从 /usr/local/nvidia 更改为 /usr/local/cuda，并更改了 LD_LIBRARY_PATH。结果，vLLM 找不到来自驱动程序挂载点的库。

在 llm-d 容器镜像和 commit 5546acb463243ce 之后的 vLLM 中存在变通方法。自定义 vLLM 镜像的用户需要确保其 vLLM 镜像中的 LD_LIBRARY_PATH 包含 /usr/local/nvidia/lib64。

vLLM 0.11.0 需要 Google InfiniBand 1.10 (gIB)​

vLLM v0.11.0 及更高版本需要 NCCL 2.27，这在 gIB 1.10+ 中受支持。请参阅集群配置中的相应部分，了解如何安装 RDMA 二进制文件和配置 NCCL（例如 针对 A3 Ultra / A4）。要获取 1.10，请至少使用此 1.10 pull request 中描述的 RDMA 安装程序 DaemonSet 版本。

NVSHMEM 在 DeepEP 初始化时报告 Unable to create ah.​

某些版本（3.3.20 到 3.4.5）的 NVSHMEM 包含一个错误，即代码中未对传递给设备初始化的 ibv_ah_attr 结构体进行清零。验证 static_rate 字段值的 Linux 内核版本可能会因为 EINVAL 而导致启动失败，并在使用 DeepEP 内核进行宽专家并行时报告 Unable to create ah.。

为了解决这个问题，llm-d 对 NVSHMEM 应用了一个补丁，在将结构体传递给内核之前对其调用 memset(..., 0, ...)。

NVSHMEM 因 no active IB device that supports GPU-initiated communication 导致 DeepEP 无法初始化 IBGDA 传输​

启动使用 DeepEP 内核的宽专家并行部署时，未按照 NVIDIA 建议针对 Mellanox OFED 驱动程序进行编译的容器镜像（特别是 Ubuntu）可能会启动失败，并出现以下错误

/tmp/nvshmem_src/src/modules/transport/ibgda/ibgda.cpp 3888 no active IB device that supports GPU-initiated communication is found, exiting...

/tmp/nvshmem_src/src/host/transport/transport.cpp:nvshmemi_transport_init:282: init failed for transport: IBGDA

基于 RHEL UBI 的默认 llm-d 镜像不受影响。Issue 412 正在跟踪更新我们的 Ubuntu 基础镜像。

要在自定义镜像中解决此问题，请添加 Mellanox OFED apt 存储库

wget -qO - https://www.mellanox.com/downloads/ofed/RPM-GPG-KEY-Mellanox | apt-key add -
cd /etc/apt/sources.list.d/ && wget https://linux.mellanox.com/public/repo/mlnx_ofed/24.10-0.7.0.0/ubuntu22.04/mellanox_mlnx_ofed.list

然后再安装 libibverbs-dev 或其他 rdma-core-devel 软件包。

内容来源

此内容自动同步自 llm-d/llm-d 仓库 main 分支下的 docs/infra-providers/gke/README.md。

📝 如需建议更改，请编辑源文件或创建 issue。