Best practices voor TensorFlow 1.x acceleratietraining op Amazon SageMaker

Tegenwoordig gebruiken veel klanten TensorFlow om deep learning-modellen te trainen voor hun klikfrequentie in advertenties en personalisatie-aanbevelingen in e-commerce. Naarmate het gedrag van hun klanten verandert, kunnen ze elke dag grote hoeveelheden nieuwe gegevens verzamelen. Het herhalen van modellen is een van de dagelijkse taken van datawetenschappers, maar ze worden geconfronteerd met het probleem dat het te lang duurt om te trainen op grote datasets.

Amazon Sage Maker is een volledig beheerd platform voor machine learning (ML) dat datawetenschappers kan helpen zich te concentreren op modellen in plaats van op infrastructuur, met native ondersteuning voor bring-your-own-algoritmen en frameworks zoals TensorFlow en PyTorch. SageMaker biedt flexibele gedistribueerde trainingsopties die zich aanpassen aan uw specifieke workflows. Omdat veel datawetenschappers misschien geen ervaring hebben met het acceleratietrainingsproces, laten we u in dit bericht de factoren zien die van belang zijn voor snelle deep learning-modeltraining en de best practices van acceleratietraining voor TensorFlow 1.x op SageMaker. We hebben ook een voorbeeldcode van: DeepFM gedistribueerde training op SageMaker op de GitHub repo.

Er zijn veel factoren waarmee u rekening moet houden om het CPU/GPU-gebruik te maximaliseren wanneer u uw TensorFlow-script op SageMaker uitvoert, zoals infrastructuur, type accelerator, gedistribueerde trainingsmethode, methode voor het laden van gegevens, gemengde precisietraining en meer.

We bespreken best practices op de volgende gebieden:

• Versnel training op één enkele instantie
• Versnel training op meerdere instanties
• Gegevenspijplijnen
• Automatische gemengde precisietraining

Versnel training op één enkele instantie

Wanneer u uw TensorFlow-script op één instantie uitvoert, kunt u een computer-geoptimaliseerde serie kiezen, zoals de Amazon Elastic Compute-cloud (Amazon EC2) C5-serie, of een versnelde computerserie met meerdere GPU's in één instantie, zoals p3.8xlarge, p3.16xlarge, p3dn.24xlarge en p4d.24xlarge.

In deze sectie bespreken we strategieën voor meerdere CPU's op één exemplaar en gedistribueerde training met meerdere GPU's op één exemplaar.

Meerdere CPU's op één exemplaar

In deze sectie bespreken we het handmatig instellen van het parallellisme van operators op CPU-apparaten, de torenmethode, TensorFlow MirroredStrategy en Horovod.

Handmatig parallellisme van operators instellen op CPU-apparaten

TensorFlow selecteert automatisch het juiste aantal threads om de bewerkingsberekening in het trainingsproces parallel te laten lopen. U kunt echter de intra_op threads pool en inter_op parallellisme-instellingen geleverd door TensorFlow en gebruik omgevingsvariabelen van MKL-DNN om binding voor de OS-thread in te stellen. Zie de volgende code:

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

De omgevingsvariabele KMP_AFFINITY van MKL-DNN is ingesteld op granularity=fine,compact,1,0 standaard. Nadat zowel intra als inter van TensorFlow het maximale aantal vCPU's van de huidige instantie is ingesteld, is de bovengrens van het CPU-gebruik bijna hetzelfde als het aantal fysieke kernen van de trainingsinstantie.

Als je instelt os.environ["KMP_AFFINITY"]= "verbose,disabled", is de OS-thread niet gebonden aan de hardware-hyperthread en kan het CPU-gebruik het aantal fysieke cores overschrijden.

