Stellen Sie BLOOM-176B und OPT-30B auf Amazon SageMaker mit großen Modellinferenz-Deep-Learning-Containern und DeepSpeed ​​bereit

In den letzten Jahren hat sich das Thema Deep Learning rasant entwickelt. Obwohl sich die Hardware verbessert hat, beispielsweise mit der neuesten Generation von Beschleunigern von NVIDIA und Amazon, stoßen fortgeschrittene Praktiker des maschinellen Lernens (ML) immer noch regelmäßig auf Probleme, wenn sie ihre großen Deep-Learning-Modelle für Anwendungen wie die Verarbeitung natürlicher Sprache (NLP) einsetzen.

In einem früheren Beitrag haben wir darüber gesprochen Funktionen und konfigurierbare Einstellungen in Amazon SageMaker-Modellbereitstellung das kann die Inferenz mit diesen großen Modellen erleichtern. Heute kündigen wir eine neue an Amazon Sage Maker Deep Learning Container (DLC), mit dem Sie innerhalb weniger Minuten mit der Inferenz großer Modelle beginnen können. Dies DLC enthält einige der beliebtesten Open-Source-Bibliotheken für die parallele Inferenz von Modellen, wie DeepSpeed ​​und Hugging Face Accelerate.

In diesem Beitrag verwenden wir einen neuen SageMaker-Inferenz-DLC für große Modelle, um zwei der beliebtesten großen NLP-Modelle bereitzustellen: BigScience BLÜTE-176B und Metas OPT-30B aus dem Hugging Face-Repository. Insbesondere verwenden wir Deep Java Library (DJL) Serving- und Tensor-Parallelismus-Techniken von DeepSpeed, um in einem Anwendungsfall zur Textgenerierung eine Latenz von 0.1 Sekunden pro Token zu erreichen.

Unsere kompletten Beispiel-Notebooks finden Sie in unserem GitHub-Repository.

Inferenztechniken für große Modelle

Sprachmodelle sind in letzter Zeit sowohl in Größe als auch in Popularität explodiert. Mit einfachem Zugang von Modellzoos wie Hugging Face und verbesserter Genauigkeit und Leistung bei NLP-Aufgaben wie Klassifizierung und Textgenerierung greifen Praktiker zunehmend nach diesen großen Modellen. Große Modelle sind jedoch oft zu groß, um in den Speicher eines einzelnen Beschleunigers zu passen. Beispielsweise kann das BLOOM-176B-Modell mehr als 350 Gigabyte Beschleunigerspeicher benötigen, was die Kapazität der heute verfügbaren Hardwarebeschleuniger bei weitem übersteigt. Dies erfordert die Verwendung von parallelen Modelltechniken aus Bibliotheken wie DeepSpeed ​​und Hugging Face Accelerate, um ein Modell zur Inferenz auf mehrere Beschleuniger zu verteilen. In diesem Beitrag verwenden wir die SageMaker-Inferenzcontainer für große Modelle Latenz- und Durchsatzleistung mithilfe dieser beiden Open-Source-Bibliotheken zu generieren und zu vergleichen.

DeepSpeed ​​und Accelerate verwenden unterschiedliche Techniken, um große Sprachmodelle für Inferenz zu optimieren. Der Hauptunterschied ist der von DeepSpeed Verwendung optimierter Kernel. Diese Kernel können die Inferenzlatenz drastisch verbessern, indem sie Engpässe im Berechnungsgraphen des Modells reduzieren. Optimierte Kernel können schwierig zu entwickeln sein und sind typischerweise spezifisch für eine bestimmte Modellarchitektur; DeepSpeed ​​unterstützt mit diesen optimierten Kerneln beliebte große Modelle wie OPT und BLOOM. Im Gegensatz dazu enthält die Accelerate-Bibliothek von Hugging Face zum Zeitpunkt des Schreibens keine optimierten Kernel. Wie wir in unserem Ergebnisabschnitt besprechen, ist dieser Unterschied für einen Großteil des Leistungsvorsprungs verantwortlich, den DeepSpeed ​​gegenüber Accelerate hat.

