使用 NVIDIA AI Cluster Runtime 构建验证过的 Kubernetes Dyn

数据中心 / 云计算

为 NVIDIA Dynamo 构建经过验证的 Kubernetes 运行时环境

2026 年 10 月 30 日

构建 AI 应用的团队需要一条可重复的路径，从模型配置直达可用的推理端点。NVIDIA Dynamo 是一个分布式推理框架，负责协调跨 GPU 工作节点的模型服务。将其部署到 Kubernetes 仅是第一步。成功的模型部署还需要更多支持：GPU 驱动、资源分配、调度、网络与监控必须协同工作。解决这些依赖关系会占用大量时间，从而挤占测试模型行为、推理性能与应用集成的精力。

NVIDIA DSX AI Factory Platform 汇聚了多项技术，旨在帮助生态伙伴设计、构建并运营更高效的 AI 工厂，Dynamo 便是其中之一。为简化这些基础设施依赖的管理，该平台内置了 NVIDIA AI Cluster Runtime（AICR）。它将 NVIDIA Dynamo 及其配套基础设施打包为经过验证的配置配方（recipes）。每个配方针对特定环境与负载定义了一套配置，包含固定的组件版本、兼容性约束以及验证检查项。AICR 为平台团队提供了一种可重复的部署与校验运行时的方法，为开发者提供一致的基础设施底座，用于模型服务与应用测试。

本指南将介绍支撑 Kubernetes 上 Dynamo 运行的基础设施，对比两种路由方案，并演示如何使用 AICR 部署与验证该运行时环境。

为什么底层运行时对 Dynamo 至关重要

在 Kubernetes 上使用 Dynamo 运行模型时，首先需要一个 DynamoGraphDeployment 对象，用于指定 vLLM、SGLang 或 NVIDIA TensorRT LLM 应在集群的 Pod 中如何运行。但此图仅处于架构栈的顶层。生产级推理集群还需要在其下方配备一层运行时环境。该层需解答以下关键问题：

• 是否已安装 NVIDIA GPU Operator，且其驱动栈与节点匹配？
• GPU 节点是否已正确打标并可被识别？
• 集群是否通过预期的动态资源分配（DRA）驱动暴露 GPU 设备？
• 调度器能否根据所需拓扑结构与并行调度语义放置 GPU 工作节点？
• 在负载部署至状态劣化的节点前，是否能获取节点健康信号？
• 是否可达 Prometheus 以采集 Dynamo 与加速器的指标数据？
• 当入口流量需保持 Kubernetes 原生特性时，是否已配置 Gateway API / Endpoint Picker（EPP）路径？

AICR 将这些运行时要求统一收录于配方之中。

AICR 为 Dynamo 提供了什么

AICR 的 Dynamo 配方同时打包了 Dynamo 本身及其所依赖的集群运行时组件。

AICR 随附 dynamo-platform Chart 的 1.4.2 版本，其中包含 Dynamo Operator、Dynamo 运行时镜像，以及 nvidia.com/v1beta1 DynamoGraphDeployment 自定义资源定义（CRD）等资源。v1beta1 版本已取代原有的 v1alpha1 API 版本。

表 1 列出了配方中包含的支持性基础设施组件。

表 1. Dynamo 下方的运行时前置条件及 AICR 配方为各项安装的组件

此外，该配方会锁定组件版本，并记录配置值、节点选择器、容忍度、校验和以及验证预期，以确保部署可复现。

在 Dynamo 1.4 中，前端、工作节点、可选的 Gateway API 推理扩展（GAIE）/端点选择插件（EPP）组件以及其他 Dynamo 服务均通过 Kubernetes 资源相互发现。因此，AICR 的默认路径不再依赖 NATS，dynamo-platform Chart 也不再默认安装它。对于需要 NATS 的部署，仍可作为可选配置启用。

智能体工作负载会反复扩展较长的 Token 前缀，包括系统提示词、工具定义、对话历史以及工具返回结果。如果某次交互到达工作节点时 GPU 内存中缺少该前缀，系统将重新处理中间 Token，而非复用缓存结果。Dynamo 会将请求路由至已持有相关 KV 块的工作节点，这可以通过其前端路由器实现，也可借助 Gateway API 层的 GAIE/EPP 集成完成。