Met betrekking tot de instellingen van TensorFlow intra parallellisme, TensorFlow inter parallellisme en het aantal MKL-DNN-threads, resulteren verschillende combinaties van deze drie parameters in verschillende trainingssnelheden. Daarom moet u elk geval testen om de beste combinatie te vinden. Een veelvoorkomende situatie is het instellen van de drie parameters (intra_op_parallelism_threads en inter_op_parallelism_threads voor TensorFlow, os.environ['OMP_NUM_THREADS'] voor MKL-DNN) tot de helft van het aantal vCPU's (fysieke kern) of het totale aantal vCPU's.

toren methode:

Om een ​​model over GPU's te repliceren, krijgt elke GPU zijn eigen exemplaar van de forward pass. De instantie van de voorwaartse pas heet a toren. De torenmethode wordt bijna altijd gebruikt voor GPU-apparaten. Om de trainingssnelheid te vergelijken met andere methoden, gebruiken we hier ook de torenmethode voor ons CPU-apparaat.

Als u het CPU-apparaat niet handmatig instelt, gebruikt TensorFlow de torenmethode niet om de hellingen te middelen, dus u hoeft de batchgrootte in dergelijke gevallen niet te schalen.

1. Stel het CPU-apparaat handmatig in:

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. Te gebruiken replicate_model_fn inpakken 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. Te gebruiken TowerOptimizer inpakken optimizer:

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

4. Wikkel je model_fn:

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

5. Schaal de batchgrootte naar (NUM_CPU – 1).

Laten we eens kijken naar het verschil in CPU-gebruik met de torenmodus ingeschakeld. De volgende afbeelding toont het CPU-gebruik van de ml.c5.18xlarge-instantie met de volgende configuratie:

Geen toren + LibSVM-gegevens + pijpmodus + MKL-DNN binding uitschakelen + TensorFlow intra/inter-op parallellisme instellen op max. aantal vCPU's van instantie

De volgende afbeelding toont het CPU-gebruik van de ml.c5.18xlarge-instantie met de volgende configuratie:

Toren met ingesteld CPU-apparaat + LibSVM-gegevens + pijpmodus + MKL-DNN binding uitschakelen + TensorFlow intra/inter-op parallellisme instellen op max. aantal vCPU's van instantie

Het CPU-gebruik is hoger bij gebruik van de torenmethode en overschrijdt het aantal fysieke kernen.

TensorFlow MirroredStrategie

TensorFlow MirroredStrategy betekent synchrone training over meerdere replica's op één machine. Deze strategie wordt meestal gebruikt voor training op één machine met meerdere GPU's. Om de trainingssnelheid te vergelijken met een andere methode, gebruiken we MirroredStrategy voor ons CPU-apparaat.

Als u TensorFlow MirroredStrategy gebruikt en u het CPU-apparaat niet instelt, gebruikt TensorFlow slechts één CPU als enkele werknemer, wat een verspilling van middelen is. We raden aan om het CPU-apparaat handmatig in te stellen, omdat dit een verminderde bewerking zal uitvoeren /CPU:0maakt, zodat de /CPU:0 apparaat wordt hier niet als replica gebruikt. Zie de volgende code:

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)

U moet de batchgrootte schalen wanneer u MirroredStrategy gebruikt; schaal bijvoorbeeld de batchgrootte naar een veelvoud van het aantal GPU-apparaten.

Voor de substrategie wanneer u het CPU-apparaat instelt, als u de . niet instelt cross_device_ops parameter in tf.distribute.MirroredStrategy(), TensorFlow gebruikt de ReductionToOneDevice standaard een substrategie. Als u echter instelt HierarchicalCopyAllReduce als de sub-strategie doet TensorFlow alleen het reducerende werk aan /CPU:0. Wanneer u de TensorFlow-gegevensset-API gebruikt en de strategie samen distribueert, moet het gegevenssetobject worden geretourneerd in plaats van functies en labels in functie input_fn.

Gewoonlijk is TensorFlow MirroredStrategy langzamer dan de torenmethode bij CPU-training, dus we raden het gebruik van MirroredStrategy op een enkele host met meerdere CPU's af.

Horovod

Horovod is een gedistribueerd deep learning-trainingsframework voor TensorFlow, Keras, PyTorch en Apache MXNet. Het doel van Horovod is om gedistribueerd deep learning snel en gebruiksvriendelijk te maken.

Er is een parameter van distribution in de SageMaker Python SDK Estimator API, die je zou kunnen gebruiken om de Horovod gedistribueerde training te vermelden. SageMaker voorziet de infrastructuur en voert uw script uit met MPI. Zie de volgende code:

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

Wanneer u een GPU-instantie kiest, zoals ml.p3.8xlarge, moet u elke GPU voor elke worker vastzetten:

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

Om de modelconvergentie te versnellen, schaalt u de leersnelheid op met het aantal werknemers volgens de officiële documentatie van Horovod. In echte projecten moet u de leersnelheid echter tot op zekere hoogte schalen, maar niet op basis van het aantal werknemers, wat resulteert in slechte modelprestaties. Als de oorspronkelijke leersnelheid bijvoorbeeld 0.001 is, schalen we de leersnelheid naar 0.0015, zelfs als het aantal werknemers vier of meer is.

Over het algemeen slaat alleen de primaire (Horovod-rang 0) het controlepunt en het model op, evenals de evaluatiebewerking. U hoeft de batchgrootte niet te schalen bij het gebruik van Horovod. SageMaker aanbiedingen Pijp modus om gegevens van te streamen Amazon eenvoudige opslagservice (Amazon S3) in trainingsinstanties. Wanneer u de Pipe-modus inschakelt, moet u er rekening mee houden dat verschillende werknemers op dezelfde host verschillende kanalen moeten gebruiken om fouten te voorkomen. Dit komt omdat het eerste werkproces de FIFO/kanaalgegevens leest, en andere werkprocessen op dezelfde instantie zullen vastlopen omdat ze geen gegevens van hetzelfde FIFO/kanaal kunnen lezen, dus Horovod werkt niet goed. Om dit probleem te voorkomen, stelt u de kanalen in op het aantal werkers per instantie. Zorg er in ieder geval voor dat verschillende werknemers op dezelfde host verschillende kanalen gebruiken; hetzelfde kanaal kan worden gebruikt door werknemers op een andere host.

Wanneer u Horovod gebruikt, kunt u de volgende fout tegenkomen:

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

De mogelijke oorzaak van dit probleem is dat een bepaalde rang (zoals rang 0) langzamer werkt of meer taken uitvoert dan andere rangen, waardoor andere rangen lang moeten wachten. Hoewel rang 0 soms meer werk moet doen dan andere rangen, moet worden opgemerkt dat rang 0 lange tijd niet veel zou moeten doen. Bijvoorbeeld, voor de modelevaluatie op de validatieset en het opslaan van checkpoints tijdens de training, als het onvermijdelijk is dat deze operaties lang zullen duren, wat fouten kan veroorzaken, is een tijdelijke oplossing om alle werknemers hetzelfde werk te laten doen als rang 0 (checkpoints opslaan, evalueren, enzovoort).

Gegevens sharding is een van de belangrijkste dingen om te overwegen bij het gebruik van gedistribueerde training. U kunt TensorFlow gebruiken dataset.shard() in je scriptie. SageMaker biedt ook een dataset-shardfunctie in de ingangen kanaal door in te stellen distribution=S3shardbykey in het datasetkanaal. Zie de volgende code:

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

De volgende afbeelding toont het resultaat bij gebruik van Horovod (ml.c5.18xlarge, Horovod + LibSVM + standaard intra- en inter-op-instelling), die u kunt vergelijken met de torenmethode.

Gedistribueerde training met meerdere GPU's op één instantie

Het is normaal om gedistribueerde training te starten met meerdere GPU's op één instantie, omdat datawetenschappers slechts één instantie hoeven te beheren en profiteren van de snelle interlink tussen GPU's. SageMaker-trainingstaken ondersteunen meerdere instantietypen met meerdere GPU's op één instantie, zoals ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge en ml.p4d.24xlarge. De methode is hetzelfde als meerdere CPU's in één instantie, maar met een paar wijzigingen in het script.