Ein zweiter Unterschied zwischen DeepSpeed ​​und Accelerate ist die Art der Modellparallelität. Accelerate verwendet Pipeline-Parallelität, um ein Modell zwischen den verborgenen Schichten eines Modells zu partitionieren, während DeepSpeed ​​Tensor-Parallelität verwendet, um die Schichten selbst zu partitionieren. Pipeline-Parallelität ist ein flexibler Ansatz, der mehr Modelltypen unterstützt und den Durchsatz verbessern kann, wenn größere Batchgrößen verwendet werden. Tensorparallelität erfordert mehr Kommunikation zwischen GPUs, da Modellschichten auf mehrere Geräte verteilt werden können, aber die Inferenzlatenz verbessern kann, indem mehrere GPUs gleichzeitig eingebunden werden. Weitere Informationen zu Parallelisierungstechniken finden Sie in Einführung in die Modellparallelität und Modellparallelität.

Lösungsüberblick

Um große Sprachmodelle effektiv hosten zu können, benötigen wir Funktionen und Unterstützung in den folgenden Schlüsselbereichen:

• Erstellen und Testen von Lösungen – Angesichts der iterativen Natur der ML-Entwicklung müssen wir in der Lage sein, zu erstellen, schnell zu iterieren und zu testen, wie sich der Inferenzendpunkt verhält, wenn diese Modelle gehostet werden, einschließlich der Fähigkeit, schnell fehlzuschlagen. Diese Modelle können normalerweise nur auf größeren Instanzen wie p4dn oder g5 gehostet werden, und angesichts der Größe der Modelle kann es eine Weile dauern, eine Inferenzinstanz hochzufahren und eine Testiteration auszuführen. Beim lokalen Testen gibt es normalerweise Einschränkungen, da Sie zum Testen eine Instanz ähnlicher Größe benötigen und diese Modelle nicht einfach zu beschaffen sind.
• Skalierte Bereitstellung und Ausführung – Die Modelldateien müssen auf die Inferenzinstanzen geladen werden, was bei der Größe schon eine Herausforderung darstellt. Tar / Un-Tar als Beispiel für den Bloom-176B dauert etwa 1 Stunde zum Erstellen und eine weitere Stunde zum Laden. Wir brauchen einen alternativen Mechanismus, um einen einfachen Zugriff auf die Modelldateien zu ermöglichen.
• Laden des Modells als Singleton – Bei einem Multi-Worker-Prozess müssen wir sicherstellen, dass das Modell nur einmal geladen wird, damit wir nicht in Race-Conditions geraten und unnötige Ressourcen verbrauchen. In diesem Beitrag zeigen wir eine Möglichkeit, direkt von zu laden Amazon Simple Storage-Service (Amazon S3). Dies funktioniert jedoch nur, wenn wir die Standardeinstellungen des DJL verwenden. Darüber hinaus muss jede Skalierung der Endpunkte in wenigen Minuten hochgefahren werden können, was eine Überlegung erfordert, wie die Modelle geladen und verteilt werden könnten.
• Sharding-Frameworks – Diese Modelle müssen in der Regel durch einen Tensor-Parallelismus-Mechanismus oder durch Pipeline-Sharding als typische Sharding-Techniken erstellt werden, und wir haben fortschrittliche Konzepte wie ZeRO-Sharding, die auf Tensor-Sharding aufbauen. Weitere Informationen zu Sharding-Techniken finden Sie unter Modellparallelität. Um dies zu erreichen, können wir verschiedene Kombinationen haben und Frameworks von NIVIDIA, DeepSpeed ​​und anderen verwenden. Dies erfordert die Fähigkeit, BYOC zu testen oder 1P-Container zu verwenden und über Lösungen zu iterieren und Benchmarking-Tests durchzuführen. Möglicherweise möchten Sie auch verschiedene Hosting-Optionen wie asynchron, serverlos und andere testen.
• Hardwareauswahl – Ihre Wahl der Hardware wird von allen oben genannten Punkten und weiteren Verkehrsmustern, Anwendungsfällen und Modellgrößen bestimmt.

In diesem Beitrag verwenden wir die optimierten Kernel und Tensor-Parallelismus-Techniken von DeepSpeed, um BLOOM-176B und OPT-30B auf SageMaker zu hosten. Wir vergleichen auch Ergebnisse von Accelerate, um die Leistungsvorteile optimierter Kernel und Tensorparallelität zu demonstrieren. Weitere Informationen zu DeepSpeed ​​und Accelerate finden Sie unter DeepSpeed-Inferenz: Effiziente Inferenz von Transformatormodellen in beispielloser Größenordnung und Unglaublich schnelle BLOOM-Inferenz mit DeepSpeed ​​und Accelerate.

