Bästa metoder för TensorFlow 1.x accelerationsträning på Amazon SageMaker

Idag använder många kunder TensorFlow för att träna modeller för djupinlärning för deras klickfrekvens i reklam och personaliseringsrekommendationer inom e-handel. När beteendet hos deras kunder förändras kan de ackumulera stora mängder ny data varje dag. Modelliteration är ett av dataforskarnas dagliga jobb, men de står inför problemet att det tar för lång tid att träna på stora datamängder.

Amazon SageMaker är en helt hanterad plattform för maskininlärning (ML) som kan hjälpa datavetare att fokusera på modeller istället för infrastruktur, med inbyggt stöd för ta med-din-egen-algoritmer och ramverk som TensorFlow och PyTorch. SageMaker erbjuder flexibla distribuerade utbildningsalternativ som anpassar sig till dina specifika arbetsflöden. Eftersom många datavetare kanske saknar erfarenhet av accelerationsträningsprocessen visar vi dig i detta inlägg de faktorer som är viktiga för snabb djupinlärningsmodellträning och de bästa metoderna för accelerationsträning för TensorFlow 1.x på SageMaker. Vi har även en exempelkod på DeepFM distribuerade utbildning på SageMaker på GitHub repo.

Det finns många faktorer du bör tänka på för att maximera CPU/GPU-användningen när du kör ditt TensorFlow-skript på SageMaker, såsom infrastruktur, typ av accelerator, distribuerad träningsmetod, dataladdningsmetod, blandad precisionsträning och mer.

Vi diskuterar bästa praxis inom följande områden:

• Accelerera träningen på en enda instans
• Påskynda träningen på flera tillfällen
• Datapipelines
• Automatisk blandad precisionsträning

Accelerera träningen på en enda instans

När du kör ditt TensorFlow-skript på en enda instans kan du välja en datoroptimerad serie som t.ex Amazon Elastic Compute Cloud (Amazon EC2) C5-serien, eller en accelererad datorserie med flera GPU i en enda instans som p3.8xlarge, p3.16xlarge, p3dn.24xlarge och p4d.24xlarge.

I det här avsnittet diskuterar vi strategier för flera processorer på en enda instans, och distribuerad utbildning med flera GPU:er på en enda instans.

Flera processorer på en enda instans

I det här avsnittet diskuterar vi manuell inställning av operatörers parallellitet på CPU-enheter, tornmetoden, TensorFlow MirroredStrategy och Horovod.

Manuell inställning av operatörers parallellitet på CPU-enheter

TensorFlow väljer automatiskt lämpligt antal trådar för att parallellisera operationsberäkningen i träningsprocessen. Du kan dock ställa in intra_op trådar pool och inter_op parallellitetsinställningar tillhandahållna av TensorFlow och använd miljövariabler för MKL-DNN för att ställa in bindning för OS-tråden. Se följande kod:

# 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övariabeln KMP_AFFINITY av MKL-DNN är inställd på granularity=fine,compact,1,0 som standard. Efter att ha ställt in både intra och inter av TensorFlow till det maximala antalet vCPU:er för den aktuella instansen, är den övre gränsen för CPU-användning nästan densamma som antalet fysiska kärnor i träningsinstansen.

Om du ställer in os.environ["KMP_AFFINITY"]= "verbose,disabled", OS-tråden är inte bunden till hårdvaruhypertråden, och CPU-användningen kan överstiga antalet fysiska kärnor.

När det gäller inställningarna för TensorFlow intraparallellism, TensorFlow interparallellism och antalet MKL-DNN-trådar, resulterar olika kombinationer av dessa tre parametrar i olika träningshastigheter. Därför måste du testa varje fall för att hitta den bästa kombinationen. En vanlig situation är att ställa in de tre parametrarna (intra_op_parallelism_threads och inter_op_parallelism_threads för TensorFlow, os.environ['OMP_NUM_THREADS'] för MKL-DNN) till hälften av antalet vCPU:er (fysisk kärna) eller det totala antalet vCPU:er.

Tower metod

För att replikera en modell över GPU:er får varje GPU sin egen instans av framåtpassningen. Förekomsten av framåtpassningen kallas a torn. Tornmetoden används nästan alltid för GPU-enheter. För att jämföra träningshastighet med andra metoder använder vi här även tornmetoden för vår CPU-enhet.

