Opprett, tren og distribuer en milliard-parameter språkmodell på terabyte med data med TensorFlow og Amazon SageMaker

Den økende størrelsen på språkmodeller har vært en av de største trendene innen naturlig språkbehandling (NLP) de siste årene. Siden 2018 har vi sett enestående utvikling og distribusjon av stadig større språkmodeller, inkludert BERT og variantene GPT-2, T-NLG og GPT-3 (175 milliarder parametere).

Disse modellene har flyttet grensene for mulige arkitektoniske innovasjoner. Vi står overfor flere utfordringer når vi trener store dyplæringsmodeller, spesielt den nye bølgen av generative forhåndstrente transformatorer. Disse utfordringene inkluderer maskinvarebegrensninger og avveininger med beregning og effektivitet. For å overvinne disse utfordringene med modell- og dataparallellisme, tilbyr AWS et bredt spekter av muligheter.

I dette innlegget introduserer vi to hovedtilnærminger: dataparallellisering og modellparallellisering ved hjelp av Amazon SageMaker, og diskuter deres fordeler og ulemper.

Modellen

For språkmodellen bruker vi Transformers, introdusert i avisen Oppmerksomhet er alt du trenger. Transformatorer er dyplæringsmodeller designet for bevisst å unngå fallgruvene til RNN-er ved å stole på en selvoppmerksomhetsmekanisme for å trekke globale avhengigheter mellom input og output. Transformer-modellarkitekturen tillater betydelig bedre parallellisering og kan oppnå høy ytelse på relativt kort treningstid. Bygget på suksessen til Transformers, BERT, introdusert i avisen BERT: Fortrening av Deep Bidirectional Transformers for Language Understanding, lagt til toveis foropplæring for språkrepresentasjon. Inspirert av Cloze-oppgaven er BERT forhåndsopplært med maskert språkmodellering (MLM), der modellen lærer å gjenopprette de originale ordene for tilfeldig maskerte tokens. BERT-modellen er også forhåndstrent på den neste setningsprediksjonsoppgaven (NSP) for å forutsi om to setninger er i riktig leserekkefølge. Siden innkomsten i 2018 har BERT og dens variasjoner blitt mye brukt i språkmodeller.

Vi begynner med å lage to innebygde lag for token og posisjonell innebygging. Innebyggingene er summen av token-innbyggingene og posisjonsinnbyggingene.

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

Deretter definerer vi en transformator-dekoderblokk med to underlag: et flerhodet selvoppmerksomhetslag, og et enkelt fullt tilkoblet feed-forward-nettverk etterfulgt av lagnormalisering og utfall:

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 slutt lager vi språkmodellen vår med det foregående innebyggingslaget og transformatorblokkene:

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

Avhengig av hyperparametrene dine kan du skalere denne modellen fra tusenvis av parametere til milliarder av parametere. Den primære utfordringen med milliardparametermodeller er at du ikke kan være vert for modellen i én instans og trenger å distribuere modellen over flere noder for opplæring og slutning.

Datasettet

I våre eksperimenter brukte vi Pile datasett. The Pile er et 800 GiB engelsk tekstdatasett designet for opplæring av store språkmodeller. Den er laget av 22 forskjellige datasett av høy kvalitet, inkludert både etablerte NLP-datasett og nylig introduserte.

Datasettet er laget fra en rekke datakilder, inkludert bøker; GitHub-lagre; nettsider; chat logger; og artikler om medisinsk, fysikk, matematikk, informatikk og filosofi. Spesifikt bruker 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-korpus og NIH ExPorter. Den inkluderer også OpenWebText2 og BookCorpus2, som er utvidelser av henholdsvis de originale OpenWebText- og BookCorpus-datasettene. Mangfoldet i datakilder kan forbedre den generelle kunnskapen på tvers av domener og følgelig forbedre nedstrøms generaliseringsevner.

Den primære utfordringen med dette datasettet er selve størrelsen; datasettet har 825 GiB med tekst, som oversettes til 4.2 TiB med forhåndsbehandlede og komprimerte datapunkter. I likhet med utfordringene vi står overfor med opplæring og vertskap for modellene, vil opplæring av en modell med dette datasettet på en enkelt forekomst ta mye tid og er ikke praktisk.

