Best practice per la formazione sull'accelerazione di TensorFlow 1.x su Amazon SageMaker

Ripubblicato da Platone

Seguaci: 0

Oggi molti clienti utilizzano TensorFlow per addestrare modelli di deep learning per la percentuale di clic nei consigli pubblicitari e di personalizzazione nell'e-commerce. Man mano che il comportamento dei loro clienti cambia, possono accumulare grandi quantità di nuovi dati ogni giorno. L'iterazione del modello è uno dei lavori quotidiani dei data scientist, ma devono affrontare il problema di impiegare troppo tempo per addestrarsi su set di dati di grandi dimensioni.

Amazon Sage Maker è una piattaforma di machine learning (ML) completamente gestita che potrebbe aiutare i data scientist a concentrarsi sui modelli anziché sull'infrastruttura, con supporto nativo per algoritmi e framework personalizzati come TensorFlow e PyTorch. SageMaker offre opzioni di formazione distribuita flessibili che si adattano ai tuoi flussi di lavoro specifici. Poiché molti data scientist potrebbero non avere esperienza nel processo di formazione con accelerazione, in questo post ti mostriamo i fattori che contano per la formazione rapida del modello di deep learning e le migliori pratiche di formazione con accelerazione per TensorFlow 1.x su SageMaker. Abbiamo anche un codice di esempio di Deep FM formazione distribuita su SageMaker su Repository GitHub.

Ci sono molti fattori che dovresti considerare per massimizzare l'utilizzo di CPU/GPU quando esegui lo script TensorFlow su SageMaker, come l'infrastruttura, il tipo di acceleratore, il metodo di training distribuito, il metodo di caricamento dei dati, il training a precisione mista e altro ancora.

Discutiamo le migliori pratiche nelle seguenti aree:

Accelera la formazione su una singola istanza
Accelera la formazione su più istanze
Pipeline di dati
Allenamento automatico di precisione misto

Accelera la formazione su una singola istanza

Quando esegui lo script TensorFlow su una singola istanza, puoi scegliere una serie ottimizzata per computer come Cloud di calcolo elastico di Amazon (Amazon EC2) Serie C5 o una serie di elaborazione accelerata con più GPU in una singola istanza come p3.8xlarge, p3.16xlarge, p3dn.24xlarge e p4d.24xlarge.

In questa sezione verranno discusse le strategie per più CPU su una singola istanza e l'addestramento distribuito con più GPU su una singola istanza.

Più CPU su una singola istanza

In questa sezione, discuteremo l'impostazione manuale del parallelismo degli operatori sui dispositivi CPU, il metodo tower, TensorFlow MirroredStrategy e Horovod.

Impostazione manuale del parallelismo degli operatori sui dispositivi CPU

TensorFlow seleziona automaticamente il numero appropriato di thread per parallelizzare il calcolo dell'operazione nel processo di training. Tuttavia, potresti impostare il file intra_op pool di thread e inter_op impostazioni di parallelismo fornite da TensorFlow e utilizza variabili di ambiente di MKL-DNN per impostare l'associazione per il thread del sistema operativo. Vedere il seguente codice:

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

La variabile d'ambiente KMP_AFFINITY di MKL-DNN è impostato su granularity=fine,compact,1,0 per impostazione predefinita. Dopo aver impostato sia intra che inter di TensorFlow sul numero massimo di vCPU dell'istanza corrente, il limite superiore di utilizzo della CPU è quasi uguale al numero di core fisici dell'istanza di training.

Se si imposta os.environ["KMP_AFFINITY"]= "verbose,disabled", il thread del sistema operativo non è vincolato all'hyper thread dell'hardware e l'utilizzo della CPU potrebbe superare il numero di core fisici.

