AWS ergänzt SageMaker-Inferenzendpunkte um NVIDIA-GPU-Partitionierung

Amazon Web Services (AWS) kündigte am 6. November 2026 die Unterstützung von NVIDIA Multi-Instance GPU für Amazon SageMaker Inference an. Damit können sich mehrere hardwareseitig isolierte Modelle auf Echtzeit-Endpunkten einen Beschleuniger teilen, anstatt jeder Bereitstellung eine vollständige GPU zuzuweisen.

Die Funktion beseitigt zwei Einschränkungen der Zuweisung ganzer GPUs. Die Anzahl der Beschleuniger begrenzt, wie viele Modelle eine Instanz hosten kann – unabhängig davon, wie wenig Speicher oder Rechenleistung jedes Modell benötigt. Kundinnen und Kunden, die einen neueren GPU-Typ in Betracht ziehen, müssen zudem das gesamte Gerät zuweisen. Multi-Instance GPU (MIG) weist jeder Partition stattdessen einen festen Anteil der Recheneinheiten und einen eigenen Speicherblock zu; die Isolation wird durch Hardware sichergestellt. Da jedes Modell geladen bleibt, entfällt außerdem die Verzögerung, die entsteht, wenn ein Endpunkt mit mehreren Modellen ein Modell für die erste Verwendung auf das gemeinsam genutzte Gerät lädt.

Die Partitionierung ist auf Echtzeit-Endpunkte beschränkt, die Inferenzkomponenten verwenden. Dabei handelt es sich um ein SageMaker-Konstrukt, mit dem mehrere Modelle auf einem Endpunkt bereitgestellt und die jeweils zugewiesenen Rechenressourcen festgelegt werden. Endpunkte mit nur einem Modell, serverlose Endpunkte und heterogene Instanzpools können nicht partitioniert werden. Auch asynchrone Workloads werden nicht unterstützt, da sich bei asynchronen Aufrufen keine Inferenzkomponente adressieren lässt.

Salesforce half bei der Festlegung der Anforderungen und der Validierung der ersten Implementierung. Richard Chang, Software-Engineering-Architekt bei Salesforce, sagte, das Unternehmen erwarte, mit MIG Workloads sicher konsolidieren, die GPU-Auslastung verbessern und die Inferenzkosten senken zu können, während eine vorhersehbare Leistung und Isolation erhalten bleiben. Salesforce bereitet derzeit die Validierung der Software anhand repräsentativer Produktions-Workloads vor. Bei diesen Vorteilen handelt es sich daher um Erwartungen und nicht um Ergebnisse aus dem Produktionseinsatz.

Zwei API-Felder steuern die Partitionierung

Die Entwicklerdokumentation zu SageMaker AI beschreibt zwei optionale Felder: AcceleratorPartitionLayouts legt die Aufteilung für eine Produktionsvariante fest, und AcceleratorPartitionType wählt das von einer Inferenzkomponente verwendete Profil aus. Es gibt keine neuen API-Operationen, Ressourcentypen oder AWS-IAM-Aktionen. Werden beide Felder weggelassen, bleibt das bisherige Verhalten des Endpunkts erhalten.

Das ausgewählte Layout gilt einheitlich für jeden Beschleuniger auf jeder Instanz der Variante. Im Beispiel von AWS wird jede der acht A100-GPUs auf einem ml.p4d.24xlarge in mig-4g.20gb, mig-2g.10gb und mig-1g.5gb Partitionen aufgeteilt, sodass sich über den Endpunkt insgesamt 24 Partitionen ergeben. Jede Kopie einer Inferenzkomponente belegt eine angeforderte Partition, während InvokeEndpoint Modelle weiterhin anhand des Komponentennamens und ohne Partitionskennung adressiert. AWS zufolge verlängerte die Aufteilung der Beschleuniger die Bereitstellung in Tests um etwa 17 Sekunden.

Die Isolation umfasst die GPU-Rechenleistung und den GPU-Speicher, nicht jedoch den gesamten Host. Modelle auf derselben Instanz nutzen weiterhin gemeinsam die Host-CPU, den Host-Speicher, den Speicherplatz, das Netzwerk und das Routing des Endpunkts. Eine Komponente, die ein im Layout nicht vorhandenes Profil anfordert, wird abgewiesen, statt eine vollständige GPU zu erhalten. Um das Layout eines laufenden Endpunkts zu ändern, ist ein neuer Endpunkt erforderlich; außerdem muss der Datenverkehr migriert werden. Soll eine Komponente ein anderes Profil nutzen, muss eine neue Komponente erstellt werden.