Dynamo 还支持将提示词处理（预填充/prefill）与 Token 生成（解码/decode）分离，这种架构被称为解耦推理（disaggregated serving）。当发生 KV 缓存未命中时，全部或部分提示词必须由预填充池重新处理。随后由解码工作节点接管逐 Token 生成任务，其在 GPU 利用率、内存占用、延迟和批处理特性上均有不同。缓存未命中率取决于具体工作负载。长期运行的智能体会话与一次性聊天请求的行为模式存在差异。解耦推理使运维人员能够针对特定的请求组合，独立扩展和调整预填充与解码容量。

请求平面与 KV 缓存事件平面相互独立。在 Dynamo 1.4.2 中，默认的 AICR Kubernetes 路径对请求使用 TCP 协议，对 KV 缓存事件使用 ZMQ 协议。每个 vLLM 工作引擎均通过本地 ZMQ 发布者输出原始 KV 缓存事件，例如以下 vLLM 配置所示：

--enable-prefix-caching --kv-transfer-config \
 {"enable_kv_cache_events": true, "publisher": "zmq", "endpoint": "tcp://*:5557"}

Dynamo 的工作运行时随后订阅该本地 vLLM 事件源，对事件进行标准化处理，并将其重新发布至 Dynamo 事件平面。原生的 Dynamo Frontend 路由器与 GAIE/EPP 路径均依赖此由 Dynamo 管理的 KV 缓存状态来执行路由决策。

Kubernetes 上的 Dynamo 路由路径有哪些？

Dynamo 在 Kubernetes 上支持两种路由路径。第一种路径使用 Dynamo Frontend 路由器进行工作节点选择。第二种路径采用 Kubernetes Gateway API 实现作为入口网关，并结合 Dynamo EPP 进行端点选择。AICR 为上述两种拓扑结构均提供并验证了 Dynamo 运行时。

路径 1：Dynamo Frontend 路由器

默认路径在 Kubernetes Service 后方暴露一个 Dynamo Frontend 实例。当配置 DYN_ROUTER_MODE=kv 运行时，Frontend 会对每个请求进行分词，基于前缀重叠度与当前负载对符合条件的工作节点进行评分，选定目标节点后，通过默认采用 TCP 协议的 Dynamo 请求平面分发该请求。

当应用团队独立维护特定模型的端点，或现有边缘代理仅需将流量转发至 Dynamo Frontend Service 时，此路径最为适用。它是部署与验证 Dynamo 计算图的最简拓扑架构，也是经过生产环境充分验证的服务方案。该方案无需引入路径 2 所需的额外网关与 EPP 组件。

图 1. Dynamo Frontend 根据 KV 缓存重叠度与负载情况选择 vLLM 工作节点。请求通过 TCP 请求平面传输；工作节点的 KV 缓存事件则经由基于 ZMQ 的事件平面送达 Frontend。

路径 2：Gateway API Inference Extension 与 Dynamo EPP

此路径将 Dynamo 与 Gateway API 及 Gateway API Inference Extension（GAIE）深度集成。在 AICR 示例中，agentgateway 将 HTTPRoute 解析映射为 InferencePool。Dynamo Operator 依据 DynamoGraphDeployment 创建该 InferencePool：其中的 selector 字段用于标识符合条件的工作节点 Pod，而 endpointPickerRef 字段则指向 Dynamo EPP Service。

网关通过 GAIE 提供的端点选择接口调用 Dynamo EPP。EPP 对请求进行分词，并利用 Dynamo 的 KV 路由器挑选目标端点。随后，EPP 将选定的端点信息及相关路由元数据返回给网关实现层（即实际的 HTTP 代理程序）。在此模式下，每个具备路由能力的工作节点 Pod 均附带一个 Dynamo Frontend Sidecar 容器，用于接收来自网关的请求并将其转发至本地的 Worker 容器。Frontend 以 --router-mode direct 模式运行，因此会直接采纳 EPP 的选择结果，无需进行二次路由转发。

当平台团队统一管理共享的 Kubernetes 入口网关，且需借助 Gateway API 机制配置模型端点的工作节点选择、超时阈值、重试策略与降级回退逻辑时，此路径最为合适。需注意，上述两种路由方式均可部署于 Gateway API HTTPRoute 之后。两者的核心差异在于由哪个组件负责向工作节点传输流量：是 Dynamo Frontend，还是网关本身。

注意：本文介绍的是 Dynamo 通过 Operator 管理的 DynamoGraphDeployment 与 GAIE 的集成方式；实验性的独立原生 vLLM 接入路径属于另一种独立的集成方案。在 Dynamo 1.4 中，该路径采用 GAIE 的 Go EPP 框架，并通过 CGO 嵌入 Dynamo 的 Rust KV 路由器，同时使用 eppConfig 进行配置。

