NVIDIA发布AICR验证式配方，把Dynamo推理运行时打包到Kubernetes
NVIDIA技术博客介绍AI Cluster Runtime（AICR）：它把Dynamo及GPU Operator、KAI Scheduler、Grove、Prometheus等依赖打包成带固定版本与校验步骤的配方，并提供快照、生成、渲染、部署、验证五步流程。文中给出EKS上GB200/GB300配方所用各组件版本。
AI解读：AICR解决的是Dynamo部署在Kubernetes上时下层运行时依赖分散的问题：GPU驱动、GPU发现与分配、调度、节点健康、监控、Ingress需要彼此配套。AICR把这些写成针对特定环境和负载的配方，包含固定组件版本、兼容性约束和验证检查。
文章区分两条路由路径。默认路径由Dynamo Frontend在Kubernetes Service后选worker，使用DYN_ROUTER_MODE=kv，请求走TCP请求面；另一条路径由Gateway API与Dynamo EPP负责入口和端点选择，worker侧带Dynamo Frontend sidecar以direct模式转发。
Dynamo 1.4起，前端、worker与可选GAIE/EPP组件通过Kubernetes资源互相发现，AICR默认路径不再使用NATS，chart也不再默认安装，NATS保留为可选。1.4.2 的默认AICR Kubernetes路径用TCP传请求、ZMQ传KV-cache事件。
文中列出AICR v1.0.0针对Amazon EKS上GB200 NVL72与GB300 NVL72的Dynamo推理配方所用Helm chart版本，例如GPU Operator 26.7.1、KAI Scheduler 0.16.9、Grove 0.1.0-alpha.13、Dynamo Platform 1.4.2、agentgateway 1.5.0。NVIDIA表示这些版本已在指定平台和硬件上一起测试。
文章还提到Dynamo 1.5计划用原生Rust EPP替代Go/CGO桥接，直接实现GAIE的ext_proc接口，改用DYN_* 环境变量配置，Kubernetes拓扑不变。
NVIDIA技术博客发布一篇操作向文章，介绍如何用NVIDIA AI Cluster Runtime（AICR）在Kubernetes上部署并验证NVIDIA Dynamo推理运行时。文章由Stefan Schimanski署名，给出的路径是：先对集群做快照，再生成匹配的Dynamo配方，渲染运行时bundle、部署，并在安装应用的DynamoGraphDeployment之前运行部署与一致性验证。
AICR配方里装了什么
Dynamo是跨GPU worker协调模型服务的分布式推理框架。文章称，把Dynamo放到Kubernetes上只是第一步，下面还需要驱动、资源分配、调度、网络和监控共同到位；AICR把这些运行时要求写进配方。
AICR内置dynamo-platform chart，文章写明固定为 1.4.2 版本，包含Dynamo operator、运行时镜像以及nvidia.com/v1beta1的DynamoGraphDeployment CRD；v1beta1取代此前的v1alpha1。配方还固定组件版本，并记录配置值、节点选择器、容忍、校验和与验证预期。
- GPU驱动栈：NVIDIA GPU Operator，需与节点匹配
- GPU发现：Node Feature Discovery，节点需带标签且可被发现
- GPU分配：面向NVIDIA GPU的DRA Driver，通过Kubernetes原生DRA暴露GPU
- 调度：KAI Scheduler，负责拓扑与gang scheduling
- 推理负载编排：Grove，按协调组启动、放置和扩缩多组件服务图
- 节点健康：NVSentinel与Nodewright（在所选配方支持时）
- 指标：Prometheus栈采集集群、加速器和Dynamo服务指标
- 入口：agentgateway与Gateway API资源，用于Kubernetes原生入口场景
两条路由路径的差别
文章比较了Dynamo在Kubernetes上的两种路由。路径一由Dynamo Frontend router选worker：Frontend对请求分词，按前缀重叠和当前负载给候选worker打分，再通过默认TCP的Dynamo请求面派发。文章称这是部署和验证Dynamo图的最小拓扑，也是“最经生产验证”的服务选项，不需要路径二中的网关和EPP组件。
路径二接入Gateway API与Gateway API Inference Extension。示例中agentgateway把HTTPRoute解析到InferencePool，Dynamo operator从DynamoGraphDeployment创建该InferencePool；网关通过GAIE的端点选择接口调用Dynamo EPP，EPP分词后用Dynamo KV router选端点并返回选择与路由元数据，实际HTTP代理仍是网关。每个可路由worker pod带一个Dynamo Frontend sidecar，以 --router-mode direct接收网关请求并转发给本地worker容器。
哪条路径取决于由谁管理到worker的转发，包括超时、重试和回退：应用团队自管模型专用端点时用Frontend路径；平台团队通过Gateway API管理共享入口时用GAIE/EPP路径。两条路径都基于worker上报的KV-cache事件做缓存感知放置；文章称也可改为根据请求发送位置预测KV-cache状态，但预测看不到驱逐，路由视图可能漂移，内存压力下路由质量可能下降，而文中AICR配置启用了实时事件。
- Dynamo 1.4.2默认AICR Kubernetes路径：请求走TCP，KV-cache事件走ZMQ
- vLLM worker引擎通过本地ZMQ publisher发出原始KV-cache事件，Dynamo worker runtime订阅、规范化后转发到Dynamo事件面
- Dynamo 1.4中前端、worker、可选GAIE/EPP及其他Dynamo服务通过Kubernetes资源互相发现，AICR默认路径不再使用NATS
- NATS仍可选择启用
五步流程与验证范围
文章给出的流程是：用aicr snapshot记录集群状态；用aicr recipe指定 --intent inference和 --platform dynamo生成配方；用aicr bundle渲染Helm values与manifests；用Helmfile或生成的deploy.sh部署；最后用aicr validate以deployment和conformance阶段检查已安装运行时，通过后才安装应用的DynamoGraphDeployment。
验证项按配方不同而异。对Dynamo推理配方，文章列出的覆盖范围包括集群基线资源、GPU可分配容量与nvidia-smi是否可用，GPU Operator与Dynamo平台/operator健康，DRA支持与安全加速器访问，gang scheduling、pod自动扩缩、集群自动扩缩与控制器行为，以及可观测性。性能验证需单独运行，因为它会部署临时服务负载并占用被测GPU。
文章还说明aicr validate带 --no-cluster时只做离线声明式检查，行为类检查会被标记为跳过。
- AICR v1.0.0的Amazon EKS Dynamo推理配方面向GB200 NVL72与GB300 NVL72，列出GPU Operator 26.7.1、NFD 0.19.0、cert-manager v1.20.2、AWS EBS CSI Driver 2.59.0、AWS EFA v0.5.29、NVSentinel v1.25.0、NodeWright Operator v0.19.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与CRD v1.5.0、Kube Prometheus Stack 84.4.0等
- NVIDIA称AICR团队在指定平台和硬件上一起测试了这些版本
- bundle支持 --deployer helmfile、helm、argocd、argocd-helm、flux；集群无默认StorageClass时需指定 --storage-class
- Dynamo 1.5起计划用原生Rust EPP取代Go/CGO桥接，直接实现GAIE的Lightweight Endpoint Picker（ext_proc）接口，完整Dynamo router在进程内运行，用DYN_* 环境变量替代eppConfig插件与调度配置