NVIDIA AICR用版本锁定配方将Dynamo推理的Kubernetes运行时与应用部署分离为五步验证流程
NVIDIA AI Cluster Runtime将Dynamo及其依赖的GPU驱动、动态资源分配、gang调度、节点健康和监控等基础设施打包为版本锁定的配方，通过快照集群、生成配方、渲染部署包、部署运行时、验证安装五步完成运行时就绪，之后才允许安装应用推理图。文章同时对比了Dynamo Frontend路由和Gateway API Inference Extension/Endpoint Picker两条路径的适用场景。
NVIDIA Dynamo是一个分布式推理框架，协调模型服务跨多个GPU工作节点运行。在Kubernetes上部署它，表面上只需要一个DynamoGraphDeployment来指定vLLM、SGLang或TensorRT-LLM如何运行在Pod中。但实际生产部署远不止于此：GPU驱动栈必须与节点匹配，GPU节点需要被标记和发现，集群需要通过Dynamic Resource Allocation暴露GPU，调度器必须支持gang scheduling以满足拓扑要求，节点健康信号需要在工作负载落到降级节点之前可用，Prometheus必须可达以收集加速器和Dynamo指标，如果部署需要Kubernetes原生ingress则Gateway API和Endpoint Picker路径也必须配置就绪。
NVIDIA AI Cluster Runtime（AICR）的设计思路是把这些基础设施依赖从应用部署中剥离出来。它不要求团队逐一手动安装和调试上述组件，而是将Dynamo及其全部运行时依赖打包为一个配方（recipe）。配方记录了锁定的组件版本、兼容性约束和验证检查项，使部署可复现。AICR v1.0.0为Amazon EKS上的Dynamo推理配方锁定了NVIDIA GPU Operator v26.7.1、Node Feature Discovery 0.19.0、cert-manager v1.20.2、AWS EFA v0.5.29、NVSentinel v1.25.0、NVIDIA DRA GPU Driver 0.5.0、KAI Scheduler v0.16.9、Grove v0.1.0-alpha.13、Dynamo Platform 1.4.2、Agent Gateway v1.5.0、Kube Prometheus Stack 84.4.0等组件版本，这些版本由AICR团队在指定平台和硬件上共同测试过。
整个流程分为五步。第一步，aicr snapshot命令捕获集群当前状态，默认自动定位标记为nvidia.com/gpu.present=true的节点并容忍GPU节点污点。第二步，aicr recipe命令根据快照识别Kubernetes发行版、GPU加速器和操作系统，结合工作负载意图（inference）和平台（dynamo）生成配方文件。第三步，aicr bundle命令将配方渲染为可直接部署的Helm values和manifests，通过节点选择器和容忍标志指定GPU工作节点和系统节点的放置策略。第四步，部署运行时：本地无GitOps控制器时可用Helmfile按依赖层级顺序应用，生产环境可渲染ArgoCD或Flux的GitOps bundle。第五步，aicr validate命令在安装后、应用工作负载之前对集群执行deployment和conformance两个阶段的验证，检查项覆盖集群基线资源与GPU可分配容量、GPU Operator健康与版本、DRA支持与加速器安全访问、gang调度与自动扩缩容、Prometheus指标采集、以及Gateway API和agentgateway就绪状态。只有验证通过，DynamoGraphDeployment才被安装。
在路由层面，Dynamo 1.4.2支持两条Kubernetes路径，AICR为两者都提供配方和验证。第一条是Dynamo Frontend路由：Frontend以DYN_ROUTER_MODE=kv运行，对每个请求进行tokenize，用前缀重叠和当前负载对候选worker打分，选定worker后通过TCP请求平面分发。这条路径拓扑最小，适合应用团队拥有模型专属端点、或已有边缘代理只需将流量转发到Dynamo Frontend Service的场景，也是目前生产验证最充分的服务选项。第二条是Gateway API Inference Extension（GAIE）/ Endpoint Picker Plugin（EPP）路径：agentgateway将HTTPRoute解析到InferencePool，Dynamo operator从DynamoGraphDeployment创建该InferencePool，其selector标识候选worker Pod，endpointPickerRef标识Dynamo EPP Service。Gateway通过GAIE的端点选择接口调用EPP，EPP用Dynamo的KV路由器选定端点后返回给Gateway，Gateway再将请求转发到被选worker的Frontend sidecar（以--router-mode direct运行，不再重新路由）。这条路径适合平台团队管理共享Kubernetes ingress、且超时、重试和回退等策略需要通过Gateway API机制配置的场景。