Bedste praksis for TensorFlow 1.x accelerationstræning på Amazon SageMaker

I dag bruger mange kunder TensorFlow til at træne deep learning-modeller til deres klikrate i annoncering og personaliseringsanbefalinger i e-handel. Efterhånden som deres kunders adfærd ændrer sig, kan de akkumulere store mængder nye data hver dag. Model iteration er et af en dataforskers daglige job, men de står over for problemet med at tage for lang tid at træne på store datasæt.

Amazon SageMaker er en fuldt administreret maskinlæringsplatform (ML), der kan hjælpe datavidenskabsfolk med at fokusere på modeller i stedet for infrastruktur, med indbygget understøttelse af bring-your-own-algoritmer og rammer såsom TensorFlow og PyTorch. SageMaker tilbyder fleksible distribuerede træningsmuligheder, der tilpasser sig dine specifikke arbejdsgange. Fordi mange datavidenskabsmænd måske mangler erfaring i accelerationstræningsprocessen, viser vi dig i dette indlæg de faktorer, der betyder noget for hurtig dyb læringsmodeltræning og den bedste praksis for accelerationstræning til TensorFlow 1.x på SageMaker. Vi har også en prøvekode af DeepFM uddelt træning på SageMaker på GitHub repo.

Der er mange faktorer, du bør overveje for at maksimere CPU/GPU-udnyttelsen, når du kører dit TensorFlow-script på SageMaker, såsom infrastruktur, type accelerator, distribueret træningsmetode, dataindlæsningsmetode, blandet præcisionstræning og mere.

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

• Accelerer træningen på en enkelt instans
• Accelerer træning på flere instanser
• Datapipelines
• Automatisk blandet præcisionstræning

Accelerer træningen på en enkelt instans

Når du kører dit TensorFlow-script på en enkelt forekomst, kan du vælge en computeroptimeret serie som f.eks Amazon Elastic Compute Cloud (Amazon EC2) C5-serien eller en accelereret computerserie med flere GPU i en enkelt instans, såsom p3.8xlarge, p3.16xlarge, p3dn.24xlarge og p4d.24xlarge.

I dette afsnit diskuterer vi strategier for flere CPU'er på en enkelt instans og distribueret træning med flere GPU'er på en enkelt instans.

Flere CPU'er på en enkelt instans

I dette afsnit diskuterer vi manuel indstilling af operatørers parallelitet på CPU-enheder, tårnmetoden, TensorFlow MirroredStrategy og Horovod.

Manuel indstilling af operatørernes parallelitet på CPU-enheder

TensorFlow vælger automatisk det passende antal tråde for at parallelisere operationsberegningen i træningsprocessen. Du kan dog indstille intra_op tråde pool og inter_op parallelitetsindstillinger leveret af TensorFlow og brug miljøvariabler fra MKL-DNN til at indstille 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øvariablen KMP_AFFINITY af MKL-DNN er indstillet til granularity=fine,compact,1,0 som standard. Efter at have indstillet både intra og inter af TensorFlow til det maksimale antal vCPU'er for den aktuelle instans, er den øvre grænse for CPU-brug næsten den samme som antallet af fysiske kerner i træningsinstansen.

Hvis du indstiller os.environ["KMP_AFFINITY"]= "verbose,disabled", OS-tråden er ikke bundet til hardware-hypertråden, og CPU-brug kan overstige antallet af fysiske kerner.

Med hensyn til indstillingerne af TensorFlow intra parallelism, TensorFlow inter parallelism og antallet af MKL-DNN tråde, resulterer forskellige kombinationer af disse tre parametre i forskellige træningshastigheder. Derfor skal du teste hvert enkelt tilfælde for at finde den bedste kombination. En almindelig situation er at indstille de tre parametre (intra_op_parallelism_threads , inter_op_parallelism_threads til TensorFlow, os.environ['OMP_NUM_THREADS'] for MKL-DNN) til halvdelen af ​​antallet af vCPU'er (fysisk kerne) eller det samlede antal vCPU'er.

Tårn metode

For at replikere en model over GPU'er får hver GPU sin egen forekomst af det fremadrettede pass. Forekomsten af ​​den fremadgående aflevering kaldes en tårn. Tårnmetoden bruges næsten altid til GPU-enheder. For at sammenligne træningshastighed med andre metoder, bruger vi her også tårnmetoden til vores CPU-enhed.

