Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Suggerimenti di configurazione per la libreria di parallelismo dei dati SageMaker distribuiti
Leggi i seguenti suggerimenti prima di utilizzare la libreria SageMaker Distributed Data Parallelism (SMDDP). Questo elenco include suggerimenti applicabili a tutti i framework.
Argomenti
Pre-elaborazione dei dati
Se preelabori i dati durante l'allenamento utilizzando una libreria esterna che utilizza la CPU, potresti incorrere in un collo di bottiglia della CPU perché distributed SageMaker data parallel utilizza la CPU per le operazioni. AllReduce È possibile migliorare i tempi di addestramento spostando le fasi di preelaborazione in una libreria che utilizza GPU o completando tutta la preelaborazione prima dell'allenamento.
Nodi singoli o multipli
È consigliabile utilizzare questa libreria con più nodi. La libreria può essere utilizzata con una configurazione a host singolo e più dispositivi (ad esempio, una singola istanza di calcolo ML con più GPU); tuttavia, quando si utilizzano due o più nodi, l’operazione AllReduce della libreria offre un miglioramento significativo delle prestazioni. Inoltre, su un singolo host, NVLink contribuisce già all'efficienza dei nodi AllReduce.
Efficienza di scalabilità del debug con Debugger
Puoi usare Amazon SageMaker Debugger per monitorare e visualizzare l'utilizzo di CPU e GPU e altre metriche di interesse durante l'allenamento. Puoi utilizzare le regole incorporate di Debugger per monitorare i problemi di prestazioni computazionali, ad esempio, CPUBottleneck, LoadBalancing e LowGPUUtilization. Puoi specificare queste regole con le configurazioni Debugger quando definisci uno stimatore SDK Amazon Python SageMaker . Se utilizzi AWS CLI e AWS SDK for Python (Boto3)
per corsi di formazione su SageMaker, puoi abilitare Debugger come mostrato in Configurare il debugger utilizzando l' SageMaker API Amazon. SageMaker
Per vedere un esempio di utilizzo di Debugger in un lavoro di SageMaker formazione, puoi fare riferimento a uno degli esempi di notebook nel repository Notebook Examples. SageMaker GitHub
Dimensione batch
Nell’addestramento distribuito, man mano che vengono aggiunti più nodi, le dimensioni dei batch dovrebbero aumentare proporzionalmente. Per migliorare la velocità di convergenza man mano che aggiungi più nodi al tuo processo di addestramento e aumenti la dimensione globale del batch, aumenta il tasso di apprendimento.
Un modo per raggiungere questo obiettivo è utilizzare un riscaldamento graduale del tasso di apprendimento, in cui il tasso di apprendimento passa da un valore piccolo a uno più grande man mano che il processo di addestramento progredisce. Questo incremento evita un aumento improvviso del tasso di apprendimento e consente una sana convergenza all'inizio dell’addestramento. Ad esempio, è possibile utilizzare una Regola di dimensionamento lineare in base alla quale ogni volta che la dimensione del mini-batch viene moltiplicata per k, anche il tasso di apprendimento viene moltiplicato per k. Per saperne di più su questa tecnica, consulta il paper di ricerca Accurate, Large Minibatch SGD: Training ImageNet in 1 Hour
Opzioni MPI personalizzate
La libreria parallela di dati SageMaker distribuiti utilizza Message Passing Interface (MPI), uno standard popolare per la gestione della comunicazione tra i nodi in un cluster ad alte prestazioni, e utilizza la libreria NCCL di NVIDIA per la comunicazione a livello di GPU. Quando si utilizza la libreria parallela di dati con un TensorFlow o PytorchEstimator, il rispettivo contenitore configura l'ambiente MPI ed esegue il mpirun comando per avviare i lavori sui nodi del cluster.
È possibile impostare operazioni MPI personalizzate utilizzando il parametro custom_mpi_options in Estimator. Tutti mpirun i flag passati in questo campo vengono aggiunti al mpirun comando ed eseguiti da per l'addestramento. SageMaker Ad esempio, è possibile definire il parametro distribution di un Estimator utilizzando quanto segue per utilizzare la variabile NCCL_DEBUG
distribution = {'smdistributed':{'dataparallel':{'enabled': True, "custom_mpi_options": "-verbose -x NCCL_DEBUG=VERSION"}}}
Usa Amazon FSx e configura una capacità di storage e throughput ottimale
Quando si addestra un modello su più nodi con parallelismo distribuito dei dati, si consiglia vivamente di utilizzare FSx for Lustre. Amazon FSx è un servizio di archiviazione scalabile e ad alte prestazioni che supporta lo storage di file condiviso con un throughput più veloce. Utilizzando lo storage Amazon FSx su larga scala, puoi ottenere una maggiore velocità di caricamento dei dati tra i nodi di calcolo.
In genere, con il parallelismo distribuito dei dati, ci si aspetterebbe che il throughput di addestramento totale cresca quasi linearmente con il numero di GPU. Tuttavia, se utilizzi uno storage Amazon FSx non ottimale, le prestazioni di addestramento potrebbero rallentare a causa di un basso throughput di Amazon FSx.
Ad esempio, se utilizzi il tipo di distribuzione SCRATCH_2 del file system Amazon FSx con una capacità di storage minima di 1,2 TiB, la capacità di throughput di I/O è di 240 MB/s. Lo storage Amazon FSx funziona in modo da poter assegnare dispositivi di storage fisici e maggiore è il numero di dispositivi assegnati, maggiore è il throughput ottenuto. L'incremento di storage minimo per il tipo SRATCH_2 è 1,2 TiB e il guadagno di throughput corrispondente è di 240 MB/s.
Supponiamo di avere un modello da addestrare su un cluster a 4 nodi su un set di dati da 100 GB. Con una determinata dimensione del batch ottimizzata per il cluster, supponiamo che il modello possa completare un'epoca in circa 30 secondi. In questo caso, la velocità di I/O minima richiesta è di circa 3 GB/s (100 GB/30 s). Apparentemente si tratta di un requisito di throughput molto più elevato rispetto a 240 MB/s. Con una capacità così limitata di Amazon FSx, scalare il processo di addestramento distribuito fino a cluster più grandi potrebbe aggravare i problemi di I/O; il throughput di addestramento del modello potrebbe migliorare in epoche successive man mano che la cache si accumula, ma il throughput di Amazon FSx può ancora essere un collo di bottiglia.
Per alleviare questi problemi di collo di bottiglia di I/O, è necessario aumentare le dimensioni dello storage Amazon FSx per ottenere una maggiore capacità di throughput. In genere, per trovare un throughput di I/O ottimale, puoi sperimentare diverse capacità di throughput di Amazon FSx, assegnando un throughput uguale o leggermente inferiore a quello stimato, finché non trovi che sia sufficiente a risolvere i problemi di collo di bottiglia di I/O. Nel caso dell'esempio precedente, sarebbe sufficiente lo storage Amazon FSx con throughput di 2,4 GB/s e cache RAM da 67 GB. Se il file system ha un throughput ottimale, il throughput di addestramento del modello dovrebbe raggiungere il massimo immediatamente o dopo la prima fase di accumulo della cache.
Per ulteriori informazioni su come aumentare i tipi di storage e distribuzione di Amazon FSx, consulta le seguenti pagine nella documentazione di Amazon FSx for Lustre:
