Maximieren Sie die stabile Diffusionsleistung und senken Sie die Inferenzkosten mit AWS Inferentia2 | Amazon Web Services

Generative KI-Modelle verzeichneten in den letzten Monaten aufgrund ihrer beeindruckenden Fähigkeiten bei der Erstellung realistischer Texte, Bilder, Codes und Audiodaten ein rasantes Wachstum. Unter diesen Modellen zeichnen sich die Stable Diffusion-Modelle durch ihre einzigartige Stärke bei der Erstellung hochwertiger Bilder auf der Grundlage von Textaufforderungen aus. Stable Diffusion kann eine Vielzahl hochwertiger Bilder erzeugen, darunter realistische Porträts, Landschaften und sogar abstrakte Kunst. Und wie andere generative KI-Modelle erfordern Stable Diffusion-Modelle eine leistungsstarke Rechenleistung, um Inferenzen mit geringer Latenz zu ermöglichen.

In diesem Beitrag zeigen wir, wie Sie Stable Diffusion-Modelle ausführen und eine hohe Leistung zu den niedrigsten Kosten erzielen können Amazon Elastic Compute-Cloud (Amazon EC2) verwenden Amazon EC2 Inf2-Instanzen YOGA MODE AWS Inferentia2. Wir betrachten die Architektur eines Stable-Diffusion-Modells und gehen durch die Schritte zum Kompilieren eines Stable-Diffusion-Modells mit AWS-Neuron und Bereitstellung auf einer Inf2-Instanz. Wir diskutieren auch die Optimierungen, die das Neuron SDK automatisch vornimmt, um die Leistung zu verbessern. Sie können sowohl die Versionen Stable Diffusion 2.1 als auch 1.5 kostengünstig auf AWS Inferentia2 ausführen. Abschließend zeigen wir, wie Sie mit ein Stable Diffusion-Modell auf einer Inf2-Instanz bereitstellen können Amazon Sage Maker.

Die Modellgröße von Stable Diffusion 2.1 in Gleitkomma 32 (FP32) beträgt 5 GB und in bfoat2.5 (BF16) 16 GB. Eine einzelne inf2.xlarge-Instanz verfügt über einen AWS Inferentia2-Beschleuniger mit 32 GB HBM-Speicher. Das Stable Diffusion 2.1-Modell passt auf eine einzelne inf2.xlarge-Instanz. Stable Diffusion ist ein Text-zu-Bild-Modell, mit dem Sie Bilder mit unterschiedlichen Stilen und Inhalten erstellen können, indem Sie einfach eine Textaufforderung als Eingabe bereitstellen. Weitere Informationen zur Architektur des Stable Diffusion-Modells finden Sie unter Erstellen Sie hochwertige Bilder mit Stable Diffusion-Modellen und stellen Sie diese kosteneffizient mit Amazon SageMaker bereit.

Wie das Neuron SDK die Leistung der stabilen Diffusion optimiert

Bevor wir das Stable Diffusion 2.1-Modell auf AWS Inferentia2-Instanzen bereitstellen können, müssen wir die Modellkomponenten mithilfe von kompilieren Neuron-SDK. Das Neuron SDK, das einen Deep-Learning-Compiler, eine Laufzeit und Tools umfasst, kompiliert und optimiert automatisch Deep-Learning-Modelle, damit sie effizient auf Inf2-Instanzen ausgeführt werden und die volle Leistung des AWS Inferentia2-Beschleunigers nutzen können. Wir haben Beispiele für das Stable Diffusion 2.1-Modell auf der Website GitHub Repo. Dieses Notebook stellt ein End-to-End-Beispiel dar, wie man ein Stable Diffusion-Modell kompiliert, die kompilierten Neuron-Modelle speichert und es zur Inferenz in die Laufzeit lädt.

Wir verwenden StableDiffusionPipeline aus dem Hugging Face diffusers Bibliothek zum Laden und Kompilieren des Modells. Anschließend kompilieren wir alle Komponenten des Modells für Neuron torch_neuronx.trace() und speichern Sie das optimierte Modell als TorchScript. Kompilierungsvorgänge können sehr speicherintensiv sein und viel RAM erfordern. Um dies zu umgehen, erstellen wir vor der Verfolgung jedes Modells ein deepcopy des Teils der Pipeline, der verfolgt wird. Anschließend löschen wir das Pipeline-Objekt mit aus dem Speicher del pipe. Diese Technik ist besonders nützlich beim Kompilieren auf Instanzen mit wenig RAM.

