Führen Sie mehrere Deep-Learning-Modelle auf der GPU mit Amazon SageMaker-Multimodell-Endpunkten aus

Da sich die Einführung von KI in der gesamten Branche beschleunigt, bauen Kunden anspruchsvolle Modelle, die sich neue wissenschaftliche Durchbrüche im Bereich Deep Learning zunutze machen. Diese Modelle der nächsten Generation ermöglichen es Ihnen, hochmoderne, menschenähnliche Leistung in den Bereichen Verarbeitung natürlicher Sprache (NLP), Computer Vision, Spracherkennung, medizinische Forschung, Cybersicherheit, Proteinstrukturvorhersage und vielen anderen zu erreichen . Beispielsweise können große Sprachmodelle wie GPT-3, OPT und BLOOM Text mit menschenähnlichen Nuancen übersetzen, zusammenfassen und schreiben. Im Computer-Vision-Bereich können Text-zu-Bild-Diffusionsmodelle wie DALL-E und Imagen fotorealistische Bilder aus natürlicher Sprache mit einem höheren Maß an visuellem und sprachlichem Verständnis aus der Welt um uns herum erstellen. Diese multimodalen Modelle bieten reichhaltigere Funktionen für verschiedene nachgelagerte Aufgaben und die Möglichkeit, sie für bestimmte Domänen zu optimieren, und sie bieten unseren Kunden leistungsstarke Geschäftsmöglichkeiten.

Diese Deep-Learning-Modelle werden immer größer und enthalten in der Regel Milliarden von Modellparametern, um die Modellleistung für eine Vielzahl von Aufgaben wie Bilderzeugung, Textzusammenfassung, Sprachübersetzung und mehr zu skalieren. Es besteht auch die Notwendigkeit, diese Modelle anzupassen, um Einzelpersonen ein hyperpersonalisiertes Erlebnis zu bieten. Infolgedessen wird eine größere Anzahl von Modellen entwickelt, indem diese Modelle für verschiedene nachgelagerte Aufgaben fein abgestimmt werden. Um die Latenz- und Durchsatzziele von KI-Anwendungen zu erreichen, werden GPU-Instanzen gegenüber CPU-Instanzen bevorzugt (angesichts der Rechenleistung, die GPUs bieten). GPU-Instanzen sind jedoch teuer und die Kosten können sich summieren, wenn Sie mehr als 10 Modelle bereitstellen. Obwohl diese Modelle potenziell wirkungsvolle KI-Anwendungen bringen können, kann es aufgrund ihrer Größe und Anzahl von Modellen schwierig sein, diese Deep-Learning-Modelle auf kostengünstige Weise zu skalieren.

Amazon Sage Maker Multi-Model-Endpunkte (MMEs) bieten eine skalierbare und kostengünstige Möglichkeit, eine große Anzahl von Deep-Learning-Modellen bereitzustellen. MMEs sind eine beliebte Hosting-Wahl, um Hunderte von CPU-basierten Modellen bei Kunden wie Zendesk, Veeva und AT&T zu hosten. Zuvor hatten Sie nur begrenzte Möglichkeiten, Hunderte von Deep-Learning-Modellen bereitzustellen, die eine beschleunigte Berechnung mit GPUs erforderten. Heute kündigen wir die MME-Unterstützung für GPU an. Jetzt können Sie Tausende von Deep-Learning-Modellen hinter einem SageMaker-Endpunkt bereitstellen. MMEs können jetzt mehrere Modelle auf einem GPU-Kern ausführen, GPU-Instanzen hinter einem Endpunkt über mehrere Modelle hinweg gemeinsam nutzen und Modelle basierend auf dem eingehenden Datenverkehr dynamisch laden und entladen. Damit können Sie deutlich Kosten sparen und die beste Preisleistung erzielen.

In diesem Beitrag zeigen wir, wie Sie mit SageMaker-MMEs mehrere Deep-Learning-Modelle auf der GPU ausführen.

SageMaker-MMEs

Mit SageMaker MMEs können Sie mehrere Modelle hinter einem einzigen Inferenzendpunkt bereitstellen, der eine oder mehrere Instanzen enthalten kann. Bei MMEs wird jede Instanz verwaltet, um mehrere Modelle zu laden und bereitzustellen. MMEs ermöglichen es Ihnen, die linear steigenden Kosten für das Hosten mehrerer Modelle zu durchbrechen und die Infrastruktur über alle Modelle hinweg wiederzuverwenden.