In diesem Beispiel verwenden wir DJLServing als Modellbereitstellungslösung. DJLServing ist eine hochleistungsfähige universelle Model-Serving-Lösung, die von der programmiersprachenunabhängigen Deep Java Library (DJL) unterstützt wird. Weitere Informationen zu DJL und DJLServing finden Sie unter Stellen Sie große Modelle auf Amazon SageMaker mit DJLServing und paralleler DeepSpeed-Modellinferenz bereit.

Es ist erwähnenswert, dass optimierte Kernel zu Genauigkeitsänderungen und einem modifizierten Berechnungsgraphen führen können, was theoretisch zu einem geänderten Modellverhalten führen könnte. Obwohl dies gelegentlich das Ergebnis der Inferenz ändern könnte, erwarten wir nicht, dass diese Unterschiede die grundlegenden Bewertungsmetriken eines Modells wesentlich beeinflussen. Dennoch wird Praktikern empfohlen, sich zu vergewissern, dass die Modellausgaben bei Verwendung dieser Kernel wie erwartet sind.

Die folgenden Schritte zeigen, wie Sie ein BLOOM-176B-Modell in SageMaker mithilfe von DJLServing und einem SageMaker-Inferenzcontainer für große Modelle bereitstellen. Das vollständige Beispiel ist auch in unserem verfügbar GitHub-Repository.

Verwenden des DJLServing SageMaker DLC-Images

Verwenden Sie den folgenden Code, um das DJLServing SageMaker DLC-Image zu verwenden, nachdem Sie die Region durch Ihre spezifische Region ersetzt haben, in der Sie das Notebook ausführen:

763104351884.dkr.ecr..amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113
# example uri might be like 763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113

Erstellen Sie unsere Modelldatei

Zuerst erstellen wir eine Datei namens serving.properties die nur eine Codezeile enthält. Dies weist den DJL-Modellserver an, die DeepSpeed-Engine zu verwenden. Die Datei enthält den folgenden Code:

engine=DeepSpeed

serving.properties ist eine von DJLServing definierte Datei, die zum Konfigurieren der Konfiguration pro Modell verwendet wird.

Als nächstes erstellen wir unsere model.py -Datei, die den Code definiert, der zum Laden und anschließenden Bereitstellen des Modells erforderlich ist. In unserem Code lesen wir die ein TENSOR_PARALLEL_DEGREE Umgebungsvariable (der Standardwert ist 1). Damit wird die Anzahl der Geräte festgelegt, auf die die Tensor-Parallelmodule verteilt werden. Beachten Sie, dass DeepSpeed ​​einige integrierte Partitionsdefinitionen bereitstellt, darunter eine für BLOOM-Modelle. Wir verwenden es durch Angabe replace_method und relpace_with_kernel_inject. Wenn Sie ein angepasstes Modell haben und DeepSpeed ​​für eine effektive Partitionierung benötigen, müssen Sie es ändern relpace_with_kernel_inject zu false und fügen injection_policy damit die Laufzeitpartition funktioniert. Weitere Informationen finden Sie unter Initialisierung für Inferenz. Für unser Beispiel haben wir das vorpartitionierte BLOOM-Modell auf DeepSpeed ​​verwendet.

Zweitens in der model.py -Datei laden wir das Modell auch aus Amazon S3, nachdem der Endpunkt hochgefahren wurde. Das Modell wird in die geladen /tmp Speicherplatz auf dem Container, weil SageMaker den abbildet /tmp zu den Amazon Elastic Block-Shop (Amazon EBS)-Volume, das gemountet wird, wenn wir den Endpunkterstellungsparameter angeben VolumeSizeInGB. Für Instanzen wie p4dn, die mit der Volume-Instanz vorkonfiguriert sind, können wir die weiterhin nutzen /tmp auf dem Behälter. Siehe folgenden Code:

from djl_python import Input, Output
import os
import deepspeed
import torch
import torch.distributed as dist
import sys
import subprocess
import time
from glob import glob
from transformers import pipeline, AutoModelForCausalLM, AutoTokenizer
from transformers.models.opt.modeling_opt import OPTDecoderLayer

predictor = None

def check_config():
    local_rank = os.getenv('LOCAL_RANK')
    
    if not local_rank:
        return False
    return True
    