Darüber hinaus führen wir auch Optimierungen an den Stable Diffusion-Modellen durch. UNet enthält den rechenintensivsten Aspekt der Schlussfolgerung. Die UNet-Komponente verarbeitet Eingabetensoren mit einer Stapelgröße von zwei und generiert einen entsprechenden Ausgabetensor ebenfalls mit einer Stapelgröße von zwei, um ein einzelnes Bild zu erzeugen. Die Elemente innerhalb dieser Chargen sind völlig unabhängig voneinander. Wir können dieses Verhalten ausnutzen, um eine optimale Latenz zu erzielen, indem wir auf jedem Neuron-Kern einen Batch ausführen. Wir kompilieren das UNet für einen Batch (indem wir Eingabetensoren mit einem Batch verwenden) und verwenden dann das torch_neuronx.DataParallel API zum Laden dieses einzelnen Batch-Modells auf jeden Kern. Die Ausgabe dieser API ist ein nahtloses Zwei-Batch-Modul: Wir können die Eingaben von zwei Batches an das UNet übergeben, und es wird eine Zwei-Batch-Ausgabe zurückgegeben, aber intern laufen die beiden Single-Batch-Modelle auf den beiden Neuron-Kernen . Diese Strategie optimiert die Ressourcennutzung und reduziert die Latenz.

Kompilieren Sie ein Stable Diffusion-Modell und stellen Sie es auf einer Inf2 EC2-Instanz bereit

Um das Stable Diffusion-Modell auf einer Inf2 EC2-Instanz zu kompilieren und bereitzustellen, melden Sie sich bei an AWS-Managementkonsole und erstellen Sie eine inf2.8xlarge-Instanz. Beachten Sie, dass eine inf2.8xlarge-Instanz nur für die Kompilierung des Modells erforderlich ist, da für die Kompilierung ein höherer Hostspeicher erforderlich ist. Das Stable Diffusion-Modell kann auf einer inf2.xlarge-Instanz gehostet werden. Sie können die neuesten AMI mit Neuron-Bibliotheken wie folgt finden AWS-Befehlszeilenschnittstelle Befehl (AWS CLI):

aws ec2 describe-images --region us-east-1 --owners amazon --filters 'Name=name,Values=Deep Learning AMI Neuron PyTorch 1.13.? (Amazon Linux 2) ????????' 'Name=state,Values=available' --query 'reverse(sort_by(Images, &CreationDate))[:1].ImageId' --output text

Für dieses Beispiel haben wir eine EC2-Instanz mit dem Deep Learning AMI Neuron PyTorch 1.13 (Ubuntu 20.04) erstellt. Anschließend können Sie eine JupyterLab-Laborumgebung erstellen, indem Sie eine Verbindung zur Instanz herstellen und die folgenden Schritte ausführen:

run source /opt/aws_neuron_venv_pytorch/bin/activate
pip install jupyterlab
jupyter-lab

Ein Notebook mit allen Schritten zum Kompilieren und Hosten des Modells befindet sich auf GitHub.

Schauen wir uns die Kompilierungsschritte für einen der Text-Encoder-Blöcke an. Andere Blöcke, die Teil der Stable Diffusion-Pipeline sind, können auf ähnliche Weise kompiliert werden.

Der erste Schritt besteht darin, das vorab trainierte Modell von Hugging Face zu laden. Der StableDiffusionPipeline.from_pretrained Die Methode lädt das vorab trainierte Modell in unser Pipeline-Objekt. pipe. Wir erstellen dann eine deepcopy des Text-Encoders aus unserer Pipeline, wodurch er effektiv geklont wird. Der del pipe Der Befehl wird dann verwendet, um das ursprüngliche Pipeline-Objekt zu löschen und so den von ihm verbrauchten Speicher freizugeben. Hier quantisieren wir das Modell auf BF16-Gewichte:

model_id = "stabilityai/stable-diffusion-2-1-base"
pipe = StableDiffusionPipeline.from_pretrained(model_id, torch_dtype=torch.bfloat16)
text_encoder = copy.deepcopy(pipe.text_encoder)
del pipe

