Opret, træne og implementer en milliard-parameter sprogmodel på terabyte data med TensorFlow og Amazon SageMaker

Den stigende størrelse af sprogmodeller har været en af ​​de største tendenser inden for naturlig sprogbehandling (NLP) i de senere år. Siden 2018 har vi set hidtil uset udvikling og implementering af stadig større sprogmodeller, inklusive BERT og dets varianter, GPT-2, T-NLG og GPT-3 (175 milliarder parametre).

Disse modeller har rykket grænserne for mulige arkitektoniske innovationer. Vi står over for adskillige udfordringer, når vi træner deep learning-modeller i stor skala, især den nye bølge af generative fortrænede transformatorer. Disse udfordringer omfatter hardwarebegrænsninger og afvejninger med beregning og effektivitet. For at overvinde disse udfordringer med model- og dataparallelisme tilbyder AWS en bred vifte af muligheder.

I dette indlæg introducerer vi to hovedtilgange: dataparallelisering og modelparallelisering ved hjælp af Amazon SageMaker, og diskutere deres fordele og ulemper.

Modellen

Til sprogmodellen bruger vi Transformers, introduceret i papiret Opmærksomhed er alt hvad du behøver. Transformere er deep learning-modeller designet til bevidst at undgå faldgruberne i RNN'er ved at stole på en selvopmærksomhedsmekanisme til at tegne globale afhængigheder mellem input og output. Transformer-modelarkitekturen giver mulighed for væsentlig bedre parallelisering og kan opnå høj ydeevne på relativt kort træningstid. Bygget på succesen med Transformers, BERT, introduceret i avisen BERT: Fortræning af dybe tovejstransformere til sprogforståelse, tilføjet tovejs fortræning til sprogrepræsentation. Inspireret af Cloze-opgaven er BERT fortrænet med masked language modeling (MLM), hvor modellen lærer at gendanne de originale ord for tilfældigt maskerede tokens. BERT-modellen er også fortrænet på den næste sætningsforudsigelse (NSP) opgave til at forudsige, om to sætninger er i korrekt læserækkefølge. Siden dets fremkomst i 2018 har BERT og dets variationer været meget brugt i sprogmodeller.

Vi begynder med at skabe to indlejringslag til token- og positionsindlejring. Input-indlejringerne er summen af ​​token-indlejringer og positionsindlejringer.

class TokenAndPositionEmbedding(tf.keras.layers.Layer): """ Creates two separate embedding layers: one for tokens and one for token index (positions). """ def __init__(self, maxlen, vocab_size, embed_dim): super(TokenAndPositionEmbedding, self).__init__() self.token_emb = tf.keras.layers.Embedding(input_dim=vocab_size, output_dim=embed_dim) self.pos_emb = tf.keras.layers.Embedding(input_dim=maxlen, output_dim=embed_dim) def call(self, x): maxlen = tf.shape(x)[-1] # positions are represented by a token's index positions = tf.range(start=0, limit=maxlen, delta=1) positions = self.pos_emb(positions) # token embedding x = self.token_emb(x) # return sum as input return x + positions

Derefter definerer vi en transformer-dekoderblok med to underlag: et multi-head selvopmærksomhedslag og et simpelt fuldt tilsluttet feed-forward-netværk efterfulgt af lagnormalisering og dropout:

class TransformerBlock(tf.keras.layers.Layer): def __init__(self, embed_dim, num_heads, ff_dim, rate=0.1): # self attention layer super(TransformerBlock, self).__init__() self.att = tf.keras.layers.MultiHeadAttention( num_heads=num_heads, key_dim=embed_dim) # feed forward layer self.ffn = [tf.keras.layers.Dense(ff_dim, activation="relu"), tf.keras.layers.Dense(embed_dim)] # layer normalization self.layernorm1 = tf.keras.layers.LayerNormalization(epsilon=1e-6) self.layernorm2 = tf.keras.layers.LayerNormalization(epsilon=1e-6) # dropout self.dropout1 = tf.keras.layers.Dropout(rate) self.dropout2 = tf.keras.layers.Dropout(rate) def call(self, inputs): # getting batch size and seq len from input shape input_shape = tf.shape(inputs) batch_size = input_shape[0] seq_len = input_shape[1] # decoder casual mask casual_mask = casual_attention_mask(batch_size, seq_len, seq_len, tf.bool) # self attention forward pass attention_output = self.att(inputs, inputs, attention_mask=causal_mask) # dense layers, dropout and normalization attention_output = self.dropout1(attention_output) ffn_output = self.ffn[0](out1) ffn_output = self.ffn[1](ffn_output) out2 = self.dropout2(ffn_output) return self.layernorm2(out1 + out2)