def get_model():

    if not check_config():
        raise Exception("DJL:DeepSpeed configurations are not default. This code does not support non default configurations") 
    
    tensor_parallel = int(os.getenv('TENSOR_PARALLEL_DEGREE', '1'))
    local_rank = int(os.getenv('LOCAL_RANK', '0'))
    model_dir = "/tmp/model"
    bucket = os.environ.get("MODEL_S3_BUCKET")
    key_prefix = os.environ.get("MODEL_S3_PREFIX")
    print(f"rank: {local_rank}")
    if local_rank == 0:
        if f"{model_dir}/DONE" not in glob(f"{model_dir}/*"):
            print("Starting Model downloading files")
            try:
                proc_run = subprocess.run(
                    ["aws", "s3", "cp", "--recursive", f"s3://{bucket}/{key_prefix}", model_dir]
                )
                print("Model downloading finished")
                # write file when download complete. Could use dist.barrier() but this makes it easier to check if model is downloaded in case of retry
                with open(f"{model_dir}/DONE", "w") as f:
                    f.write("download_complete")
                    
                proc_run.check_returncode() # to throw the error in case there was one
                
            except subprocess.CalledProcessError as e:
                print ( "Model download failed: Error:nreturn code: ", e.returncode, "nOutput: ", e.stderr )
                raise # FAIL FAST  
                               
    dist.barrier()
                
    
    tokenizer = AutoTokenizer.from_pretrained(model_dir)
    
    # has to be FP16 as Int8 model loading not yet supported
    with deepspeed.OnDevice(dtype=torch.float16, device="meta"):
        model = AutoModelForCausalLM.from_config(
            AutoConfig.from_pretrained(model_dir), torch_dtype=torch.bfloat16
        )
    model = model.eval()
    
    model = deepspeed.init_inference(
        model,
        mp_size=tensor_parallel,
        dtype=torch.int8,
        base_dir = model_dir,
        checkpoint=os.path.join(model_dir, "ds_inference_config.json"),
        replace_method='auto',
        replace_with_kernel_inject=True
    )

    model = model.module
    dist.barrier()
    return model, tokenizer

DJLServing verwaltet die Laufzeitinstallation auf allen Pip-Paketen, die in definiert sind requirement.txt. Diese Datei enthält:

awscli
boto3

Wir haben ein Verzeichnis namens erstellt code und für model.py, serving.properties und requirements.txt In diesem Verzeichnis sind bereits Dateien angelegt. Um die Dateien anzuzeigen, können Sie den folgenden Code vom Terminal aus ausführen:

mkdir -p code
cat code/model.py 
cat code/serving.properties 
cat code/requirements.txt 

Die folgende Abbildung zeigt den Aufbau der model.tar.gz.

Zuletzt erstellen wir die Modelldatei und laden sie auf Amazon S3 hoch:

tar cvfz model.tar.gz code
s3_code_artifact = sess.upload_data("model.tar.gz", bucket, s3_code_prefix)

Laden Sie das Modell von Hugging Face herunter und speichern Sie es (optional)

Wir haben die Schritte in diesem Abschnitt für den Fall bereitgestellt, dass Sie das Modell auf Amazon S3 herunterladen und von dort aus verwenden möchten. Die Schritte werden in der Jupyter-Datei auf GitHub bereitgestellt. Der folgende Screenshot zeigt eine Momentaufnahme der Schritte.

Erstellen Sie ein SageMaker-Modell

Wir erstellen jetzt eine SageMaker-Modell. Wir benutzen das Amazon Elastic Container-Registrierung (Amazon ECR)-Bild bereitgestellt von und das Modellartefakt aus dem vorherigen Schritt zum Erstellen des SageMaker-Modells. Im Modellaufbau konfigurieren wir TENSOR_PARALLEL_DEGREE=8, was bedeutet, dass das Modell entlang von 8 GPUs partitioniert ist. Siehe folgenden Code:

PrimaryContainer={
        "Image": inference_image_uri,
        "ModelDataUrl": s3_code_artifact,
        "Environment": {
            "MODEL_S3_BUCKET": bucket,
            "MODEL_S3_PREFIX": s3_model_prefix,
            "TENSOR_PARALLEL_DEGREE": "8",
},

Nachdem Sie die vorherige Zelle in der Jupyter-Datei ausgeführt haben, sehen Sie eine Ausgabe ähnlich der folgenden:

{
    "ModelArn": "arn:aws:sagemaker:us-east-1::model/bloom-djl-ds-"
}

Erstellen Sie einen SageMaker-Endpunkt

Sie können beliebige Instanzen mit mehreren GPUs zum Testen verwenden. In dieser Demo verwenden wir eine p4d.24xlarge-Instanz. Beachten Sie im folgenden Code, wie wir die festlegen ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds und VolumeSizeInGB Parameter zur Anpassung an die große Modellgröße. Das VolumeSizeInGB Der Parameter gilt für GPU-Instances, die den EBS-Volume-Anhang unterstützen.

endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "variant1",
            "ModelName": model_name,
            "InstanceType": "ml.p4d.24xlarge",
            "InitialInstanceCount": 1,
            #"VolumeSizeInGB" : 200,
            "ModelDataDownloadTimeoutInSeconds": 2400,
            "ContainerStartupHealthCheckTimeoutInSeconds": 2400,
        },
    ],
)'