Dieser Schritt beinhaltet das Umschließen unseres Text-Encoders mit dem NeuronTextEncoder Verpackung. Die Ausgabe eines kompilierten Text-Encoder-Moduls ist von dict. Wir konvertieren es in a list Geben Sie mit diesem Wrapper Folgendes ein:

text_encoder = NeuronTextEncoder(text_encoder)

Wir initialisieren den PyTorch-Tensor emb mit einigen Werten. Der emb Tensor wird als Beispieleingabe für verwendet torch_neuronx.trace Funktion. Diese Funktion verfolgt unseren Text-Encoder und kompiliert ihn in ein für Neuron optimiertes Format. Der Verzeichnispfad für das kompilierte Modell wird durch Zusammenfügen erstellt COMPILER_WORKDIR_ROOT mit dem Unterverzeichnis text_encoder:

emb = torch.tensor([...])
text_encoder_neuron = torch_neuronx.trace(
        text_encoder.neuron_text_encoder,
        emb,
        compiler_workdir=os.path.join(COMPILER_WORKDIR_ROOT, 'text_encoder'),
        )

Der kompilierte Text-Encoder wird mit gespeichert torch.jit.save. Es wird unter dem Dateinamen model.pt im gespeichert text_encoder Verzeichnis des Arbeitsbereichs unseres Compilers:

text_encoder_filename = os.path.join(COMPILER_WORKDIR_ROOT, 'text_encoder/model.pt')
torch.jit.save(text_encoder_neuron, text_encoder_filename)

Das Notizbuch Enthält ähnliche Schritte zum Kompilieren anderer Komponenten des Modells: UNet, VAE-Decoder und VAE post_quant_conv. Nachdem Sie alle Modelle kompiliert haben, können Sie das Modell wie folgt laden und ausführen:

1. Definieren Sie die Pfade für die kompilierten Modelle.
2. Laden Sie ein vorab trainiertes StableDiffusionPipeline Modell, dessen Konfiguration für die Verwendung des Datentyps bfloat16 angegeben ist.
3. Laden Sie das UNet-Modell mit auf zwei Neuron-Kerne torch_neuronx.DataParallel API. Dadurch kann eine datenparallele Inferenz durchgeführt werden, was die Modellleistung erheblich beschleunigen kann.
4. Laden Sie die restlichen Teile des Modells (text_encoder, decoder und post_quant_conv) auf einen einzelnen Neuronenkern.

Anschließend können Sie die Pipeline ausführen, indem Sie Eingabetext als Eingabeaufforderungen bereitstellen. Im Folgenden sind einige vom Modell für die Eingabeaufforderungen generierte Bilder aufgeführt:

• Porträt von Renaud Sechan, Feder und Tinte, komplizierte Strichzeichnungen, von Craig Mullins, Ruan Jia, Kentaro Miura, Greg Rutkowski, Loundraw

• Porträt eines alten Bergarbeiters aus dem 19. Jahrhundert, wunderschönes Gemälde, mit sehr detaillierter Gesichtsbemalung von Greg Rutkowski

• Ein Schloss mitten im Wald

Hosten Sie Stable Diffusion 2.1 auf AWS Inferentia2 und SageMaker

Das Hosten stabiler Diffusionsmodelle mit SageMaker erfordert auch die Kompilierung mit dem Neuron SDK. Sie können die Kompilierung vorab oder während der Laufzeit mithilfe von LMI-Containern (Large Model Inference) abschließen. Eine vorzeitige Kompilierung ermöglicht schnellere Modellladezeiten und ist die bevorzugte Option.

SageMaker LMI-Container bieten zwei Möglichkeiten zur Bereitstellung des Modells:

• Eine No-Code-Option, bei der wir lediglich eine bereitstellen serving.properties Datei mit den erforderlichen Konfigurationen
• Bringen Sie Ihr eigenes Inferenzskript mit

Wir schauen uns beide Lösungen an und gehen die Konfigurationen und das Inferenzskript durch (model.py). In diesem Beitrag demonstrieren wir die Bereitstellung mithilfe eines vorkompilierten Modells, das in einem gespeichert ist Amazon Simple Storage-Service (Amazon S3) Eimer. Sie können dieses vorkompilierte Modell für Ihre Bereitstellungen verwenden.

Konfigurieren Sie das Modell mit einem bereitgestellten Skript