Om du inte ställer in CPU-enheten manuellt, använder TensorFlow inte tornmetoden för att ta ett genomsnitt av gradienterna, så du behöver inte skala batchstorleken i sådana fall.

1. Ställ in CPU-enheten manuellt:

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. Använda replicate_model_fn att linda 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. Använda TowerOptimizer att linda optimizer:

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

4. Vik in din model_fn:

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

5. Skala batchstorlek till (NUM_CPU – 1).

Låt oss titta på skillnaden mellan CPU-användning med tornläge aktiverat. Följande bild visar ml.c5.18xlarge-instansens CPU-användning med följande konfiguration:

Inget torn + LibSVM-data + rörläge + MKL-DNN inaktivera bindning + TensorFlow intra/inter op parallellism inställning till max antal instansers vCPU:er

Följande bild visar ml.c5.18xlarge-instansens CPU-användning med följande konfiguration:

Torn med inställd CPU-enhet + LibSVM-data + pipe-läge + MKL-DNN inaktivera bindning + TensorFlow intra/inter op-parallellism-inställning till max antal instansers vCPU:er

CPU-användningen är högre när man använder tornmetoden och den överstiger antalet fysiska kärnor.

TensorFlow Mirrored Strategy

TensorFlow MirroredStrategy innebär synkron träning över flera repliker på en maskin. Denna strategi används vanligtvis för träning på en maskin med flera GPU:er. För att jämföra träningshastighet med en annan metod använder vi MirroredStrategy för vår CPU-enhet.

När du använder TensorFlow MirroredStrategy, om du inte ställer in CPU-enheten, använder TensorFlow bara en CPU som enskild arbetare, vilket är ett slöseri med resurser. Vi rekommenderar att du ställer in CPU-enheten manuellt, eftersom det kommer att göra en reducerad operation på /CPU:0, Så /CPU:0 enheten används inte som en replik här. Se följande kod:

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åste skala batchstorlek när du använder MirroredStrategy; skala till exempel batchstorleken till en multipel av antalet GPU-enheter.

För delstrategin när du ställer in CPU-enhet, om du inte ställer in cross_device_ops parameter i tf.distribute.MirroredStrategy(), TensorFlow använder ReductionToOneDevice delstrategi som standard. Men om du ställer in HierarchicalCopyAllReduce Som delstrategi gör TensorFlow bara reduceringsarbetet på /CPU:0. När du använder TensorFlow dataset-API och distribuerar strategi tillsammans, bör datauppsättningsobjektet returneras istället för funktioner och etiketter i funktion input_fn.

Vanligtvis är TensorFlow MirroredStrategy långsammare än tornmetoden på CPU-träning, så vi rekommenderar inte att du använder MirroredStrategy på en enskild värd med flera processorer.

Horovod

Horovod är ett distribuerat ramverk för djupinlärning för TensorFlow, Keras, PyTorch och Apache MXNet. Målet med Horovod är att göra distribuerad djupinlärning snabb och enkel att använda.

Det finns en parameter av distribution i SageMaker Python SDK Estimator API, som du kan använda för att ange Horovods distribuerade utbildning. SageMaker tillhandahåller infrastrukturen och kör ditt skript med MPI. Se följande kod:

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äljer en GPU-instans som ml.p3.8xlarge måste du fästa varje GPU för varje arbetare:

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

För att påskynda modellkonvergensen, skala inlärningshastigheten med antalet arbetare enligt Horovods officiella dokumentation. I verkliga projekt bör du dock skala inlärningshastigheten i viss utsträckning, men inte efter antalet arbetare, vilket resulterar i dålig modellprestanda. Till exempel, om den ursprungliga inlärningsgraden är 0.001, skalar vi inlärningsgraden till 0.0015, även om antalet arbetare är fyra eller fler.

