要点
- NVIDIA DSX AI Factory 的 AI Cluster Runtime（AICR）把 Dynamo 与其依赖（GPU Operator、DRA、KAI Scheduler、Grove、Prometheus、agentgateway 等）打包成带钉死版本与校验的「菜谱」。
- Dynamo 1.4.2 默认请求面走 TCP、KV 缓存事件走 ZMQ；原生 Frontend KV 路由与 Gateway API Inference Extension（GAIE）/EPP 两条路径，决定由谁拥有 ingress、超时与重试。
- AICR 流程强制「先快照集群→生成菜谱→渲染捆绑→部署→校验」再装应用级 DynamoGraphDeployment，把运行时与业务图解耦。
NVIDIA 开发者博客在 2026年10月30日 发布了一篇偏平台工程的长文：如何用 NVIDIA AI Cluster Runtime（AICR） 为 NVIDIA Dynamo 构建「经验证」的 Kubernetes 运行时。表面是 Helmfile/GitOps 操作说明；真正的新闻是——在 AI 工厂叙事里，推理服务的瓶颈正从「图怎么声明」下沉到「图下面那一层运行时能否被钉死、复现、校验」。 DynamoGraphDeployment 只是栈顶；驱动、DRA、绑核调度、节点健康与指标面不齐，模型行为测试就会被基础设施排障吞掉。
[1]文中把 AICR 菜谱写成可复现工件：钉死组件版本、兼容约束、校验期望，以及节点选择器/污点容忍等环境事实。以 AICR v1.0.0 在 Amazon EKS、面向 GB200/GB300 NVL72 的 Dynamo 推理菜谱为例，列出了 GPU Operator v26.7.1、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 等 Helm chart 版本——这不是「随便 helm install」的口号，而是把兼容矩阵产品化。Dynamo 1.4 起默认发现路径不再依赖 NATS（可选用），请求面与 KV 事件面分离：请求默认 TCP，vLLM worker 经本地 ZMQ 发布原始 KV 事件，再由 Dynamo worker 运行时规范化后进入事件面，供路由决策使用。
[1]可核对的机制有两块。其一是路由分权。 Path 1：Dynamo Frontend（DYN_ROUTER_MODE=kv）做分词、按前缀重叠与负载打分并派发，适合模型专用端点、最小拓扑。Path 2：agentgateway 解析 HTTPRoute→InferencePool，Dynamo EPP 经 GAIE 接口做 KV 感知选端，Gateway 负责实际转发；worker 旁路 Frontend sidecar 以 --router-mode direct 执行选择而不二次路由——适合平台统一管共享 ingress 的超时/重试/回退。其二是校验门禁。 aicr validate 在部署与一致性阶段检查 GPU Operator/Dynamo 健康、DRA、绑核调度、Prometheus 指标与 Gateway 就绪；应用图只有在这些检查通过后才安装。文中还提示：用预测性 KV 状态会因驱逐而漂移，AICR 配置启用 live events，使两条路径都基于 worker 上报状态路由。Outlook：Dynamo 1.5 计划用原生 Rust EPP 替换 Go/CGO 桥，降低单请求 EPP 开销。
钢人反驳一：菜谱降低安装摩擦，但「经验证」仍是厂商在指定平台/硬件上的联测——换发行版、驱动分支或自研调度器后，校验通过不等于生产 SLA。钢人二：GAIE/EPP 路径引入更多 CRD 与 sidecar，对只需要模型专用 Service 的应用团队可能过重；Frontend 路径更小，却把超时与回退留在 Dynamo 侧，平台标准可能分裂。钢人三：文中性能校验（performance validation）故意与部署校验拆开，因为会占用 GPU——这意味着「菜谱绿灯」仍未覆盖吞吐/时延合约。
[1]对平台团队，这篇把争论从「选 vLLM 还是 TensorRT-LLM」推到「谁拥有 ingress 与 KV 事件面、以及运行时是否可审计地复现」。对做长会话 agent 的应用团队，前缀命中与 prefill/decode 分离（disaggregated serving）是否可独立扩缩，取决于事件面与调度语义是否真的装上——而不是 CRD YAML 写得漂不漂亮。采购若只买「Dynamo 支持」而不买运行时菜谱与校验门禁，会重复「图已提交、节点却不健康」的旧故事。
[1]未来六个月应看三件事：AICR 菜谱是否从 EKS/GB200 样例扩到更多发行版与加速器且保持钉死矩阵可读；Dynamo 1.5 Rust EPP 是否在共享 ingress 场景成为默认且可观测开销下降；以及有多少团队把 aicr validate 的部署/一致性报告纳入变更门禁，而不是只在博客复现一次。若生产 Dynamo 越来越取决于「可验证运行时」而非「能提交一张图」，则 AICR 这类菜谱会从可选加速器变成默认采购附件。