In diesem Abschnitt zeigen wir, wie Sie den LMI-Container zum Hosten der Stable Diffusion-Modelle konfigurieren. Das SD2.1-Notebook ist verfügbar unter GitHub. Der erste Schritt besteht darin, das Modellkonfigurationspaket gemäß der folgenden Verzeichnisstruktur zu erstellen. Unser Ziel ist es, die minimalen Modellkonfigurationen zu verwenden, die zum Hosten des Modells erforderlich sind. Die benötigte Verzeichnisstruktur ist wie folgt:

<config-root-directory> / 
    ├── serving.properties
    │   
    └── model.py [OPTIONAL]

Als nächstes erstellen wir die dienende.Eigenschaften Datei mit den folgenden Parametern:

%%writefile code_sd/serving.properties
engine=Python
option.entryPoint=djl_python.transformers-neuronx
option.use_stable_diffusion=True
option.model_id=s3url
option.tensor_parallel_degree=2
option.dtype=bf16

Die Parameter legen Folgendes fest:

• option.model_id – Die LMI-Container verwenden s5cmd, um das Modell vom S3-Speicherort zu laden, und daher müssen wir den Speicherort angeben, an dem sich unsere kompilierten Gewichte befinden.
• option.entryPoint – Um die integrierten Handler zu verwenden, geben wir die Klasse „transformers-neuronx“ an. Wenn Sie über ein benutzerdefiniertes Inferenzskript verfügen, müssen Sie stattdessen dieses bereitstellen.
• option.dtype – Dies legt fest, dass die Gewichte in einer bestimmten Größe geladen werden sollen. Für diesen Beitrag verwenden wir BF16, was unseren Speicherbedarf im Vergleich zu FP32 weiter reduziert und dadurch unsere Latenz verringert.
• option.tensor_parallel_degree – Dieser Parameter gibt die Anzahl der Beschleuniger an, die wir für dieses Modell verwenden. Der AWS Inferentia2-Chipbeschleuniger verfügt über zwei Neuron-Kerne. Die Angabe eines Werts von 2 bedeutet also, dass wir einen Beschleuniger (zwei Kerne) verwenden. Das bedeutet, dass wir jetzt mehrere Worker erstellen können, um den Durchsatz des Endpunkts zu erhöhen.
• option.engine – Dies ist auf Python eingestellt, um anzuzeigen, dass wir für dieses Hosting keine anderen Compiler wie DeepSpeed ​​oder Faster Transformer verwenden.

Bringen Sie Ihr eigenes Skript mit

Wenn Sie Ihr eigenes benutzerdefiniertes Inferenzskript mitbringen möchten, müssen Sie das entfernen option.entryPoint für serving.properties. Der LMI-Container sucht in diesem Fall nach a model.py Datei am selben Ort wie die serving.properties und verwenden Sie dies, um die Inferenz auszuführen.

Erstellen Sie Ihr eigenes Inferenzskript (model.py)

Das Erstellen eines eigenen Inferenzskripts ist mit dem LMI-Container relativ einfach. Der Container erfordert Ihre model.py Datei, um eine Implementierung der folgenden Methode zu haben:

def handle(inputs: Input) which returns an object of type Outputs

Lassen Sie uns einige der kritischen Bereiche untersuchen beigefügtes Notizbuch, das die Bring-Your-Own-Script-Funktion demonstriert.

Ersetzen Sie die cross_attention Modul mit der optimierten Version:

# Replace original cross-attention module with custom cross-attention module for better performance
    CrossAttention.get_attention_scores = get_attention_scores
Load the compiled weights for the following
text_encoder_filename = os.path.join(COMPILER_WORKDIR_ROOT, 'text_encoder.pt')
decoder_filename = os.path.join(COMPILER_WORKDIR_ROOT, 'vae_decoder.pt')
unet_filename = os.path.join(COMPILER_WORKDIR_ROOT, 'unet.pt')
post_quant_conv_filename =. os.path.join(COMPILER_WORKDIR_ROOT, 'vae_post_quant_conv.pt')

Dies sind die Namen der kompilierten Gewichtungsdatei, die wir beim Erstellen der Zusammenstellungen verwendet haben. Sie können die Dateinamen gerne ändern, aber stellen Sie sicher, dass die Namen Ihrer Gewichtungsdateien mit den hier angegebenen übereinstimmen.