Hvis du ikke indstiller CPU-enheden manuelt, bruger TensorFlow ikke tower-metoden til at beregne et gennemsnit af gradienterne, så du behøver ikke at skalere batchstørrelsen i sådanne tilfælde.

1. Indstil CPU-enheden 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. Brug replicate_model_fn At indpakke 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. Brug TowerOptimizer At indpakke optimizer:

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

4. Pak din model_fn:

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

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

Lad os se på forskellen i CPU-udnyttelse med tårntilstand aktiveret. Følgende figur viser ml.c5.18xlarge-instansens CPU-udnyttelse med følgende konfiguration:

Ingen Tower + LibSVM data + pipe mode + MKL-DNN deaktiver binding + TensorFlow intra/inter op parallelisme indstilling til maks. antal forekomsters vCPU'er

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

Tårn med indstillet CPU-enhed + LibSVM-data + pipe-tilstand + MKL-DNN deaktiver binding + TensorFlow intra/inter op-parallelisme-indstilling til maks. antal af instansens vCPU'er

CPU-forbruget er højere, når du bruger tårnmetoden, og det overstiger antallet af fysiske kerner.

TensorFlow Mirrored Strategy

TensorFlow MirroredStrategy betyder synkron træning på tværs af flere replikaer på én maskine. Denne strategi bruges typisk til træning på én maskine med flere GPU'er. For at sammenligne træningshastighed med en anden metode bruger vi MirroredStrategy til vores CPU-enhed.

Når du bruger TensorFlow MirroredStrategy, hvis du ikke indstiller CPU-enheden, bruger TensorFlow blot én CPU som enkelt arbejder, hvilket er spild af ressourcer. Vi anbefaler, at du manuelt indstiller CPU-enheden, da den vil reducere funktionen /CPU:0, Så /CPU:0 enheden bruges ikke som en replika 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 skal skalere batchstørrelse, når du bruger MirroredStrategy; skaler f.eks. batchstørrelsen til et multiplum af antallet af GPU-enheder.

For sub-strategien, når du indstiller CPU-enhed, hvis du ikke indstiller cross_device_ops parameter i tf.distribute.MirroredStrategy(), TensorFlow bruger ReductionToOneDevice delstrategi som standard. Men hvis du indstiller HierarchicalCopyAllReduce som delstrategi udfører TensorFlow blot reduceret arbejde på /CPU:0. Når du bruger TensorFlow-datasættet API og distribuerer strategi sammen, skal datasætobjektet returneres i stedet for funktioner og etiketter i funktion input_fn.

Normalt er TensorFlow MirroredStrategy langsommere end tårnmetoden til CPU-træning, så vi anbefaler ikke at bruge MirroredStrategy på en multi-CPU enkelt vært.

Horovod

Horovod er en distribueret deep learning-træningsramme for TensorFlow, Keras, PyTorch og Apache MXNet. Målet med Horovod er at gøre distribueret dyb læring hurtig og nem at bruge.

Der er en parameter på distribution i SageMaker Python SDK Estimator API, som du kan bruge til at angive den distribuerede Horovod-uddannelse. SageMaker sørger for infrastrukturen og kører dit script 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 vælger en GPU-instans såsom ml.p3.8xlarge, skal du fastgøre hver GPU for hver arbejder:

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

For at fremskynde modelkonvergens skal du skalere indlæringshastigheden efter antallet af arbejdere ifølge Horovods officielle dokumentation. I virkelige projekter bør du dog skalere indlæringshastigheden til en vis grad, men ikke efter antallet af arbejdere, hvilket resulterer i dårlig modelydelse. For eksempel, hvis den oprindelige indlæringsrate er 0.001, skalerer vi indlæringshastigheden til 0.0015, selvom antallet af arbejdere er fire eller flere.

Generelt er det kun den primære (Horovod rang 0) der gemmer kontrolpunktet og modellen samt evalueringsoperationen. Du behøver ikke skalere batchstørrelsen, når du bruger Horovod. SageMaker tilbyder Rørtilstand at streame data fra Amazon Simple Storage Service (Amazon S3) til træningsinstanser. Når du aktiverer rørtilstand, skal du være opmærksom på, at forskellige arbejdere på den samme vært skal bruge forskellige kanaler for at undgå fejl. Dette skyldes, at den første arbejdsproces læser FIFO/kanaldata, og andre arbejdsprocesser på samme instans vil hænge, ​​fordi de ikke kan læse data fra samme FIFO/kanal, så Horovod fungerer ikke korrekt. For at undgå dette problem skal du indstille kanalerne i henhold til antallet af arbejdere pr. instans. Sørg i det mindste for, at forskellige arbejdere på den samme vært bruger forskellige kanaler; den samme kanal kan forbruges af arbejdere på en anden vært.

