NVIDIA 详解 AICR 为 Dynamo 搭建 Kubernetes 基础环境：先验运行时，再部署模型服务图

NVIDIA 在 2026 年 10 月 30 日说明 AI Cluster Runtime（AICR）如何为 Dynamo 推理服务搭建经过校验的 Kubernetes 基础环境。DynamoGraphDeployment 定义模型服务图，却不会自动保证 GPU 驱动、资源分配、调度、网络入口与监控都已就绪。AICR 用带版本的 recipe 打包 Dynamo 及依赖组件，再检查目标集群是否满足 recipe 的要求。文章讨论运行时部署与验证流程，没有宣称训练了新模型，也没有给某个业务应用的吞吐增益实测值。

原文区分两种请求路由路径。较简单的路径把 Dynamo Frontend 放在 Kubernetes Service 后面；启用 KV 路由时，Frontend 对请求分词，结合前缀重合度与当前负载选 worker，再亲自把请求转发过去。它适用于模型专用端点或只需把流量转给 Frontend 的现有代理。另一种路径使用 Gateway API 和 Inference Extension。HTTPRoute 指向 InferencePool，Dynamo operator 根据 DynamoGraphDeployment 创建池和 Endpoint Picker 引用。Gateway 调用 Dynamo EPP，EPP 借助 KV 信息选 worker 并返回路由元数据；真正代理 HTTP 请求至目标 worker 的 Frontend sidecar 的是 Gateway。选点与转发不能混为一谈。

两种路径都能放在 HTTPRoute 后面，所以区别不是有没有网关，而是谁管理 worker 方向的传输、超时、重试与 fallback：第一种是 Dynamo Frontend，第二种是 Gateway。第二种还需要兼容的 Gateway、InferencePool、EPP 和 worker sidecar。NVIDIA 称第一种拓扑更小、生产经验更成熟。文章讨论的是 operator 管理的 DynamoGraphDeployment 集成，不应扩大到实验性的独立原生 vLLM 接入。Dynamo 1.4 的 EPP 采用 Go 框架并经 CGO 嵌入 Rust KV 路由器；原生 Rust EPP 被描述为 1.5 方向，不是当前 1.4.2 recipe 已有功能。

代理对话常重复系统指令、工具定义和历史消息等长前缀。把请求送到已有相应 KV 缓存块的 worker，可避免重新处理整段输入。worker 经本地 ZMQ 发布缓存事件，Dynamo 规范化后转发到自己的事件平面。请求平面默认用 TCP，缓存事件平面用 ZMQ，两者不是同一传输。两条路由路径都可用 worker 实际发布的缓存及负载状态。也能配置预测式缓存视图，但 NVIDIA 提醒它看不到驱逐事件，可能逐渐偏离真实状态。文章还讨论 prefill 与 decode 分离；缓存未命中率取决于工作负载，不能只凭架构图推断。

AICR 流程有顺序：先用 aicr snapshot 记录集群，再用 aicr recipe 根据快照选择 Dynamo 推理 recipe，写入固定组件版本、平台约束与校验。文中 AICR v1.0.0 针对 Amazon EKS 上 GB200 NVL72 和 GB300 NVL72 的例子把 Dynamo Platform chart 固定在 1.4.2；这是特定平台经测试的版本组合，不是全平台“最新版”。可选离线检查能把 recipe 与另一份快照比较，但没有在线集群时行为检查会跳过。之后用 aicr bundle 渲染 Helm 配置与清单，部署运行时，最后用 aicr validate 在真实集群执行 deployment 与 conformance 检查，再装应用的 DynamoGraphDeployment。

AICR recipe 不只是 Helm chart 清单。它还记录组件校验和、节点选择器、污点容忍、兼容性约束和预期检查，因此同一份配置可以对照目标集群反复验证。文章举的是 Amazon EKS 上两类 Grace Blackwell 系统的固定版本组合；选择 recipe 时会读取集群发行版、加速器和 GPU 节点操作系统，不能把表格直接复制到任意云或任意 GPU。离线比较不同快照可预先发现声明式的不兼容，但不会接触 Kubernetes 集群，因而不会执行真实的行为探针。

文中还提到 Dynamo 1.4 的默认 Kubernetes 路径已经不再依赖 NATS；需要它的部署仍可自行选择。请求转发和 KV 缓存事件独立：默认请求沿 TCP，缓存事件从 vLLM worker 的本地 ZMQ 源发布，再由 Dynamo 归一化。缓存驱逐若没有被预测视图观察到，路由器可能误以为某个 worker 仍保留前缀，造成不必要的重新处理。采用实际事件能改善视图，但实际表现仍取决于代理会话长度、命中率及硬件负载，文章没有给出可推广的统一增益比例。

部署后验证包含硬件可分配量、节点健康、调度、自动扩容、监控与入口的就绪情况。即使这些基础条件都满足，应用的 DynamoGraphDeployment 仍是下一步，性能验证则再往后。它会部署临时推理负载并占用 GPU，所以不能用仅检查清单或版本匹配的离线结果代替。

校验通常覆盖 GPU 容量与 nvidia-smi、GPU Operator 与 Dynamo 健康、DRA 访问、协同调度和自动扩缩、Prometheus 指标，以及选用 Kubernetes 原生入口时的 Gateway 就绪。NVIDIA 明确把性能验证列为另一阶段，因为它会运行临时服务负载并消耗 GPU；基础环境通过部署和符合性检查不等于业务吞吐已被证明。recipe 的检查因平台而异，文章也没有证明本站或读者集群已通过。可复用的价值是从集群快照、固定版本到渲染、部署和在线检查的明确顺序。