Beste praksis for TensorFlow 1.x akselerasjonstrening på Amazon SageMaker

I dag bruker mange kunder TensorFlow for å trene dyplæringsmodeller for deres klikkfrekvens i annonsering og personaliseringsanbefalinger i e-handel. Ettersom atferden til klientene deres endrer seg, kan de akkumulere store mengder ny data hver dag. Modelliterering er en av dataforskers daglige jobber, men de står overfor problemet med å ta for lang tid å trene på store datasett.

Amazon SageMaker er en fullstendig administrert maskinlæringsplattform (ML) som kan hjelpe dataforskere med å fokusere på modeller i stedet for infrastruktur, med innebygd støtte for ta med-din-egen-algoritmer og rammeverk som TensorFlow og PyTorch. SageMaker tilbyr fleksible distribuerte opplæringsalternativer som tilpasser seg dine spesifikke arbeidsflyter. Fordi mange dataforskere kan mangle erfaring i akselerasjonstreningsprosessen, viser vi deg i dette innlegget faktorene som betyr noe for rask dyplæringsmodelltrening og beste praksis for akselerasjonstrening for TensorFlow 1.x på SageMaker. Vi har også en prøvekode på DeepFM delte ut opplæring på SageMaker på GitHub repo.

Det er mange faktorer du bør vurdere for å maksimere CPU/GPU-utnyttelsen når du kjører TensorFlow-skriptet på SageMaker, for eksempel infrastruktur, type akselerator, distribuert treningsmetode, datainnlastingsmetode, blandet presisjonstrening og mer.

Vi diskuterer beste praksis på følgende områder:

• Akselerer treningen på en enkelt forekomst
• Akselerer trening på flere instanser
• Datarørledninger
• Automatisk blandet presisjonstrening

Akselerer treningen på en enkelt forekomst

Når du kjører TensorFlow-skriptet på en enkelt forekomst, kan du velge en datamaskinoptimalisert serie som Amazon Elastic Compute Cloud (Amazon EC2) C5-serien, eller en akselerert databehandlingsserie med flere GPU i en enkelt forekomst, for eksempel p3.8xlarge, p3.16xlarge, p3dn.24xlarge og p4d.24xlarge.

I denne delen diskuterer vi strategier for flere CPUer på en enkelt forekomst, og distribuert trening med flere GPUer på en enkelt forekomst.

Flere CPUer på en enkelt forekomst

I denne delen diskuterer vi manuell innstilling av operatørers parallellitet på CPU-enheter, tårnmetoden, TensorFlow MirroredStrategy og Horovod.

Manuell innstilling av operatørers parallellitet på CPU-enheter

TensorFlow velger automatisk riktig antall tråder for å parallellisere operasjonsberegningen i treningsprosessen. Du kan imidlertid stille inn intra_op tråder basseng og inter_op parallellitetsinnstillinger levert av TensorFlow og bruk miljøvariabler til MKL-DNN for å angi binding for OS-tråden. Se følgende kode:

# Set parallelism of intra_op and inter_op
num_cpus = int(os.environ['SM_NUM_CPUS'])
config = tf.ConfigProto(allow_soft_placement=True, device_count={'CPU': num_cpus}, intra_op_parallelism_threads=num_cpus, inter_op_parallelism_threads=num_cpus)
run_config = tf.estimator.RunConfig().replace(session_config = config)

# Use Intel MKL-DNN Setting to accelerate training speed
os.environ["KMP_AFFINITY"]= "verbose,disabled"
os.environ['OMP_NUM_THREADS'] = str(num_cpus)
os.environ['KMP_SETTINGS'] = '1'

Miljøvariabelen KMP_AFFINITY av MKL-DNN er satt til granularity=fine,compact,1,0 som standard. Etter å ha satt både intra og inter av TensorFlow til det maksimale antallet vCPUer for gjeldende instans, er den øvre grensen for CPU-bruk nesten den samme som antall fysiske kjerner i treningsforekomsten.

Hvis du angir os.environ["KMP_AFFINITY"]= "verbose,disabled", OS-tråden er ikke bundet til maskinvarehypertråden, og CPU-bruken kan overstige antallet fysiske kjerner.

Når det gjelder innstillingene for TensorFlow intraparallellisme, TensorFlow interparallellisme og antall MKL-DNN-tråder, resulterer forskjellige kombinasjoner av disse tre parameterne i forskjellige treningshastigheter. Derfor må du teste hvert tilfelle for å finne den beste kombinasjonen. En vanlig situasjon er å angi de tre parameterne (intra_op_parallelism_threads og inter_op_parallelism_threads for TensorFlow, os.environ['OMP_NUM_THREADS'] for MKL-DNN) til halvparten av antallet vCPUer (fysisk kjerne) eller det totale antallet vCPUer.