Når du bruger Horovod, kan du støde på følgende fejl:

“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 årsag til dette problem er, at en bestemt rang (såsom rang 0) arbejder langsommere eller udfører flere job end andre rangerer, og dette får andre rang til at vente i lang tid. Selvom rang 0 nogle gange skal udføre mere arbejde end andre rangerer, skal det bemærkes, at rang 0 ikke burde gøre meget i lang tid. For eksempel, for modelevaluering af valideringssættet og lagring af kontrolpunkter under træning, hvis det er uundgåeligt, at disse operationer vil tage lang tid, hvilket kan forårsage fejl, er en løsning at lade alle arbejdere udføre det samme arbejde som rang 0 (kontrolpunkter besparelse, evaluering og så videre).

Datadeling er en af ​​de vigtigste ting at overveje, når du bruger distribueret træning. Du kan bruge TensorFlow dataset.shard() i dit manuskript. SageMaker tilbyder også en datasæt shard funktion i indgangskanal ved indstilling distribution=S3shardbykey i datasætkanalen. 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 bruger Horovod (ml.c5.18xlarge, Horovod + LibSVM + standard intra op og inter op indstilling), som du kan sammenligne med tårnmetoden.

Distribueret træning med flere GPU'er på en enkelt instans

Det er normalt at starte distribueret træning med flere GPU'er på en enkelt instans, fordi dataforskere kun behøver at administrere én instans og drage fordel af højhastighedsforbindelsen mellem GPU'er. SageMaker træningsjob understøtter flere instanstyper, der har flere GPU'er på en enkelt instans, såsom ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge og ml.p4d.24xlarge. Metoden er den samme som flere CPU'er i en enkelt instans, men med nogle få ændringer i scriptet.

Tårn metode

Tårnmetoden her er næsten den samme som ved multi-CPU træning. Du skal skalere batchstørrelsen i henhold til antallet af GPU'er i brug.

TensorFlow Mirrored Strategy

Standard understrategi for MirroredStrategy is NcclAllReduce. Du skal skalere batchstørrelsen i henhold til antallet af GPU'er i brug. Se følgende kode:

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

Accelerer træning på flere instanser

Udskalering er altid en mulighed for at forbedre træningshastigheden. Flere og flere dataforskere vælger dette som en standardindstilling i forhold til distribueret træning. I dette afsnit diskuterer vi strategier for distribueret træning med flere værter.

Flere CPU'er med flere instanser

Der er fire hovedmetoder til at bruge flere CPU'er med flere instanser, når du aktiverer distribueret træning:

• • Parameterserver uden manuelt at indstille operatørernes parallelitet på CPU-enheder
  • Parameterserver med manuel indstilling af operatørernes parallelitet på CPU-enheder
  • Parameterserver med tårn (indstilling af CPU-enheder manuelt og indstillet allow_soft_placement=True in tf.ConfigProto)
  • Horovod

Når du bruger en parameterserver i tf.estimator API, stien til kontrolpunktet skal være en delbar sti, såsom Amazon S3 eller den lokale sti til Amazon Elastic File Service (Amazon EFS) kortlægning til containeren. For en parameterserver i tf.keras, kan kontrolpunktstien indstilles til den lokale sti. For Horovod kan checkpointstien indstilles til en lokal sti for træningsinstansen.

Når du bruger en parameterserver og tf.estimator API med checkpoint-stien til Amazon S3, hvis modellen er ret stor, kan du støde på en fejl i det primære sidder fast ved at gemme checkpoint til S3. Du kan bruge SageMaker indbyggede container TensorFlow 1.15 eller TensorFlow 1.15.2 eller bruge Amazon EFS som checkpointstien til sharen.