Dann müssen wir sie mit dem Neuron SDK laden und sie auf die tatsächlichen Modellgewichte einstellen. Beachten Sie beim Laden der für UNet optimierten Gewichte, dass wir auch die Anzahl der Neuron-Kerne angeben, auf die wir diese laden müssen. Hier laden wir auf einen einzelnen Beschleuniger mit zwei Kernen:

# Load the compiled UNet onto two neuron cores.
    pipe.unet = NeuronUNet(UNetWrap(pipe.unet))
    logging.info(f"Loading model: unet:created")
    device_ids = [idx for idx in range(tensor_parallel_degree)]
   
    pipe.unet.unetwrap = torch_neuronx.DataParallel(torch.jit.load(unet_filename), device_ids, set_dynamic_batching=False)
   
 
    # Load other compiled models onto a single neuron core.
 
    # - load encoders
    pipe.text_encoder = NeuronTextEncoder(pipe.text_encoder)
    clip_compiled = torch.jit.load(text_encoder_filename)
    pipe.text_encoder.neuron_text_encoder = clip_compiled
    #- load decoders
    pipe.vae.decoder = torch.jit.load(decoder_filename)
    pipe.vae.post_quant_conv = torch.jit.load(post_quant_conv_filename)

Das Ausführen der Inferenz mit einer Eingabeaufforderung ruft das Pipe-Objekt auf, um ein Bild zu generieren.

Erstellen Sie den SageMaker-Endpunkt

Wir verwenden Boto3-APIs, um einen SageMaker-Endpunkt zu erstellen. Führen Sie die folgenden Schritte aus:

1. Erstellen Sie den Tarball nur mit der Portion und dem optionalen model.py Dateien und laden Sie sie auf Amazon S3 hoch.
2. Erstellen Sie das Modell mithilfe des Bildcontainers und des zuvor hochgeladenen Modell-Tarballs.
3. Erstellen Sie die Endpunktkonfiguration mit den folgenden Schlüsselparametern:
   1. Benutze ein ml.inf2.xlarge Beispiel.
   2. Sept ContainerStartupHealthCheckTimeoutInSeconds auf 240, um sicherzustellen, dass die Integritätsprüfung nach der Bereitstellung des Modells beginnt.
   3. Sept VolumeInGB auf einen größeren Wert, sodass es zum Laden von Modellgewichten mit einer Größe von 32 GB verwendet werden kann.

Erstellen Sie ein SageMaker-Modell

Nachdem Sie die Datei „model.tar.gz“ erstellt und auf Amazon S3 hochgeladen haben, müssen wir ein SageMaker-Modell erstellen. Wir verwenden den LMI-Container und das Modellartefakt aus dem vorherigen Schritt, um das SageMaker-Modell zu erstellen. Mit SageMaker können wir verschiedene Umgebungsvariablen anpassen und einfügen. Für diesen Workflow können wir alles als Standard belassen. Siehe den folgenden Code:

inference_image_uri = (
    f"763104351884.dkr.ecr.{region}.amazonaws.com/djl-inference:0 djl-serving-inf2"
)

Erstellen Sie das Modellobjekt, das im Wesentlichen einen Sperrcontainer erstellt, der auf die Instanz geladen und für Rückschlüsse verwendet wird:

model_name = name_from_base(f"inf2-sd")
create_model_response = boto3_sm_client.create_model(
    ModelName=model_name,
    ExecutionRoleArn=role,
    PrimaryContainer={"Image": inference_image_uri, "ModelDataUrl": s3_code_artifact},
)

Erstellen Sie einen SageMaker-Endpunkt

In dieser Demo verwenden wir eine ml.inf2.xlarge-Instanz. Wir müssen das einstellen VolumeSizeInGB Parameter, um den erforderlichen Speicherplatz zum Laden des Modells und der Gewichte bereitzustellen. Dieser Parameter gilt für Instanzen, die das unterstützen Amazon Elastic Block-Shop (Amazon EBS) Volumenanhang. Wir können das Modell-Download-Timeout und die Container-Start-Zustandsprüfung auf einem höheren Wert belassen, was dem Container ausreichend Zeit gibt, die Gewichte von Amazon S3 abzurufen und in die AWS Inferentia2-Beschleuniger zu laden. Weitere Einzelheiten finden Sie unter CreateEndpointConfig.