AWS testet eine H100-Partition im Vergleich zu einer vollständigen A100

AWS verglich eine mig-3g.40gb H100-Partition mit einer vollständigen A100-40GB und verwendete dafür Llama-3.1-8B-Instruct auf SageMaker-Echtzeit-Endpunkten in der Produktion. Auf beiden Seiten kamen jeweils eine Modellreplik, identische Container, Tokenizer und Client-Konfigurationen zum Einsatz. genai-bench erzeugte fünf Verkehrsmuster bei Parallelitätsstufen von 2 bis 512. Der Profilleitfaden von NVIDIA weist dem getesteten H100-Profil drei von sieben Anteilen der Streaming-Multiprozessoren und vier von acht Speichereinheiten zu. Die beiden Konfigurationen verfügen über eine vergleichbare Speicherkapazität, unterscheiden sich jedoch bei der Rechenleistung.

Über alle Tests hinweg meldete AWS für die H100-Partition bei der Last, bei der das Kostennutzenverhältnis des jeweiligen Szenarios am größten war, eine um 53 % bis 89 % höhere Zahl ausgegebener Token pro Sekunde. Die Latenz zwischen den Token war um 8,9 % bis 42,1 % niedriger, die Zeit bis zum ersten Token um 5,6 % bis 47,5 %. Bei der höchsten Parallelität in Workloads mit 6.000 und 8.000 Token verfehlte die A100 bei einem Drittel bis zur Hälfte der Anfragen die Bereitstellungsfrist, während die Partition keine einzige Anfrage verfehlte.

Die Kostenanalyse von AWS, die als Einzelfallvergleich und nicht als allgemeingültiges Fazit präsentiert wurde, ergab ab einem workloadspezifischen Break-even-Punkt um 18 % bis 34 % niedrigere Kosten pro einer Million ausgegebener Token. Dieser Punkt lag bei einer Parallelität von 64 für Prompts mit 100 Token und bei einer Parallelität von 4 für Prompts mit 8.000 Token. Darunter blieb die vollständige A100 günstiger. Für Workloads mit kurzen Eingaben oder geringer Parallelität könnte daher die ältere GPU als vollständiges Gerät besser geeignet sein. Für den Vergleich der Stückkosten wurden die On-Demand-Preise der Instanzen durch die Anzahl der getesteten Einheiten auf jeder Instanz geteilt.

Unterstützte Hardware und Betriebsgrenzen

Zum Start werden vier Instanzfamilien unterstützt. Die Anzahl der Partitionen und die verfügbaren Profile hängen vom jeweiligen Beschleuniger ab:

Die GPU-Partitionierung ist in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt) und Europe (Ireland) verfügbar, vorbehaltlich der regionalen Verfügbarkeit von Instances und des Endpoint-Kontingents. Da sich keine Partition über mehrere Beschleuniger erstreckt, benötigen Modelle, die eine vollständige GPU oder mehrere GPUs erfordern, weiterhin ganze Geräte.

Kunden zahlen weiterhin den Preis für die vollständige GPU-Instance. Durch die Partitionierung lässt sich zwar die nutzbare Kapazität erhöhen, der Stundenpreis sinkt dadurch jedoch nicht. Für partitionierte Endpoints und ihre Inferenzkomponenten werden außerdem keine Auslastungsmetriken für GPU, CPU oder Arbeitsspeicher in CloudWatch veröffentlicht; Aufruf- und Latenzmetriken bleiben jedoch verfügbar. Bei P4d erfordert das mig-1g.10gb Profil den NVIDIA-Treiber R525 oder eine neuere Version. AWS empfiehlt Kunden eine neuere Inferenz-AMI, da das Standardimage diesen Treiber nicht enthält.

Für die Kapazitätsplanung bedeutet die Einführung, dass jeder unterstützte Beschleuniger in mehrere feste GPU-Größen aufgeteilt werden kann. Dichtere, hardwareisolierte Bereitstellungen gehen jedoch mit der Abrechnung der vollständigen Instance, Layouts, die sich nicht nachträglich ändern lassen, und einer eingeschränkten Auslastungstelemetrie einher. Der Benchmark von AWS zeigt, wie wichtig es ist, den tatsächlichen Datenverkehr zu messen: In diesen Tests bot die H100-Partition bei anspruchsvolleren Bedingungen mit langen Kontexten Vorteile bei Leistung und Kosten, während die Ergebnisse zum Break-even zeigten, dass eine vollständige A100 bei geringerer Auslastung günstiger war.