Til sidst skaber vi vores sprogmodel med det foregående indlejringslag og transformerblokke:

class MyModel(tf.keras.Model): def __init__(self, maxlen, vocab_size, embed_dim, num_heads, feed_forward_dim, num_layers, learning_rate): super(MyModel, self).__init__(maxlen, vocab_size, embed_dim, num_heads, feed_forward_dim, num_layers, learning_rate) # embedding layer self.embedding_layer = TokenAndPositionEmbedding(maxlen, vocab_size, embed_dim) # transformer blocks self.transformer_blocks = [ TransformerBlock(embed_dim, num_heads, feed_forward_dim) for i in range(num_layers) ] # last dense layer self.dense = tf.keras.layers.Dense(vocab_size) def call(self, inputs, training=None): x_emb = self.embedding_layer(inputs) x = x_emb for transformer_block in self.transformer_blocks: x = transformer_block(x) outputs = self.dense(x) return [outputs, x_emb] def init_train_settings(maxlen, vocab_size, embed_dim, num_heads, feed_forward_dim, num_layers, learning_rate): """ Creates model, optimizer and loss function """ model = MyModel(maxlen, vocab_size, embed_dim, num_heads, feed_forward_dim, num_layers, learning_rate) loss_fn = tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True) optimizer = tf.keras.optimizers.Adam(learning_rate=learning_rate) return model, optimizer, loss_fn

Afhængigt af dine hyperparametre kan du skalere denne model fra tusindvis af parametre til milliarder af parametre. Den primære udfordring med milliardparametermodeller er, at du ikke kan være vært for modellen i én instans og skal fordele modellen over flere noder til træning og inferens.

Datasættet

I vores eksperimenter brugte vi Bunkedatasæt. The Pile er et 800 GiB engelsk tekstdatasæt designet til træning af store sprogmodeller. Det er skabt af 22 forskellige datasæt af høj kvalitet, herunder både etablerede NLP-datasæt og nyligt introducerede.

Datasættet er skabt ud fra en række forskellige datakilder, herunder bøger; GitHub repositories; web sider; chat logs; og artikler om medicin, fysik, matematik, datalogi og filosofi. Specifikt bruger den følgende kilder: Pile-CC, PubMed Central, ArXiv, GitHub, FreeLaw Project, Stack Exchange, US Patent and Trademark Office, PubMed, Ubuntu, IRC, HackerNews, YouTube, PhilPapers, Books3, Project Gutenberg ( PG-19), OpenSubtitles, engelsk Wikipedia, DM Mathematics, EuroParl, Enron Emails corpus og NIH ExPorter. Det inkluderer også OpenWebText2 og BookCorpus2, som er udvidelser af henholdsvis de originale OpenWebText- og BookCorpus-datasæt. Mangfoldigheden i datakilder kan forbedre den generelle viden på tværs af domæner og følgelig forbedre downstream-generaliseringskapaciteten.

Den primære udfordring med dette datasæt er den store størrelse; datasættet har 825 GiB tekst, hvilket omsættes til 4.2 TiB forbehandlede og komprimerede datapunkter. I lighed med de udfordringer, vi står over for med træning og hosting af modellerne, vil træning af en model med dette datasæt på en enkelt instans tage meget tid og er ikke praktisk.

Vores løsning er at opdele datasættet i ca. 1 GiB datastykker, indlæse og forbehandle funktionerne i TensorFlow-datasæt genstande og opbevare dem i Amazon Elastic File Service (Amazon EFS). TensorFlow-datasæt giver en brugervenlig og højtydende datapipeline, der integreres godt med vores modeller. Amazon EFS er en brugervenlig tjeneste, der gør os i stand til at bygge et delt filsystem, der automatisk skaleres, når filer tilføjes og slettes. Derudover er Amazon EFS i stand til at springe til højere gennemstrømningsniveauer, når det er nødvendigt, hvilket er afgørende i vores data- og modeltræningspipeline.

Dernæst ser vi på distribuerede træningsstrategier for at tackle disse udfordringer.

Distribueret træning

