Wer NVIDIA Nemotron 3.5 Super VL mit dem AWS-Beispiel auf Kubernetes betreiben will, braucht Zugriff auf EC2-Instanzen vom Typ P5en.48xlarge oder P6-b200.48xlarge, Git und Docker auf einem Terminal sowie AWS-Berechtigungen für EC2, EKS und FSx for Lustre. Der Standard-EKS-Einstieg führt von der Regionskonfiguration über einen Hilfscontainer und ein Cluster-Manifest bis zur Kontrolle der Knoten. Die AWS-Anleitung enthält diese Voraussetzungen und die einzelnen Startschritte.

AWS beschreibt drei Orchestrierungswege: Standard-Amazon EKS, Amazon EKS Auto Mode und SageMaker HyperPod EKS. Nemotron 3.5 Super VL hat 120 Milliarden Parameter, von denen pro Token 12 Milliarden aktiv sind. Das Modell verarbeitet Text, Bilder, Dokumente und Videos, gibt Text aus und unterstützt laut AWS einen Kontext von bis zu einer Million Tokens. (AWS-Beitrag; technischer Bericht von NVIDIA)

Voraussetzungen für den Beispiel-Workflow

Für den AWS-Beispiel-Workflow müssen die genannten GPU-Instanzen für dein Konto zugänglich sein. AWS weist darauf hin, dass dafür eine Erhöhung des Kontingents oder eine Kapazitätsreservierung nötig sein kann. Auf dem lokalen Terminal müssen Git und Docker installiert sein. Die verwendeten AWS-Zugangsdaten benötigen Rechte zur Verwaltung von EC2, EKS und FSx for Lustre.

Die GPU-Zahlen weiter unten sind Mindestwerte für das Modell-Serving mit vLLM. Sie ersetzen weder die Planung des gesamten Clusters noch die Prüfung, ob dein Konto die benötigten Ressourcen starten kann.

Die ersten Schritte mit Standard-EKS

Der Beispiel-Workflow führt zunächst bis zum Erstellen des Clusters und zur Prüfung seiner Knoten. AWS nennt für das Erstellen bis zu 30 Minuten. Gehe in dieser Reihenfolge vor:

  1. Repository klonen. Führe git clone https://github.com/aws-samples/aws-do-eks aus und wechsle mit cd aws-do-eks in den Ordner. So stehen die Hilfsskripte des Beispiels bereit.
  2. AWS-Region konfigurieren. Starte ./config.sh und setze in der .env-Datei AWS_DEFAULT_REGION auf die gewünschte Cluster-Region.
  3. Hilfscontainer erstellen. Führe ./build.sh aus. Das Skript baut lokal das Docker-Image aws-do-eks mit Werkzeugen und Automatisierung für die Clusterverwaltung.
  4. Container starten. Starte ihn mit ./run.sh, damit die weiteren Einrichtungsschritte in der vorgesehenen Umgebung laufen.
  5. Containerstatus prüfen. Führe ./status.sh aus und kontrolliere, dass der Container läuft.
  6. Shell im Container öffnen. Mit ./exec.sh erhältst du die Shell mit AWS CLI, eksctl, kubectl und weiteren Hilfswerkzeugen.
  7. AWS-Zugangsdaten konfigurieren. Starte in der Container-Shell aws configure und folge den Eingaben für Zugangsschlüssel, Region und Ausgabeformat.
  8. Cluster-Manifest auswählen. Führe ./env-config.sh aus und wähle in der Konfiguration das gewünschte Manifest.
  9. Clusterparameter bearbeiten. Mit ./eks-config.sh öffnest du das Manifest, in dem sich unter anderem Clustername, Region und Instanztyp festlegen lassen.
  10. Cluster erstellen. Starte ./eks-create.sh. Das Skript erstellt den Cluster auf Grundlage der gewählten Konfiguration; laut AWS kann dieser Schritt bis zu 30 Minuten dauern.
  11. Knoten auflisten. Prüfe das Ergebnis mit kubectl get nodes. AWS nennt diesen Befehl als Kontrolle nach dem Erstellen des Clusters.

Damit ist der Einstieg in den Cluster erledigt. Der weitere AWS-Workflow umfasst zusätzliche Treiber und Operatoren, eine Clusterprüfung, das Laden der Modellgewichte, die Bereitstellung des Modells, Tests, Benchmarks und das Entfernen der angelegten Ressourcen.

Orchestrierung und GPU-Minima für vLLM

Bei Standard-EKS legt der Beispielpfad ein Cluster-Manifest an. Amazon EKS Auto Mode übernimmt laut AWS die Verwaltung von Skalierung, GPU-Unterstützung und Elastic Fabric Adapter (EFA). SageMaker HyperPod EKS ist die dritte aufgeführte Orchestrierungsoption. AWS verwendet für die Modellbereitstellung dieselben Kubernetes-Manifeste über diese Wege hinweg.

Die Referenzarchitektur verteilt Aufgaben auf CPU- und GPU-Knoten. Amazon ECR speichert Container-Images, ein gemeinsames Amazon-FSx-for-Lustre-Dateisystem hält die Modellgewichte, und EFA verbindet die GPU-Knoten. Für den Modellserver nennt die Beispielanleitung NVIDIA Dynamo mit vLLM als Backend. Als weitere Konfigurationsentscheidungen führt sie BF16 oder NVFP4, aggregiertes oder disaggregiertes Serving sowie EBS zusammen mit FSx oder FSx allein auf.

GPU-ModellBF16: minimale GPU-ZahlNVFP4: minimale GPU-Zahl
B200/GB20082
B300/GB30041
H20084
H100168

Die Mindestzahlen stammen aus AWS' vLLM-Konfigurationen für die jeweilige Präzision. Sie beschreiben die benötigten GPUs für das Serving des Modells, nicht die vollständige Infrastruktur oder deren Kosten.

AWS' Latenzvergleich und seine Bedingungen

AWS berichtet für einen Test mit disaggregiertem Serving eine niedrigere Zeit bis zum ersten Token (TTFT) und eine ungefähr gleiche Inter-Token-Latenz (ITL) wie beim aggregierten Serving. Die Bedingungen im Diagramm: BF16 auf H200-GPUs, 1.024 Eingabe- und 512 Ausgabetokens, eine Nebenläufigkeit von 1 bis 128 und ein Durchlauf je Messpunkt. Die aggregierte Konfiguration nutzt 8 GPUs, die disaggregierte 16 GPUs. Da die GPU-Zahl unterschiedlich ist, lässt sich der Effekt der Topologie aus diesem Vergleich nicht isoliert ableiten. (AWS' technischer Beitrag)

TTFT misst die Zeit bis zur Ausgabe des ersten Tokens; ITL bezeichnet den Abstand zwischen aufeinanderfolgenden Tokens. AWS nennt NVIDIA aiperf zur Messung von TTFT, ITL und Durchsatz bei verschiedenen Werten für die Nebenläufigkeit. Ein NCCL-All-reduce-Mikrobenchmark prüft die Funktion von Cluster und Netzwerk. AWS zufolge sprechen dabei Aktivitäten auf allen GPUs und Datenverkehr über die EFA-Adapter dafür, dass der Cluster wie erwartet arbeitet.

Für die eigene Kapazitätsplanung empfiehlt sich daher ein Benchmark mit den Ressourcen und der Anfragenlast, die für den konkreten Einsatz vorgesehen sind. AWS zufolge kann eine steigende ITL auf zusätzlichen Bedarf an Decode-Kapazität hindeuten, eine steigende TTFT auf zusätzlichen Bedarf an Prefill-Kapazität.