Das folgende Diagramm veranschaulicht die Architektur einer SageMaker-MME.

Die SageMaker MME lädt Modelle dynamisch von herunter Amazon Simple Storage-Service (Amazon S3), anstatt alle Modelle herunterzuladen, wenn der Endpunkt zum ersten Mal erstellt wird. Infolgedessen kann bei einem anfänglichen Aufruf eines Modells eine höhere Inferenzlatenz auftreten als bei den nachfolgenden Inferenzen, die mit geringer Latenz abgeschlossen werden. Wenn das Modell beim Aufrufen bereits in den Container geladen ist, wird der Download- und Ladeschritt übersprungen und das Modell gibt die Inferenzen mit geringer Latenz zurück. Angenommen, Sie haben ein Modell, das nur wenige Male am Tag verwendet wird. Es wird automatisch bei Bedarf geladen, während Modelle, auf die häufig zugegriffen wird, im Speicher verbleiben und mit konstant niedriger Latenz aufgerufen werden.

SageMaker MMEs mit GPU-Unterstützung

SageMaker MMEs mit GPU arbeiten mit NVIDIA Triton-Inferenzserver. NVIDIA Triton Inference Server ist eine Open-Source-Inferenz-Serving-Software, die den Inferenz-Serving-Prozess vereinfacht und eine hohe Inferenzleistung bietet. Triton unterstützt alle wichtigen Trainings- und Inferenz-Frameworks wie TensorFlow, NVIDIA® TensorRT™, PyTorch, MXNet, Python, ONNX, XGBoost, Scikit-learn, RandomForest, OpenVINO, benutzerdefiniertes C++ und mehr. Es bietet dynamisches Batching, gleichzeitige Läufe, Quantisierung nach dem Training und eine optimale Modellkonfiguration, um eine hochleistungsfähige Inferenz zu erreichen. Darüber hinaus wurde der NVIDIA Triton Inference Server zur Implementierung erweitert MME-API-Vertrag, zur Integration mit MME.

Das folgende Diagramm veranschaulicht einen MME-Workflow.

Die Arbeitsschritte sind wie folgt:

1. Die SageMaker MME empfängt eine HTTP-Aufrufanforderung für ein bestimmtes Modell mit TargetModel in der Anfrage zusammen mit der Nutzlast.
2. SageMaker leitet den Datenverkehr an die richtige Instanz hinter dem Endpunkt weiter, an dem das Zielmodell geladen wird. SageMaker versteht das Verkehrsmuster über alle Modelle hinter dem MME und leitet Anfragen intelligent weiter.
3. SageMaker kümmert sich um die Modellverwaltung hinter dem Endpunkt, lädt das Modell dynamisch in den Speicher des Containers und entlädt das Modell basierend auf der gemeinsam genutzten Flotte von GPU-Instanzen, um die beste Preisleistung zu erzielen.
4. SageMaker lädt Modelle dynamisch von Amazon S3 auf das Speichervolume der Instance herunter. Wenn das aufgerufene Modell nicht auf dem Instanz-Speicherdatenträger verfügbar ist, wird das Modell auf den Instanz-Speicherdatenträger heruntergeladen. Wenn das Speichervolume der Instanz seine Kapazität erreicht, löscht SageMaker alle nicht verwendeten Modelle aus dem Speichervolume.
5. SageMaker lädt das Modell auf einer GPU-beschleunigten Instanz in den Speicher des NVIDIA Triton-Containers und bedient die Inferenzanforderung. Der GPU-Kern wird von allen Modellen in einer Instanz gemeinsam genutzt. Wenn das Modell bereits im Containerspeicher geladen ist, werden die nachfolgenden Anforderungen schneller bedient, da SageMaker es nicht erneut herunterladen und laden muss.
6. SageMaker kümmert sich um das Traffic-Shaping zum MME-Endpunkt und behält optimale Modellkopien auf GPU-Instanzen bei, um die beste Preisleistung zu erzielen. Es leitet den Datenverkehr weiterhin zu der Instanz weiter, in der das Modell geladen wird. Wenn die Instanzressourcen aufgrund hoher Auslastung ihre Kapazitätsgrenze erreichen, entlädt SageMaker die am wenigsten verwendeten Modelle aus dem Container, um Ressourcen zum Laden häufiger verwendeter Modelle freizugeben.