Per quanto riguarda le impostazioni dell'intraparallelismo di TensorFlow, dell'interparallelismo di TensorFlow e del numero di thread MKL-DNN, diverse combinazioni di questi tre parametri determinano velocità di training diverse. Pertanto, è necessario testare ciascun caso per trovare la combinazione migliore. Una situazione comune è impostare i tre parametri (intra_op_parallelism_threads ed inter_op_parallelism_threads per TensorFlow, os.environ['OMP_NUM_THREADS'] per MKL-DNN) alla metà del numero di vCPU (core fisico) o al numero totale di vCPU.

Metodo della torre

Per replicare un modello sulle GPU, ciascuna GPU ottiene la propria istanza del passaggio in avanti. L'istanza del passaggio in avanti è chiamata a torre. Il metodo tower viene quasi sempre utilizzato per i dispositivi GPU. Per confrontare la velocità di allenamento con altri metodi, qui utilizziamo anche il metodo tower per il nostro dispositivo CPU.

Se non imposti manualmente il dispositivo CPU, TensorFlow non utilizza il metodo della torre per calcolare la media dei gradienti, quindi in questi casi non è necessario ridimensionare la dimensione del batch.

Imposta manualmente il dispositivo 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))

Usa il replicate_model_fn avvolgere 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)

Usa il TowerOptimizer avvolgere optimizer:

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

Avvolgi il tuo model_fn:

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

Ridimensiona la dimensione del batch su (NUM_CPU – 1).

Diamo un'occhiata alla differenza di utilizzo della CPU con la modalità tower abilitata. La figura seguente mostra l'utilizzo della CPU dell'istanza ml.c5.18xlarge con la seguente configurazione:

Nessuna torre + dati LibSVM + modalità pipe + disabilitazione MKL-DNN + impostazione del parallelismo intra/inter op TensorFlow sul numero massimo di vCPU dell'istanza

La figura seguente mostra l'utilizzo della CPU dell'istanza ml.c5.18xlarge con la seguente configurazione:

Tower con dispositivo CPU impostato + dati LibSVM + modalità pipe + disabilitazione MKL-DNN + impostazione del parallelismo intra/inter op TensorFlow sul numero massimo di vCPU dell'istanza

L'utilizzo della CPU è maggiore quando si utilizza il metodo tower e supera il numero di core fisici.

Strategia con mirroring di TensorFlow

TensorFlow MirroredStrategy significa addestramento sincrono su più repliche su una macchina. Questa strategia viene in genere utilizzata per l'addestramento su una macchina con più GPU. Per confrontare la velocità di allenamento con un altro metodo, utilizziamo MirroredStrategy per il nostro dispositivo CPU.

Quando si utilizza TensorFlow MirroredStrategy, se non si imposta il dispositivo CPU, TensorFlow utilizza solo una CPU come singolo lavoratore, il che è uno spreco di risorse. Si consiglia di impostare manualmente il dispositivo CPU, poiché eseguirà un'operazione di riduzione su /CPU:0, Quindi la /CPU:0 il dispositivo non viene utilizzato come replica qui. Vedere il seguente codice:

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)

È necessario ridimensionare le dimensioni del batch quando si utilizza MirroredStrategy; ad esempio, ridimensionare la dimensione del batch su un multiplo del numero di dispositivi GPU.

Per la strategia secondaria quando si imposta il dispositivo CPU, se non si imposta il file cross_device_ops parametro in tf.distribute.MirroredStrategy(), TensorFlow utilizza il file ReductionToOneDevice sottostrategia per impostazione predefinita. Tuttavia, se imposti HierarchicalCopyAllReduce come strategia secondaria, TensorFlow esegue solo il lavoro di riduzione /CPU:0. Quando utilizzi l'API del set di dati TensorFlow e distribuisci insieme la strategia, deve essere restituito l'oggetto del set di dati anziché le funzionalità e le etichette in funzione input_fn.

Di solito, TensorFlow MirroredStrategy è più lento del metodo tower nell'addestramento della CPU, quindi non consigliamo di utilizzare MirroredStrategy su un singolo host con più CPU.

Horovod