toren methode:

De torenmethode is hier bijna hetzelfde als bij multi-CPU-training. U moet de batchgrootte schalen op basis van het aantal GPU's dat in gebruik is.

TensorFlow MirroredStrategie

De standaardsubstrategie van MirroredStrategy is NcclAllReduce. U moet de batchgrootte schalen op basis van het aantal GPU's dat in gebruik is. Zie de volgende code:

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

Versnel training op meerdere instanties

Uitschalen is altijd een optie om de trainingssnelheid te verbeteren. Steeds meer datawetenschappers kiezen dit als standaardoptie met betrekking tot gedistribueerde training. In deze sectie bespreken we strategieën voor gedistribueerde training met meerdere hosts.

Meerdere CPU's met meerdere instanties

Er zijn vier hoofdmethoden voor het gebruik van meerdere CPU's met meerdere instanties bij het inschakelen van gedistribueerde training:

• • Parameterserver zonder handmatig het parallellisme van operators op CPU-apparaten in te stellen
  • Parameterserver met handmatig instellen van het parallellisme van operators op CPU-apparaten
  • Parameterserver met toren (CPU-apparaten handmatig instellen en instellen) allow_soft_placement=True in tf.ConfigProto)
  • Horovod

Bij gebruik van een parameterserver in de tf.estimator API, het pad van het controlepunt moet een deelbaar pad zijn, zoals Amazon S3 of het lokale pad van Amazon Elastic-bestandsservice (Amazon EFS) toewijzing aan de container. Voor een parameterserver in tf.keras, kan het controlepuntpad worden ingesteld op het lokale pad. Voor Horovod kan het controlepuntpad worden ingesteld op een lokaal pad van het trainingsexemplaar.

Bij gebruik van een parameterserver en de tf.estimator API met het controlepuntpad naar Amazon S3, als het model vrij groot is, kunt u een fout tegenkomen van de primaire die vastzit bij het opslaan van controlepunt naar S3. U kunt de ingebouwde container TensorFlow 1.15 of TensorFlow 1.15.2 van SageMaker gebruiken of Amazon EFS gebruiken als het controlepuntpad van de share.

Wanneer een parameterserver voor meerdere hosts wordt gebruikt, kan de parameterbelasting op elk parameterserverproces onevenwichtig zijn (vooral wanneer er relatief grote inbeddingstabelvariabelen zijn), wat fouten kan veroorzaken. U kunt de bestandsgrootte van elk controlepunt van de shard in Amazon S3 controleren om te bepalen of de parameters op de parameterserver in evenwicht zijn, omdat elke parameterserver overeenkomt met een shard van het controlepuntbestand. Om dergelijke problemen te voorkomen, kunt u de partitionerfunctie gebruiken om te proberen de parameters van elke parameterserver gelijkmatig te verdelen:

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

Enkele GPU met meerdere instanties

SageMaker-trainingstaken ondersteunen instanties die slechts één GPU hebben, zoals de series ml.p3.xlarge, ml.g4dn en ml.g5. Er zijn twee hoofdmethoden die in dit scenario worden gebruikt: parameterservers en Horovod.

De ingebouwde parameterserver gedistribueerde trainingsmethode van SageMaker is het starten van een parameterserverproces en een werkproces voor elke trainingsinstantie (elke parameterserver is slechts verantwoordelijk voor een deel van de modelparameters), dus de standaard is multi-machine single- GPU-training. De SageMaker ingebouwde parameterserver gedistribueerde training is een asynchrone methode voor het bijwerken van gradiënten. Om de impact van asynchrone updates op trainingsconvergentie te verminderen, wordt aanbevolen om de leersnelheid te verlagen. Als u alle GPU's op de instantie wilt gebruiken, moet u een combinatie van parameterservers en de torenmethode gebruiken.

Voor Horovod, stel gewoon in processes_per_host=1 in de distributieparameter van de SageMaker Python Estimator API.

Meerdere GPU's met meerdere instanties