Løsningen vår er å bryte ned datasettet i omtrent 1 GiB databiter, laste inn og forhåndsbehandle funksjonene i TensorFlow-datasett gjenstander og lagre dem i Amazon Elastic File Service (Amazon EFS). TensorFlow-datasett gir en brukervennlig og høyytelses datapipeline som integreres godt med modellene våre. Amazon EFS er en brukervennlig tjeneste som lar oss bygge et delt filsystem som skaleres automatisk når filer legges til og slettes. I tillegg er Amazon EFS i stand til å eksplodere til høyere gjennomstrømningsnivåer når det er nødvendig, noe som er avgjørende i vår data- og modelltreningspipeline.

Deretter ser vi nærmere på distribuerte opplæringsstrategier for å takle disse utfordringene.

Distribuert trening

I dette prosjektet sto vi overfor to utfordringer: skalering av modellstørrelse og datavolum. Å øke modellstørrelsen og antall trenbare parametere kan resultere i bedre nøyaktighet, men det er en grense for modellen du kan passe inn i et enkelt GPU-minne eller til og med flere GPUer i en enkelt forekomst. I tillegg tar større modellstørrelser mer tid å trene.

Du kan takle disse utfordringene på to forskjellige måter: dataparallellisme og modellparallellisme. Med dataparallellisme utfører vi Stokastisk Gradient Descent (SGD) ved å distribuere postene til en minibatch over forskjellige enheter for å få fart på treningen. Parallell dataopplæring kommer imidlertid med ekstra kompleksitet ved å beregne mini-batch gradientgjennomsnitt med gradienter fra alle enheter, et trinn som kalles AllReduce, som blir vanskeligere etter hvert som treningsklyngen vokser. Mens vi bruker dataparallellisme, må vi være i stand til å passe modellen og et enkelt datapunkt i en enhet (CPU eller GPU), noe som er en begrensende faktor i våre eksperimenter fordi størrelsen på en så stor modell er mye større enn minnet til den enkelt GPUen. størrelse.

En annen løsning er å bruke modellparallellisme, som deler modellen over flere enheter. Modellparallellisme er prosessen med å dele en modell opp mellom flere enheter eller noder (som GPU-utstyrte forekomster) og skape en effektiv pipeline for å trene modellen på tvers av disse enhetene for å maksimere GPU-utnyttelsen.

Dataparallellisering

Parallellisering av data er den vanligste tilnærmingen til flere GPUer eller distribuert trening. Du kan gruppere dataene dine, sende dem til flere enheter (hver har en replikert modell), og deretter samle resultatene. Vi eksperimenterte med to pakker for dataparallellisering: Horovod og SageMaker distribuerte dataparallellbibliotek.

Horovod er et distribuert rammeverk for dyplæring for TensorFlow, Keras, PyTorch og Apache MXNet. For å bruke Horovod gikk vi gjennom følgende prosess:

1. Initialiser ved å løpe hvd.init().
2. Knytt hver enhet til en enkelt prosess. Den første prosessen eller arbeideren er knyttet til den første enheten, den andre prosessen er assosiert med den andre enheten, og så videre.
3. Juster læringshastigheten basert på antall enheter.
4. Pakk inn optimizeren hvd.DistributedOptimizer.
5. Kringkast de innledende variabeltilstandene fra den første arbeideren med rangering 0 til alle andre prosesser. Dette er nødvendig for å sikre konsekvent initialisering av alle arbeidere når trening startes med tilfeldige vekter eller gjenopprettes fra et sjekkpunkt.
6. Sørg for at bare enhet 0 kan lagre sjekkpunkter for å forhindre at andre arbeidere ødelegger dem.

Følgende er treningsskriptet:

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 biblioteket gjør det mulig for oss å skalere treningen vår med nesten lineær effektivitet, og øke hastigheten på treningen med minimale kodeendringer. Biblioteket utfører en skikk AllReduce drift og optimaliserer enhet-til-enhet-kommunikasjon ved å fullt ut utnytte AWS sin nettverksinfrastruktur og Amazon Elastic Compute Cloud (Amazon EC2) instanstopologi. For å bruke SageMaker dataparallelle bibliotek, gikk vi gjennom følgende prosess:

1. Importer og initialiser sdp.init().
2. Knytt hver enhet til en enkelt smdistributed.dataparallel prosess med local_rank. sdp.tensorflow.local_rank() gir oss den lokale rangeringen av enheter. Lederen er rangert 0, og arbeiderne er rangert 1, 2, 3, og så videre.
3. Juster læringshastigheten basert på antall enheter.
4. Pakk tf.GradientTape med DistributedGradientTape å fremføre AllReduce.
5. Kringkast de innledende modellvariablene fra ledernoden til alle arbeidernodene.
6. Pass på at bare enhet 0 kan lagre sjekkpunkter.