Horovod è un framework di formazione distribuito per il deep learning per TensorFlow, Keras, PyTorch e Apache MXNet. L'obiettivo di Horovod è rendere il deep learning distribuito veloce e facile da usare.

C'è un parametro di distribution nell'API SageMaker Python SDK Estimator, che potresti utilizzare per indicare la formazione distribuita Horovod. SageMaker effettua il provisioning dell'infrastruttura ed esegue il tuo script con MPI. Vedere il seguente codice:

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

Quando scegli un'istanza GPU come ml.p3.8xlarge, devi aggiungere ciascuna GPU per ogni lavoratore:

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

Per accelerare la convergenza dei modelli, ridimensionare il tasso di apprendimento in base al numero di lavoratori secondo la documentazione ufficiale di Horovod. Tuttavia, nei progetti reali, è necessario ridimensionare il tasso di apprendimento in una certa misura, ma non in base al numero di lavoratori, il che si traduce in prestazioni scadenti del modello. Ad esempio, se il tasso di apprendimento originale è 0.001, lo ridimensioniamo a 0.0015, anche se il numero di lavoratori è quattro o più.

Generalmente, solo il primario (Horovod rango 0) salva il checkpoint e il modello, nonché l'operazione di valutazione. Non è necessario ridimensionare la dimensione del batch quando si utilizza Horovod. Offerte SageMaker Modalità pipe da cui eseguire lo streaming dei dati Servizio di archiviazione semplice Amazon (Amazon S3) nelle istanze di formazione. Quando abiliti la modalità Pipe, tieni presente che diversi lavoratori sullo stesso host devono utilizzare canali diversi per evitare errori. Questo perché il primo processo di lavoro legge i dati FIFO/canale e altri processi di lavoro sulla stessa istanza si bloccheranno perché non possono leggere i dati dallo stesso FIFO/canale, quindi Horovod non funziona correttamente. Per evitare questo problema, impostare i canali in base al numero di lavoratori per istanza. Assicurati almeno che diversi lavoratori sullo stesso host utilizzino canali diversi; lo stesso canale può essere utilizzato dai lavoratori su un host diverso.

Quando usi Horovod, potresti riscontrare il seguente errore:

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

La possibile causa di questo problema è che un determinato rango (ad esempio il rango 0) funziona più lentamente o esegue più lavori rispetto ad altri ranghi e questo fa sì che altri ranghi attendano a lungo. Sebbene il grado 0 a volte debba svolgere più lavoro degli altri ranghi, va notato che il grado 0 non dovrebbe fare molto per molto tempo. Ad esempio, per la valutazione del modello sul set di validazione e il salvataggio dei checkpoint durante l'addestramento, se è inevitabile che queste operazioni richiedano molto tempo, il che potrebbe causare errori, una soluzione alternativa è consentire a tutti i lavoratori di svolgere lo stesso lavoro del rango 0 (checkpoint salvataggio, valutazione e così via).

Lo sharding dei dati è una delle cose più importanti da considerare quando si utilizza la formazione distribuita. Puoi usare TensorFlow dataset.shard() nella tua sceneggiatura. SageMaker offre anche una funzionalità di shard del set di dati nel file canale di ingressi IMPOSTANDO distribution=S3shardbykey nel canale del set di dati. Vedere il seguente codice:

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

La figura seguente mostra il risultato quando si utilizza Horovod (ml.c5.18xlarge, Horovod + LibSVM + impostazione intra op e inter op predefinita), che è possibile confrontare con il metodo tower.

Formazione distribuita con più GPU su una singola istanza

È normale avviare un addestramento distribuito con più GPU su una singola istanza perché i data scientist devono gestire solo un'istanza e sfruttare l'interconnessione ad alta velocità tra le GPU. I processi di formazione SageMaker supportano più tipi di istanze che hanno più GPU su una singola istanza, come ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge e ml.p4d.24xlarge. Il metodo è lo stesso di più CPU in una singola istanza, ma con alcune modifiche nello script.