Når du bruger en parameterserver til flere værter, kan parameterbelastningen på hver parameterserverproces være ubalanceret (især når der er relativt store indlejringstabelvariabler), hvilket kan forårsage fejl. Du kan kontrollere filstørrelsen for hvert shards kontrolpunkt i Amazon S3 for at bestemme, om parametrene på parameterserveren er afbalancerede, fordi hver parameterserver svarer til et skår af kontrolpunktfilen. For at undgå sådanne problemer kan du bruge partitioneringsfunktionen til at forsøge at gøre parametrene for hver parameterserver jævnt fordelt:

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

Enkelt GPU med flere forekomster

SageMaker-træningsjob understøtter instanser, der kun har én GPU, såsom ml.p3.xlarge-, ml.g4dn- og ml.g5-serien. Der er to hovedmetoder, der bruges i dette scenarie: parameterservere og Horovod.

Den indbyggede parameterserver-distribuerede træningsmetode i SageMaker er at starte en parameterserverproces og en arbejdsproces for hver træningsinstans (hver parameterserver er kun ansvarlig for en del af modelparametrene), så standarden er multi-maskine single- GPU træning. SageMaker indbyggede parameterserver-distribuerede træning er en asynkron gradientopdateringsmetode. For at reducere virkningen af ​​asynkrone opdateringer på træningskonvergens, anbefales det at reducere indlæringshastigheden. Hvis du vil bruge alle GPU'erne på instansen, skal du bruge en kombination af parameterservere og tårnmetoden.

For Horovod, bare sæt processes_per_host=1 i distributionsparameteren for SageMaker Python Estimator API.

Flere GPU'er med flere forekomster

For parameterservere og tårnmetoden er kodeændringerne stort set de samme som tårnmetoden for en enkelt instans med flere GPU'er, og der er ingen grund til manuelt at indstille GPU-enhederne.

For Horovod skal du indstille processes_per_host i distributionsparameteren til antallet af GPU'er for hver træningsinstans. Hvis du bruger rørtilstand, skal antallet af arbejdere pr. instans svare til antallet af kanaler.

Datapipelines

Ud over den infrastruktur, vi har diskuteret, er der en anden vigtig ting at overveje: datapipelinen. En datapipeline refererer til, hvordan du indlæser data og transformerer data, før de feeds ind i neurale netværk. CPU bruges til at forberede data, mens GPU bruges til at beregne data fra CPU. Fordi GPU er en dyr ressource, er mere GPU-tomgang ineffektiv; en god datapipeline i dit træningsjob kunne forbedre GPU- og CPU-udnyttelsen.

Når du forsøger at optimere din TensorFlow-datainputpipeline, skal du overveje den API-rækkefølge, der bruges i TensorFlow-datasæt, træningsdatastørrelsen (mange små filer eller flere store filer), batchstørrelse og så videre.

Lad os se på samspillet mellem GPU og CPU under træning. De følgende figurer sammenligner interaktioner med og uden en pipeline.

En bedre pipeline kunne reducere GPU's inaktive tid. Overvej følgende tips:

• Brug simpel funktionslogik til at udtrække funktioner og etiketter
• Forudhent prøver til hukommelsen
• Reducer unødvendig disk I/O og netværks I/O
• Cache de behandlede funktioner og etiketter i hukommelsen
• Reducer antallet af replikeringstider mellem CPU og GPU
• Få forskellige medarbejdere til at håndtere forskellige dele af træningsdatasættet
• Reducer tidspunktet for opkald til TensorFlow-datasættet API

TensorFlow giver en transformations-API relateret til datasætformater, og rækkefølgen af ​​transformations-API'en i TensorFlow påvirker træningshastigheden meget. Den bedste rækkefølge for at kalde TensorFlow-datasættet API skal testes. Følgende er nogle grundlæggende principper:

• Brug et vektoriseret kort. Det betyder, at man først skal kalde TensorFlow-datasættets batch-API og derefter datasættets kort-API. Den brugerdefinerede parsing-funktion, som findes i kortfunktionen, som f.eks decode_tfrecord parser en minibatch af data i eksempelkoden. Tværtimod er kort først og derefter batch et skalært kort, og den brugerdefinerede parserfunktion behandler kun én prøve.
• Brug TensorFlow-datasættets cache-API til at cache funktioner og etiketter. Sæt TensorFlow-datasættets cache-API før TensorFlow-datasættets gentagelses-API, ellers øges RAM-udnyttelsen lineært epoke for epoke. Hvis datasættet er så stort som RAM, skal du ikke bruge TensorFlow-datasættets cache API. Hvis du skal bruge TensorFlow-datasæt-cache-API'en og shuffle-API'en, skal du overveje at bruge følgende rækkefølge: opret TensorFlow-datasætobjekt -> cache-API -> shuffle-API -> batch-API -> kort-API -> gentag API -> prefetch API.
• Brug tfrecord datasætformat mere end LibSVM-format.
• Filtilstand eller rørtilstand afhænger af dit datasætformat og mængden af ​​filer. Det tfrecorddataset API kan indstilles num_parallel_reads at læse flere filer parallelt og indstille buffer_size at optimere datas læsning, hvorimod pipemodedataset API har ikke sådanne indstillinger. Pipe-tilstand er mere velegnet til situationer, hvor en enkelt fil er stor, og det samlede antal filer er lille. Vi anbefaler at bruge et SageMaker-behandlingsjob til at udføre forbehandlingsarbejdet, såsom at sammenføje flere filer til en større fil i henhold til etiketter, bruge en prøveudtagningsmetode for at gøre datasættet mere afbalanceret og blande det balancerede datasæt.

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)

Til træning i CPU-forekomster indstilles parallelitet af intra op, inter op, og miljøvariablen i MKL-DNN er et godt udgangspunkt.

Automatisk blandet præcisionstræning

Det sidste vi diskuterer er automatisk blandet præcisionstræning, som kan accelerere hastigheden og resultere i modelpræstation. Når dette skrives, understøtter Nvidia V100 GPU (P3-instans) og A100 (P4dn-instans) Tensor-kerne. Du kan aktivere blandet præcisionstræning i TensorFlow, når du bruger disse typer instanser. Fra version 1.14 har TensorFlow understøttet automatisk blandet præcisionstræning. Du kan bruge følgende udsagn til at indpakke din originale optimering:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Hvis modellen er lille, og udnyttelsen af ​​GPU er lav, er der ingen fordel ved automatisk blandet præcisionstræning. Hvis modellen er stor, kan automatisk blandet præcisionstræning accelerere træningshastigheden.

Konklusion

Når du starter din dybe læringsmodeltræning i SageMaker, skal du overveje følgende tips for at opnå en hurtigere træningshastighed:

• Prøv først multi-CPU, single-instance-metoden eller single-GPU, single-instance-metoden. Hvis CPU/GPU-udnyttelsen er meget høj (for eksempel mere end 90%), skal du gå videre til næste trin.
• Prøv flere CPU'er i enkelt vært eller flere GPU'er i enkelt vært. Hvis udnyttelsen er tæt på den maksimale udnyttelse af CPU'er eller GPU'er, skal du gå videre til næste trin.
• Prøv flere CPU'er eller flere GPU'er med flere værter.
• Du skal ændre koder, når du bruger parameterservere eller Horovod. Kodeændringen er ikke den samme for TensorFlow session-baserede API, tf.estimator API, og tf.keras API. En parameterserver eller Horovod kan vise forskellige træningshastigheder i forskellige træningstilfælde og opgaver, så prøv begge metoder, hvis du har tid og budget til at finde den bedste.

Husk følgende råd:

• Tjek udnyttelsen før skalering, optimer din datapipeline, og få CPU og GPU til at overlappe hinanden på tidslinjen.
• Først skaler op, så skaler ud.
• Hvis du ikke kan øge din GPU-udnyttelse efter alle metoderne, så prøv CPU. Der er mange tilfælde (især for klikfrekvens-rangeringsmodellen), hvor den samlede træningstid for CPU-instanstræning er kortere og mere omkostningseffektiv end GPU-instanstræning.

Vi har også et kodeeksempel i GitHub repo, hvor vi viser to eksempler på DeepFM distribueret træning på SageMaker. Den ene er en TensorFlow-parameterserver på CPU-instanser, den anden er Horovod på GPU-instanser.

Om forfatterne

Yuhui Liang er Sr. Machine Learning Solutions Architect. Han er fokuseret på promovering og anvendelse af machine learning og dybt involveret i mange kunders maskinlæringsprojekter. Han har en rig erfaring med distribueret deep learning, anbefalingssystemer og computerbaseret annoncering.

Shishuai Wang er Sr. Machine Learning Solutions Architect. Han arbejder med AWS-kunder for at hjælpe dem med at indføre maskinlæring i stor skala. Han nyder at se film og rejse rundt i verden.