Tårnmetoden

For å replikere en modell over GPU-er, får hver GPU sin egen forekomst av videresendingen. Forekomsten av foroverpasningen kalles a tårn. Tårnmetoden brukes nesten alltid for GPU-enheter. For å sammenligne treningshastighet med andre metoder bruker vi her også tårnmetoden for vår CPU-enhet.

Hvis du ikke stiller inn CPU-enheten manuelt, bruker ikke TensorFlow tårnmetoden for å snitte gradientene, så du trenger ikke skalere batchstørrelsen i slike tilfeller.

1. Still inn CPU-enheten manuelt:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))

2. Bruk replicate_model_fn å pakke inn model_fn:

DeepFM = tf.estimator.Estimator(model_fn=tf.contrib.estimator.replicate_model_fn(model_fn, devices=device_list), model_dir=FLAGS.model_dir, params=model_params, config=config)

3. Bruk TowerOptimizer å pakke inn optimizer:

optimizer = tf.contrib.estimator.TowerOptimizer(optimizer)

4. Pakk inn model_fn:

with tf.variable_scope(‘deepfm_model’, reuse=tf.AUTO_REUSE)

5. Skaler batchstørrelse til (NUM_CPU – 1).

La oss se på forskjellen på CPU-utnyttelse med tårnmodus aktivert. Følgende figur viser ml.c5.18xlarge-forekomstens CPU-bruk med følgende konfigurasjon:

Ingen tårn + LibSVM-data + rørmodus + MKL-DNN deaktiver binding + TensorFlow intra/inter op-parallellisme-innstilling til maksimalt antall forekomsters vCPUer

Følgende figur viser ml.c5.18xlarge-forekomstens CPU-bruk med følgende konfigurasjon:

Tårn med innstilt CPU-enhet + LibSVM-data + pipe-modus + MKL-DNN deaktiver binding + TensorFlow intra/inter op-parallellisme-innstilling til maksimalt antall forekomsters vCPUer

CPU-bruken er høyere når du bruker tårnmetoden, og den overskrider antallet fysiske kjerner.

TensorFlow Mirrored Strategy

TensorFlow MirroredStrategy betyr synkron trening på tvers av flere kopier på én maskin. Denne strategien brukes vanligvis for trening på én maskin med flere GPUer. For å sammenligne treningshastighet med en annen metode bruker vi MirroredStrategy for vår CPU-enhet.

Når du bruker TensorFlow MirroredStrategy, hvis du ikke stiller inn CPU-enheten, bruker TensorFlow bare én CPU som enkeltarbeider, noe som er sløsing med ressurser. Vi anbefaler å stille inn CPU-enheten manuelt, fordi den vil gjøre en redusert operasjon på /CPU:0, Så /CPU:0 enheten brukes ikke som en kopi her. Se følgende kode:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))
mirrored_strategy = tf.distribute.MirroredStrategy(devices=devices_list)
	else:
mirrored_strategy = tf.distribute.MirroredStrategy()

# Set strategy to config:
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
eval_distribute=mirrored_strategy,
session_config = config)

Du må skalere batchstørrelse når du bruker MirroredStrategy; skaler for eksempel batchstørrelsen til et multiplum av antall GPU-enheter.

For understrategien når du angir CPU-enhet, hvis du ikke angir cross_device_ops parameter i tf.distribute.MirroredStrategy(), TensorFlow bruker ReductionToOneDevice delstrategi som standard. Men hvis du setter HierarchicalCopyAllReduce som delstrategi, utfører TensorFlow bare reduksjonsarbeidet /CPU:0. Når du bruker TensorFlow datasett API og distribuerer strategi sammen, skal datasettobjektet returneres i stedet for funksjoner og etiketter i funksjon input_fn.

Vanligvis er TensorFlow MirroredStrategy tregere enn tårnmetoden på CPU-trening, så vi anbefaler ikke å bruke MirroredStrategy på en enkeltvert med flere CPUer.

Horovod

Horovod er et distribuert rammeverk for dyplæring for TensorFlow, Keras, PyTorch og Apache MXNet. Målet med Horovod er å gjøre distribuert dyplæring rask og enkel å bruke.

