Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Modellbereitstellung mit Triton Inference Server
Triton Inference Server
Die SageMaker Triton-Container helfen Ihnen bei der Bereitstellung von Triton Inference Server auf der SageMaker Hosting-Plattform, um trainierte Modelle in der Produktion bereitzustellen. Es unterstützt die verschiedenen Betriebsmodi. SageMaker Eine Liste der verfügbaren Triton Inference Server-Container, die auf verfügbar sind SageMaker, finden Sie unter NVIDIATriton Inference Containers (nur SM-Unterstützung)
Hosting-Modi
Die folgenden SageMaker Hosting-Modi werden von Triton-Containern unterstützt:
-
Endpunkte für ein einzelnes Modell
-
Dies SageMaker ist der Standardbetriebsmodus. In diesem Modus kann der Triton-Container ein einzelnes Modell oder ein einzelnes Ensemble-Modell laden.
-
Der Name des Modells muss als Eigenschaft der Container-Umgebung übergeben werden, die Teil des
CreateModel
SageMaker API Aufrufs ist. Die Umgebungsvariable, die zur Übergabe des Modellnamens verwendet wird, istSAGEMAKER_TRITON_DEFAULT_MODEL_NAME
.
-
-
Endpunkte eines einzelnen Modells mit Ensemble
-
Triton Inference Server unterstützt ein Ensemble, bei dem es sich um eine Pipeline oder einen DAG (gerichteten azyklischen Graphen) von Modellen handelt. Während ein Ensemble technisch gesehen aus mehreren Modellen besteht, SageMaker kann es im standardmäßigen Einzelmodell-Endpunktmodus das eigentliche Ensemble (das Metamodell, das die Pipeline darstellt) als das zu ladende Hauptmodell behandeln und anschließend die zugehörigen Modelle laden.
-
Zum Laden des Modells muss der Modellname des eigentlichen Ensembles verwendet werden. Es muss als Eigenschaft der Container-Umgebung übergeben werden, die Teil des
CreateModel
SageMaker API Aufrufs ist. Die Umgebungsvariable, die zur Übergabe des Modellnamens verwendet wird, istSAGEMAKER_TRITON_DEFAULT_MODEL_NAME
.
-
-
Multimodell-Endpunkte
-
In diesem Modus SageMaker können mehrere Modelle auf einem einzigen Endpunkt bedient werden. Sie können diesen Modus verwenden, indem Sie die Umgebungsvariable
‘MultiModel’: true
als Eigenschaft der Container-Umgebung angeben, die Teil desCreateModel
SageMaker API Aufrufs ist. -
Standardmäßig wird beim Start der Instance kein Modell geladen. Um eine Inferenzanforderung für ein bestimmtes Modell auszuführen, geben Sie die
*.tar.gz
Datei des entsprechenden Modells als Argument für dieTargetModel
Eigenschaft desInvokeEndpoint
SageMaker API Aufrufs an.
-
-
Endpunkte mit mehreren Modellen und Ensemble
-
In diesem Modus SageMaker funktioniert es wie für Endpunkte mit mehreren Modellen beschrieben. Der SageMaker Triton-Container kann jedoch mehrere Ensemble-Modelle laden, was bedeutet, dass mehrere Modell-Pipelines auf derselben Instanz ausgeführt werden können. SageMaker behandelt jedes Ensemble als ein Modell, und das eigentliche Ensemble jedes Modells kann aufgerufen werden, indem das entsprechende
*.tar.gz
Archiv als angegeben wird.TargetModel
Für eine bessere Speicherverwaltung während des dynamischen Speichers
LOAD
undUNLOAD
empfehlen wir, die Ensemblegröße klein zu halten.
-
Inferenz-Payload-Typen
Triton unterstützt zwei Methoden zum Senden einer Inferenz-Payload über das Netzwerk – json
und binary+json
(oder binär codiertes JSON). Die JSON Nutzlast umfasst in beiden Fällen den Datentyp, die Form und den eigentlichen Inferenzanforderungstensor. Der Anforderungstensor muss ein binärer Tensor sein.
Bei dem binary+json
Format müssen Sie die Länge der Anforderungsmetadaten im Header angeben, damit Triton die binäre Nutzlast korrekt analysieren kann. Im SageMaker Triton-Container erfolgt dies mithilfe eines benutzerdefinierten Headers:. Content-Type
application/vnd.sagemaker-triton.binary+json;json-header-size={}
Dies unterscheidet sich von der Verwendung des Inference-Header-Content-Length
Headers auf einem eigenständigen Triton Inference Server, da benutzerdefinierte Header nicht zulässig sind. SageMaker
Verwenden Sie config.pbtxt, um die Modellkonfiguration festzulegen
Wenn Triton Inference Server aktiviert sind SageMaker, muss jedes Modell eine config.pbtxt
Datei enthalten, die mindestens die folgenden Konfigurationen für das Modell spezifiziert:
-
name
: Für Modelle, die außerhalb von laufen, ist dies zwar optional SageMaker, wir empfehlen jedoch, immer einen Namen für die Modelle anzugeben, auf denen Triton ausgeführt werden soll. SageMaker -
platform
und/oderbackend
: Die Einrichtung eines Backends ist wichtig, um den Typ des Modells zu spezifizieren. Einige Backends haben eine weitere Klassifizierung, wie tensorflow_savedmodel
odertensorflow_graphdef
zum Beispiel. Solche Optionen können zusätzlich zum Schlüsselbackend
als Teil desplatform
Schlüssels angegeben werden. Die gängigsten Backends sindtensorrt
,onnxruntime
,tensorflow
,pytorch
,python
,dali
,fil
, undopenvino
. -
input
: Geben Sie drei Attribute für die Eingabe an:name
,data_type
unddims
(die Form). -
output
: Geben Sie drei Attribute für die Ausgabe an:name
,data_type
unddims
(die Form). -
max_batch_size
: Stellen Sie die Chargengröße auf einen Wert größer oder gleich 1 ein, der die maximale Chargengröße angibt, die Triton für das Modell verwenden sollte.
Weitere Informationen zur Konfiguration finden config.pbtxt
Sie im Triton-Repository. GitHub
-
instance_groups
: Instance-Gruppen helfen bei der Angabe der Nummer und des Standorts für ein bestimmtes Modell. Sie haben die Attribute count
kind
, undgpus
(werden verwendet, wennkind
KIND_GPU
ist). Dascount
Attribut entspricht der Anzahl der Worker. Für die reguläre Bereitstellung von Models hat jeder Worker seine eigene Kopie des Modells. In ähnlicher Weisecount
gibt der in Triton die Anzahl der Modellkopien pro Gerät an. Wenn derinstance_group
Typ beispielsweise istKIND_CPU
, dann CPU hat der diecount
Anzahl der Modellkopien.Anmerkung
Auf einer GPU Instanz gilt die
instance_group
Konfiguration pro GPU Gerät. Beispielsweise wird diecount
Anzahl der Modellkopien auf jedem GPU Gerät platziert, sofern Sie nicht explizit angeben, auf welche GPU Geräte das Modell geladen werden soll. -
dynamic_batching
und sequence_batching
: Dynamisches Batching wird für statuslose Modelle verwendet, und Sequenz-Batching wird für statusbehaftete Modelle verwendet (bei denen Sie jedes Mal eine Anfrage an dieselbe Modell-Instance weiterleiten möchten). Batching-Scheduler ermöglichen eine modellspezifische Warteschlange, wodurch der Durchsatz je nach Batching-Konfiguration erhöht werden kann. -
ensemble
: Ein Ensemble-Modell stellt eine Pipeline aus einem oder mehreren Modellen und die Verbindung von Eingabe- und Ausgangstensoren zwischen diesen Modellen dar. Es kann konfiguriert werden, indem platform
alsensemble
angegeben wird. Die Ensemble-Konfiguration ist nur eine Darstellung der Modellpipeline. Bei SageMaker Aktivierung werden alle Modelle eines Ensembles als vom Ensemblemodell abhängige Modelle behandelt und bei SageMaker Metriken wie z. B. alsLoadedModelCount
einzelnes Modell gezählt.
Veröffentlichung von Triton-Standardmetriken auf Amazon CloudWatch
Der NVIDIA Triton Inference Container stellt Metriken an Port 8002 (konfigurierbar) für die verschiedenen Modelle zur VerfügungGPUs, die im Triton Inference Server verwendet werden. Vollständige Informationen zu den verfügbaren Standardmetriken finden Sie auf der GitHub Seite für die Triton Inference Server-Metriken.
Ab Version v23.07 unterstützt der SageMaker Triton-Container die Veröffentlichung dieser Metriken auf Amazon, CloudWatch indem er einige Umgebungsvariablen angibt. Um die Prometheus-Metriken zu ermitteln, nutzt der SageMaker Triton-Container den Amazon-Agenten. CloudWatch
Die erforderlichen Umgebungsvariablen, die Sie für die Erfassung von Metriken angeben müssen, lauten wie folgt:
Umgebungsvariable | Beschreibung | Beispielwert |
---|---|---|
|
Geben Sie diese Option an, damit Triton Metriken auf seinem Prometheus-Endpunkt veröffentlichen kann. |
„true“ |
|
Geben Sie diese Option an, um die Vorabprüfungen zu starten, die für die Veröffentlichung von Metriken auf Amazon CloudWatch erforderlich sind. |
„true“ |
|
Geben Sie diese Option an, um auf die Protokollgruppe zu verweisen, in die die Metriken geschrieben werden. |
„/aws/ /Endpoints//SageMaker“ TritonMetrics SageMakerTwoEnsemblesTest |
|
Geben Sie diese Option an, um auf den Metrik-Namespace zu verweisen, in dem Sie die Metriken sehen und grafisch darstellen möchten. |
„/aws/ SageMaker /Endpunkte/TritonMetrics/SageMakerTwoEnsemblesPublicTest“ |
|
Geben Sie dies als 8002 oder einen anderen Port an. Wenn der angegebene SageMaker Port nicht blockiert wurde, wird er verwendet. Andernfalls wird automatisch ein anderer nicht blockierter Port ausgewählt. |
„8002" |
Beachten Sie bei der Veröffentlichung von Metriken bei SageMaker eingeschaltetem Triton die folgenden Einschränkungen:
Sie können zwar benutzerdefinierte Metriken über das C- API und Python-Backend (ab Version 23.05) generieren, diese werden jedoch derzeit nicht für die Veröffentlichung auf Amazon unterstützt. CloudWatch
Im Modus Endpoints (MME) mit SageMaker mehreren Modellen läuft Triton in einer Umgebung, in der Modell-Namespacing aktiviert sein muss, da jedes Modell (außer Ensemble-Modellen) so behandelt wird, als ob es sich in seinem eigenen Modell-Repository befände. Derzeit führt dies zu einer Einschränkung für Metriken. Wenn Modell-Namespacing aktiviert ist, unterscheidet Triton die Metriken nicht zwischen zwei Modellen mit demselben Namen, die zu unterschiedlichen Ensembles gehören. Um das Problem zu umgehen, stellen Sie sicher, dass jedes bereitgestellte Modell einen eindeutigen Namen hat. Dies macht es auch einfacher, Ihre Metriken darin nachzuschlagen. CloudWatch
Umgebungsvariablen
In der folgenden Tabelle sind die unterstützten Umgebungsvariablen für Triton on SageMaker aufgeführt.
Umgebungsvariable | Beschreibung | Typ | Mögliche Werte |
---|---|---|---|
|
Ermöglicht Triton den Betrieb im Modus für Endgeräte mit SageMaker mehreren Modellen. |
Boolesch |
|
|
Geben Sie das Modell an, das im SageMaker Einzelmodellmodus (Standard) geladen werden soll. Geben Sie für den Ensemble-Modus den Namen des eigentlichen Ensembles an. |
String |
|
|
|
String |
|
|
Im SageMaker Triton-Container ist dieser Wert standardmäßig auf |
Boolesch |
|
|
Wenn diese Option aktiviert ist SageMaker, ist der Standardport 8080. In Szenarien mit mehreren Containern können Sie eine Anpassung an einen anderen Port vornehmen. |
String |
|
|
Dies wird von der SageMaker Plattform festgelegt, wenn der Multi-Container-Modus verwendet wird. |
String |
|
|
Wird GRPC derzeit zwar SageMaker nicht unterstützt, aber wenn Sie Triton vor einem benutzerdefinierten Reverse-Proxy verwenden, können Sie diese Option aktivieren. GRPC |
Boolesch |
|
|
Der Standardport für GRPC ist 8001, aber Sie können ihn ändern. |
String |
|
|
Sie können die Anzahl der HTTP Standard-Request-Handler-Threads festlegen. |
String |
|
|
|
Boolesch |
|
|
|
Boolesch |
|
|
|
Boolesch |
|
|
|
Boolesch |
|
|
Geben Sie die Shm-Größe für das Python-Backend in Byte an. Der Standardwert ist 16 MB, kann aber erhöht werden. |
String |
|
|
Geben Sie die Shm-Wachstumsgröße für das Python-Backend in Byte an. Der Standardwert ist 1 MB, kann aber erhöht werden, um größere Inkremente zu ermöglichen. |
String |
|
|
Der Standardwert ist |
String |
|
|
Schränkt den maximalen GPU Speicheranteil ein, der für das Laden des Modells verwendet wird, sodass der Rest für die Inferenzanforderungen verwendet werden kann. |
String |
|
|
|
Boolesch |
|
|
Der Standard-Port ist 8002. |
String |
|
|
|
Boolesch |
|
|
Erforderlich, wenn Sie die Veröffentlichung von Kennzahlen auf aktiviert haben CloudWatch. |
String |
|
|
Erforderlich, wenn Sie die Veröffentlichung von Metriken für aktiviert haben CloudWatch. |
String |
|
|
Hängt beim Starten des Triton-Servers alle zusätzlichen Argumente an. |
String |
|