Metodo della torre

Il metodo tower qui è quasi lo stesso dell'addestramento multi-CPU. È necessario ridimensionare le dimensioni del batch in base al numero di GPU in uso.

Strategia con mirroring di TensorFlow

La sottostrategia predefinita di MirroredStrategy is NcclAllReduce. È necessario ridimensionare le dimensioni del batch in base al numero di GPU in uso. Vedere il seguente codice:

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

Accelera la formazione su più istanze

La scalabilità orizzontale è sempre un'opzione per migliorare la velocità di formazione. Sempre più data scientist scelgono questa opzione come opzione predefinita per quanto riguarda la formazione distribuita. In questa sezione verranno discusse le strategie per la formazione distribuita con più host.

Più CPU con più istanze

Esistono quattro metodi principali per utilizzare più CPU con più istanze quando si abilita l'addestramento distribuito:

- Server di parametri senza impostare manualmente il parallelismo degli operatori sui dispositivi CPU
- Server di parametri con impostazione manuale del parallelismo degli operatori sui dispositivi CPU
- Server dei parametri con torre (impostazione manuale dei dispositivi CPU e impostazione allow_soft_placement=True in tf.ConfigProto)
- Horovod

Quando si utilizza un server dei parametri in tf.estimator API, il percorso del checkpoint deve essere un percorso condivisibile come Amazon S3 o il percorso locale di Servizio file elastico Amazon (Amazon EFS) mappato al contenitore. Per un server dei parametri in tf.keras, il percorso del checkpoint può essere impostato sul percorso locale. Per Horovod, il percorso del checkpoint può essere impostato su un percorso locale dell'istanza di training.

Quando si utilizza un server dei parametri e il file tf.estimator API con il percorso del checkpoint su Amazon S3, se il modello è piuttosto grande, potresti riscontrare un errore di blocco del checkpoint primario durante il salvataggio del checkpoint su S3. Puoi utilizzare il contenitore integrato SageMaker TensorFlow 1.15 o TensorFlow 1.15.2 oppure utilizzare Amazon EFS come percorso del checkpoint della condivisione.

Quando si utilizza un server dei parametri per più host, il carico dei parametri su ciascun processo del server dei parametri potrebbe essere sbilanciato (specialmente quando sono presenti variabili di tabella di incorporamento relativamente grandi), il che potrebbe causare errori. Puoi controllare la dimensione del file di ciascun checkpoint dello shard in Amazon S3 per determinare se i parametri sul server dei parametri sono bilanciati, poiché ciascun server dei parametri corrisponde a uno shard del file del checkpoint. Per evitare tali problemi, è possibile utilizzare la funzione partizionatore per provare a distribuire uniformemente i parametri di ciascun server dei parametri:

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

GPU singola con più istanze

I processi di formazione SageMaker supportano istanze che hanno una sola GPU, come le serie ml.p3.xlarge, ml.g4dn e ml.g5. Esistono due metodi principali utilizzati in questo scenario: server di parametri e Horovod.

Il metodo di training distribuito del server dei parametri integrato di SageMaker consiste nell'avviare un processo del server dei parametri e un processo di lavoro per ogni istanza di training (ciascun server dei parametri è responsabile solo di una parte dei parametri del modello), quindi l'impostazione predefinita è multi-macchina singola- Formazione GPU. Il training distribuito del server dei parametri integrato di SageMaker è un metodo di aggiornamento del gradiente asincrono. Per ridurre l'impatto degli aggiornamenti asincroni sulla convergenza della formazione, è consigliabile ridurre la velocità di apprendimento. Se desideri utilizzare tutte le GPU sull'istanza, devi utilizzare una combinazione di server di parametri e il metodo tower.

Per Horovod, basta impostare processes_per_host=1 nel parametro di distribuzione dell'API SageMaker Python Estimator.

Più GPU con più istanze

