NVIDIA AI Cluster Runtime bündelt Dynamo in validierten Kubernetes-Rezepten

Warum die Runtime-Ebene wichtig ist

NVIDIA Dynamo ist ein verteiltes Inferenz-Framework, das das Model Serving über GPU-Worker hinweg koordiniert. Unter Kubernetes wird ein Modell über ein DynamoGraphDeployment beschrieben, das festlegt, wie vLLM, SGLang oder NVIDIA TensorRT LLM in Pods laufen sollen. Dieser Graph sei jedoch nur die Spitze des Stacks, so NVIDIA: GPU-Treiber, Ressourcenzuweisung, Scheduling, Netzwerk und Monitoring müssten zusammenspielen, und das Auflösen dieser Abhängigkeiten gehe zulasten der Zeit für Tests von Modellverhalten, Serving-Performance und Anwendungsintegration.

AICR ist Teil der NVIDIA DSX AI Factory Platform. Jedes Rezept definiert eine Konfiguration für eine bestimmte Umgebung und einen bestimmten Workload, einschließlich festgelegter Komponentenversionen, Kompatibilitätsbeschränkungen und Validierungsprüfungen. Außerdem hält das Rezept Konfigurationswerte, Node Selectors, Tolerations, Prüfsummen und Validierungserwartungen fest, um das Deployment reproduzierbar zu machen.

Was ein AICR-Dynamo-Rezept enthält

Das Rezept liefert das Chart dynamo-platform in der festgelegten Version 1.4.2 mit. Es enthält den Dynamo Operator, die Dynamo-Runtime-Images und die CustomResourceDefinition nvidia.com/v1beta1 DynamoGraphDeployment, die die bisherige API-Version v1alpha1 ablöst. Zu den von NVIDIA aufgeführten unterstützenden Komponenten zählen:

• NVIDIA GPU Operator für Treiber und GPU-Software-Stack
• Node Feature Discovery zum Labeln und Erkennen von GPU-Knoten
• DRA Driver for NVIDIA GPUs für die Kubernetes-native Dynamic Resource Allocation
• KAI Scheduler für topologiebewusste Platzierung und Gang Scheduling
• Grove zum Starten, Platzieren und Skalieren von Serving-Graphen aus mehreren Komponenten als koordinierte Gruppen
• NVSentinel und Nodewright für Signale zum Knotenzustand, sofern das gewählte Rezept sie unterstützt
• Prometheus-Stack für Metriken zu Cluster, Beschleunigern und Dynamo-Diensten
• agentgateway und Gateway-API-Ressourcen für Kubernetes-nativen Ingress

Mit Dynamo 1.4 finden sich Frontends, Worker und optionale Komponenten der Gateway API Inference Extension (GAIE) bzw. des Endpoint Picker Plugin (EPP) über Kubernetes-Ressourcen. Der Standardpfad von AICR verwendet deshalb kein NATS mehr, und das Chart dynamo-platform installiert es standardmäßig nicht mehr. NATS bleibt als Opt-in verfügbar.

Cache-bewusstes Routing und zwei Pfade

NVIDIA verweist auf agentische Workloads, die lange Token-Präfixe wie System-Prompts, Tool-Definitionen, Gesprächsverlauf und Tool-Ergebnisse wiederholt erweitern. Erreicht eine Anfrage einen Worker, dessen GPU-Speicher dieses Präfix nicht enthält, werden Zwischen-Token neu berechnet, statt wiederverwendet zu werden. Dynamo leitet Anfragen deshalb an Worker weiter, die die relevanten KV-Blöcke bereits halten. Zudem kann es Prefill und Decode trennen (Disaggregated Serving), sodass Betreiber jeden Pool für einen gegebenen Anfragemix unabhängig skalieren und abstimmen können.

In Dynamo 1.4.2 nutzt der Standardpfad von AICR unter Kubernetes TCP für Anfragen und ZMQ für KV-Cache-Ereignisse. Jeder vLLM-Worker gibt rohe KV-Cache-Ereignisse über einen lokalen ZMQ-Publisher aus. Die Worker-Runtime von Dynamo abonniert diese Quelle, normalisiert die Ereignisse und veröffentlicht sie erneut auf der Dynamo Event Plane. Beide Routing-Pfade nutzen diesen KV-Cache-Zustand.

Der erste Pfad verwendet den Dynamo-Frontend-Router. Mit DYN_ROUTER_MODE=kv tokenisiert das Frontend jede Anfrage, bewertet geeignete Worker nach Präfix-Überlappung und aktueller Last und leitet die Anfrage standardmäßig per TCP weiter. NVIDIA beschreibt ihn als geeignet für einen modellspezifischen Endpunkt in der Hand eines Anwendungsteams, als kleinste Topologie und als die in der Produktion am besten erprobte Serving-Option. Der zweite Pfad nutzt eine Kubernetes-Gateway-API-Implementierung für den Ingress und Dynamo EPP für die Endpunktauswahl und lässt sich in gemeinsam genutzten Kubernetes-Ingress integrieren. AICR liefert und validiert die Runtime für beide Topologien.

Was das für Plattform- und Anwendungsteams bedeutet

Laut NVIDIA trennt AICR die Einrichtung der Runtime vom Deployment der Anwendung, und zwar in fünf Schritten: Snapshot des Clusters erstellen, ein Dynamo-Inferenzrezept generieren, ein Deployment-Bundle rendern, die Runtime mit Helmfile oder GitOps bereitstellen und die installierte Runtime validieren, bevor Anwendungs-Workloads installiert werden.

Für Plattformteams bietet das einen wiederholbaren Weg, die Runtime bereitzustellen und zu prüfen. Entwicklern liefere es nach Angaben von NVIDIA ein einheitliches Fundament zum Ausliefern von Modellen und zum Testen von Anwendungen. Für den weiteren Austausch und Workshops verweist NVIDIA auf die Repositories von AICR und Dynamo sowie auf die Slack-Community der DSX AI Factory.