Det er en parameter på distribution i SageMaker Python SDK Estimator API, som du kan bruke til å angi Horovod-distribuerte opplæring. SageMaker sørger for infrastrukturen og kjører skriptet ditt med MPI. Se følgende kode:

hvd_processes_per_host = 4
distribution = {'mpi': { 
'enabled': True, 
'processes_per_host': hvd_processes_per_host,
'custom_mpi_options': '-verbose --NCCL_DEBUG=INFO -x OMPI_MCA_btl_vader_single_copy_mechanism=none' 
} 
}

Når du velger en GPU-instans som ml.p3.8xlarge, må du feste hver GPU for hver arbeider:

config = tf.ConfigProto()
config.gpu_options.visible_device_list = str(hvd.local_rank())

For å fremskynde modellkonvergens, skaler læringsraten etter antall arbeidere i henhold til Horovod offisielle dokumentasjon. I virkelige prosjekter bør du imidlertid skalere læringsraten til en viss grad, men ikke etter antall arbeidere, noe som resulterer i dårlig modellytelse. For eksempel, hvis den opprinnelige læringsraten er 0.001, skalerer vi læringsraten til 0.0015, selv om antallet arbeidere er fire eller flere.

Generelt er det bare den primære (Horovod rangering 0) som lagrer sjekkpunktet og modellen samt evalueringsoperasjonen. Du trenger ikke skalere batchstørrelsen når du bruker Horovod. SageMaker tilbyr Rørmodus å streame data fra Amazon enkel lagringstjeneste (Amazon S3) inn i treningsinstanser. Når du aktiverer rørmodus, vær oppmerksom på at forskjellige arbeidere på samme vert må bruke forskjellige kanaler for å unngå feil. Dette er fordi den første arbeidsprosessen leser FIFO/kanaldataene, og andre arbeidsprosesser på samme instans vil henge fordi de ikke kan lese data fra samme FIFO/kanal, så Horovod fungerer ikke ordentlig. For å unngå dette problemet, still inn kanalene i henhold til antall arbeidere per forekomst. Sørg i det minste for at forskjellige arbeidere på samme vert bruker forskjellige kanaler; den samme kanalen kan konsumeres av arbeidere på en annen vert.

Når du bruker Horovod, kan du støte på følgende feil:

“One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.”

Den mulige årsaken til dette problemet er at en viss rangering (som rangering 0) fungerer tregere eller gjør flere jobber enn andre rangeringer, og dette får andre rangerer til å vente lenge. Selv om rangering 0 noen ganger må gjøre mer arbeid enn andre rangeringer, bør det bemerkes at rangering 0 ikke bør gjøre mye på lang tid. For eksempel, for modellevaluering av valideringssettet og lagring av sjekkpunkter under trening, hvis det er uunngåelig at disse operasjonene vil ta lang tid, noe som kan forårsake feil, er en løsning å la alle arbeidere gjøre det samme arbeidet som rang 0 (sjekkpunkter lagring, evaluering og så videre).

Datadeling er en av de viktigste tingene å vurdere når du bruker distribuert opplæring. Du kan bruke TensorFlow dataset.shard() i manuset ditt. SageMaker tilbyr også en datasettskårfunksjon i inngangskanal ved innstilling distribution=S3shardbykey i datasettkanalen. Se følgende kode:

dataset = PipeModeDataset(channel, record_format='TFRecord')

number_host = len(FLAGS.hosts)

if FLAGS.enable_data_multi_path : # If there are multi channels mapping with different S3 path
    if FLAGS.enable_s3_shard == False :
        if number_host > 1:
            index = hvd.rank() // FLAGS.worker_per_host
            dataset = dataset.shard(number_host, index)
else :
    if FLAGS.enable_s3_shard :
        dataset = dataset.shard(FLAGS.worker_per_host, hvd.local_rank())
    else :
        dataset = dataset.shard(hvd.size(), hvd.rank())

Følgende figur viser resultatet når du bruker Horovod (ml.c5.18xlarge, Horovod + LibSVM + standard intra op og inter op innstilling), som du kan sammenligne med tårnmetoden.

Distribuert trening med flere GPUer på en enkelt forekomst

Det er normalt å starte distribuert trening med flere GPUer på en enkelt forekomst fordi dataforskere bare trenger å administrere én forekomst og dra nytte av høyhastighetsforbindelsen mellom GPUer. SageMaker-opplæringsjobber støtter flere forekomsttyper som har flere GPUer på en enkelt forekomst, for eksempel ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge og ml.p4d.24xlarge. Metoden er den samme som flere CPUer i en enkelt forekomst, men med noen få endringer i skriptet.