Zuletzt erstellen wir einen SageMaker-Endpunkt:

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=f"{endpoint_name}", EndpointConfigName=endpoint_config_name
)

Sie sehen es im folgenden Code ausgedruckt:

{
    "EndpointArn": "arn:aws:sagemaker:us-east-1::endpoint/bloom-djl-ds-"
}

Das Starten des Endpunkts kann eine Weile dauern. Sie können es noch ein paar Mal versuchen, wenn Sie auf das stoßen InsufficientInstanceCapacity Fehler, oder Sie können eine Anfrage an AWS stellen, um das Limit in Ihrem Konto zu erhöhen.

Leistungsoptimierung

Wenn Sie beabsichtigen, diesen Post und das begleitende Notebook mit einem anderen Modell zu verwenden, möchten Sie vielleicht einige der einstellbaren Parameter erkunden, die SageMaker, DeepSpeed ​​und DJL bieten. Iteratives Experimentieren mit diesen Parametern kann erhebliche Auswirkungen auf die Latenz, den Durchsatz und die Kosten Ihres gehosteten großen Modells haben. Weitere Informationen zum Optimieren von Parametern wie Anzahl der Worker, Grad der Tensorparallelität, Größe der Auftragswarteschlange usw. finden Sie unter DJL Serving-Konfigurationen und Stellen Sie große Modelle auf Amazon SageMaker mit DJLServing und paralleler DeepSpeed-Modellinferenz bereit.

Die Ergebnisse

In diesem Beitrag haben wir DeepSpeed ​​verwendet, um BLOOM-176B und OPT-30B auf SageMaker ML-Instanzen zu hosten. Die folgende Tabelle fasst unsere Leistungsergebnisse zusammen, einschließlich eines Vergleichs mit Accelerate von Hugging Face. Die Latenz spiegelt die Anzahl der Millisekunden wider, die benötigt wird, um viermal eine 256-Token-Zeichenfolge zu erzeugen (batch_size=4) aus dem Modell. Der Durchsatz spiegelt die Anzahl der Token wider, die pro Sekunde für jeden Test produziert werden. Für Hugging Face Accelerate haben wir das Standardladen der Bibliothek mit GPU-Speicherzuordnung verwendet. Für DeepSpeed ​​haben wir seinen schnelleren Checkpoint-Lademechanismus verwendet.

Aus Latenzsicht ist DeepSpeed ​​etwa 3.4-mal schneller für BLOOM-176B und 5.6-mal schneller für OPT-30B als Accelerate. Die optimierten Kernel von DeepSpeed ​​sind für einen Großteil dieses Latenzunterschieds verantwortlich. Angesichts dieser Ergebnisse empfehlen wir, DeepSpeed ​​statt Accelerate zu verwenden, wenn das Modell Ihrer Wahl unterstützt wird.

Es ist auch erwähnenswert, dass die Modellladezeiten mit DeepSpeed ​​viel kürzer waren, was es zu einer besseren Option macht, wenn Sie davon ausgehen, dass Sie Ihre Anzahl von Endpunkten schnell erhöhen müssen. Die flexiblere Pipeline-Parallelisierungstechnik von Accelerate ist möglicherweise eine bessere Option, wenn Sie über Modelle oder Modellgenauigkeiten verfügen, die von DeepSpeed ​​nicht unterstützt werden.

Diese Ergebnisse demonstrieren auch den Unterschied in Latenz und Durchsatz unterschiedlicher Modellgrößen. In unseren Tests generiert OPT-30B die 2.4-fache Anzahl an Tokens pro Zeiteinheit als BLOOM-176B auf einem Instance-Typ, der mehr als dreimal billiger ist. Bezogen auf den Durchsatzpreis pro Einheit ist OPT-30B auf einer g5.24xl-Instanz 8.9-mal besser als BLOOM-176B auf einer p4d.24xl-Instanz. Wenn Sie strenge Latenz-, Durchsatz- oder Kostenbeschränkungen haben, sollten Sie das kleinstmögliche Modell verwenden, das die funktionalen Anforderungen noch erfüllt.