I allmänhet är det bara den primära (Horovod rank 0) som sparar kontrollpunkten och modellen samt utvärderingsoperationen. Du behöver inte skala batchstorleken när du använder Horovod. SageMaker erbjuder Rörläge att strömma data från Amazon enkel lagringstjänst (Amazon S3) till träningsinstanser. När du aktiverar rörläget, var medveten om att olika arbetare på samma värd måste använda olika kanaler för att undvika fel. Detta beror på att den första arbetsprocessen läser FIFO/kanaldata, och andra arbetsprocesser på samma instans kommer att hänga sig eftersom de inte kan läsa data från samma FIFO/kanal, så Horovod fungerar inte korrekt. För att undvika det här problemet, ställ in kanalerna efter antalet arbetare per instans. Se åtminstone till att olika arbetare på samma värd konsumerar olika kanaler; samma kanal kan konsumeras av arbetare på en annan värd.

När du använder Horovod kan du stöta på följande fel:

“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 möjliga orsaken till detta problem är att en viss rang (t.ex. rang 0) fungerar långsammare eller utför fler jobb än andra led, och detta får andra rang att vänta länge. Även om rank 0 ibland måste göra mer arbete än andra rankar, bör det noteras att rank 0 inte borde göra mycket under en lång tid. Till exempel, för modellutvärdering av valideringsuppsättningen och sparande av kontrollpunkter under utbildning, om det är oundvikligt att dessa operationer kommer att ta lång tid, vilket kan orsaka fel, är en lösning att låta alla arbetare göra samma arbete som rang 0 (kontrollpunkter) sparande, utvärdering och så vidare).

Datadelning är en av de viktigaste sakerna att tänka på när du använder distribuerad utbildning. Du kan använda TensorFlow dataset.shard() i ditt manus. SageMaker erbjuder också en dataskärffunktion i ingångskanal genom att sätta distribution=S3shardbykey i datasetkanalen. Se följande kod:

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öljande figur visar resultatet när du använder Horovod (ml.c5.18xlarge, Horovod + LibSVM + standardinställning för intra op och inter op), som du kan jämföra med tornmetoden.

Distribuerad träning med flera GPU:er på en enda instans

Det är normalt att starta distribuerad träning med flera GPU:er på en enda instans eftersom datavetare bara behöver hantera en instans och dra fördel av den snabba sammankopplingen mellan GPU:er. SageMaker-utbildningsjobb stöder flera instanstyper som har flera GPU:er på en enda instans, till exempel ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge och ml.p4d.24xlarge. Metoden är densamma som flera processorer i en enda instans, men med några ändringar i skriptet.

Tower metod

Tornmetoden här är nästan densamma som vid multi-CPU-träning. Du måste skala batchstorleken efter antalet GPU:er som används.

TensorFlow Mirrored Strategy

Standardunderstrategin för MirroredStrategy is NcclAllReduce. Du måste skala batchstorleken efter antalet GPU:er som används. Se följande kod:

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

Påskynda träningen på flera tillfällen

Att skala ut är alltid ett alternativ för att förbättra träningshastigheten. Fler och fler dataforskare väljer detta som ett standardalternativ när det gäller distribuerad utbildning. I det här avsnittet diskuterar vi strategier för distribuerad utbildning med flera värdar.

Flera processorer med flera instanser

Det finns fyra huvudmetoder för att använda flera processorer med flera instanser när du aktiverar distribuerad träning:

• • Parameterserver utan att manuellt ställa in operatörernas parallellitet på CPU-enheter
  • Parameterserver med manuell inställning av operatörers parallellitet på CPU-enheter
  • Parameterserver med torn (ställ in CPU-enheter manuellt och ställ in allow_soft_placement=True in tf.ConfigProto)
  • Horovod

När du använder en parameterserver i tf.estimator API, sökvägen till kontrollpunkten måste vara en delbar sökväg som Amazon S3 eller den lokala sökvägen till Amazon Elastic File Service (Amazon EFS) mappning till behållaren. För en parameterserver i tf.keras, kan kontrollpunktens sökväg ställas in på den lokala sökvägen. För Horovod kan kontrollpunktsvägen ställas in på en lokal väg för träningsinstansen.

När du använder en parameterserver och tf.estimator API med checkpoint sökvägen till Amazon S3, om modellen är ganska stor, kan du stöta på ett fel av den primära har fastnat vid att spara checkpoint till S3. Du kan använda SageMaker inbyggda behållare TensorFlow 1.15 eller TensorFlow 1.15.2 eller använda Amazon EFS som checkpoint-sökväg för andelen.

