AWS SageMaker führt GPU-Partitionierung für effizienteres Model-Hosting ein
Amazon SageMaker Inference unterstützt jetzt die NVIDIA Multi-Instance-GPU-Partitionierung. Damit können mehrere Modelle über hardwareisolierte Partitionen eine physische GPU gemeinsam nutzen. Laut AWS können Kunden so mehr Modelle bereitstellen, die passende Kapazität auswählen und auf die Verwaltung eines Kubernetes-Stacks zur GPU-Partitionierung verzichten.
- SageMaker Inference unterstützt jetzt die NVIDIA-MIG-GPU-Partitionierung.
- Eine GPU kann je nach Beschleuniger in bis zu sieben isolierte Instanzen aufgeteilt werden.
- Die Funktion arbeitet mit Inference Components auf verwalteten Endpunkten.
- Laut AWS kann die Partitionierung die Auslastung verbessern und Modelle passenden, kleineren GPU-Slices zuordnen.
- Das Aufteilen der Beschleuniger verlängerte die Bereitstellung in AWS-Tests um rund 17 Sekunden.
Eine GPU für mehrere Modelle gemeinsam nutzen
Vor dieser Unterstützung war beim Bereitstellen eines Modells auf einem GPU-Endpunkt eine komplette Beschleunigerkarte die kleinste verfügbare GPU-Ressource. AWS nennt als Beispiel eine ml.p4d.24xlarge-Instanz mit acht A100-GPUs. Nach dem bisherigen Modell konnte sie acht Modelle hosten, selbst wenn die einzelnen Modelle deutlich weniger als den verfügbaren GPU-Speicher benötigten.
Die GPU-Partitionierung nutzt NVIDIA Multi-Instance GPU, kurz MIG, um einen physischen Beschleuniger in unabhängige Partitionen aufzuteilen. Jede Partition erhält einen festen Anteil der Rechenleistung und einen dedizierten Speicherblock, wobei die Isolation hardwareseitig durchgesetzt wird. Dadurch können Kunden verschiedene Modelle in separaten Partitionen platzieren und einen Teil eines neueren Beschleunigers nutzen, statt zwischen einer kompletten älteren GPU und einer kompletten neueren GPU wählen zu müssen.
NVIDIA MIG kann eine GPU je nach Beschleuniger in bis zu sieben Instanzen aufteilen. AWS zufolge bieten die Partitionen vorhersehbare Latenzen, Fehlereingrenzung, bedarfsgerecht dimensionierte Kapazität, keine durch Verdrängung verursachten Kaltstarts von Modellen sowie hardwareseitig durchgesetzte Mandantenisolation. Auch unterschiedlich große Partitionen können auf einem Gerät kombiniert werden.
Verwaltete Alternative zu bisherigen Lösungen
AWS beschreibt drei Ansätze, die Kunden verwendet haben, wenn sie mehr Modelle als Beschleuniger haben. Sie können weniger, größere Endpunkte betreiben und Anfragen bündeln, was jedoch nur funktioniert, wenn die Modelle austauschbar sind. Sie können Multi-Model-Endpunkte einsetzen, die Modelle bei Bedarf laden und entladen, aber keine Geräteisolation bieten und bei der ersten Nutzung eine Ladeverzögerung verursachen können. Oder sie können selbst verwaltetes Kubernetes betreiben, bei dem MIG unter anderem die Verwaltung von Treiberversionen, die Partitionskonfiguration, Geräte-Plugins und die Konsistenz der Flotte erfordert.
Bei der GPU-Partitionierung in Amazon SageMaker AI wählen Kunden ein Partitionsprofil für ein Modell aus, während SageMaker AI die GPU-Konfiguration, die Platzierung und die Skalierung übernimmt. Die Funktion arbeitet mit Endpunkten, die Inference Components verwenden. Diese ermöglichen es, mehrere Modelle auf einem Endpunkt mit separat zugewiesener Rechenleistung auszuführen. Endpunkte mit nur einem Modell, serverlose Endpunkte und heterogene Instanzpools können nicht partitioniert werden.
Salesforce half dabei, die Anforderungen zu definieren und die erste Implementierung zu validieren. Richard Chang, Software-Engineering-Architekt bei Salesforce, sagte, MIG könne dem Unternehmen helfen, „Workloads sicher zu konsolidieren, die GPU-Auslastung deutlich zu verbessern, Inferenzkosten zu senken und eine vorhersehbare Leistung sowie eine starke Isolation aufrechtzuerhalten.“
So funktionieren Konfiguration und Kapazität
Die Funktion ergänzt bestehende API-Aufrufe um zwei optionale Felder. AcceleratorPartitionLayouts wird bei einer Produktionsvariante in CreateEndpointConfig angegeben und legt fest, wie jeder Beschleuniger aufgeteilt wird. AcceleratorPartitionType wird bei einer Inference Component angegeben und bestimmt die von ihrem Modell verwendete Partition. Laut AWS gibt es keine neuen API-Operationen, Ressourcentypen oder IAM-Aktionen. Endpunkte, bei denen beide Felder fehlen, verhalten sich wie bisher.
Im Beispiel von AWS wird eine A100 in die Partitionen mig-4g.20gb, mig-2g.10gb und mig-1g.5gb aufgeteilt. Da jede A100 über sieben Rechenslices verfügt, nutzt das Layout alle sieben. Auf einer ml.p4d.24xlarge-Instanz entstehen dadurch 24 Partitionen, jeweils acht von jedem Typ.
Jede Kopie einer Inference Component belegt eine Partition des angeforderten Typs. Durch die Erhöhung von CopyCount können zusätzliche Kopien auf freien Partitionen platziert werden. Laut AWS kann dies einem kleinen Modell helfen, eine höhere Parallelität zu bewältigen. Der Aufruf bleibt unverändert, da InvokeEndpoint das Modell über den Namen der Inference Component adressiert.
Partitionslayouts werden bei der Erstellung eines Endpunkts ausgewählt. Ein Modell, das mehr als eine GPU benötigt, erfordert weiterhin ganze Geräte. AWS maß beim Aufteilen der Beschleuniger rund 17 Sekunden zusätzliche Bereitstellungszeit, getrennt vom normalen Start der Instanz und dem Abruf des Container-Images. Für Nutzer bedeutet die Änderung eine granularere GPU-Zuweisung und verwaltete Hardwareisolation. Zu den im Ausgangstext genannten Vorteilen zählen eine bessere Auslastung, die passendere Zuordnung von Kapazität und eine klarere Kostenzuordnung.
