NVIDIA beschreibt das Kubernetes-Runtime-Rezept für Dynamo
NVIDIA sagte, dass Teams, die Dynamo auf Kubernetes einsetzen, mehr benötigen als nur das Serving-Framework selbst: Der GPU-Treiberstack, die Planungs-, Netzwerk- und Observabilitätsschichten müssen ebenfalls ausgerichtet sein, bevor ein Inferenzendpunkt zuverlässig ist. In einem technischen Beitrag, der am 30. Oktober 2026 veröffentlicht wurde, beschrieb das Unternehmen, wie sein NVIDIA KI Cluster Runtime (AICR) Dynamo mit validierten Infrastrukturrezepten verpackt, um diesen Prozess wiederholbar zu machen.
Beweise und Kontext
Der Postframe setzt Dynamo als verteiltes Inferenz-Framework vor, das die Modellbereitstellung über GPU-Arbeiter koordiniert, sagt aber, dass die darunterliegende Laufzeit ebenso wichtig ist. NVIDIA sagte, ein Produktions-Inferenzcluster müsse bestätigen, dass GPU-Operator und Treiber-Stack mit den Knoten übereinstimmen, GPU-Knoten sind beschriftet und auffindbar, Kubernetes stellt GPUs über Dynamic Resource Allocation frei, der Scheduler kann Arbeiter mit der richtigen Topologie und Gang-Scheduling-Semantik platzieren, Knoten-Gesundheitssignale sind verfügbar, bevor die Workloads landen, Prometheus ist für Metriken erreichbar und der Gateway-API-Pfad wird konfiguriert, wenn Kubernetes-native Ingress verwendet wird.
Laut dem Artikel erfasst AICR diese Anforderungen in einem Rezept. Das Rezept enthält angepinnte Komponentenversionen, Kompatibilitätsbeschränkungen, Knotenselektoren, Toleranzen, Prüfsummen und Validierungserwartungen. NVIDIA erklärte, dass das Dynamo-Rezept Version 1.4.2 des Dynamo-Plattform-Diagramms ausliefert, einschließlich des Dynamo-Operators, Laufzeitabbildungen und der nvidia.com/v1beta1 benutzerdefinierten Ressourcendefinition von DynamoGraphDeployment. Das Unternehmen erklärte, v1beta1 ersetze die frühere v1alpha1 API-Version.
Der Beitrag sagte außerdem, dass das AICR-Rezept NATS nicht mehr standardmäßig für Dynamo 1.4 installiert; stattdessen entdecken Frontends, Workers und optionale Komponenten der Gateway API Inference Extension / Endpoint Picker Plugin eins andere über Kubernetes-Ressourcen. NVIDIA sagte, NATS bleibe als Opt-in für Deployments verfügbar, die es weiterhin benötigen.
Routingpfade für Dynamo auf Kubernetes
NVIDIA beschrieb zwei Routing-Topologien. Die erste verwendet den Dynamo-Frontend-Router hinter einem Kubernetes-Service. In diesem Pfad tokenisiert das Frontend Anfragen, bewertet berechtigte Arbeiter anhand von Präfixüberlappung und aktueller Last, wählt einen Worker aus und sendet die Anfrage über Dynamos TCP-Anforderungsebene. Das Unternehmen erklärte, dies sei die kleinste Topologie und geeignet für einen modellspezifischen Endpunkt oder einen bestehenden Edge-Proxy, der den Datenverkehr nur an den Dynamo Frontend Service weiterleitet.
Der zweite Pfad integriert Dynamo mit der Gateway-API und der Gateway API Inference Extension. In dieser Topologie löst ein Gateway wie AgentGateway eine HTTPRoute in einen InferencePool um, der Betreiber erstellt diesen Pool aus der DynamoGraphDeployment und Dynamo EPP führt die token-bewusste Endend-Auswahl durch. NVIDIA sagte, das Gateway bleibt der HTTP-Proxy, während in jedem routablen Worker-Pod ein Dynamo-Frontend-Sidecar im Direktmodus läuft und die Anfrage an den Worker-Container weiterleitet.
Der Beitrag besagte, dass beide Pfade von Arbeitern veröffentlichte KV-Cache-Events für Routing-Entscheidungen verwenden. Es wurde außerdem darauf hingewiesen, dass Dynamo basierend auf dem vorhergesagten Cache-Status routen kann, die Vorhersage jedoch keine Evictions erkennen kann, sodass die Routing-Qualität unter Speicherdruck nachlassen kann. Die AICR-Konfiguration im Artikel verwendet stattdessen Live-Events.
Bereitstellungs- und Validierungsworkflow
NVIDIA hat einen fünf-Schritte-AICR-Workflow erstellt. Zuerst wird ein Cluster-Snapshot mit dem AICR-Snapshot-Befehl erstellt. Zweitens erzeugt AICR ein Rezept für die Inferenz auf der ausgewählten Plattform. Drittens wird das Laufzeitpaket in bereitstellende Manifeste und Helm-Werte gerendert. Viertens wird die Laufzeit über Helmfile oder andere unterstützte Deployer bereitgestellt. Fünftens wird die installierte Laufzeit validiert, bevor die Anwendungsarbeitslast hinzugefügt wird.
Für das Amazon EKS Dynamo Inferenzrezept für NVIDIA GB200 NVL72 und NVIDIA GB300 NVL72 Systeme listete der Beitrag angepinnte Diagrammversionen auf, darunter NVIDIA GPU Operator v26.7.1, Node Feature Discovery 0.19.0, cert-manager v1.20.2, AWS EBS CSI Driver 2.59.0 und 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 v1.5.0, Agent Gateway CRDs v1.5.0, Kube Prometheus Stack 84.4.0, Prometheus Operator CRDs 28.0.1, Prometheus Adapter 5.3.0 und Kubernetes Ephemeral Storage Metrics 1.19.2.
Validierungsprüfungen umfassen laut Artikel typischerweise die Cluster-Baseline-Gesundheit, den GPU-Operator-Status, den Zugriff auf den Beschleuniger, Gang-Planung und Autoskalierung, Beobachtbarkeit über Prometheus-gestützte Metriken sowie die Bereitschaft der Gateway-API und Agentgateway für Kubernetes-native Ingress. NVIDIA erklärte, dass die Leistungsvalidierung separat ist, da sie eine temporäre Bereitstellung bereitstellt und die getesteten GPUs verbraucht.
Das Unternehmen schloss mit der Aussage, dass AICR und Dynamo Open-Source-Komponenten der NVIDIA DSX KI Factory Platform seien, wobei Bereitstellungsbeispiele und Community-Ressourcen über die NVIDIA DSX KI Factory GitHub- und Slack-Community verfügbar sind. Es wurde auch auf praktische Workshop-Aktivitäten auf der KubeCon + CloudNativeCon Nordamerika verwiesen, obwohl der Artikel kein zukünftiges Katalysatordatum über diese Erwähnung hinaus nennt.