Modellparallellisering

Vi kan justere hyperparametrene for å holde modellen liten nok til å trene med en enkelt GPU, eller vi kan bruke modellparallellisme for å dele modellen mellom flere GPUer på tvers av flere instanser. Å øke en modells antall trenbare parametere kan resultere i bedre nøyaktighet, men det er en grense for den maksimale modellstørrelsen du kan få plass til i et enkelt GPU-minne. Vi brukte SageMaker distribuerte modell parallellbibliotek for å trene våre større modeller. Fremgangsmåten er som følger:

1. Importer og initialiser biblioteket med smp.init().
2. Keras-modellen må arve fra smp.DistributedModel i stedet for Keras Model-klassen.
3. Sett drop_remainder=True i tf.Dataset.batch() metode for å sikre at batchstørrelsen alltid er delbar med antall mikrobatcher.
4. Tilfeldige operasjoner i datapipelinen må alle bruke samme frø: smp.dp_rank(), For eksempel, shuffle(ds, seed=smp.dp_rank()). Dette sikrer konsistens av dataprøver på tvers av enheter som har forskjellige modellpartisjoner.
5. Forover- og bakoverlogikk må være i en trinnfunksjon med smp.step dekorasjon.
6. Utfør etterbehandling på utgangene på tvers av mikrobatcher ved å bruke StepOutput-metoder som reduce_mean. De smp.step funksjonen må ha en returverdi som avhenger av utgangen av smp.DistributedModel.

Opplæringsskriptet 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 detaljert veiledning for å aktivere TensorFlow-treningsskriptet for SageMaker distribuerte modell parallellbibliotek, se Endre et TensorFlow-treningsskript. For PyTorch, se Endre et PyTorch-treningsskript.

SageMaker Debugger

I de forrige avsnittene diskuterte vi hvordan man kan optimalisere treningen ved hjelp av modell- og dataparallelliseringsteknikker. Med Amazon SageMaker Debugger, kan vi nå fange opp ytelsesprofileringsinformasjon fra treningsløpene våre for å finne ut hvor mye treningen har forbedret. Som standard fanger Debugger opp systemmålinger for hver SageMaker-treningsjobb som GPU, CPU-utnyttelse, minne, nettverk og I/O med et samplingsintervall på 500 millisekunder. Vi kan få tilgang 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 gir verktøy til visualisere profileringsdataene på ulike måter. I følgende eksempel ser vi den totale GPU- og CPU-utnyttelsen samt I/O-ventetiden for multi-GPU-treningsjobben ved bruk av Horovod. For å generere disse grafene kjø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-utnyttelsen svinger ofte mellom 0–100 %, og høye I/O-ventetider med lav GPU-utnyttelse er en indikator på en I/O-flaskehals. Dessuten overstiger aldri den totale CPU-utnyttelsen 70 %, noe som betyr at vi kan forbedre dataforbehandlingen ved å øke antall arbeidsprosesser.

Vi kan forbedre ytelsen ved å bytte fra Horovod til SageMaker distribuerte dataparallelle bibliotek. I de følgende grafene kan vi se at GPU-er utnyttes mer effektivt og bare faller til lav utnyttelse i korte perioder.

Treningsinfrastruktur

For å trene modellene brukte vi 10 ml.p3.16xlarge forekomster ved å bruke en SageMaker-treningsjobb. SageMaker reduserer tiden og kostnadene for å trene og tune maskinlæringsmodeller (ML) uten behov for å administrere infrastruktur. Med SageMaker kan du enkelt trene og justere ML-modeller ved å bruke innebygde verktøy for å administrere og spore treningseksperimenter, automatisk velge optimale hyperparametre, feilsøke treningsjobber og overvåke bruken av systemressurser som GPUer, CPUer og nettverksbåndbredde. Dataene ble lagret i Amazon EFS, noe som gjorde det mulig for oss å vokse og krympe når vi legger til og fjerner filer uten behov for administrasjon eller klargjøring. Våre primære mål var å forbedre treningshastigheten og redusere kostnadene.

Modellens skalerbarhet