Per i server dei parametri e il metodo tower, le modifiche al codice sono sostanzialmente le stesse del metodo tower per una singola istanza con più GPU e non è necessario impostare manualmente i dispositivi GPU.

Per Horovod, imposta Processs_per_host nel parametro di distribuzione sul numero di GPU di ciascuna istanza di training. Se utilizzi la modalità Pipe, il numero di lavoratori per istanza deve corrispondere al numero di canali.

Pipeline di dati

Oltre all’infrastruttura di cui abbiamo parlato, c’è un’altra cosa importante da considerare: la pipeline dei dati. Una pipeline di dati si riferisce al modo in cui carichi e trasformi i dati prima che vengano immessi nelle reti neurali. La CPU viene utilizzata per preparare i dati, mentre la GPU viene utilizzata per calcolare i dati dalla CPU. Poiché la GPU è una risorsa costosa, un tempo di inattività maggiore della GPU risulta inefficiente; una buona pipeline di dati nel tuo lavoro di formazione potrebbe migliorare l'utilizzo di GPU e CPU.

Quando provi a ottimizzare la pipeline di input dei dati TensorFlow, considera l'ordine API utilizzato Set di dati TensorFlow, la dimensione dei dati di training (molti file piccoli o diversi file di grandi dimensioni), la dimensione batch e così via.

Diamo un'occhiata all'interazione tra GPU e CPU durante l'allenamento. Le figure seguenti confrontano le interazioni con e senza pipeline.

Una pipeline migliore potrebbe ridurre i tempi di inattività della GPU. Considera i seguenti suggerimenti:

Utilizzare una logica di funzione semplice per estrarre caratteristiche ed etichette
Precarica i campioni in memoria
Riduci gli I/O del disco e gli I/O di rete non necessari
Memorizza nella cache le caratteristiche e le etichette elaborate
Ridurre il numero di tempi di replica tra CPU e GPU
Chiedi a diversi operatori di gestire parti diverse del set di dati di addestramento
Riduci i tempi di chiamata dell'API del set di dati TensorFlow

TensorFlow fornisce un'API di trasformazione relativa ai formati dei set di dati e l'ordine dell'API di trasformazione in TensorFlow influisce molto sulla velocità di addestramento. È necessario testare l'ordine migliore per chiamare l'API del set di dati TensorFlow. Di seguito sono riportati alcuni principi fondamentali:

Utilizza una mappa vettoriale. Ciò significa chiamare prima l'API batch del set di dati TensorFlow, quindi l'API della mappa del set di dati. La funzione di analisi personalizzata fornita nella funzione mappa, come ad esempio decode_tfrecord nel codice di esempio, analizza un mini batch di dati. Al contrario, prima map e poi batch è una mappa scalare e la funzione parser personalizzata elabora solo un campione.
Utilizza l'API della cache del set di dati TensorFlow per memorizzare nella cache funzionalità ed etichette. Inserisci l'API della cache del set di dati TensorFlow prima dell'API di ripetizione del set di dati TensorFlow, altrimenti l'utilizzo della RAM aumenta linearmente epoca per epoca. Se il set di dati è grande quanto la RAM, non utilizzare l'API della cache del set di dati TensorFlow. Se è necessario utilizzare l'API della cache del set di dati TensorFlow e l'API shuffle, considera l'utilizzo del seguente ordine: crea l'oggetto del set di dati TensorFlow -> API della cache -> API shuffle -> API batch -> API della mappa -> API di ripetizione -> API di prelettura.
Usa il tfrecord formato del set di dati più del formato LibSVM.
La modalità file o la modalità pipe dipende dal formato del set di dati e dalla quantità di file. IL tfrecorddataset L'API può essere impostata num_parallel_reads per leggere più file in parallelo e impostare buffer_size per ottimizzare la lettura dei dati, mentre il pipemodedataset L'API non ha tali impostazioni. La modalità pipe è più adatta alle situazioni in cui un singolo file è grande e il numero totale di file è piccolo. Ti consigliamo di utilizzare un processo di elaborazione SageMaker per eseguire il lavoro di preelaborazione, come unire più file in un file più grande in base alle etichette, utilizzare un metodo di campionamento per rendere il set di dati più bilanciato e mescolare il set di dati bilanciato.