SageMaker MMEs können mithilfe einer automatischen Skalierungsrichtlinie horizontal skalieren und zusätzliche GPU-Recheninstanzen basierend auf Metriken wie Aufrufen pro Instanz und GPU-Auslastung bereitstellen, um jeden Datenverkehrsanstieg an MME-Endpunkten zu bedienen.

Lösungsüberblick

In diesem Beitrag zeigen wir Ihnen, wie Sie die neuen Funktionen von SageMaker MMEs mit GPU mit einem Computer-Vision-Anwendungsfall verwenden können. Zu Demonstrationszwecken verwenden wir ein vortrainiertes ResNet-50 Convolutional Neural Network-Modell, das Bilder in 1,000 Kategorien klassifizieren kann. Wir besprechen, wie Folgendes zu tun ist:

• Verwenden Sie einen NVIDIA Triton-Inferenzcontainer auf SageMaker-MMEs, indem Sie verschiedene Triton-Modell-Framework-Backends wie PyTorch und TensorRT verwenden
• Konvertieren Sie ResNet-50-Modelle in das optimierte TensorRT-Engine-Format und stellen Sie es mit einer SageMaker-MME bereit
• Richten Sie Auto Scaling-Richtlinien für die MME ein
• Erhalten Sie Einblicke in Instanz- und Aufrufmetriken mit Amazon CloudWatch

Erstellen Sie Modellartefakte

Dieser Abschnitt führt Sie durch die Schritte zum Vorbereiten eines vorab trainierten ResNet-50-Modells, das auf einer SageMaker MME mithilfe von Triton Inference Server-Modellkonfigurationen bereitgestellt werden soll. Alle Schritte können Sie anhand des Schritt-für-Schritt-Notizbuchs nachvollziehen GitHub.

Für diesen Beitrag demonstrieren wir die Bereitstellung mit zwei Modellen. Sie können jedoch Hunderte von Modellen vorbereiten und bereitstellen. Die Modelle können denselben Rahmen haben oder nicht.

Bereiten Sie ein PyTorch-Modell vor

Zuerst laden wir ein vortrainiertes ResNet50-Modell mit dem Torchvision-Modellpaket. Wir speichern das Modell als model.pt-Datei im für TorchScript optimierten und serialisierten Format. TorchScript kompiliert einen Forward Pass des ResNet50-Modells im Eager-Modus mit Beispieleingaben, sodass wir eine Instanz eines RGB-Bildes mit drei Farbkanälen der Dimension 224 x 224 übergeben.

Dann müssen wir die Modelle für Triton Inference Server vorbereiten. Der folgende Code zeigt das Modellrepository für das PyTorch-Framework-Back-End. Triton verwendet die im Modellrepository platzierte Datei model.pt, um Vorhersagen zu treffen.

resnet
├── 1
│   └── model.pt
└── config.pbtxt

Die Modellkonfigurationsdatei config.pbtxt muss den Namen des Modells angeben (resnet), die Plattform- und Backend-Eigenschaften (pytorch_libtorch), max_batch_size (128) und die Eingabe- und Ausgabetensoren zusammen mit dem Datentyp (TYPE_FP32) Information. Zusätzlich können Sie angeben instance_group und dynamic_batching Eigenschaften, um eine Hochleistungsinferenz zu erreichen. Siehe folgenden Code:

name: "resnet"
platform: "pytorch_libtorch"
max_batch_size: 128
input {
  name: "INPUT__0"
  data_type: TYPE_FP32
  dims: 3
  dims: 224
  dims: 224
}
output {
  name: "OUTPUT__0"
  data_type: TYPE_FP32
  dims: 1000
}

Bereiten Sie das TensorRT-Modell vor

NVIDIA TensorRT ist ein SDK für hochleistungsfähige Deep-Learning-Inferenz und enthält einen Deep-Learning-Inferenzoptimierer und eine Laufzeit, die eine geringe Latenz und einen hohen Durchsatz für Inferenzanwendungen bietet. Wir verwenden das Kommandozeilentool trtexec zum Generieren einer serialisierten TensorRT-Engine aus einer ONNX Modellformat. Führen Sie die folgenden Schritte aus, um ein vortrainiertes ResNet-50-Modell in NVIDIA TensorRT zu konvertieren:

1. Exportieren Sie das vortrainierte ResNet-50-Modell mithilfe von in ein ONNX-Format Torch.onnx. Dieser Schritt führt das Modell einmal aus, um seine Ausführung mit einer Beispieleingabe zu verfolgen, und exportiert dann das verfolgte Modell in die angegebene Datei model.onnx.
2. Verwenden Sie trtexec, um einen TensorRT-Engine-Plan aus der zu erstellen model.onnx Datei. Sie können optional die Genauigkeit von Gleitkommaberechnungen verringern, indem Sie sie entweder einfach in 16-Bit-Gleitkommazahlen ausführen oder Gleitkommawerte quantisieren, sodass Berechnungen mit 8-Bit-Ganzzahlen durchgeführt werden können.

Der folgende Code zeigt die Modell-Repository-Struktur für das TensorRT-Modell:

resnet
├── 1
│   └── model.plan
└── config.pbtxt

Für das TensorRT-Modell spezifizieren wir tensorrt_plan als Plattform und geben Sie die Tensor-Spezifikationen des Bildes mit den Abmessungen 224 x 224 ein, das die Farbkanäle enthält. Der Ausgabetensor mit 1,000 Dimensionen ist vom Typ TYPE_FP32, entsprechend den verschiedenen Objektkategorien. Siehe folgenden Code:

name: "resnet"
platform: "tensorrt_plan"
max_batch_size: 128
input {
  name: "input"
  data_type: TYPE_FP32
  dims: 3
  dims: 224
  dims: 224
}
output {
  name: "output"
  data_type: TYPE_FP32
  dims: 1000
}
model_warmup {
    name: "bs128 Warmup"
    batch_size: 128
    inputs: {
        key: "input"
        value: {
            data_type: TYPE_FP32
            dims: 3
            dims: 224
            dims: 224
            zero_data: false
        }
    }
}

Speichern Sie Modellartefakte in Amazon S3

SageMaker erwartet die Modellartefakte in .tar.gz Format. Sie sollten auch die Anforderungen des Triton-Containers wie Modellname, Version, config.pbtxt Dateien und mehr. tar der Ordner mit der Modelldatei als .tar.gz und laden Sie es auf Amazon S3 hoch:

!mkdir -p triton-serve-pt/resnet/1/
!mv -f workspace/model.pt triton-serve-pt/resnet/1/
!tar -C triton-serve-pt/ -czf resnet_pt_v0.tar.gz resnet
model_uri_pt = sagemaker_session.upload_data(path="resnet_pt_v0.tar.gz", key_prefix="resnet-mme-gpu")
!mkdir -p triton-serve-trt/resnet/1/
!mv -f workspace/model.plan triton-serve-trt/resnet/1/
!tar -C triton-serve-trt/ -czf resnet_trt_v0.tar.gz resnet
model_uri_trt = sagemaker_session.upload_data(path="resnet_trt_v0.tar.gz", key_prefix="resnet-mme-gpu")

Nachdem wir die Modellartefakte in Amazon S3 hochgeladen haben, können wir eine SageMaker-MME erstellen.

Stellen Sie Modelle mit einer MME bereit

Wir stellen jetzt ein ResNet-50-Modell mit zwei verschiedenen Framework-Backends (PyTorch und TensorRT) für eine SageMaker-MME bereit.

Beachten Sie, dass Sie Hunderte von Modellen bereitstellen können und die Modelle dasselbe Framework verwenden können. Sie können auch verschiedene Frameworks verwenden, wie in diesem Beitrag gezeigt.

Wir nutzen die AWS SDK für Python (Boto3) APIs create_model, create_endpoint_config und create_endpoint MME erstellen.

Definieren Sie den Bereitstellungscontainer

Definieren Sie in der Containerdefinition die model_data_url um das S3-Verzeichnis anzugeben, das alle Modelle enthält, die die SageMaker-MME zum Laden und Bereitstellen von Vorhersagen verwendet. Satz Mode zu MultiModel um anzuzeigen, dass SageMaker den Endpunkt mit MME-Containerspezifikationen erstellt. Wir setzen den Container mit einem Image, das die Bereitstellung von MMEs mit GPU unterstützt. Siehe folgenden Code:

container = {
"Image": ,
"ModelDataUrl": ,
"Mode": "MultiModel"
}

Erstellen Sie ein Objekt mit mehreren Modellen

Verwenden Sie den SageMaker Boto3-Client, um das Modell mit dem zu erstellen create_model API. Wir übergeben die Containerdefinition zusammen mit der API zum Erstellen von Modellen ModelName und ExecutionRoleArn:

create_model_response = sm_client.create_model(
    ModelName=, ExecutionRoleArn=role, PrimaryContainer=container
)

Definieren Sie MME-Konfigurationen

Erstellen Sie MME-Konfigurationen mit der create_endpoint_config Boto3-API. Geben Sie eine beschleunigte GPU-Computing-Instanz in an InstanceType (Wir verwenden den Instanztyp g4dn.4xlarge). Wir empfehlen, Ihre Endpunkte mit mindestens zwei Instanzen zu konfigurieren. Dadurch kann SageMaker einen hochverfügbaren Satz von Vorhersagen über mehrere Availability Zones für die Modelle bereitstellen.

Basierend auf unseren Erkenntnissen können Sie bei ML-optimierten Instanzen mit einem einzigen GPU-Kern eine bessere Preisleistung erzielen. Daher ist die MME-Unterstützung für die GPU-Funktion nur für Single-GPU-Kerninstanzen aktiviert. Eine vollständige Liste der unterstützten Instanzen finden Sie unter Unterstützte GPU-Instanztypen.

create_endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=,
    ProductionVariants=[
        {
            "InstanceType": "ml.g4dn.4xlarge",
            "InitialVariantWeight": 1,
            "InitialInstanceCount": 2,
            "ModelName": ,
            "VariantName": "AllTraffic",
        }
    ],
)

Erstellen Sie eine MME

Mit der vorangegangenen Endpunktkonfiguration erstellen wir eine SageMaker-MME mithilfe der create_endpoint API. SageMaker erstellt die MME, startet die ML-Recheninstanz g4dn.4xlarge und stellt die PyTorch- und TensorRT-ResNet-50-Modelle darauf bereit. Siehe folgenden Code:

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=, EndpointConfigName=
)

Rufen Sie das Zielmodell auf der MME auf

Nachdem wir den Endpunkt erstellt haben, können wir mithilfe von eine Inferenzanforderung an die MME senden invoke_enpoint API. Wir geben die an TargetModel im Aufruf und übergeben Sie die Nutzlast für jeden Modelltyp. Der folgende Code ist ein Beispielaufruf für das PyTorch-Modell und das TensorRT-Modell:

runtime_sm_client.invoke_endpoint(
    EndpointName=,
    ContentType="application/octet-stream",
    Body=json.dumps(pt_payload),
    TargetModel='resnet_pt_v0.tar.gz', #PyTorch Model
)
runtime_sm_client.invoke_endpoint(
    EndpointName=, 
    ContentType="application/octet-stream", 
    Body=json.dumps(trt_payload),
    TargetModel='resnet_trt_v0.tar.gz' #TensorRT Model
)

Richten Sie Auto Scaling-Richtlinien für die GPU-MME ein

SageMaker MMEs unterstützen die automatische Skalierung für Ihre gehosteten Modelle. Die automatische Skalierung passt die Anzahl der für ein Modell bereitgestellten Instanzen als Reaktion auf Änderungen Ihrer Arbeitslast dynamisch an. Wenn die Arbeitslast zunimmt, bringt die automatische Skalierung mehr Instanzen online. Wenn die Arbeitslast abnimmt, entfernt die automatische Skalierung unnötige Instanzen, sodass Sie nicht für bereitgestellte Instanzen bezahlen, die Sie nicht verwenden.

In der folgenden Skalierungsrichtlinie verwenden wir die benutzerdefinierte Metrik GPUUtilization der TargetTrackingScalingPolicyConfiguration konfigurieren und einstellen a TargetValue of 60.0 für den Zielwert dieser Metrik. Diese Autoscaling-Richtlinie stellt zusätzliche Instanzen bis zu bereit MaxCapacity wenn die GPU-Auslastung mehr als 60 % beträgt.

