Cele mai bune practici pentru antrenamentul de accelerare TensorFlow 1.x pe Amazon SageMaker

Astăzi, mulți clienți folosesc TensorFlow pentru a instrui modele de deep learning pentru rata lor de clic în recomandările de publicitate și personalizare în comerțul electronic. Pe măsură ce comportamentul clienților lor se schimbă, aceștia pot acumula cantități mari de date noi în fiecare zi. Iterația modelului este una dintre sarcinile zilnice ale cercetătorilor de date, dar aceștia se confruntă cu problema de a dura prea mult timp pentru a se instrui pe seturi mari de date.

Amazon SageMaker este o platformă de învățare automată (ML) complet gestionată care ar putea ajuta oamenii de știință de date să se concentreze pe modele în loc de infrastructură, cu suport nativ pentru algoritmi și framework-uri, cum ar fi TensorFlow și PyTorch. SageMaker oferă opțiuni flexibile de instruire distribuite care se adaptează la fluxurile dvs. de lucru specifice. Deoarece mulți oameni de știință de date ar putea să nu aibă experiență în procesul de antrenament cu accelerare, în această postare vă arătăm factorii care contează pentru formarea rapidă a modelului de învățare profundă și cele mai bune practici de antrenament în accelerare pentru TensorFlow 1.x pe SageMaker. Avem și un exemplu de cod al DeepFM instruire distribuită pe SageMaker pe GitHub repo.

Există mulți factori pe care ar trebui să îi luați în considerare pentru a maximiza utilizarea CPU/GPU atunci când rulați scriptul TensorFlow pe SageMaker, cum ar fi infrastructura, tipul de accelerator, metoda de antrenament distribuită, metoda de încărcare a datelor, antrenamentul de precizie mixtă și multe altele.

Discutăm cele mai bune practici în următoarele domenii:

• Accelerează antrenamentul pe o singură instanță
• Accelerați antrenamentul în mai multe cazuri
• Conducte de date
• Antrenament automat de precizie mixtă

Accelerează antrenamentul pe o singură instanță

Când rulați scriptul TensorFlow pe o singură instanță, puteți alege o serie optimizată pentru computer, cum ar fi Cloud Elastic de calcul Amazon (Amazon EC2) Seria C5 sau o serie de calcul accelerată cu mai multe GPU într-o singură instanță, cum ar fi p3.8xlarge, p3.16xlarge, p3dn.24xlarge și p4d.24xlarge.

În această secțiune, discutăm strategii pentru mai multe procesoare pe o singură instanță și instruire distribuită cu mai multe GPU-uri pe o singură instanță.

Mai multe procesoare pe o singură instanță

În această secțiune, discutăm setarea manuală a paralelismului operatorilor pe dispozitivele CPU, metoda turnului, TensorFlow MirroredStrategy și Horovod.

Setarea manuală a paralelismului operatorilor pe dispozitivele CPU

TensorFlow selectează automat numărul adecvat de fire pentru a paraleliza calculul operației în procesul de antrenament. Cu toate acestea, puteți seta intra_op fire pool și inter_op setările de paralelism oferite de TensorFlow și utilizați variabilele de mediu ale MKL-DNN pentru a seta legarea pentru firul de operare. Vezi următorul cod:

# 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'

Variabila de mediu KMP_AFFINITY de MKL-DNN este setat la granularity=fine,compact,1,0 în mod implicit. După setarea atât intra cât și inter TensorFlow la numărul maxim de vCPU al instanței curente, limita superioară a utilizării CPU este aproape aceeași cu numărul de nuclee fizice ale instanței de antrenament.

Dacă stabiliți os.environ["KMP_AFFINITY"]= "verbose,disabled", firul de execuție al sistemului de operare nu este legat de hyperfirul hardware, iar utilizarea CPU ar putea depăși numărul de nuclee fizice.