展望：从 Dynamo 1.5 开始，原生 Rust EPP 将取代 Go/CGO 桥接层。它直接实现 GAIE 的轻量级端点选择器（Lightweight Endpoint Picker, ext_proc）接口，以进程内方式运行完整的 Dynamo 路由器，并使用 DYN_* 环境变量替代原有的 eppConfig 插件与调度配置文件。聚合与非聚合路由逻辑将直接由通过 Dynamo 服务发现注册的 Worker 角色处理。外围的 Kubernetes 拓扑结构保持不变。移除 Go 插件框架与 CGO 边界还能有效降低单次请求的 EPP 开销。

图 2。GAIE / EPP 路径将 Worker 的网络传输委托给 Gateway，而 Dynamo 负责执行基于 KV 感知的端点选择。

客户端请求首先进入网关（例如 agentgateway），并匹配由 InferencePool 支撑的 HTTPRoute。网关随后调用 Dynamo EPP，后者仅执行基于 Token 的 KV 选择，并返回选定的端点及路由元数据。接着，网关以直连模式将请求转发至目标 Worker 的 Frontend Sidecar，该 Sidecar 再通过 Dynamo 请求平面将请求发送至 vLLM Worker。Worker 的 KV Cache 状态则通过 Dynamo 事件平面同步至 EPP。此外，Dynamo Operator 会根据 DynamoGraphDeployment 自动创建对应的 EPP 与 InferencePool。

路径选择

路由路径的选择取决于请求转发至 Worker 的逻辑（包括超时控制、重试机制与降级管理）应由 Gateway 还是 Dynamo Frontend 来承担。表 2 对比了 Dynamo Frontend 路径与 Gateway API/EPP 路径的差异。

表 2。Dynamo 路由器与 GAIE / EPP 路由路径的决策标准

两条路径均使用工作节点发布的 KV-cache 事件来实现精确的缓存感知放置。Dynamo 也可配置为根据请求发送目标来预测 KV-cache 状态。由于预测机制无法感知驱逐操作，路由器的视图可能与各工作节点实际持有的数据产生偏差，从而导致路由质量下降，在内存压力较大时尤为明显。本文中的 AICR 配置启用了实时事件，因此两条路径均基于工作节点上报的 KV-cache 状态进行路由。

AICR 配方流程工作原理

AICR 将运行时配置与应用部署相分离。首先，系统会捕获现有的 Kubernetes 集群，并生成与之匹配的 Dynamo 配方。随后，在应用安装 DynamoGraphDeployment 及测试推理端点之前，会先完成运行时包的渲染、部署与验证。

步骤 1：快照集群

该快照记录了 AICR 用于配方选择与验证的集群状态：

aicr snapshot \
 --namespace aicr-validation \
 --output snapshot.yaml

若未指定放置参数，AICR 会自动定位带有 nvidia.com/gpu.present=true 标签的节点，并容忍 GPU 节点的污点。当集群有特殊要求时，可通过 --node-selector 和 --toleration 标志提供更精确的放置策略。

步骤 2：生成 Dynamo 推理配方

AICR 利用快照识别 Kubernetes 发行版、GPU 加速器及 GPU 节点操作系统。该命令指定了工作负载意图与平台：

aicr recipe \
 --snapshot snapshot.yaml \
 --intent inference \
 --platform dynamo \
 --output recipe.yaml

生成的配方会记录固定的组件版本、环境特定配置、兼容性约束及验证检查项。针对适用于 NVIDIA GB200 NVL72 与 GB300 NVL72 系统的 Amazon EKS Dynamo 推理配方，AICR v1.0.0 选择了以下 Helm Chart 版本：

表 3. AICR v1.0.0 Amazon EKS Dynamo 推理配方的 Helm Chart 版本

AICR 团队已在指定平台与硬件上对这些组件版本进行了联合测试。以下步骤用于验证集群是否满足所选配方的要求。

可选离线检查

配方选择过程已直接调用 snapshot.yaml 中的集群事实信息，因此仅用同一份快照验证新生成的配方意义有限。离线验证的价值在于：在不连接 Kubernetes 的情况下，使用其他已捕获的集群快照测试配方。该模式会评估声明式约束，而行为检查项将被标记为跳过。