Selv om denne infrastrukturen primært brukes til språkgenerering, med GPT-arkitekturen og Pile-datasettet, kan du bruke disse teknikkene til å trene opp storskala transformatormodeller, noe som er nyttig i mange domener utover NLP. I selve maskinlæring løses mange datasynsoppgaver nå med storparameter (transformator) arkitekturer der de har vist seg å overgå tradisjonelle CNN (Convolutional Neural Network) på oppgaver som representasjonslæring (se Fremme det nyeste innen datasyn med selvkontrollerte transformatorer og 10 ganger mer effektiv trening) og storskala kartlegging av bilder til tekst (som f.eks CLIP). Modeller med store parametere bryter også ny mark innen biovitenskap på felt som analyse av proteinstruktur og analyse av medisinske bildedata.

Løsningene vi beskriver i dette innlegget for distribuert opplæring og administrasjon av store modeller bør også gjelde for modeller i alle disse domenene.

Avveininger

Det har vært en pågående diskusjon i forskningsmiljøet om risikoen ved å trene opp store språkmodeller, og om det er tenkt nok på de potensielle risikoene forbundet med å utvikle dem og strategier for å redusere disse risikoene, hvorav noen inkluderer økonomiske og miljøkostnader. I følge a papir publisert i ACM ble trening av en enkelt BERT-basismodell (uten hyperparameterinnstilling) på GPU-er beregnet å kreve like mye energi som en transamerikansk flytur. Miljøpåvirkningene skalerer med modellstørrelse, og å kunne finjustere slike modeller effektivt kan potensielt redusere utslippene betydelig. AWS lanserte nylig en ny Customer Carbon Footprint Tool, tilgjengelig for alle AWS-kunder uten kostnad, som en del av Amazons innsats for å øke bærekraften og redusere karbonutslipp. Å kjøre applikasjoner på AWS Cloud kan potensielt redusere karbonavtrykket (sammenlignet med bedriftsdatasentre som ble undersøkt i en 2019-rapport).

konklusjonen

Dette innlegget demonstrerte en løsning som letter finjusteringen av språkmodeller med en milliard parametere på AWS Cloud ved hjelp av SageMaker.

For mer informasjon om modellparallellisme med SageMaker, se Tren 175+ milliarder parameter NLP-modeller med parallelle modelltilføyelser og Hugging Face på Amazon SageMaker og Hvordan Latent Space brukte Amazon SageMaker-modellens parallellbibliotek for å skyve grensene til store transformatorer.

Hvis du vil ha hjelp til å akselerere bruken av ML i produktene og prosessene dine, kan du kontakte Amazon ML Solutions Lab.

Om forfatterne

Sia Gholami er senior dataforsker ved Amazon ML Solutions Lab, hvor han bygger AI/ML-løsninger for kunder på tvers av ulike bransjer. Han brenner for naturlig språkbehandling (NLP) og dyp læring. Utenom jobben liker Sia å tilbringe tid i naturen og spille tennis.

Mehdi Noorier en leder og en senior applied Scientist ved Amazon ML Solutions Lab, hvor han jobber med kunder på tvers av ulike bransjer, og hjelper dem med å akselerere deres skymigrasjonsreise, og å løse deres ML-problemer ved å bruke avanserte løsninger og teknologier.

Muhyun Kim er dataforsker ved Amazon Machine Learning Solutions Lab. Han løser kundens ulike forretningsproblemer ved å bruke maskinlæring og dyp læring, og hjelper dem også med å bli dyktige.

Danny Byrd er en Applied Scientist ved Amazon ML Solutions Lab. På laboratoriet har han hjulpet kunder med å utvikle avanserte ML-løsninger, innen ML-spesialiteter fra datasyn til forsterkende læring. Han er lidenskapelig opptatt av å skyve teknologi fremover og frigjøre nytt potensial fra AWS-produkter underveis.

Francisco Calderon Rodriguez er en dataforsker i Amazon ML Solutions Lab. Som medlem av ML Solutions Lab hjelper han med å løse kritiske forretningsproblemer for AWS-kunder ved hjelp av dyp læring. På fritiden liker Francisco å spille musikk og gitar, spille fotball med døtrene og nyte tiden med familien.

Yohei Nakayama er en Deep Learning Architect ved Amazon ML Solutions Lab. Han jobber med kunder på tvers av ulike vertikaler for å akselerere deres bruk av kunstig intelligens og AWS Cloud-tjenester for å løse forretningsutfordringene deres. Han er interessert i å bruke ML/AI-teknologier til romindustrien.

Nathalie Rauschmayr er Senior Applied Scientist ved AWS, hvor hun hjelper kunder med å utvikle dyplæringsapplikasjoner.

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• 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/