În ceea ce privește setările TensorFlow intra paralelism, TensorFlow inter paralelism și numărul de fire MKL-DNN, diferite combinații ale acestor trei parametri au ca rezultat viteze de antrenament diferite. Prin urmare, trebuie să testați fiecare caz pentru a găsi cea mai bună combinație. O situație comună este setarea celor trei parametri (intra_op_parallelism_threads și inter_op_parallelism_threads pentru TensorFlow, os.environ['OMP_NUM_THREADS'] pentru MKL-DNN) la jumătate din numărul de vCPU (nucleu fizic) sau numărul total de vCPU.

Metoda turnului

Pentru a replica un model peste GPU-uri, fiecare GPU primește propria instanță a trecerii înainte. Exemplul de trecere înainte se numește a turn. Metoda turn este aproape întotdeauna folosită pentru dispozitivele GPU. Pentru a compara viteza de antrenament cu alte metode, aici folosim și metoda turn pentru dispozitivul nostru CPU.

Dacă nu setați manual dispozitivul CPU, TensorFlow nu folosește metoda turn pentru a media gradienții, așa că nu trebuie să scalați dimensiunea lotului în astfel de cazuri.

1. Setați manual dispozitivul CPU:

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. Utilizare replicate_model_fn a încheia 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. Utilizare TowerOptimizer a încheia optimizer:

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

4. Înfășurați-vă model_fn:

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

5. Scalați dimensiunea lotului la (NUM_CPU – 1).

Să ne uităm la diferența de utilizare a procesorului cu modul turn activat. Următoarea figură arată utilizarea procesorului instanței ml.c5.18xlarge cu următoarea configurație:

Fără turn + date LibSVM + modul pipe + MKL-DNN dezactivați legarea + Setarea paralelismului intra/inter operațional TensorFlow la numărul maxim de vCPU ale instanței

Următoarea figură arată utilizarea procesorului instanței ml.c5.18xlarge cu următoarea configurație:

Turn cu dispozitiv CPU setat + date LibSVM + modul pipe + MKL-DNN dezactivează legarea + Setarea paralelismului intra/inter operațional TensorFlow la numărul maxim de vCPU-uri ale instanței

Utilizarea procesorului este mai mare atunci când se folosește metoda turn și depășește numărul de nuclee fizice.

TensorFlow MirroredStrategy

TensorFlow MirroredStrategy înseamnă antrenament sincron pe mai multe replici pe o singură mașină. Această strategie este utilizată de obicei pentru antrenament pe o singură mașină cu mai multe GPU-uri. Pentru a compara viteza de antrenament cu o altă metodă, folosim MirroredStrategy pentru dispozitivul nostru CPU.

Când utilizați TensorFlow MirroredStrategy, dacă nu setați dispozitivul CPU, TensorFlow folosește doar un CPU ca lucrător unic, ceea ce este o risipă de resurse. Vă recomandăm să setați manual dispozitivul CPU, deoarece va face o operație de reducere /CPU:0, Astfel încât /CPU:0 dispozitivul nu este folosit ca o replică aici. Vezi următorul cod:

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)

Trebuie să scalați dimensiunea lotului când utilizați MirroredStrategy; de exemplu, scalați dimensiunea lotului la un multiplu al numărului de dispozitive GPU.

Pentru substrategia când setați dispozitivul CPU, dacă nu setați cross_device_ops parametru în tf.distribute.MirroredStrategy(), TensorFlow folosește ReductionToOneDevice substrategie implicit. Cu toate acestea, dacă setați HierarchicalCopyAllReduce ca substrategie, TensorFlow face doar munca de reducere /CPU:0. Când utilizați API-ul setului de date TensorFlow și distribuiți strategia împreună, obiectul setului de date ar trebui să fie returnat în loc de caracteristici și etichete în funcție input_fn.

De obicei, TensorFlow MirroredStrategy este mai lentă decât metoda turn pentru antrenamentul CPU, așa că nu recomandăm să utilizați MirroredStrategy pe o singură gazdă cu mai multe CPU.

Horovod

Horovod este un cadru distribuit de instruire pentru învățare profundă pentru TensorFlow, Keras, PyTorch și Apache MXNet. Scopul Horovod este de a face învățarea profundă distribuită rapidă și ușor de utilizat.