aicr validate \
 --recipe recipe.yaml \
 --snapshot candidate-snapshot.yaml \
 --no-cluster \
 --output dry-run.json

步骤 3：渲染运行时包

AICR 会将配方（recipe）渲染为可直接部署的 Helm values 与清单文件：

aicr bundle \
 --recipe recipe.yaml \
 --accelerated-node-selector nodeGroup=gpu-worker \
 --accelerated-node-toleration dedicated=worker-workload:NoSchedule \
 --accelerated-node-toleration dedicated=worker-workload:NoExecute \
 --system-node-selector nodeGroup=system-worker \
 --system-node-toleration dedicated=system-workload:NoSchedule \
 --system-node-toleration dedicated=system-workload:NoExecute \
 --set-json agentgateway:allowedSourceRanges='[""]' \
 --deployer helmfile \
 --output bundle

这些节点放置标志对应本指南所使用的测试集群。若目标集群的标签与污点配置不同，可相应调整或省略这些参数。若集群未配置默认的 StorageClass，还需额外添加 --storage-class 参数。

步骤 4：部署运行时

若本地环境未配置集群内的 GitOps 控制器，可使用 Helmfile 进行部署。在本地已安装 Helm 与 helm-diff 插件的前提下，可通过以下命令在正式应用前预览 AICR 生成的发布依赖图：

helmfile -f bundle/helmfile.yaml diff
helmfile -f bundle/helmfile.yaml apply

AICR 会在生成的 Helmfile 包中记录组件间的依赖关系。Helmfile 将按序解析这些依赖层级，并在同一层级内并发部署相互独立的组件。再次执行 apply 命令可使已安装的 Helm 发布版本与当前配置保持一致。

若环境中未提供 Helmfile，也可调用 AICR 内置的默认 Helm 部署器重新生成该包。其自动生成的 deploy.sh 脚本可作为轻量级备选方案，适用于交互式测试：

aicr bundle \
 --recipe recipe.yaml \
 [... all the flags setting node selectors and tolerations ...] \
 --set-json agentgateway:allowedSourceRanges='[""]' \
 --deployer helm \
 --output bundle-helm

chmod +x bundle-helm/deploy.sh
 ./bundle-helm/deploy.sh

针对生产环境，AICR 还支持通过 --deployer argocd、--deployer argocd-helm 以及 --deployer flux 参数生成 GitOps 部署包。

步骤 5：验证已安装的运行时

完成安装后，需在部署应用程序工作负载之前，对实际运行的集群进行部署检查与合规性验证。由于本例未提供快照文件，AICR 会在执行验证任务前自动捕获当前的集群状态。

aicr validate \
 --recipe recipe.yaml \
 --node-selector nodeGroup=gpu-worker \
 --toleration dedicated=worker-workload:NoSchedule \
 --toleration dedicated=worker-workload:NoExecute \
 --phase deployment \
 --phase conformance \
 --output report.json

仅当上述检查全部通过后，才会正式安装应用程序 DynamoGraphDeployment。性能验证需独立执行，因其会部署临时推理服务工作负载并占用待测 GPU 资源。

AICR 验证具体检查哪些内容？

AICR 会根据所选配方（recipe）中编码的检查项与约束条件，验证已安装运行时的合规性。各项检查因配方而异。针对 Dynamo 推理配方，部署与一致性验证通常涵盖以下内容：

表 4. AICR Dynamo 配方的部署与一致性检查项

这些检查旨在确保在应用部署前，已安装运行时符合所选配方的要求。

AICR 将版本化的运行时配置与检查机制相结合，用于验证集群是否满足所选配方的需求。

快速开始

NVIDIA AI Cluster Runtime（AICR）与 NVIDIA Dynamo 均为 NVIDIA DSX AI Factory Platform 的开源组件。在 Kubernetes 上部署 Dynamo 的团队，可利用 AICR 提供的配方与部署示例，来配置、部署并验证支撑其推理工作负载的基础设施。

更多项目与社区资源可通过 NVIDIA DSX AI Factory GitHub 仓库获取。

您可在 NVIDIA DSX AI Factory Slack 社区参与讨论。NVIDIA DSX OS AI Inference and Contributor Workshop 将在 KubeCon + CloudNativeCon North America 期间提供 AICR 的实操体验。由于席位有限，需提前注册报名。

KubeCon 展会期间，NVIDIA 展位 #170 将展示 Kubernetes 深度技术分享与现场演示。