Tårnmetoden

Tårnmetoden her er nesten den samme som i multi-CPU-trening. Du må skalere batchstørrelsen i henhold til antall GPUer som er i bruk.

TensorFlow Mirrored Strategy

Standard understrategi for MirroredStrategy is NcclAllReduce. Du må skalere batchstørrelsen i henhold til antall GPUer som er i bruk. Se følgende kode:

mirrored_strategy = tf.distribute.MirroredStrategy()
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
				eval_distribute=mirrored_strategy)

Akselerer trening på flere instanser

Utskalering er alltid et alternativ for å forbedre treningshastigheten. Flere og flere dataforskere velger dette som standardalternativ i forhold til distribuert opplæring. I denne delen diskuterer vi strategier for distribuert opplæring med flere verter.

Flere CPUer med flere forekomster

Det er fire hovedmetoder for å bruke flere CPUer med flere forekomster når du aktiverer distribuert opplæring:

• • Parameterserver uten å manuelt stille inn operatørens parallellitet på CPU-enheter
  • Parameterserver med manuell innstilling av operatørers parallellitet på CPU-enheter
  • Parameterserver med tårn (stiller inn CPU-enheter manuelt, og still inn allow_soft_placement=True in tf.ConfigProto)
  • Horovod

Når du bruker en parameterserver i tf.estimator API, banen til sjekkpunktet må være en delbar bane som Amazon S3 eller den lokale banen til Amazon Elastic File Service (Amazon EFS) kartlegging til containeren. For en parameterserver i tf.keras, kan sjekkpunktbanen settes til den lokale banen. For Horovod kan sjekkpunktbanen settes til en lokal bane for treningsforekomsten.

Når du bruker en parameterserver og tf.estimator API med sjekkpunktstien til Amazon S3, hvis modellen er ganske stor, kan du støte på en feil ved at primæren sitter fast ved lagring av sjekkpunkt til S3. Du kan bruke SageMaker innebygde container TensorFlow 1.15 eller TensorFlow 1.15.2 eller bruke Amazon EFS som sjekkpunktbanen til andelen.

Når du bruker en parameterserver for flere verter, kan parameterbelastningen på hver parameterserverprosess være ubalansert (spesielt når det er relativt store innbyggingstabellvariabler), noe som kan forårsake feil. Du kan sjekke filstørrelsen til hvert shards sjekkpunkt i Amazon S3 for å finne ut om parameterne på parameterserveren er balansert, fordi hver parameterserver tilsvarer et shard av sjekkpunktfilen. For å unngå slike problemer, kan du bruke partisjoneringsfunksjonen til å prøve å gjøre parametrene til hver parameterserver jevnt fordelt:

with tf.variable_scope('deepfm_model', reuse=tf.AUTO_REUSE, partitioner = tf.fixed_size_partitioner(num_shards=len(FLAGS.hosts))):

Enkel GPU med flere forekomster

SageMaker-treningsjobber støtter forekomster som bare har én GPU, som ml.p3.xlarge-, ml.g4dn- og ml.g5-seriene. Det er to hovedmetoder som brukes i dette scenariet: parameterservere og Horovod.

Den innebygde parameterserver-distribuerte treningsmetoden til SageMaker er å starte en parameterserverprosess og en arbeidsprosess for hver treningsforekomst (hver parameterserver er kun ansvarlig for deler av modellparametrene), så standarden er multi-maskin single- GPU opplæring. SageMaker innebygde parameterserver-distribuerte opplæring er en asynkron gradientoppdateringsmetode. For å redusere virkningen av asynkrone oppdateringer på treningskonvergens, anbefales det å redusere læringshastigheten. Hvis du vil bruke alle GPUene på instansen, må du bruke en kombinasjon av parameterservere og tårnmetoden.

For Horovod, bare sett processes_per_host=1 i distribusjonsparameteren til SageMaker Python Estimator API.

Flere GPUer med flere forekomster

For parameterservere og tårnmetoden er kodeendringene i utgangspunktet de samme som tårnmetoden for en enkelt forekomst med flere GPUer, og det er ikke nødvendig å stille inn GPU-enhetene manuelt.

For Horovod, sett processes_per_host i distribusjonsparameteren til antall GPUer for hver treningsforekomst. Hvis du bruker rørmodus, må antallet arbeidere per forekomst samsvare med antall kanaler.

Datarørledninger