Există un parametru de distribution în API-ul SageMaker Python SDK Estimator, pe care îl puteți folosi pentru a stabili instruirea distribuită Horovod. SageMaker asigură infrastructura și rulează scriptul dvs. cu MPI. Vezi următorul cod:

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' 
} 
}

Când alegeți o instanță GPU, cum ar fi ml.p3.8xlarge, trebuie să fixați fiecare GPU pentru fiecare lucrător:

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

Pentru a accelera convergența modelului, scalați rata de învățare în funcție de numărul de lucrători conform documentației oficiale Horovod. Cu toate acestea, în proiectele din lumea reală, ar trebui să scalați rata de învățare într-o oarecare măsură, dar nu după numărul de lucrători, ceea ce are ca rezultat performanța proastă a modelului. De exemplu, dacă rata de învățare inițială este de 0.001, scalam rata de învățare la 0.0015, chiar dacă numărul de lucrători este de patru sau mai mult.

În general, doar primarul (Horovod rang 0) salvează punctul de control și modelul, precum și operația de evaluare. Nu trebuie să măriți dimensiunea lotului când utilizați Horovod. SageMaker oferă Modul țeavă pentru a transmite date în flux Serviciul Amazon de stocare simplă (Amazon S3) în instanțe de antrenament. Când activați modul Pipe, rețineți că diferiți lucrători de pe aceeași gazdă trebuie să folosească canale diferite pentru a evita erorile. Acest lucru se datorează faptului că primul proces de lucru citește datele FIFO/canal, iar alte procese de lucru din aceeași instanță se vor bloca deoarece nu pot citi date de pe același FIFO/canal, deci Horovod nu funcționează corect. Pentru a evita această problemă, setați canalele în funcție de numărul de lucrători per instanță. Cel puțin asigurați-vă că lucrătorii diferiți de pe aceeași gazdă consumă canale diferite; același canal poate fi consumat de lucrătorii de pe o gazdă diferită.

Când utilizați Horovod, este posibil să întâmpinați următoarea eroare:

“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.”

Cauza posibilă a acestei probleme este că un anumit rang (cum ar fi rangul 0) funcționează mai lent sau face mai multe locuri de muncă decât alte ranguri, iar acest lucru face ca alte ranguri să aștepte mult timp. Deși rangul 0 trebuie uneori să lucreze mai mult decât alte ranguri, trebuie remarcat că rangul 0 nu ar trebui să facă mare lucru pentru o lungă perioadă de timp. De exemplu, pentru evaluarea modelului pe setul de validare și salvarea punctelor de control în timpul antrenamentului, dacă este inevitabil ca aceste operațiuni să dureze mult timp, ceea ce ar putea cauza erori, o soluție este să lași toți lucrătorii să facă aceeași muncă ca rangul 0 (puncte de control salvare, evaluare și așa mai departe).

Împărțirea datelor este unul dintre cele mai importante lucruri de luat în considerare atunci când utilizați instruirea distribuită. Puteți utiliza TensorFlow dataset.shard() în scenariul tău. SageMaker oferă, de asemenea, o caracteristică shard de set de date în canal de intrare prin setare distribution=S3shardbykey în canalul setului de date. Vezi următorul cod:

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())

Următoarea figură arată rezultatul când utilizați Horovod (ml.c5.18xlarge, Horovod + LibSVM + setare implicită intra op și inter op), pe care îl puteți compara cu metoda turn.

Antrenament distribuit cu mai multe GPU-uri pe o singură instanță

Este normal să începeți instruirea distribuită cu mai multe GPU-uri pe o singură instanță, deoarece oamenii de știință din date trebuie să gestioneze doar o instanță și să profite de interconectarea de mare viteză dintre GPU-uri. Lucrările de instruire SageMaker acceptă mai multe tipuri de instanțe care au mai multe GPU-uri pe o singură instanță, cum ar fi ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge și ml.p4d.24xlarge. Metoda este aceeași cu mai multe procesoare într-o singură instanță, dar cu câteva modificări în script.