auto_scaling_client = boto3.client('application-autoscaling')

resource_id='endpoint/' +  + '/variant/' + 'AllTraffic' 
response = auto_scaling_client.register_scalable_target(
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    MinCapacity=1,
    MaxCapacity=5
)

response = auto_scaling_client.put_scaling_policy(
    PolicyName='GPUUtil-ScalingPolicy',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 60.0, 
        'CustomizedMetricSpecification':
        {
            'MetricName': 'GPUUtilization',
            'Namespace': '/aws/sagemaker/Endpoints',
            'Dimensions': [
                {'Name': 'EndpointName', 'Value':  },
                {'Name': 'VariantName','Value': 'AllTraffic'}
            ],
            'Statistic': 'Average',
            'Unit': 'Percent'
        },
        'ScaleInCooldown': 600,
        'ScaleOutCooldown': 200 
    }
)

Wir empfehlen die Verwendung GPUUtilization or InvocationsPerInstance um Auto Scaling-Richtlinien für Ihre MME zu konfigurieren. Weitere Einzelheiten finden Sie unter Legen Sie Autoscaling-Richtlinien für Endpunktbereitstellungen mit mehreren Modellen fest

CloudWatch-Metriken für GPU-MMEs

SageMaker MMEs stellen die folgenden zu überwachenden Metriken auf Instanzebene bereit:

• LoadedModelCount – Anzahl der in die Container geladenen Modelle
• GPU-Auslastung – Prozentsatz der GPU-Einheiten, die von den Containern verwendet werden
• GPU-Speicherauslastung – Prozentsatz des von den Containern verwendeten GPU-Speichers
• Festplattennutzung – Prozentsatz des von den Containern belegten Speicherplatzes

Mit diesen Metriken können Sie die effektive Nutzung von GPU-Instanzressourcen planen. In der folgenden Grafik sehen wir GPUMemoryUtilization betrug 38.3 %, wenn mehr als 16 ResNet-50-Modelle in den Container geladen wurden. Die Summe der Auslastung jedes einzelnen CPU-Kerns (CPUUtilization) betrug 60.9 % und der Prozentsatz des von den Containern verwendeten Arbeitsspeichers (MemoryUtilization) lag bei 9.36 %.

SageMaker MMEs bieten auch Metriken zum Laden von Modellen, um Einblicke auf Modellaufrufebene zu erhalten:

• ModelLoadingWaitTime – Zeitintervall für den Download bzw. das Laden des Modells
• ModelUnloadingTime – Zeitintervall zum Entladen des Modells aus dem Container
• ModelDownloadingTime – Zeit, das Modell von Amazon S3 herunterzuladen
• ModelCacheHit – Anzahl der Aufrufe des Modells, die bereits in den Container geladen wurden

In der folgenden Grafik können wir beobachten, dass es 8.22 Sekunden dauerte, bis ein Modell auf eine Inferenzanforderung (ModelLatency) und 24.1 Millisekunden wurden zur End-to-End-Latenz aufgrund von SageMaker-Overheads hinzugefügt (OverheadLatency). Wir können auch alle Fehlermetriken von Aufrufen zum Aufrufen eines Endpunkt-API-Aufrufs sehen, wie z Invocation4XXErrors und Invocation5XXErrors.

Weitere Informationen zu MME CloudWatch-Metriken finden Sie unter CloudWatch-Metriken für Endpunktbereitstellungen mit mehreren Modellen.

Zusammenfassung

In diesem Beitrag haben Sie von der neuen SageMaker Multi-Model-Unterstützung für GPU erfahren, die es Ihnen ermöglicht, Hunderte von Deep-Learning-Modellen kostengünstig auf beschleunigter Rechenhardware zu hosten. Sie haben gelernt, wie Sie den NVIDIA Triton Inference Server verwenden, der eine Modell-Repository-Konfiguration für verschiedene Framework-Backends erstellt, und wie Sie eine MME mit automatischer Skalierung bereitstellen. Mit dieser Funktion können Sie Hunderte von hyperpersonalisierten Modellen skalieren, die fein abgestimmt sind, um einzigartigen Endbenutzererfahrungen in KI-Anwendungen gerecht zu werden. Sie können diese Funktion auch nutzen, um die erforderliche Preisleistung für Ihre Inferenzanwendung mit fraktionierten GPUs zu erzielen.