I tillegg til infrastrukturen vi har diskutert, er det en annen viktig ting å vurdere: datarørledningen. En datapipeline refererer til hvordan du laster inn data og transformerer data før de mates inn i nevrale nettverk. CPU brukes til å forberede data, mens GPU brukes til å beregne data fra CPU. Fordi GPU er en dyr ressurs, er mer GPU-tomgang ineffektiv; en god datapipeline i treningsjobben din kan forbedre GPU- og CPU-utnyttelsen.

Når du prøver å optimalisere TensorFlow-datainndatapipeline, bør du vurdere API-rekkefølgen som brukes i TensorFlow-datasett, treningsdatastørrelsen (mange små filer eller flere store filer), batchstørrelse og så videre.

La oss se på samspillet mellom GPU og CPU under trening. De følgende figurene sammenligner interaksjoner med og uten rørledning.

En bedre pipeline kan redusere GPU-tomgangstiden. Vurder følgende tips:

• Bruk enkel funksjonslogikk for å trekke ut funksjoner og etiketter
• Forhåndshent prøver til minnet
• Reduser unødvendig disk-I/O og nettverks-I/O
• Buffer de behandlede funksjonene og etikettene i minnet
• Reduser antall replikeringstider mellom CPU og GPU
• La ulike arbeidere håndtere ulike deler av opplæringsdatasettet
• Reduser tiden for å kalle TensorFlow datasett API

TensorFlow gir en transformasjons-API relatert til datasettformater, og rekkefølgen på transformasjons-APIen i TensorFlow påvirker treningshastigheten mye. Den beste rekkefølgen for å kalle TensorFlow datasett API må testes. Følgende er noen grunnleggende prinsipper:

• Bruk et vektorisert kart. Dette betyr å kalle TensorFlow dataset batch API først, deretter datasett map API. Den egendefinerte parsingsfunksjonen som er gitt i kartfunksjonen, for eksempel decode_tfrecord i eksempelkoden, analyserer en minibatch med data. Tvert imot, kart først og deretter batch er et skalært kart, og den tilpassede parserfunksjonen behandler bare ett eksempel.
• Bruk TensorFlow datasettbuffer-API for å bufre funksjoner og etiketter. Sett TensorFlow datasett cache API før TensorFlow datasett repeat API, ellers øker RAM-utnyttelsen lineært epoke for epoke. Hvis datasettet er så stort som RAM, ikke bruk TensorFlow datasettbuffer-API. Hvis du trenger å bruke TensorFlow datasett cache API og shuffle API, bør du vurdere å bruke følgende rekkefølge: opprett TensorFlow datasettobjekt -> cache API -> shuffle API -> batch API -> kart API -> gjenta API -> forhåndshent API.
• Bruke tfrecord datasettformat mer enn LibSVM-format.
• Filmodus eller rørmodus avhenger av datasettformatet og mengden filer. De tfrecorddataset API kan stilles inn num_parallel_reads å lese flere filer parallelt og sette buffer_size for å optimere dataavlesningen, mens pipemodedataset API har ikke slike innstillinger. Rørmodus er mer egnet for situasjoner der en enkelt fil er stor og det totale antallet filer er lite. Vi anbefaler å bruke en SageMaker-behandlingsjobb for å gjøre forbehandlingsarbeidet, for eksempel å slå sammen flere filer til en større fil i henhold til etiketter, bruke en samplingsmetode for å gjøre datasettet mer balansert, og stokke det balanserte datasettet.

Se følgende kodeeksempel:

def decode_tfrecord(batch_examples):
        # The feature definition here should BE consistent with LibSVM TO TFRecord process.
        features = tf.parse_example(batch_examples,
                                           features={
                                               "label": tf.FixedLenFeature([], tf.float32),
                                               "ids": tf.FixedLenFeature(dtype=tf.int64, shape=[FLAGS.field_size]),
                                               "values": tf.FixedLenFeature(dtype=tf.float32, shape=[FLAGS.field_size]) 
                                           })
        
        batch_label = features["label"]
        batch_ids = features["ids"]
        batch_values = features["values"]
        
        return {"feat_ids": batch_ids, "feat_vals": batch_values}, batch_label


    def decode_libsvm(line):
        columns = tf.string_split([line], ' ')
        labels = tf.string_to_number(columns.values[0], out_type=tf.float32)
        splits = tf.string_split(columns.values[1:], ':')
        id_vals = tf.reshape(splits.values,splits.dense_shape)
        feat_ids, feat_vals = tf.split(id_vals,num_or_size_splits=2,axis=1)
        feat_ids = tf.string_to_number(feat_ids, out_type=tf.int32)
        feat_vals = tf.string_to_number(feat_vals, out_type=tf.float32)
        return {"feat_ids": feat_ids, "feat_vals": feat_vals}, labels