Metoda turnului

Metoda turn aici este aproape aceeași ca și în antrenamentul cu mai multe CPU. Trebuie să scalați dimensiunea lotului în funcție de numărul de GPU-uri utilizate.

TensorFlow MirroredStrategy

Substrategia implicită a MirroredStrategy is NcclAllReduce. Trebuie să scalați dimensiunea lotului în funcție de numărul de GPU-uri utilizate. Vezi următorul cod:

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

Accelerați antrenamentul în mai multe cazuri

Scaling out este întotdeauna o opțiune pentru a îmbunătăți viteza de antrenament. Din ce în ce mai mulți oameni de știință ai datelor aleg aceasta ca opțiune implicită în ceea ce privește instruirea distribuită. În această secțiune, discutăm strategii pentru instruire distribuită cu mai multe gazde.

Procesoare multiple cu mai multe instanțe

Există patru metode principale pentru utilizarea mai multor procesoare cu mai multe instanțe atunci când se activează instruirea distribuită:

• • Server de parametri fără a seta manual paralelismul operatorilor pe dispozitivele CPU
  • Server de parametri cu setarea manuală a paralelismului operatorilor pe dispozitivele CPU
  • Server de parametri cu turn (setarea manuală a dispozitivelor CPU și setarea allow_soft_placement=True in tf.ConfigProto)
  • Horovod

Când utilizați un server de parametri în tf.estimator API, calea punctului de control trebuie să fie o cale partajabilă, cum ar fi Amazon S3 sau calea locală a Serviciul Amazon Elastic File (Amazon EFS) mapare la container. Pentru un server de parametri în tf.keras, calea punctului de control poate fi setată la calea locală. Pentru Horovod, calea punctului de control poate fi setată la o cale locală a instanței de antrenament.

Când utilizați un server de parametri și tf.estimator API cu calea punctului de control către Amazon S3, dacă modelul este destul de mare, s-ar putea să întâmpinați o eroare a elementului principal blocat la salvarea punctului de control în S3. Puteți utiliza containerul încorporat SageMaker TensorFlow 1.15 sau TensorFlow 1.15.2 sau puteți utiliza Amazon EFS ca cale de control a partajării.

Când se utilizează un server de parametri pentru mai multe gazde, încărcarea parametrilor pe fiecare proces de server de parametri poate fi dezechilibrata (mai ales când există variabile de tabel de încorporare relativ mari), ceea ce ar putea cauza erori. Puteți verifica dimensiunea fișierului fiecărui punct de control al fragmentului în Amazon S3 pentru a determina dacă parametrii de pe serverul de parametri sunt echilibrați, deoarece fiecare server de parametri corespunde unui fragment al fișierului punct de control. Pentru a evita astfel de probleme, puteți utiliza funcția de partiționare pentru a încerca să distribuiți uniform parametrii fiecărui server de parametri:

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

Un singur GPU cu mai multe instanțe

Joburile de instruire SageMaker acceptă instanțe care au un singur GPU, cum ar fi seriile ml.p3.xlarge, ml.g4dn și ml.g5. Există două metode principale utilizate în acest scenariu: serverele de parametri și Horovod.

Metoda de instruire distribuită server de parametri încorporată a SageMaker este de a porni un proces de server de parametri și un proces de lucru pentru fiecare instanță de antrenament (fiecare server de parametri este responsabil doar pentru o parte din parametrii modelului), deci implicit este multi-mașină unică Antrenament GPU. Instruirea distribuită pentru serverul de parametri SageMaker încorporat este o metodă de actualizare a gradientului asincron. Pentru a reduce impactul actualizărilor asincrone asupra convergenței antrenamentului, se recomandă reducerea ratei de învățare. Dacă doriți să utilizați toate GPU-urile de pe instanță, trebuie să utilizați o combinație de servere de parametri și metoda turnului.

Pentru Horovod, gata processes_per_host=1 în parametrul de distribuție al API-ului SageMaker Python Estimator.