Informationen zum Einstieg in die MME-Unterstützung für GPU finden Sie unter Endpunktunterstützung für mehrere Modelle für GPU.

Über die Autoren

Dhawal Patel ist Principal Machine Learning Architect bei AWS. Er hat mit Organisationen von großen Unternehmen bis hin zu mittelständischen Startups an Problemen im Zusammenhang mit verteiltem Computing und künstlicher Intelligenz gearbeitet. Er konzentriert sich auf Deep Learning, einschließlich NLP und Computer Vision-Domänen. Er hilft Kunden dabei, eine leistungsstarke Modellinferenz auf Amazon SageMaker zu erreichen.

Vikram Elango ist Senior AI/ML Specialist Solutions Architect bei Amazon Web Services mit Sitz in Virginia, USA. Vikram unterstützt globale Kunden aus der Finanz- und Versicherungsbranche mit Design, Implementierung und Vordenkerrolle bei der Erstellung und Bereitstellung von Anwendungen für maschinelles Lernen in großem Maßstab. Derzeit konzentriert er sich auf die Verarbeitung natürlicher Sprache, verantwortungsbewusste KI, Inferenzoptimierung und die Skalierung von ML im gesamten Unternehmen. In seiner Freizeit reist er gerne, wandert, kocht und campt mit seiner Familie.

Saurabh Trikande ist Senior Product Manager für Amazon SageMaker Inference. Er arbeitet leidenschaftlich gerne mit Kunden zusammen und ist motiviert von dem Ziel, maschinelles Lernen zu demokratisieren. Er konzentriert sich auf die Kernherausforderungen im Zusammenhang mit der Bereitstellung komplexer ML-Anwendungen, mandantenfähigen ML-Modellen, Kostenoptimierungen und der leichteren Bereitstellung von Deep-Learning-Modellen. In seiner Freizeit wandert Saurabh gerne, lernt etwas über innovative Technologien, folgt TechCrunch und verbringt Zeit mit seiner Familie.

Deepti Ragha ist Software Development Engineer im Amazon SageMaker-Team. Ihre aktuelle Arbeit konzentriert sich auf das Erstellen von Funktionen zum effizienten Hosten von Modellen für maschinelles Lernen. In ihrer Freizeit reist sie gerne, wandert und züchtet Pflanzen.

Nikhil Kulkarni ist ein Softwareentwickler bei AWS Machine Learning, der sich darauf konzentriert, Workloads für maschinelles Lernen in der Cloud leistungsfähiger zu machen, und ist Mitgestalter von AWS Deep Learning Containers für Training und Inferenz. Seine Leidenschaft gilt verteilten Deep-Learning-Systemen. Außerhalb der Arbeit liest er gerne Bücher, spielt mit der Gitarre und backt Pizza.

Jiahong Liu ist Solution Architect im Cloud Service Provider-Team bei NVIDIA. Er unterstützt Kunden bei der Einführung von Lösungen für maschinelles Lernen und KI, die NVIDIA Accelerated Computing nutzen, um ihre Trainings- und Inferenzherausforderungen zu bewältigen. In seiner Freizeit beschäftigt er sich gerne mit Origami, DIY-Projekten und spielt Basketball.

Eliuth Triana ist Developer Relations Manager im NVIDIA-AWS-Team. Er verbindet Amazon- und AWS-Produktleiter, Entwickler und Wissenschaftler mit NVIDIA-Technologen und Produktleitern, um Amazon ML/DL-Workloads, EC2-Produkte und AWS-KI-Services zu beschleunigen. Außerdem ist Eliuth leidenschaftlicher Mountainbiker, Skifahrer und Pokerspieler.

Maximilian Maccanti ist Principal Engineer bei AWS, derzeit bei DynamoDB, ich war im Launch-Team von SageMaker bei re:Invent 2017 und verbrachte die folgenden 5 Jahre auf der Hosting-Plattform, um alle Arten von kundenorientierten Funktionen hinzuzufügen. In meiner Freizeit sammle, repariere und spiele ich mit alten Videospielkonsolen.