endpoint_config_response = boto3_sm_client.create_endpoint_config( EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "variant1",
            "ModelName": model_name,
            "InstanceType": "ml.inf2.xlarge", # - 
            "InitialInstanceCount": 1,
            "ContainerStartupHealthCheckTimeoutInSeconds": 360, 
            "VolumeSizeInGB": 400
        },
    ],
)

Zuletzt erstellen wir einen SageMaker-Endpunkt:

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

Rufen Sie den Modellendpunkt auf

Da es sich um ein generatives Modell handelt, übergeben wir die Eingabeaufforderung, die das Modell zum Generieren des Bildes verwendet. Die Nutzlast ist vom Typ JSON:

response_model = boto3_sm_run_client.invoke_endpoint( EndpointName=endpoint_name,
    Body=json.dumps(
        {
            "prompt": "Mountain Landscape", 
            "parameters": {} # 
        }
    ), 
    ContentType="application/json",
)

Benchmarking des stabilen Diffusionsmodells auf Inf2

Wir haben einige Tests durchgeführt, um das Stable Diffusion-Modell mit dem Datentyp BF 16 auf Inf2 zu vergleichen, und wir sind in der Lage, Latenzzahlen abzuleiten, die mit einigen anderen Beschleunigern für Stable Diffusion mithalten oder diese sogar übertreffen. Dies, gepaart mit den geringeren Kosten der AWS Inferentia2-Chips, macht dies zu einem äußerst wertvollen Angebot.

Die folgenden Zahlen stammen aus dem Stable Diffusion-Modell, das auf einer inf2.xl-Instanz bereitgestellt wird. Weitere Informationen zu den Kosten finden Sie unter Amazon EC2 Inf2-Instanzen.

Zusammenfassung

In diesem Beitrag haben wir uns eingehend mit der Kompilierung, Optimierung und Bereitstellung des Stable Diffusion 2.1-Modells mithilfe von Inf2-Instanzen befasst. Wir haben auch den Einsatz stabiler Diffusionsmodelle mit SageMaker demonstriert. Inf2-Instanzen bieten auch ein hervorragendes Preis-Leistungs-Verhältnis für Stable Diffusion 1.5. Weitere Informationen darüber, warum sich Inf2-Instanzen hervorragend für generative KI und große Sprachmodelle eignen, finden Sie unter Amazon EC2 Inf2-Instanzen für kostengünstige, leistungsstarke generative KI-Inferenz sind jetzt allgemein verfügbar. Einzelheiten zur Leistung finden Sie unter Inf2-Leistung. Schauen Sie sich weitere Beispiele an GitHub Repo.

Besonderer Dank geht an Matthew Mcclain, Beni Hegedus, Kamran Khan, Shruti Koparkar und Qing Lan für die Durchsicht und Bereitstellung wertvoller Beiträge.

Über die Autoren

Vivek Gangasani ist Senior Machine Learning Solutions Architect bei Amazon Web Services. Er arbeitet mit Startups für maschinelles Lernen zusammen, um KI/ML-Anwendungen auf AWS zu erstellen und bereitzustellen. Derzeit konzentriert er sich auf die Bereitstellung von Lösungen für MLOps, ML-Inferenz und Low-Code-ML. Er hat an Projekten in verschiedenen Bereichen gearbeitet, darunter Verarbeitung natürlicher Sprache und Computer Vision.

KC Tung ist Senior Solution Architect bei AWS Annapurna Labs. Er ist spezialisiert auf das Training großer Deep-Learning-Modelle und die Bereitstellung in großem Maßstab in der Cloud. Er hat einen Ph.D. in molekularer Biophysik vom University of Texas Southwestern Medical Center in Dallas. Er hat auf AWS Summits und AWS Reinvent gesprochen. Heute hilft er Kunden beim Trainieren und Bereitstellen großer PyTorch- und TensorFlow-Modelle in der AWS-Cloud. Er ist Autor zweier Bücher: Lernen Sie TensorFlow Enterprise kennen und TensorFlow 2 Pocket-Referenz.

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.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Automobil / Elektrofahrzeuge, Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• BlockOffsets. Modernisierung des Eigentums an Umweltkompensationen. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/maximize-stable-diffusion-performance-and-lower-inference-costs-with-aws-inferentia2/