I dette projekt stod vi over for to udfordringer: skalering af modelstørrelse og datavolumen. Forøgelse af modelstørrelsen og antallet af parametre, der kan trænes, kan resultere i bedre nøjagtighed, men der er en grænse for den model, du kan passe ind i en enkelt GPU-hukommelse eller endda flere GPU'er i et enkelt tilfælde. Derudover tager større modelstørrelser mere tid at træne.

Du kan tackle disse udfordringer på to forskellige måder: dataparallelisme og modelparallelisme. Med dataparallelisme udfører vi Stokastisk Gradient Descent (SGD) ved at distribuere registreringerne af en mini-batch over forskellige enheder for at fremskynde træningen. Parallel datatræning kommer dog med ekstra kompleksitet ved beregning af mini-batch gradientgennemsnit med gradienter fra alle enheder, et trin kaldet AllReduce, hvilket bliver sværere i takt med at træningsklyngen vokser. Mens vi bruger dataparallelisme, skal vi være i stand til at passe modellen og et enkelt datapunkt i en enhed (CPU eller GPU), hvilket er en begrænsende faktor i vores eksperimenter, fordi størrelsen af ​​en så stor model er meget større end den enkelte GPU's hukommelse størrelse.

En anden løsning er at bruge modelparallelisme, som opdeler modellen over flere enheder. Modelparallelisme er processen med at opdele en model mellem flere enheder eller noder (såsom GPU-udstyrede instanser) og skabe en effektiv pipeline til at træne modellen på tværs af disse enheder for at maksimere GPU-udnyttelsen.

Dataparallelisering

Parallelisering af data er den mest almindelige tilgang til flere GPU'er eller distribueret træning. Du kan batch dine data, sende dem til flere enheder (hver er vært for en replikeret model) og derefter samle resultaterne. Vi eksperimenterede med to pakker til dataparallelisering: Horovod og SageMaker distribuerede data parallelbibliotek.

Horovod er en distribueret deep learning-træningsramme for TensorFlow, Keras, PyTorch og Apache MXNet. For at bruge Horovod gik vi igennem følgende proces:

1. Initialiser ved at køre hvd.init().
2. Knyt hver enhed til en enkelt proces. Den første proces eller arbejder er knyttet til den første enhed, den anden proces er knyttet til den anden enhed, og så videre.
3. Juster indlæringshastigheden baseret på antallet af enheder.
4. Pak optimizeren ind hvd.DistributedOptimizer.
5. Udsend de indledende variable tilstande fra den første arbejder med rang 0 til alle andre processer. Dette er nødvendigt for at sikre ensartet initialisering af alle arbejdere, når træning startes med tilfældige vægte eller genoprettes fra et kontrolpunkt.
6. Sørg for, at kun enhed 0 kan gemme kontrolpunkter for at forhindre andre arbejdere i at ødelægge dem.

Følgende er træningsscriptet:

import horovod.tensorflow as hvd
# Initialize Horovod
hvd.init() # Pin GPU to be used to process local rank (one GPU per process)
gpus = tf.config.experimental.list_physical_devices('GPU')
for gpu in gpus: tf.config.experimental.set_memory_growth(gpu, True)
if gpus: tf.config.experimental.set_visible_devices(gpus[hvd.local_rank()], 'GPU') # Build model
... @tf.function
def training_step(texts, labels, first_batch): with tf.GradientTape() as tape: predictions = model(texts, training=True) loss = loss_fn(labels, predictions[0]) # Horovod: add Horovod Distributed GradientTape. tape = hvd.DistributedGradientTape(tape) grads = tape.gradient(loss, model.trainable_variables) opt.apply_gradients(zip(grads, model.trainable_variables)) # Horovod: broadcast initial variable states from rank 0 to all other processes. # This is necessary to ensure consistent initialization of all workers when # training is started with random weights or restored from a checkpoint. # # Note: broadcast should be done after the first gradient step to ensure optimizer # initialization. if first_batch: hvd.broadcast_variables(model.variables, root_rank=0) hvd.broadcast_variables(opt.variables(), root_rank=0) return loss # Horovod: adjust number of steps based on number of GPUs.
for batch, (texts, labels) in enumerate(dataset.take(10000 // hvd.size())): loss = training_step(texts, labels, batch == 0) if batch % 10 == 0 and hvd.local_rank() == 0: print('Step #%dtLoss: %.6f' % (batch, loss)) # Horovod: save checkpoints only on worker 0 to prevent other workers from
# corrupting it.
if hvd.rank() == 0: checkpoint.save(checkpoint_dir)

SageMaker dataparallelle bibliotek gør det muligt for os at skalere vores træning med næsten lineær effektivitet, hvilket fremskynder vores træning med minimale kodeændringer. Biblioteket udfører en skik AllReduce drift og optimerer enhed-til-enhed kommunikation ved fuldt ud at udnytte AWS's netværksinfrastruktur og Amazon Elastic Compute Cloud (Amazon EC2) instanstopologi. For at bruge SageMakers dataparallelle bibliotek gennemgik vi følgende proces:

1. Importer og initialiser sdp.init().
2. Tilknyt hver enhed med en enkelt smdistributed.dataparallel behandle med local_rank. sdp.tensorflow.local_rank() giver os den lokale rangering af enheder. Lederen er rang 0, og arbejdere er rang 1, 2, 3, og så videre.
3. Juster indlæringshastigheden baseret på antallet af enheder.
4. Wrap tf.GradientTape med DistributedGradientTape at optræde AllReduce.
5. Udsend de indledende modelvariabler fra lederknudepunktet til alle arbejderknudepunkter.
6. Sørg for, at kun enhed 0 kan gemme kontrolpunkter.

Model parallelisering

Vi kan justere hyperparametrene for at holde modellen lille nok til at træne ved hjælp af en enkelt GPU, eller vi kan bruge modelparallelisme til at opdele modellen mellem flere GPU'er på tværs af flere instanser. At øge en models antal af parametre, der kan trænes, kan resultere i bedre nøjagtighed, men der er en grænse for den maksimale modelstørrelse, du kan passe i en enkelt GPU-hukommelse. Vi brugte SageMaker distribuerede model parallelbibliotek til at træne vores større modeller. Trinene er som følger:

1. Importer og initialiser biblioteket med smp.init().
2. Keras-modellen skal arve fra smp.DistributedModel i stedet for Keras Model-klassen.
3. sæt drop_remainder=True i tf.Dataset.batch() metode til at sikre, at batchstørrelsen altid er delelig med antallet af mikrobatcher.
4. Tilfældige operationer i datapipelinen skal alle bruge det samme frø: smp.dp_rank(), For eksempel, shuffle(ds, seed=smp.dp_rank()). Dette sikrer konsistens af dataeksempler på tværs af enheder, der indeholder forskellige modelpartitioner.
5. Frem- og baglæns logik skal være i en trinfunktion med smp.step dekoration.
6. Udfør efterbehandling af udgangene på tværs af mikrobatcher ved hjælp af StepOutput-metoder som f.eks reduce_mean. Det smp.step funktion skal have en returværdi, der afhænger af outputtet af smp.DistributedModel.

Træningsscriptet er som følger:

import smdistributed.modelparallel.tensorflow as smp # SMP: Initialize
smp.init() # SMP: Define smp.DistributedModel the same way as Keras sub-classing API
class MyModel(smp.DistributedModel): def __init__(self, maxlen, vocab_size, embed_dim, num_heads, feed_forward_dim, num_layers, learning_rate): super(MyModel, self).__init__(maxlen, vocab_size, embed_dim, num_heads, feed_forward_dim, num_layers, learning_rate) self.embedding_layer = gpt_model.TokenAndPositionEmbedding(maxlen, vocab_size, embed_dim) self.transformer_blocks = [ gpt_model.TransformerBlock(embed_dim, num_heads, feed_forward_dim) for i in range(num_layers) ] self.dense = tf.keras.layers.Dense(vocab_size) def call(self, inputs, training=None): x_emb = self.embedding_layer(inputs) x = x_emb for transformer_block in self.transformer_blocks: x = transformer_block(x) outputs = self.dense(x) return [outputs, x_emb] # SMP: Define smp.step. Return any tensors needed outside
@smp.step
def get_grads(texts, labels): predictions = model(texts, training=True) loss = loss_fn(labels, predictions[0]) grads = optimizer.get_gradients(loss, model.trainable_variables) return grads, loss, predictions[0] @tf.function
def train_step(texts, labels, first_batch): gradients, loss, predictions = get_grads(texts, labels) # SMP: Accumulate the gradients across microbatches gradients = [g.accumulate() for g in gradients] optimizer.apply_gradients(zip(gradients, model.trainable_variables)) # SMP: Average the loss across microbatches train_loss(loss.reduce_mean()) # SMP: Merge predictions across microbatches train_accuracy(labels, predictions.merge()) return loss.reduce_mean() histories = [] for _ in range(epochs): train_loss.reset_states() train_accuracy.reset_states() for texts, labels in text_ds: for i in range(128): text = tf.expand_dims(texts[0][i], axis=0) label = tf.expand_dims(labels[0][i], axis=0) train_step(text, label) 

For en detaljeret vejledning til at aktivere TensorFlow-træningsscriptet til SageMaker distribuerede model parallelbibliotek, se Rediger et TensorFlow-træningsscript. For PyTorch, se Rediger et PyTorch-træningsscript.

SageMaker Debugger

I de foregående afsnit diskuterede vi, hvordan man optimerer træningen ved hjælp af model- og dataparalleliseringsteknikker. Med Amazon SageMaker Debugger, kan vi nu fange præstationsprofileringsoplysninger fra vores træningsløb for at bestemme, hvor meget træningen er blevet forbedret. Som standard fanger Debugger systemmålinger for hvert SageMaker-træningsjob, såsom GPU, CPU-udnyttelse, hukommelse, netværk og I/O med et samplingsinterval på 500 millisekunder. Vi kan få adgang til dataene som følger:

from smdebug.profiler.analysis.notebook_utils.training_job import TrainingJob
tj = TrainingJob('SMD-MP-demo-2022-01-21-06-43-23-841', "us-east-1")
tj.wait_for_sys_profiling_data_to_be_available()
system_metrics_reader = tj.get_systems_metrics_reader()

Debugger leverer værktøjer til Visualiser profileringsdataene på forskellige måder. I det følgende eksempel ser vi den samlede GPU- og CPU-udnyttelse samt I/O-ventetiden for multi-GPU-træningsjob ved hjælp af Horovod. For at generere disse grafer kører vi følgende kode:

from smdebug.profiler.analysis.notebook_utils.timeline_charts import TimelineCharts view_timeline_charts = TimelineCharts( system_metrics_reader, framework_metrics_reader, select_dimensions=["CPU", "GPU", "I/O"], select_events=["total"], show_workers=False )

GPU-udnyttelsen svinger ofte mellem 0-100 %, og høje I/O-ventetider med lav GPU-udnyttelse er en indikator for en I/O-flaskehals. Ydermere overstiger den samlede CPU-udnyttelse aldrig 70%, hvilket betyder, at vi kan forbedre dataforbehandlingen ved at øge antallet af arbejdsprocesser.

Vi kan forbedre ydeevnen ved at skifte fra Horovod til SageMaker distribuerede data parallelbibliotek. I de følgende grafer kan vi se, at GPU'er udnyttes mere effektivt og kun falder til lav udnyttelse i korte perioder.

Træningsinfrastruktur

Til træning af modellerne brugte vi 10 ml.p3.16xlarge instanser ved at bruge et SageMaker træningsjob. SageMaker reducerer tiden og omkostningerne til at træne og tune maskinlæringsmodeller (ML) uden behov for at administrere infrastruktur. Med SageMaker kan du nemt træne og tune ML-modeller ved hjælp af indbyggede værktøjer til at styre og spore træningseksperimenter, automatisk vælge optimale hyperparametre, fejlsøge træningsjob og overvåge udnyttelsen af ​​systemressourcer såsom GPU'er, CPU'er og netværksbåndbredde. Dataene blev hostet i Amazon EFS, hvilket gjorde det muligt for os at vokse og krympe, når vi tilføjer og fjerner filer uden behov for administration eller klargøring. Vores primære mål var at forbedre træningshastigheden og reducere omkostningerne.

Model skalerbarhed

Selvom denne infrastruktur primært bruges til sproggenerering, med GPT-arkitekturen og Pile-datasættet, kan du bruge disse teknikker til at træne transformatormodeller i stor skala, hvilket er nyttigt i mange domæner ud over NLP. I selve maskinlæring løses mange computervisionsopgaver nu med stor-parameter (transformer) arkitekturer, hvor de har vist sig at overgå traditionelle CNN'er (Convolutional Neural Network) på opgaver som repræsentationslæring (se Fremme det nyeste inden for computersyn med selvovervågede Transformers og 10x mere effektiv træning) og storstilet kortlægning af billeder til tekst (som f.eks CLIP). Modeller med store parametre bryder også nye veje inden for biovidenskab inden for områder som protein struktur analyse , analyse af medicinske billeddata.

De løsninger, vi beskriver i dette indlæg til distribueret træning og styring af store modeller, bør også gælde for modeller i ethvert af disse domæner.

Afvejninger

Der har været en løbende diskussion i forskermiljøet om risiciene ved at træne store sprogmodeller, og om der er tænkt tilstrækkeligt over de potentielle risici forbundet med at udvikle dem og strategier til at afbøde disse risici, hvoraf nogle omfatter de økonomiske og miljøomkostninger. Ifølge en papir offentliggjort i ACM, blev træning af en enkelt BERT-basismodel (uden hyperparameterjustering) på GPU'er anslået til at kræve lige så meget energi som en transamerikansk flyvning. Miljøpåvirkningerne skalerer med modelstørrelsen, og at være i stand til effektivt at finjustere sådanne modeller kan potentielt begrænse emissionerne betydeligt. AWS lancerede for nylig en ny Customer Carbon Footprint Tool, tilgængelig for alle AWS-kunder uden omkostninger, som en del af Amazons bestræbelser på at øge bæredygtighed og reducere kulstofemissioner. At køre applikationer på AWS Cloud kan potentielt reducere COXNUMX-fodaftrykket (sammenlignet med virksomhedsdatacentre, der blev undersøgt i en 2019-rapport).

Konklusion

Dette indlæg demonstrerede en løsning, der letter finjusteringen af ​​sprogmodeller med en milliard parametre på AWS Cloud ved hjælp af SageMaker.

For mere information om modelparallelisme med SageMaker, se Træn 175+ milliarder parameter NLP-modeller med parallelle modeltilføjelser og Hugging Face på Amazon SageMaker , Hvordan Latent Space brugte Amazon SageMaker model parallelisme bibliotek til at flytte grænserne for storskala transformere.

Hvis du gerne vil have hjælp til at fremskynde din brug af ML i dine produkter og processer, så kontakt venligst Amazon ML Solutions Lab.

Om forfatterne

Sia Gholami er Senior Data Scientist hos Amazon ML Solutions Lab, hvor han bygger AI/ML-løsninger til kunder på tværs af forskellige brancher. Han brænder for naturlig sprogbehandling (NLP) og deep learning. Uden for arbejdet nyder Sia at tilbringe tid i naturen og spille tennis.

Mehdi Noorier Manager og Senior Applied Scientist hos Amazon ML Solutions Lab, hvor han arbejder med kunder på tværs af forskellige industrier og hjælper dem med at accelerere deres cloud-migreringsrejse og løse deres ML-problemer ved hjælp af avancerede løsninger og teknologier.

Muhyun Kim er dataforsker ved Amazon Machine Learning Solutions Lab. Han løser kundens forskellige forretningsproblemer ved at anvende machine learning og deep learning og hjælper dem også med at blive dygtige.

Danny Byrd er en anvendt videnskabsmand ved Amazon ML Solutions Lab. I laboratoriet har han hjulpet kunder med at udvikle avancerede ML-løsninger inden for ML-specialiteter fra computervision til forstærkningslæring. Han brænder for at skubbe teknologien fremad og frigøre nyt potentiale fra AWS-produkter undervejs.

Francisco Calderon Rodriguez er dataforsker i Amazon ML Solutions Lab. Som medlem af ML Solutions Lab hjælper han med at løse kritiske forretningsproblemer for AWS-kunder ved hjælp af deep learning. I sin fritid kan Francisco godt lide at spille musik og guitar, spille fodbold med sine døtre og nyde tiden med sin familie.

Yohei Nakayama er Deep Learning Architect ved Amazon ML Solutions Lab. Han arbejder med kunder på tværs af forskellige vertikaler for at fremskynde deres brug af kunstig intelligens og AWS Cloud-tjenester for at løse deres forretningsmæssige udfordringer. Han er interesseret i at anvende ML/AI-teknologier til rumindustrien.

Nathalie Rauschmayr er Senior Applied Scientist hos AWS, hvor hun hjælper kunder med at udvikle deep learning-applikationer.

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://aws.amazon.com/blogs/machine-learning/create-train-and-deploy-a-billion-parameter-language-model-on-terabytes-of-data-with-tensorflow-and- amazon-sagemaker/