Mai multe GPU-uri cu mai multe instanțe

Pentru serverele de parametri și metoda turn, modificările codului sunt practic aceleași cu metoda turn pentru o singură instanță cu mai multe GPU și nu este nevoie să setați manual dispozitivele GPU.

Pentru Horovod, setați processes_per_host în parametrul de distribuție la numărul de GPU-uri ale fiecărei instanțe de antrenament. Dacă utilizați modul Pipe, numărul de lucrători per instanță trebuie să se potrivească cu numărul de canale.

Conducte de date

Pe lângă infrastructura despre care am discutat, mai este un lucru important de luat în considerare: conducta de date. O conductă de date se referă la modul în care încărcați și transformați datele înainte ca acestea să intre în rețelele neuronale. CPU este folosit pentru a pregăti date, în timp ce GPU este folosit pentru a calcula datele din CPU. Deoarece GPU-ul este o resursă costisitoare, mai mult timp inactiv GPU este ineficient; o conductă bună de date în munca dvs. de antrenament ar putea îmbunătăți utilizarea GPU și CPU.

Când încercați să optimizați conducta de intrare a datelor TensorFlow, luați în considerare ordinea API utilizată în Seturi de date TensorFlow, dimensiunea datelor de antrenament (o mulțime de fișiere mici sau mai multe fișiere mari), dimensiunea lotului și așa mai departe.

Să ne uităm la interacțiunea dintre GPU și CPU în timpul antrenamentului. Următoarele cifre compară interacțiunile cu și fără o conductă.

O conductă mai bună ar putea reduce timpul de inactivitate a GPU-ului. Luați în considerare următoarele sfaturi:

• Utilizați logica funcțională simplă în extragerea caracteristicilor și a etichetelor
• Preluați mostre în memorie
• Reduceți I/O pe disc inutile și I/O în rețea
• Memorați în memoria cache caracteristicile și etichetele procesate
• Reduceți numărul de replici între CPU și GPU
• Puneți diferiți lucrători să se ocupe de diferite părți ale setului de date de instruire
• Reduceți timpul de apelare a API-ului setului de date TensorFlow

TensorFlow oferă un API de transformare legat de formatele setului de date, iar ordinea API-ului de transformare în TensorFlow afectează foarte mult viteza de antrenament. Trebuie testată cea mai bună ordine de apelare a API-ului setului de date TensorFlow. Următoarele sunt câteva principii de bază:

• Utilizați o hartă vectorizată. Aceasta înseamnă că apelați mai întâi API-ul batch al setului de date TensorFlow, apoi API-ul hartă setului de date. Funcția de analiză personalizată furnizată în funcția de hartă, cum ar fi decode_tfrecord în exemplul de cod, analizează un mini lot de date. Dimpotrivă, harta mai întâi și apoi lotul este o hartă scalară, iar funcția de analiză personalizată procesează doar un eșantion.
• Utilizați API-ul cache al setului de date TensorFlow pentru a stoca în cache funcțiile și etichetele. Puneți API-ul cache al setului de date TensorFlow înaintea API-ului de repetiție al setului de date TensorFlow, altfel utilizarea RAM crește liniar epocă cu epocă. Dacă setul de date este la fel de mare ca RAM, nu utilizați API-ul cache al setului de date TensorFlow. Dacă trebuie să utilizați API-ul cache al setului de date TensorFlow și API-ul shuffle, luați în considerare următoarea ordine: creați obiectul setului de date TensorFlow -> API cache -> API shuffle -> API batch -> API map -> repetare API -> API prefetch.
• Folosește tfrecord format de set de date mai mult decât formatul LibSVM.
• Modul fișier sau modul Pipe depinde de formatul setului de date și de cantitatea de fișiere. The tfrecorddataset API-ul se poate seta num_parallel_reads pentru a citi mai multe fișiere în paralel și a seta buffer_size pentru a optimiza citirea datelor, în timp ce pipemodedataset API-ul nu are astfel de setări. Modul Pipe este mai potrivit pentru situațiile în care un singur fișier este mare și numărul total de fișiere este mic. Vă recomandăm să utilizați o lucrare de procesare SageMaker pentru a face munca de preprocesare, cum ar fi unirea mai multor fișiere la un fișier mai mare conform etichetelor, utilizarea unei metode de eșantionare pentru a face setul de date mai echilibrat și amestecarea setului de date echilibrat.