Aufräumen

Als Teil der Best Practices wird immer empfohlen, inaktive Instanzen zu löschen. Der folgende Code zeigt Ihnen, wie Sie die Instanzen löschen.

# - Delete the end point
sm_client.delete_endpoint(EndpointName=endpoint_name)

# - In case the end point failed we still want to delete the model
sm_client.delete_endpoint_config(EndpointConfigName=endpoint_config_name)
sm_client.delete_model(ModelName=model_name)

Löschen Sie optional den Modellprüfpunkt von Ihrem S3

!aws s3 rm --recursive s3:///{s3_model_prefix}

Zusammenfassung

In diesem Beitrag haben wir gezeigt, wie SageMaker-Inferenzcontainer für große Modelle verwendet werden, um zwei große Sprachmodelle, BLOOM-176B und OPT-30B, zu hosten. Wir haben die modellparallelen Techniken von DeepSpeed ​​mit mehreren GPUs auf einer einzigen SageMaker ML-Instanz verwendet.

Weitere Einzelheiten zu Amazon SageMaker und seinen Inferenzfunktionen für große Modelle finden Sie unter Amazon SageMaker unterstützt jetzt die Bereitstellung großer Modelle durch konfigurierbare Volume-Größe und Timeout-Kontingente und Echtzeit-Inferenz.

Über die Autoren

Simon Zamarin ist ein AI / ML Solutions Architect, dessen Hauptaugenmerk darauf liegt, Kunden dabei zu helfen, Wert aus ihren Datenbeständen zu ziehen. In seiner Freizeit verbringt Simon gerne Zeit mit seiner Familie, liest Science-Fiction und arbeitet an verschiedenen DIY-Hausprojekten.

Rupinder Grewal ist ein Sr Ai/ML Specialist Solutions Architect bei AWS. Derzeit konzentriert er sich auf die Bereitstellung von Modellen und MLOps auf SageMaker. Vor dieser Funktion hat er als Machine Learning Engineer gearbeitet und Modelle erstellt und gehostet. Außerhalb der Arbeit spielt er gerne Tennis und radelt auf Bergpfaden.

Frank Liu ist ein Software Engineer für AWS Deep Learning. Er konzentriert sich auf den Aufbau innovativer Deep-Learning-Tools für Software-Ingenieure und Wissenschaftler. In seiner Freizeit wandert er gerne mit Freunden und der Familie.

Alan Tan ist Senior Product Manager bei SageMaker und leitet die Bemühungen zur Inferenz großer Modelle. Er setzt sich leidenschaftlich für die Anwendung von Machine Learning im Bereich Analytics ein. Außerhalb der Arbeit genießt er die Natur.

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, hochleistungsfähige Modellinferenz auf SageMaker zu erreichen.

Qing Lan ist Softwareentwicklungsingenieur bei AWS. Er hat an mehreren herausfordernden Produkten bei Amazon gearbeitet, darunter Hochleistungs-ML-Inferenzlösungen und Hochleistungs-Protokollierungssysteme. Das Team von Qing führte erfolgreich das erste Billion-Parameter-Modell in Amazon Advertising mit sehr geringer Latenz ein. Qing verfügt über fundierte Kenntnisse in den Bereichen Infrastrukturoptimierung und Deep-Learning-Beschleunigung.

Qingwei Li ist Spezialist für maschinelles Lernen bei Amazon Web Services. Er erhielt seinen Ph.D. in Operations Research, nachdem er das Konto seines Beraters für Forschungsstipendien aufgelöst und den versprochenen Nobelpreis nicht geliefert hatte. Derzeit hilft er Kunden in der Finanzdienstleistungs- und Versicherungsbranche beim Aufbau von Lösungen für maschinelles Lernen auf AWS. In seiner Freizeit liest und unterrichtet er gerne.

Robert Van Dusen ist Senior Product Manager bei Amazon SageMaker. Er leitet die Deep-Learning-Modelloptimierung für Anwendungen wie die Inferenz großer Modelle.

Siddharth Venkatesan ist Software Engineer bei AWS Deep Learning. Derzeit konzentriert er sich auf die Entwicklung von Lösungen für die Inferenz großer Modelle. Vor AWS arbeitete er in der Amazon Grocery-Organisation am Aufbau neuer Zahlungsfunktionen für Kunden auf der ganzen Welt. Außerhalb der Arbeit fährt er gerne Ski, ist in der Natur und schaut sich Sport an.