if FLAGS.pipe_mode == 0:
        dataset = tf.data.TFRecordDataset(filenames)
    else :
        # Enter Pipe mode
        dataset = PipeModeDataset(channel, record_format='TFRecord')
        
    if FLAGS.enable_s3_shard == False:
        host_rank = FLAGS.hosts.index(FLAGS.current_host)
        number_host = len(FLAGS.hosts)
        dataset = dataset.shard(number_host, host_rank)
    
    dataset = dataset.batch(batch_size, drop_remainder=True) # Batch size to use
    dataset = dataset.map(decode_tfrecord,
                          num_parallel_calls=tf.data.experimental.AUTOTUNE) 

    if num_epochs > 1:
        dataset = dataset.repeat(num_epochs)
    dataset = dataset.prefetch(buffer_size=tf.data.experimental.AUTOTUNE)

For opplæring på CPU-forekomster, innstilling av parallellitet til intra op, inter op, og miljøvariabelen til MKL-DNN er et godt utgangspunkt.

Automatisk blandet presisjonstrening

Det siste vi diskuterer er automatisk blandet presisjonstrening, som kan øke hastigheten og resultere i modellytelse. Når dette skrives, støtter Nvidia V100 GPU (P3-forekomst) og A100 (P4dn-forekomst) Tensor-kjerne. Du kan aktivere blandet presisjonstrening i TensorFlow når du bruker slike instanser. Fra og med versjon 1.14 har TensorFlow støttet automatisk blandet presisjonstrening. Du kan bruke følgende setning for å pakke inn den opprinnelige optimizeren:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Hvis modellen er liten og utnyttelsen av GPU er lav, er det ingen fordel med automatisk blandet presisjonstrening. Hvis modellen er stor, kan automatisk blandet presisjonstrening akselerere treningshastigheten.

konklusjonen

Når du starter din dyplæringsmodelltrening i SageMaker, bør du vurdere følgende tips for å oppnå en raskere treningshastighet:

• Prøv metoden med multi-CPU, enkeltforekomst eller enkelt-GPU, enkeltforekomstmetoden først. Hvis CPU/GPU-bruken er svært høy (for eksempel mer enn 90%), gå videre til neste trinn.
• Prøv flere CPUer i én vert eller flere GPUer i én vert. Hvis utnyttelsen er nær maksimal utnyttelse av CPUer eller GPUer, gå videre til neste trinn.
• Prøv flere CPUer eller flere GPUer med flere verter.
• Du må endre koder når du bruker parameterservere eller Horovod. Kodemodifikasjonen er ikke den samme for TensorFlow-øktbaserte API, tf.estimator API, og tf.keras API. En parameterserver eller Horovod kan vise forskjellige treningshastigheter i forskjellige treningstilfeller og -oppgaver, så prøv begge metodene hvis du har tid og budsjett til å finne den beste.

Husk følgende råd:

• Sjekk bruken før du skalerer, optimaliser datapipelinen din og få CPU og GPU til å overlappe i tidslinjen.
• Skaler først opp, så skalerer ut.
• Hvis du ikke kan øke GPU-bruken etter alle metodene, prøv CPU. Det er mange tilfeller (spesielt for klikkfrekvens-rangeringsmodellen) der den totale treningstiden for CPU-instansopplæring er kortere og mer kostnadseffektiv enn GPU-instansopplæring.

Vi har også et kodeeksempel i GitHub repo, hvor vi viser to eksempler på DeepFM distribuert opplæring på SageMaker. Den ene er en TensorFlow-parameterserver på CPU-forekomster, den andre er Horovod på GPU-forekomster.

Om forfatterne

Yuhui Liang er en senior maskinlæringsarkitekt. Han er fokusert på promotering og anvendelse av maskinlæring, og er dypt involvert i mange kunders maskinlæringsprosjekter. Han har rik erfaring innen distribuert opplæring i dyp læring, anbefalingssystemer og beregningsbasert annonsering.

Shishuai Wang er en senior maskinlæringsarkitekt. Han jobber med AWS-kunder for å hjelpe dem å ta i bruk maskinlæring i stor skala. Han liker å se filmer og reise rundt i verden.