Vedere il seguente esempio di codice:

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)

Per l'addestramento sulle istanze della CPU, impostando il parallelismo di intra op, inter ope la variabile d'ambiente MKL-DNN è un buon punto di partenza.

Allenamento automatico di precisione misto

L'ultima cosa di cui discutiamo è l'addestramento automatico a precisione mista, che può accelerare la velocità e migliorare le prestazioni del modello. Al momento della stesura di questo articolo, la GPU Nvidia V100 (istanza P3) e A100 (istanza P4dn) supportano Tensor core. Puoi abilitare l'addestramento a precisione mista in TensorFlow quando utilizzi questi tipi di istanze. A partire dalla versione 1.14, TensorFlow supporta l'allenamento automatico di precisione mista. Puoi utilizzare la seguente istruzione per racchiudere il tuo ottimizzatore originale:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Se il modello è piccolo e l'utilizzo della GPU è basso, non vi è alcun vantaggio nell'addestramento automatico a precisione mista. Se il modello è di grandi dimensioni, l'addestramento automatico di precisione mista può accelerare la velocità di addestramento.

Conclusione

Quando inizi l'addestramento del modello di deep learning in SageMaker, prendi in considerazione i seguenti suggerimenti per ottenere una velocità di addestramento più rapida:

Prova prima il metodo multi-CPU, a istanza singola o il metodo a GPU singola, a istanza singola. Se l'utilizzo della CPU/GPU è molto elevato (ad esempio superiore al 90%), vai al passaggio successivo.
Prova più CPU in un singolo host o più GPU in un singolo host. Se l'utilizzo è vicino all'utilizzo massimo di CPU o GPU, vai al passaggio successivo.
Prova più CPU o più GPU con più host.
È necessario modificare i codici quando si utilizzano i server dei parametri o Horovod. La modifica del codice non è la stessa per l'API basata su sessione TensorFlow, tf.estimator API e tf.keras API. Un server di parametri o Horovod può mostrare velocità di allenamento diverse in diversi casi e attività di allenamento, quindi prova entrambi i metodi se hai tempo e budget per determinare quello migliore.

Tieni presente il seguente consiglio:

Controlla l'utilizzo prima della scalabilità, ottimizza la pipeline dei dati e fai in modo che CPU e GPU si sovrappongano nella sequenza temporale.
Prima aumenta, poi aumenta.
Se non riesci ad aumentare l'utilizzo della GPU dopo tutti i metodi, prova la CPU. Esistono molti casi (in particolare per il modello di classificazione della percentuale di clic) in cui il tempo di addestramento totale dell'addestramento dell'istanza CPU è più breve e più conveniente rispetto all'addestramento dell'istanza GPU.

Abbiamo anche un esempio di codice nel file Repository GitHub, dove mostriamo due esempi di formazione distribuita DeepFM su SageMaker. Uno è un server di parametri TensorFlow sulle istanze CPU, l'altro è Horovod sulle istanze GPU.

Informazioni sugli autori

Yuhui Liang è un architetto senior di soluzioni di machine learning. Si concentra sulla promozione e sull'applicazione dell'apprendimento automatico ed è profondamente coinvolto nei progetti di apprendimento automatico di molti clienti. Ha una vasta esperienza nella formazione distribuita sul deep learning, nei sistemi di raccomandazione e nella pubblicità computazionale.

Shishuai Wang è un architetto senior di soluzioni di machine learning. Lavora con i clienti AWS per aiutarli ad adottare il machine learning su larga scala. Gli piace guardare film e viaggiare in giro per il mondo.