Vedeți următorul exemplu de cod:

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)

Pentru instruirea pe instanțele CPU, setarea paralelismului de intra op, inter op, iar variabila de mediu MKL-DNN este un bun punct de plecare.

Antrenament automat de precizie mixtă

Ultimul lucru pe care îl discutăm este antrenamentul automat de precizie mixtă, care poate accelera viteza și poate duce la performanța modelului. În momentul scrierii acestui articol, GPU Nvidia V100 (instanță P3) și A100 (instanță P4dn) acceptă nucleul Tensor. Puteți activa antrenamentul de precizie mixtă în TensorFlow atunci când utilizați aceste tipuri de instanțe. Începând cu versiunea 1.14, TensorFlow a acceptat antrenamentul automat de precizie mixtă. Puteți folosi următoarea declarație pentru a încheia optimizatorul original:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Dacă modelul este mic și utilizarea GPU-ului este scăzută, nu există niciun avantaj al antrenamentului automat de precizie mixtă. Dacă modelul este mare, antrenamentul automat de precizie mixtă poate accelera viteza de antrenament.

Concluzie

Când începeți antrenamentul modelului de învățare profundă în SageMaker, luați în considerare următoarele sfaturi pentru a obține o viteză mai rapidă de antrenament:

• Încercați mai întâi metoda multi-CPU, cu o singură instanță sau cu un singur GPU, metoda cu o singură instanță. Dacă utilizarea CPU/GPU este foarte mare (de exemplu, mai mult de 90%), treceți la pasul următor.
• Încercați mai multe procesoare într-o singură gazdă sau mai multe GPU-uri într-o singură gazdă. Dacă utilizarea este aproape de utilizarea maximă a procesoarelor sau a GPU-urilor, treceți la pasul următor.
• Încercați mai multe procesoare sau mai multe GPU-uri cu mai multe gazde.
• Trebuie să modificați codurile atunci când utilizați servere de parametri sau Horovod. Modificarea codului nu este aceeași pentru API-ul bazat pe sesiune TensorFlow, tf.estimator API și tf.keras API. Un server de parametri sau Horovod poate afișa viteze diferite de antrenament în diferite cazuri și sarcini de antrenament, așa că încercați ambele metode dacă aveți timp și buget pentru a o determina pe cea mai bună.

Ține cont de următoarele sfaturi:

• Verificați utilizarea înainte de scalare, optimizați canalul de date și faceți ca CPU și GPU să se suprapună în cronologie.
• Mai întâi creșteți, apoi extindeți.
• Dacă nu vă puteți crește utilizarea GPU-ului după toate metodele, încercați CPU. Există multe cazuri (în special pentru modelul de clasare a ratei de clic) în care timpul total de antrenament al antrenării instanței CPU este mai scurt și mai rentabil decât antrenamentul instanței GPU.

Avem, de asemenea, un eșantion de cod în GitHub repo, unde arătăm două mostre de instruire distribuită DeepFM pe SageMaker. Unul este un server de parametri TensorFlow pe instanțele CPU, celălalt este Horovod pe instanțele GPU.

Despre Autori

Yuhui Liang este un arhitect Sr. Machine Learning Solutions. El este concentrat pe promovarea și aplicarea învățării automate și s-a implicat profund în proiectele de învățare automată ale multor clienți. Are o experiență bogată în instruire distribuită de deep learning, sisteme de recomandare și publicitate computațională.

Shishuai Wang este un arhitect Sr. Machine Learning Solutions. El lucrează cu clienții AWS pentru a-i ajuta să adopte învățarea automată la scară largă. Îi place să se uite la filme și să călătorească în jurul lumii.