NVIDIA erläutert AICRs geprüfte Kubernetes-Runtime für Dynamo mit Infrastrukturkontrollen vor der Modellbereitstellung
NVIDIA erläutert am 30. Oktober 2026, wie AI Cluster Runtime (AICR) eine geprüfte Kubernetes-Grundlage für Dynamo-Inferenz aufbaut. Ein DynamoGraphDeployment beschreibt die Modellbereitstellung, stellt aber nicht automatisch passende GPU-Treiber, Ressourcenzuteilung, Scheduling, Netzwerkeingang und Überwachung sicher. AICR behandelt diese Infrastrukturebene mit versionierten Rezepten, die Dynamo und benötigte Komponenten bündeln und die Eignung eines Clusters prüfen.
NVIDIA erläutert am 30. Oktober 2026, wie AI Cluster Runtime (AICR) eine geprüfte Kubernetes-Grundlage für Dynamo-Inferenz aufbaut. Ein DynamoGraphDeployment beschreibt die Modellbereitstellung, stellt aber nicht automatisch passende GPU-Treiber, Ressourcenzuteilung, Scheduling, Netzwerkeingang und Überwachung sicher. AICR behandelt diese Infrastrukturebene mit versionierten Rezepten, die Dynamo und benötigte Komponenten bündeln und die Eignung eines Clusters prüfen. Der Beitrag beschreibt Runtime-Installation und Validierung, keine Ausbildung eines neuen Modells und keinen gemessenen Durchsatzgewinn einer bestimmten Anwendung.
Der Artikel unterscheidet zwei Wege für Anfragen. Beim einfachen Weg steht ein Dynamo Frontend hinter einem Kubernetes Service. Mit KV-Routing zerlegt das Frontend die Anfrage in Tokens, bewertet gemeinsame Präfixe und aktuelle Last, wählt einen Worker und sendet die Anfrage selbst dorthin. Das passt zu einem modellbezogenen Endpunkt oder einem vorhandenen Proxy, der nur an das Frontend weiterleitet. Der zweite Weg nutzt Kubernetes Gateway API und Inference Extension. Ein HTTPRoute zeigt auf einen InferencePool, den der Dynamo-Operator aus dem DynamoGraphDeployment erzeugt. Das Gateway ruft den Dynamo EPP auf, der anhand von KV-Informationen einen Worker auswählt und Routingdaten zurückgibt. Erst das Gateway transportiert die HTTP-Anfrage zum Frontend-Sidecar des ausgewählten Workers. Endpunktauswahl und tatsächliche Weiterleitung sind unterschiedliche Aufgaben.
Beide Wege können hinter einem HTTPRoute liegen. Der Unterschied lautet daher nicht einfach „mit oder ohne Gateway“, sondern wer Transport, Zeitüberschreitungen, Wiederholungen und Fallback zum Worker verwaltet: das Dynamo Frontend im ersten Fall, das Gateway im zweiten. Der zweite Weg benötigt zusätzlich ein kompatibles Gateway, InferencePool, EPP und Worker-Sidecars. NVIDIA nennt den ersten die kleinere und in Produktion bewährtere Topologie. Der zweite behandelt die vom Operator verwaltete DynamoGraphDeployment-Integration, nicht den experimentellen eigenständigen Zugang für vanilla vLLM. Dynamo 1.4 verwendet für den EPP ein Go-Framework mit per CGO eingebettetem Rust-KV-Router. Ein nativer Rust EPP ist eine Aussicht für Dynamo 1.5 und nicht schon Teil des beschriebenen 1.4.2-Rezepts.
Agentenunterhaltungen wiederholen oft lange Präfixe aus Systemanweisungen, Werkzeugdefinitionen und Verlauf. Ein Worker mit passenden KV-Cache-Blöcken kann erneute Verarbeitung sparen. Worker veröffentlichen Cache-Ereignisse lokal über ZMQ; Dynamo normalisiert sie und verteilt sie auf seinem Ereignisplan weiter. Der Anfrageplan nutzt standardmäßig TCP, der KV-Ereignisplan ZMQ. Beide Routingwege können die von Workern gemeldete aktuelle Cache- und Lastlage verwenden. Eine Vorhersage der Cache-Lage ist ebenfalls einstellbar, übersieht aber möglicherweise Verdrängungen und kann laut NVIDIA von der Wirklichkeit abweichen. Der Text behandelt außerdem die Trennung von prefill und decode; wie oft der Cache verfehlt wird, hängt von der tatsächlichen Last ab und ist nicht aus dem Architekturdiagramm abzulesen.
AICR führt durch geordnete Schritte. aicr snapshot erfasst den Cluster. aicr recipe wählt auf dieser Grundlage ein Dynamo-Inferenzrezept mit festgelegten Versionen, Plattformbedingungen und Prüfungen. Im AICR-v1.0.0-Beispiel für Amazon EKS auf GB200 NVL72 und GB300 NVL72 ist Dynamo Platform auf Chart-Version 1.4.2 festgelegt. Diese getesteten Komponenten gelten für die Beispielplattform und sind keine allgemeine Aussage über neueste Versionen. Eine optionale Offlineprüfung kann ein Rezept mit einem anderen gespeicherten Snapshot vergleichen; ohne Live-Cluster bleiben Verhaltensprüfungen aus. Danach erzeugt aicr bundle Helm-Werte und Manifeste, die Runtime wird ausgebracht und aicr validate prüft Deployment und Konformität im echten Cluster. Erst danach wird das DynamoGraphDeployment der Anwendung installiert.
Typische Prüfungen betreffen GPU-Kapazität und nvidia-smi, GPU Operator und Dynamo, DRA-Zugang, Gang-Scheduling und Autoscaling, Prometheus-Metriken sowie Gateway-Bereitschaft für Kubernetes-native Eingänge. NVIDIA trennt Performance-Validierung ausdrücklich ab, weil diese einen vorübergehenden Serving-Workload startet und GPU-Ressourcen verbraucht. Ein bestandener Infrastrukturtest belegt daher keinen Anwendungsdurchsatz. Die Prüfungen unterscheiden sich je nach Rezept, und der Beitrag beweist nicht, dass unser oder ein fremder Cluster sie bestanden hat. Der Nutzen liegt im reproduzierbaren Ablauf von Clusteraufnahme über feste Versionen bis zur Live-Prüfung der installierten Grundlage.
Sources
FAQ
Wer wählt und wer transportiert Anfragen auf Frontend- beziehungsweise Gateway/EPP-Weg?
Auf dem Frontend-Weg wählt Dynamo Frontend den Worker anhand von Präfix-Cache und Last aus und leitet die Anfrage selbst weiter. Auf dem Gateway/EPP-Weg ruft das Gateway EPP auf; EPP wählt nur den Endpunkt und meldet Routingdaten, während das Gateway die HTTP-Anfrage zum Worker-Sidecar transportiert. Beide Wege können hinter HTTPRoute liegen; die Transportverantwortung unterscheidet sich.
Welche AICR-Schritte führen vom Cluster-Snapshot zur Modellbereitstellung?
aicr snapshot erfasst zuerst den Cluster, aicr recipe wählt danach eine Dynamo-Inferenzkonfiguration mit festen Versionen. Ein optionaler Offlinevergleich mit einem anderen Snapshot führt keine Verhaltensprüfungen aus. aicr bundle rendert Helm-Ressourcen, die Runtime wird installiert und aicr validate prüft Deployment und Konformität im Live-Cluster. Erst danach folgt das DynamoGraphDeployment der Anwendung.
Beweist bestandene Deployment- und Konformitätsvalidierung die Inferenzleistung?
Nein. Deployment und Konformität prüfen GPU, Treiber, DRA, Scheduling, Überwachung und Netzwerkeingang; genaue Punkte hängen vom Rezept ab. NVIDIA trennt die Leistungsvalidierung, weil sie einen temporären Inferenz-Workload startet und GPUs nutzt. Der Text belegt weder das Bestehen eines fremden Clusters noch einen bestimmten Anwendungsdurchsatz.