Voor parameterservers en de torenmethode zijn de codewijzigingen in principe hetzelfde als de torenmethode voor een enkele instantie met meerdere GPU's, en het is niet nodig om de GPU-apparaten handmatig in te stellen.

Stel voor Horovod processen_per_host in de distributieparameter in op het aantal GPU's van elk trainingsexemplaar. Als u de Pipe-modus gebruikt, moet het aantal werkers per instantie overeenkomen met het aantal kanalen.

Gegevenspijplijnen

Naast de infrastructuur die we hebben besproken, is er nog iets belangrijks om rekening mee te houden: de datapijplijn. Een gegevenspijplijn verwijst naar hoe u gegevens laadt en gegevens transformeert voordat deze in neurale netwerken worden ingevoerd. CPU wordt gebruikt om gegevens voor te bereiden, terwijl GPU wordt gebruikt om de gegevens van CPU te berekenen. Omdat GPU een dure bron is, is meer inactieve tijd van de GPU inefficiënt; een goede gegevenspijplijn in uw trainingstaak kan het GPU- en CPU-gebruik verbeteren.

Wanneer u uw TensorFlow-gegevensinvoerpijplijn probeert te optimaliseren, moet u rekening houden met de API-volgorde die wordt gebruikt in TensorFlow-gegevenssets, de grootte van de trainingsgegevens (veel kleine bestanden of meerdere grote bestanden), batchgrootte, enzovoort.

Laten we eens kijken naar de interactie tussen GPU en CPU tijdens de training. In de volgende figuren worden interacties met en zonder pijpleiding vergeleken.

Een betere pijplijn zou de inactieve tijd van de GPU kunnen verminderen. Denk aan de volgende tips:

• Gebruik eenvoudige functielogica bij het extraheren van kenmerken en labels
• Prefetch samples naar het geheugen
• Verminder onnodige schijf-I/O en netwerk-I/O
• Cache de verwerkte functies en labels in het geheugen
• Verminder het aantal replicatietijden tussen CPU en GPU
• Verschillende werknemers verschillende delen van de trainingsdataset laten behandelen
• Verminder de tijden van het aanroepen van de TensorFlow-dataset-API

TensorFlow biedt een transformatie-API met betrekking tot dataset-indelingen, en de volgorde van de transformatie-API in TensorFlow heeft veel invloed op de trainingssnelheid. De beste volgorde voor het aanroepen van de TensorFlow-dataset-API moet worden getest. Hieronder volgen enkele basisprincipes:

• Gebruik een gevectoriseerde kaart. Dit betekent dat u eerst de batch-API van de TensorFlow-dataset aanroept en daarna de dataset-kaart-API. De aangepaste parseerfunctie in de kaartfunctie, zoals: decode_tfrecord in de voorbeeldcode een mini-batch gegevens parseert. Integendeel, eerst map en dan batch is een scalaire map, en de aangepaste parserfunctie verwerkt slechts één voorbeeld.
• Gebruik de cache-API van de TensorFlow-gegevensset om functies en labels in de cache op te slaan. Plaats de cache-API van de TensorFlow-gegevensset vóór de herhaal-API van de TensorFlow-gegevensset, anders neemt het RAM-gebruik lineair per tijdperk toe. Als de gegevensset zo groot is als RAM, gebruik dan niet de TensorFlow-gegevenssetcache-API. Als u de cache-API en shuffle-API van de TensorFlow-gegevensset moet gebruiken, overweeg dan de volgende volgorde te gebruiken: maak een TensorFlow-gegevenssetobject -> cache-API -> shuffle-API -> batch-API -> kaart-API -> herhaal-API -> prefetch-API.
• Gebruik de tfrecord dataset-indeling meer dan LibSVM-indeling.
• De bestandsmodus of Pipe-modus is afhankelijk van uw dataset-indeling en het aantal bestanden. De tfrecorddataset API kan instellen num_parallel_reads om meerdere bestanden parallel te lezen en in te stellen buffer_size om het lezen van gegevens te optimaliseren, terwijl de pipemodedataset API heeft dergelijke instellingen niet. De modus Pipe is meer geschikt voor situaties waarin een enkel bestand groot is en het totale aantal bestanden klein. We raden aan om een ​​SageMaker-verwerkingstaak te gebruiken om het voorverwerkingswerk uit te voeren, zoals het samenvoegen van meerdere bestanden tot een groter bestand volgens labels, het gebruik van een steekproefmethode om de gegevensset evenwichtiger te maken en het shuffelen van de uitgebalanceerde gegevensset.