När en parameterserver används för flera värdar kan parameterbelastningen på varje parameterserverprocess vara obalanserad (särskilt när det finns relativt stora inbäddningstabellvariabler), vilket kan orsaka fel. Du kan kontrollera filstorleken för varje fragments kontrollpunkt i Amazon S3 för att avgöra om parametrarna på parameterservern är balanserade, eftersom varje parameterserver motsvarar en fragment av kontrollpunktsfilen. För att undvika sådana problem kan du använda partitioneringsfunktionen för att försöka fördela parametrarna för varje parameterserver jämnt:

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

Enkel GPU med flera instanser

SageMaker-utbildningsjobb stöder instanser som bara har en GPU, som ml.p3.xlarge-, ml.g4dn- och ml.g5-serierna. Det finns två huvudmetoder som används i detta scenario: parameterservrar och Horovod.

Den inbyggda parameterserverns distribuerade träningsmetoden i SageMaker är att starta en parameterserverprocess och en arbetsprocess för varje träningsinstans (varje parameterserver ansvarar bara för en del av modellparametrarna), så standarden är multi-machine single- GPU utbildning. SageMaker inbyggda parameterserver distribuerad träning är en asynkron gradientuppdateringsmetod. För att minska effekten av asynkrona uppdateringar på träningskonvergens, rekommenderas att minska inlärningshastigheten. Om du vill använda alla GPU:er på instansen måste du använda en kombination av parameterservrar och tornmetoden.

För Horovod, bara ställ in processes_per_host=1 i distributionsparametern för SageMaker Python Estimator API.

Flera GPU:er med flera instanser

För parameterservrar och tornmetoden är kodändringarna i princip desamma som tornmetoden för en enda instans med flera GPU:er, och det finns inget behov av att manuellt ställa in GPU-enheterna.

För Horovod, ställ in processes_per_host i distributionsparametern till antalet GPU:er för varje träningsinstans. Om du använder Pipe-läge måste antalet arbetare per instans matcha antalet kanaler.

Datapipelines

Utöver den infrastruktur vi har diskuterat finns det en annan viktig sak att tänka på: datapipeline. En datapipeline hänvisar till hur du laddar data och transformerar data innan den matas in i neurala nätverk. CPU används för att förbereda data, medan GPU används för att beräkna data från CPU. Eftersom GPU är en dyr resurs, är mer GPU:s vilotid ineffektiv; en bra datapipeline i ditt träningsjobb kan förbättra GPU och CPU-användning.

När du försöker optimera din TensorFlow-datainmatningspipeline, överväg API-ordningen som används i TensorFlow-datauppsättningar, träningsdatastorleken (många små filer eller flera stora filer), batchstorlek och så vidare.

Låt oss titta på interaktionen mellan GPU och CPU under träning. Följande figurer jämför interaktioner med och utan en pipeline.

En bättre pipeline kan minska GPU:s vilotid. Tänk på följande tips:

• Använd enkel funktionslogik för att extrahera funktioner och etiketter
• Förhämta prover till minnet
• Minska onödiga disk I/O och nätverks I/O
• Cachelagra de bearbetade funktionerna och etiketterna i minnet
• Minska antalet replikeringstider mellan CPU och GPU
• Låt olika arbetare ta itu med olika delar av utbildningsdataset
• Minska tiderna för anrop av TensorFlow dataset API

TensorFlow tillhandahåller ett transformerings-API relaterat till datasetformat, och ordningen för transformations-API:t i TensorFlow påverkar träningshastigheten mycket. Den bästa ordningen för att anropa TensorFlow dataset API måste testas. Följande är några grundläggande principer:

• Använd en vektoriserad karta. Detta innebär att först anropa TensorFlow dataset batch API, sedan dataset map API. Den anpassade analysfunktionen som tillhandahålls i kartfunktionen, t.ex decode_tfrecord i exempelkoden, analyserar en minibatch av data. Tvärtom, map first och sedan batch är en skalär karta, och den anpassade parserfunktionen bearbetar bara ett prov.
• Använd TensorFlow dataset cache API för att cache funktioner och etiketter. Placera TensorFlow dataset cache API före TensorFlow dataset repeat API, annars ökar RAM-användningen linjärt epok för epok. Om datauppsättningen är lika stor som RAM, använd inte TensorFlow datasetcache-API. Om du behöver använda TensorFlow dataset cache API och shuffle API, överväg att använda följande ordning: skapa TensorFlow dataset objekt -> cache API -> shuffle API -> batch API -> map API -> repeat API -> prefetch API.
• Använd tfrecord datauppsättningsformat mer än LibSVM-format.
• Filläge eller Pipe-läge beror på ditt datauppsättningsformat och mängden filer. De tfrecorddataset API kan ställa in num_parallel_reads att läsa flera filer parallellt och ställa in buffer_size för att optimera dataavläsningen, medan pipemodedataset API har inte sådana inställningar. Pipe-läget är mer lämpligt för situationer där en enskild fil är stor och det totala antalet filer är litet. Vi rekommenderar att du använder ett SageMaker-bearbetningsjobb för att utföra förbearbetningsarbetet, som att sammanfoga flera filer till en större fil enligt etiketter, använda en samplingsmetod för att göra datamängden mer balanserad och blanda den balanserade datamängden.

Se följande kodexempel:

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)

För utbildning på CPU-instanser, ställa in parallellism av intra op, inter op, och miljövariabeln för MKL-DNN är en bra utgångspunkt.

Automatisk blandad precisionsträning

Det sista vi diskuterar är automatisk blandad precisionsträning, som kan accelerera hastigheten och resultera i modellprestanda. När detta skrivs stöder Nvidia V100 GPU (P3-instans) och A100 (P4dn-instans) Tensor-kärna. Du kan aktivera blandad precisionsträning i TensorFlow när du använder den typen av instanser. Från och med version 1.14 har TensorFlow stöd för automatisk blandad precisionsträning. Du kan använda följande uttalande för att omsluta din ursprungliga optimerare:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Om modellen är liten och användningen av GPU är låg, finns det ingen fördel med automatisk blandad precisionsträning. Om modellen är stor kan automatisk blandad precisionsträning accelerera träningshastigheten.

Slutsats

När du börjar din djupinlärningsmodellträning i SageMaker, överväg följande tips för att uppnå en snabbare träningshastighet:

• Prova metoden med flera processorer, en instans eller metoden med en GPU, en instans först. Om CPU/GPU-användningen är mycket hög (till exempel mer än 90%), gå vidare till nästa steg.
• Prova fler processorer i en värd eller fler GPU:er i en värd. Om utnyttjandet är nära det maximala utnyttjandet av CPU:er eller GPU:er, gå vidare till nästa steg.
• Prova flera processorer eller flera GPU:er med flera värdar.
• Du måste ändra koder när du använder parameterservrar eller Horovod. Kodändringen är inte densamma för TensorFlow-sessionsbaserade API, tf.estimator API och tf.keras API. En parameterserver eller Horovod kan visa olika träningshastigheter i olika träningsfall och -uppgifter, så prova båda metoderna om du har tid och budget att bestämma den bästa.

Tänk på följande råd:

• Kontrollera användningen innan du skalar, optimera din datapipeline och få CPU och GPU att överlappa varandra i tidslinjen.
• Skala först upp och sedan ut.
• Om du inte kan öka din GPU-användning efter alla metoder, prova CPU. Det finns många fall (särskilt för klickfrekvensrankningsmodellen) där den totala träningstiden för CPU-instansträning är kortare och mer kostnadseffektiv än GPU-instansutbildning.

Vi har också ett kodexempel i GitHub repo, där vi visar två exempel på DeepFM distribuerad utbildning på SageMaker. Den ena är en TensorFlow-parameterserver på CPU-instanser, den andra är Horovod på GPU-instanser.

Om författarna

Yuhui Liang är Sr. Machine Learning Solutions Architect. Han är fokuserad på främjande och tillämpning av maskininlärning och djupt involverad i många kunders maskininlärningsprojekt. Han har en rik erfarenhet av distribuerad utbildning för djupinlärning, rekommendationssystem och beräkningsreklam.

Shishuai Wang är Sr. Machine Learning Solutions Architect. Han arbetar med AWS-kunder för att hjälpa dem att ta till sig maskininlärning i stor skala. Han tycker om att titta på film och att resa runt i världen.