Zie het volgende codevoorbeeld:

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)

Voor training op CPU-instanties, het instellen van parallellisme van intra op, inter op, en de omgevingsvariabele van MKL-DNN is een goed startpunt.

Automatische gemengde precisietraining

Het laatste dat we bespreken is automatische gemengde precisietraining, die de snelheid kan versnellen en kan resulteren in modelprestaties. Op het moment van schrijven ondersteunen Nvidia V100 GPU (P3-instantie) en A100 (P4dn-instantie) Tensor-kern. U kunt gemengde precisietraining inschakelen in TensorFlow wanneer u dit soort instanties gebruikt. Vanaf versie 1.14 ondersteunt TensorFlow automatische gemengde precisietraining. U kunt de volgende verklaring gebruiken om uw oorspronkelijke optimalisatieprogramma in te pakken:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Als het model klein is en het GPU-gebruik laag is, is er geen voordeel van automatische gemengde precisietraining. Als het model groot is, kan automatische gemengde precisietraining de trainingssnelheid versnellen.

Conclusie

Wanneer u uw deep learning-modeltraining in SageMaker start, overweeg dan de volgende tips om een ​​hogere trainingssnelheid te bereiken:

• Probeer eerst de methode met meerdere CPU's, één instantie of één GPU, één instantie. Als het CPU/GPU-gebruik erg hoog is (bijvoorbeeld meer dan 90%), ga dan naar de volgende stap.
• Probeer meer CPU's in één host of meer GPU's in één host. Als het gebruik in de buurt van het maximale gebruik van CPU's of GPU's ligt, gaat u naar de volgende stap.
• Probeer meerdere CPU's of meerdere GPU's met meerdere hosts.
• U moet codes wijzigen wanneer u parameterservers of Horovod gebruikt. De codewijziging is niet hetzelfde voor de TensorFlow-sessiegebaseerde API, tf.estimator API, en tf.keras API. Een parameterserver of Horovod kan verschillende trainingssnelheden tonen in verschillende trainingsgevallen en taken, dus probeer beide methoden als je de tijd en het budget hebt om de beste te bepalen.

Houd rekening met het volgende advies:

• Controleer het gebruik voordat u gaat schalen, optimaliseer uw gegevenspijplijn en zorg dat CPU en GPU elkaar in de tijdlijn overlappen.
• Eerst opschalen, dan uitschalen.
• Als u uw GPU-gebruik na alle methoden niet kunt verhogen, probeer dan CPU. Er zijn veel gevallen (met name voor het rangschikkingsmodel voor klikfrequenties) waarin de totale trainingstijd van CPU-instantietraining korter en kosteneffectiever is dan GPU-instantietraining.

We hebben ook een codevoorbeeld in de GitHub repo, waar we twee voorbeelden van gedistribueerde DeepFM-training op SageMaker laten zien. De ene is een TensorFlow-parameterserver op CPU-instanties, de andere is Horovod op GPU-instanties.

Over de auteurs

Yuhui Liang is Sr. Machine Learning Solutions Architect. Hij is gefocust op de promotie en toepassing van machine learning en is nauw betrokken bij de machine learning-projecten van veel klanten. Hij heeft een rijke ervaring in deep learning gedistribueerde trainingen, aanbevelingssystemen en computationele reclame.

Shishuai Wang is Sr. Machine Learning Solutions Architect. Hij werkt samen met AWS-klanten om hen te helpen machine learning op grote schaal toe te passen. Hij kijkt graag films en reist de wereld rond.