Najlepsze praktyki dotyczące treningu akceleracyjnego TensorFlow 1.x na Amazon SageMaker

Obecnie wielu klientów używa TensorFlow do trenowania modeli głębokiego uczenia się pod kątem współczynnika klikalności w rekomendacjach reklamowych i personalizacji w e-commerce. W miarę jak zmieniają się zachowania ich klientów, każdego dnia mogą gromadzić duże ilości nowych danych. Iteracja modeli to jedno z codziennych zadań analityków danych, ale napotykają oni na problem zbyt długiego trenowania na dużych zbiorach danych.

Amazon Sage Maker to w pełni zarządzana platforma uczenia maszynowego (ML), która może pomóc naukowcom zajmującym się danymi skupić się na modelach zamiast na infrastrukturze, z natywną obsługą algorytmów i platform typu „przynieś własne” i platform, takich jak TensorFlow i PyTorch. SageMaker oferuje elastyczne opcje szkoleń rozproszonych, które dostosowują się do konkretnych przepływów pracy. Ponieważ wielu analityków danych może nie mieć doświadczenia w procesie uczenia akceleracyjnego, w tym poście przedstawiamy czynniki, które mają znaczenie dla szybkiego uczenia modelu uczenia głębokiego oraz najlepsze praktyki treningu akceleracyjnego dla TensorFlow 1.x na SageMaker. Mamy też przykładowy kod DeepFM rozproszone szkolenia na temat SageMaker na GitHub repo.

Istnieje wiele czynników, które należy wziąć pod uwagę, aby zmaksymalizować wykorzystanie procesora/GPU podczas uruchamiania skryptu TensorFlow w programie SageMaker, takich jak infrastruktura, typ akceleratora, metoda rozproszonego szkolenia, metoda ładowania danych, szkolenie z mieszaną precyzją i inne.

Omawiamy najlepsze praktyki w następujących obszarach:

• Przyspiesz szkolenie na jednej instancji
• Przyspiesz szkolenie na wielu instancjach
• Potoki danych
• Automatyczne szkolenie mieszanej precyzji

Przyspiesz szkolenie na jednej instancji

Uruchamiając skrypt TensorFlow na pojedynczej instancji, możesz wybrać serię zoptymalizowaną pod kątem komputera, taką jak Elastyczna chmura obliczeniowa Amazon (Amazon EC2) seria C5 lub seria przyspieszonych obliczeń z wieloma procesorami graficznymi w jednym wystąpieniu, na przykład p3.8xlarge, p3.16xlarge, p3dn.24xlarge i p4d.24xlarge.

W tej sekcji omówimy strategie dla wielu procesorów CPU w jednej instancji oraz szkolenia rozproszone z wieloma procesorami GPU w jednej instancji.

Wiele procesorów na jednej instancji

W tej sekcji omówimy ręczne ustawianie równoległości operatorów na urządzeniach z procesorem, metodę wieży, TensorFlow MirroredStrategy i Horovod.

Ręczne ustawianie równoległości operatorów na urządzeniach CPU

TensorFlow automatycznie wybiera odpowiednią liczbę wątków, aby zrównoleglać obliczenia operacji w procesie uczenia. Możesz jednak ustawić intra_op pula wątków i inter_op ustawienia równoległości dostarczone przez TensorFlow i użyj zmiennych środowiskowych MKL-DNN do ustawienia powiązania dla wątku systemu operacyjnego. Zobacz następujący 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'

Zmienna środowiskowa KMP_AFFINITY MKL-DNN jest ustawione na granularity=fine,compact,1,0 domyślnie. Po ustawieniu zarówno intra, jak i inter TensorFlow na maksymalną liczbę vCPU bieżącej instancji, górny limit wykorzystania procesora jest prawie taki sam, jak liczba fizycznych rdzeni instancji szkoleniowej.

Jeśli ustawisz os.environ["KMP_AFFINITY"]= "verbose,disabled", wątek systemu operacyjnego nie jest powiązany ze sprzętowym wątkiem Hyper, a użycie procesora może przekroczyć liczbę rdzeni fizycznych.

Jeśli chodzi o ustawienia paralelizmu wewnętrznego TensorFlow, paralelizmu wewnętrznego TensorFlow oraz liczby wątków MKL-DNN, różne kombinacje tych trzech parametrów skutkują różnymi szybkościami uczenia. Dlatego musisz przetestować każdy przypadek, aby znaleźć najlepszą kombinację. Częstą sytuacją jest ustawienie trzech parametrów (intra_op_parallelism_threads i inter_op_parallelism_threads dla TensorFlow, os.environ['OMP_NUM_THREADS'] dla MKL-DNN) do połowy liczby wirtualnych procesorów (rdzeń fizyczny) lub całkowitej liczby wirtualnych procesorów.

Metoda wieżowa

Aby replikować model za pomocą procesorów GPU, każdy procesor GPU otrzymuje własną instancję przejścia do przodu. Instancja podania w przód nazywa się a wieża. Metoda wieży jest prawie zawsze używana w przypadku urządzeń GPU. Aby porównać szybkość treningu z innymi metodami, tutaj również używamy metody wieży dla naszego urządzenia z procesorem.

Jeśli nie ustawisz urządzenia procesora ręcznie, TensorFlow nie użyje metody wieży do uśredniania gradientów, więc w takich przypadkach nie musisz skalować rozmiaru partii.

1. Ustaw urządzenie CPU ręcznie:

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. Zastosowanie replicate_model_fn zawijać 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. Zastosowanie TowerOptimizer zawijać optimizer:

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

4. Owiń swój model_fn:

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

5. Skaluj rozmiar partii do (NUM_CPU – 1).

Przyjrzyjmy się różnicy w wykorzystaniu procesora przy włączonym trybie wieżowym. Poniższy rysunek przedstawia wykorzystanie procesora przez instancję ml.c5.18xlarge przy następującej konfiguracji:

Brak Tower + dane LibSVM + tryb potoku + MKL-DNN wyłącza wiązanie + ustawienie równoległości wewnątrz/między operacjami TensorFlow na maksymalną liczbę procesorów wirtualnych instancji

Poniższy rysunek przedstawia wykorzystanie procesora przez instancję ml.c5.18xlarge w następującej konfiguracji:

Wieża z ustawionym urządzeniem CPU + dane LibSVM + tryb potoku + MKL-DNN wyłącza wiązanie + ustawienie równoległości wewnątrz/między operacjami TensorFlow na maksymalną liczbę procesorów wirtualnych instancji

Użycie procesora jest wyższe w przypadku korzystania z metody wieży i przekracza liczbę rdzeni fizycznych.

Strategia TensorFlow Mirrored

TensorFlow MirroredStrategy oznacza synchroniczne trenowanie w wielu replikach na jednej maszynie. Ta strategia jest zwykle używana do trenowania na jednej maszynie z wieloma procesorami GPU. Aby porównać szybkość treningu z inną metodą, używamy MirroredStrategy dla naszego urządzenia z procesorem.

Podczas korzystania z TensorFlow MirroredStrategy, jeśli nie ustawisz urządzenia procesora, TensorFlow używa tylko jednego procesora jako pojedynczego pracownika, co jest marnowaniem zasobów. Zalecamy ręczne ustawienie urządzenia CPU, ponieważ spowoduje to zmniejszenie operacji na /CPU:0, Tak /CPU:0 urządzenie nie jest tutaj używane jako replika. Zobacz następujący 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)

Musisz skalować rozmiar partii podczas korzystania z MirroredStrategy; na przykład przeskaluj rozmiar partii do wielokrotności liczby urządzeń GPU.

Dla podstrategii po ustawieniu urządzenia procesora, jeśli nie ustawisz cross_device_ops parametr w tf.distribute.MirroredStrategy(), TensorFlow wykorzystuje ReductionToOneDevice podstrategii domyślnie. Jeśli jednak ustawisz HierarchicalCopyAllReduce jako strategia podrzędna TensorFlow po prostu wykonuje prace redukujące /CPU:0. Gdy używasz interfejsu API zestawu danych TensorFlow i rozpowszechniasz strategię razem, obiekt zestawu danych powinien zostać zwrócony zamiast cech i etykiet w funkcji input_fn.

Zwykle metoda TensorFlow MirroredStrategy jest wolniejsza niż metoda wieży w przypadku trenowania procesora, więc nie zalecamy korzystania z MirroredStrategy na pojedynczym hoście z wieloma procesorami.

Horowod

Horowod to rozproszona platforma szkolenia głębokiego dla TensorFlow, Keras, PyTorch i Apache MXNet. Celem Horovod jest szybkie i łatwe w użyciu rozproszone uczenie głębokie.

Istnieje parametr distribution w SageMaker Python SDK Estimator API, którego można użyć do określenia szkolenia rozproszonego Horovod. SageMaker udostępnia infrastrukturę i uruchamia Twój skrypt za pomocą MPI. Zobacz następujący 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' 
} 
}

Wybierając instancję GPU, taką jak ml.p3.8xlarge, musisz przypiąć każdy GPU dla każdego pracownika:

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

Aby przyspieszyć konwergencję modelu, skaluj współczynnik uczenia się przez liczbę pracowników zgodnie z oficjalną dokumentacją Horovod. Jednak w rzeczywistych projektach należy skalować tempo uczenia się do pewnego stopnia, ale nie według liczby pracowników, co skutkuje słabą wydajnością modelu. Na przykład, jeśli oryginalna szybkość uczenia się wynosi 0.001, skalujemy wskaźnik uczenia się do 0.0015, nawet jeśli liczba pracowników wynosi cztery lub więcej.

Ogólnie tylko główny (ranga Horovoda 0) zapisuje punkt kontrolny i model, a także operację oceny. Nie musisz skalować wielkości partii podczas korzystania z Horovod. Oferty SageMaker Tryb potoku strumieniować dane z Usługa Amazon Simple Storage (Amazon S3) na instancje szkoleniowe. Po włączeniu trybu potoku należy pamiętać, że różne procesy robocze na tym samym hoście muszą używać różnych kanałów, aby uniknąć błędów. Dzieje się tak, ponieważ pierwszy proces roboczy odczytuje dane FIFO/kanału, a inne procesy robocze w tym samym wystąpieniu zawieszą się, ponieważ nie mogą odczytać danych z tego samego FIFO/kanału, więc Horovod nie działa poprawnie. Aby uniknąć tego problemu, ustaw kanały zgodnie z liczbą pracowników na instancję. Przynajmniej upewnij się, że różni pracownicy na tym samym hoście korzystają z różnych kanałów; ten sam kanał może być używany przez pracowników na innym hoście.

Podczas korzystania z Horovod możesz napotkać następujący błąd:

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

Możliwą przyczyną tego problemu jest to, że pewna ranga (taka jak ranga 0) działa wolniej lub wykonuje więcej zadań niż inne rangi, co powoduje, że inne rangi czekają przez długi czas. Chociaż ranga 0 czasami musi zrobić więcej pracy niż inne rangi, należy zauważyć, że ranga 0 nie powinna robić wiele przez długi czas. Na przykład w przypadku oceny modelu w zestawie walidacji i zapisywania punktów kontrolnych podczas uczenia, jeśli nieuniknione jest, że te operacje zajmą dużo czasu, co może spowodować błędy, jednym obejściem jest umożliwienie wszystkim pracownikom wykonywania tej samej pracy co pozycja 0 (punkty kontrolne zapisywanie, ocena i tak dalej).

Dzielenie danych na fragmenty jest jedną z najważniejszych kwestii, które należy wziąć pod uwagę podczas korzystania z treningu rozproszonego. Możesz użyć TensorFlow dataset.shard() w twoim skrypcie. SageMaker oferuje również funkcję fragmentu zestawu danych w kanał wejściowy przez ustawienie distribution=S3shardbykey w kanale zbioru danych. Zobacz następujący 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())

Poniższy rysunek przedstawia wynik korzystania z Horovod (ml.c5.18xlarge, Horovod + LibSVM + domyślne ustawienia intraop i interop), który można porównać z metodą wieży.

Rozproszone szkolenie z wieloma procesorami graficznymi w jednej instancji

Rozpoczęcie szkolenia rozproszonego z wieloma procesorami GPU w jednej instancji jest normalnym zjawiskiem, ponieważ naukowcy zajmujący się danymi muszą zarządzać tylko jedną instancją i korzystać z szybkiego połączenia między procesorami GPU. Zadania szkoleniowe programu SageMaker obsługują wiele typów wystąpień, które mają wiele procesorów GPU w jednym wystąpieniu, na przykład ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge i ml.p4d.24xlarge. Metoda jest taka sama, jak w przypadku wielu procesorów w jednej instancji, ale z kilkoma zmianami w skrypcie.

Metoda wieżowa

Metoda wieży jest tutaj prawie taka sama, jak w przypadku treningu z wieloma procesorami. Musisz przeskalować rozmiar partii zgodnie z liczbą używanych procesorów graficznych.

Strategia TensorFlow Mirrored

Domyślna strategia podrzędna MirroredStrategy is NcclAllReduce. Musisz przeskalować rozmiar partii zgodnie z liczbą używanych procesorów graficznych. Zobacz następujący kod:

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

Przyspiesz szkolenie na wielu instancjach

Skalowanie jest zawsze opcją poprawy szybkości treningu. Coraz więcej analityków danych wybiera tę opcję jako domyślną opcję w odniesieniu do szkolenia rozproszonego. W tej sekcji omówimy strategie rozproszonego szkolenia z wieloma hostami.

Wiele procesorów z wieloma instancjami

Istnieją cztery główne metody używania wielu procesorów z wieloma instancjami podczas włączania szkolenia rozproszonego:

• • Serwer parametrów bez ręcznego ustawiania równoległości operatorów na urządzeniach CPU
  • Serwer parametrów z ręcznym ustawianiem równoległości operatorów na urządzeniach CPU
  • Serwer parametrów z wieżą (ręczne ustawianie urządzeń procesora i ustawianie allow_soft_placement=True in tf.ConfigProto)
  • Horowod

W przypadku korzystania z serwera parametrów w tf.estimator API, ścieżka punktu kontrolnego musi być ścieżką udostępnianą, taką jak Amazon S3 lub ścieżka lokalna Elastyczna usługa plików Amazon (Amazon EFS) mapowanie do kontenera. Dla serwera parametrów w tf.keras, ścieżka punktu kontrolnego może być ustawiona na ścieżkę lokalną. W przypadku Horovod ścieżka punktu kontrolnego może być ustawiona na ścieżkę lokalną instancji szkoleniowej.

W przypadku korzystania z serwera parametrów i tf.estimator API ze ścieżką punktu kontrolnego do Amazon S3, jeśli model jest dość duży, możesz napotkać błąd podstawowego, który utknął przy zapisywaniu punktu kontrolnego do S3. Możesz użyć wbudowanego kontenera SageMaker TensorFlow 1.15 lub TensorFlow 1.15.2 albo użyć Amazon EFS jako ścieżki kontrolnej udziału.

W przypadku korzystania z serwera parametrów dla wielu hostów obciążenie parametrów w każdym procesie serwera parametrów może być niezrównoważone (szczególnie w przypadku stosunkowo dużych zmiennych tabeli osadzania), co może powodować błędy. Możesz sprawdzić rozmiar pliku każdego punktu kontrolnego fragmentu w Amazon S3, aby określić, czy parametry na serwerze parametrów są zrównoważone, ponieważ każdy serwer parametrów odpowiada fragmentowi pliku punktu kontrolnego. Aby uniknąć takich problemów, możesz użyć funkcji partycjonowania, aby spróbować równomiernie rozłożyć parametry każdego serwera parametrów:

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

Pojedynczy procesor graficzny z wieloma instancjami

Zadania szkoleniowe programu SageMaker obsługują wystąpienia, które mają tylko jeden procesor GPU, takie jak serie ml.p3.xlarge, ml.g4dn i ml.g5. W tym scenariuszu są używane dwie główne metody: serwery parametrów i Horovod.

Wbudowana metoda uczenia rozproszonego serwera parametrów programu SageMaker polega na uruchomieniu procesu serwera parametrów i procesu roboczego dla każdej instancji uczącej (każdy serwer parametrów odpowiada tylko za część parametrów modelu), więc domyślnie jest to wiele maszyn Trening GPU. Szkolenie rozproszone serwera parametrów wbudowanego w SageMaker jest asynchroniczną metodą aktualizacji gradientu. Aby zmniejszyć wpływ aktualizacji asynchronicznych na zbieżność uczenia, zaleca się zmniejszenie szybkości uczenia się. Jeśli chcesz korzystać ze wszystkich procesorów graficznych w instancji, musisz użyć kombinacji serwerów parametrów i metody wieży.

Dla Horovod po prostu ustaw processes_per_host=1 w parametrze dystrybucji SageMaker Python Estimator API.

Wiele procesorów graficznych z wieloma instancjami

W przypadku serwerów parametrów i metody wieży zmiany kodu są zasadniczo takie same, jak w przypadku metody wieży dla pojedynczego wystąpienia z wieloma procesorami GPU i nie ma potrzeby ręcznego ustawiania urządzeń GPU.

W przypadku Horovod ustaw process_per_host w parametrze dystrybucji na liczbę procesorów GPU każdego wystąpienia szkoleniowego. Jeśli używasz trybu potoku, liczba procesów roboczych na instancję musi być zgodna z liczbą kanałów.

Potoki danych

Oprócz infrastruktury, którą omówiliśmy, należy wziąć pod uwagę jeszcze jedną ważną rzecz: potok danych. Potok danych odnosi się do sposobu ładowania danych i przekształcania danych, zanim zostaną one wprowadzone do sieci neuronowych. Procesor służy do przygotowania danych, podczas gdy GPU służy do obliczania danych z procesora. Ponieważ GPU jest kosztownym zasobem, dłuższy czas bezczynności GPU jest nieefektywny; dobry potok danych w zadaniu treningowym może poprawić wykorzystanie procesora graficznego i procesora.

Kiedy próbujesz zoptymalizować swój potok danych wejściowych TensorFlow, rozważ kolejność API używaną w Zbiory danych TensorFlow, rozmiar danych uczących (wiele małych plików lub kilka dużych plików), rozmiar wsadu itd.

Przyjrzyjmy się interakcji między GPU a CPU podczas treningu. Poniższe rysunki porównują interakcje z potokiem i bez niego.

Lepszy potok może skrócić czas bezczynności GPU. Rozważ następujące wskazówki:

• Użyj prostej logiki funkcji do wyodrębniania funkcji i etykiet
• Wstępnie pobieraj próbki do pamięci
• Zmniejsz liczbę niepotrzebnych operacji we/wy na dysku i we/wy w sieci
• Buforuj przetworzone funkcje i etykiety w pamięci
• Zmniejsz liczbę czasów replikacji między procesorem a GPU
• Niech różni pracownicy zajmują się różnymi częściami zestawu danych szkoleniowych
• Skróć czas wywoływania interfejsu API zestawu danych TensorFlow

TensorFlow zapewnia interfejs API transformacji związany z formatami zestawów danych, a kolejność API transformacji w TensorFlow ma duży wpływ na szybkość treningu. Należy przetestować najlepszą kolejność wywoływania interfejsu API zestawu danych TensorFlow. Oto kilka podstawowych zasad:

• Użyj mapy wektorowej. Oznacza to, że najpierw wywołaj interfejs API wsadowego zestawu danych TensorFlow, a następnie interfejs API mapowania zestawu danych. Niestandardowa funkcja analizowania dostępna w funkcji mapy, taka jak decode_tfrecord w przykładowym kodzie analizuje mini partię danych. Wręcz przeciwnie, mapuj najpierw, a potem wsadowo to mapa skalarna, a niestandardowa funkcja parsera przetwarza tylko jedną próbkę.
• Użyj interfejsu API pamięci podręcznej zestawu danych TensorFlow, aby buforować funkcje i etykiety. Umieść interfejs API pamięci podręcznej zestawu danych TensorFlow przed interfejsem API powtarzania zestawu danych TensorFlow, w przeciwnym razie wykorzystanie pamięci RAM wzrasta liniowo z epoki na epokę. Jeśli zestaw danych jest tak duży jak pamięć RAM, nie używaj interfejsu API pamięci podręcznej zestawu danych TensorFlow. Jeśli potrzebujesz użyć interfejsu API pamięci podręcznej zestawu danych TensorFlow i interfejsu shuffle API, rozważ użycie następującej kolejności: utwórz obiekt zestawu danych TensorFlow -> API pamięci podręcznej -> API shuffle -> API partii -> API map -> API repeat -> API prefetch.
• Użyj tfrecord format zestawu danych bardziej niż format LibSVM.
• Tryb pliku lub tryb potoku zależy od formatu zestawu danych i ilości plików. The tfrecorddataset API można ustawić num_parallel_reads czytać wiele plików równolegle i ustawiać buffer_size do optymalizacji odczytu danych, podczas gdy pipemodedataset API nie posiada takich ustawień. Tryb potoku jest bardziej odpowiedni w sytuacjach, w których jeden plik jest duży, a łączna liczba plików jest niewielka. Zalecamy użycie zadania przetwarzania SageMaker do wykonania czynności przetwarzania wstępnego, takich jak łączenie wielu plików w większy plik zgodnie z etykietami, użycie metody próbkowania, aby zestaw danych był bardziej zrównoważony i tasowanie zrównoważonego zestawu danych.

Zobacz następujący przykładowy kod:

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)

W przypadku szkolenia na instancjach procesora, ustawiając równoległość intra op, inter op, a zmienna środowiskowa MKL-DNN jest dobrym punktem wyjścia.

Automatyczne szkolenie mieszanej precyzji

Ostatnią rzeczą, o której mówimy, jest automatyczne szkolenie o mieszanej precyzji, które może przyspieszyć prędkość i skutkować wydajnością modelu. W chwili pisania tego tekstu karty graficzne Nvidia V100 (instancja P3) i A100 (instancja P4dn) obsługują rdzeń Tensor. Możesz włączyć mieszaną precyzję trenowania w TensorFlow podczas korzystania z tych typów instancji. Począwszy od wersji 1.14, TensorFlow obsługuje automatyczne trenowanie precyzji mieszanej. Aby zapakować oryginalny optymalizator, możesz użyć następującej instrukcji:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Jeśli model jest mały, a wykorzystanie procesora GPU jest niskie, automatyczne trenowanie precyzji mieszanej nie jest korzystne. Jeśli model jest duży, automatyczne trenowanie z mieszaną precyzją może przyspieszyć tempo treningu.

Wnioski

Rozpoczynając naukę modelu głębokiego uczenia się w programie SageMaker, rozważ następujące wskazówki, aby osiągnąć większą szybkość szkolenia:

• Najpierw wypróbuj metodę z wieloma procesorami w jednym wystąpieniu lub z jednym procesorem w jednym wystąpieniu. Jeśli wykorzystanie procesora/GPU jest bardzo wysokie (na przykład ponad 90%), przejdź do następnego kroku.
• Wypróbuj więcej procesorów w jednym hoście lub więcej procesorów graficznych w jednym hoście. Jeśli wykorzystanie zbliża się do maksymalnego wykorzystania procesorów lub procesorów graficznych, przejdź do następnego kroku.
• Wypróbuj wiele procesorów lub wiele procesorów graficznych z wieloma hostami.
• Musisz zmodyfikować kody podczas korzystania z serwerów parametrów lub Horovod. Modyfikacja kodu nie jest taka sama dla API opartego na sesjach TensorFlow, tf.estimator API i tf.keras API. Serwer parametrów lub Horovod może pokazywać różne prędkości treningu w różnych przypadkach i zadaniach szkoleniowych, więc wypróbuj obie metody, jeśli masz czas i budżet, aby określić najlepszą.

Pamiętaj o następujących wskazówkach:

• Sprawdź wykorzystanie przed skalowaniem, zoptymalizuj potok danych i spraw, aby procesor i GPU nakładały się na osi czasu.
• Najpierw skaluj w górę, a następnie w górę.
• Jeśli nie możesz utworzyć wykorzystania procesora GPU po zastosowaniu wszystkich metod, wypróbuj procesor. Istnieje wiele przypadków (zwłaszcza w przypadku modelu rankingu współczynnika klikalności), w których łączny czas trenowania instancji procesora CPU jest krótszy i bardziej opłacalny niż trenowanie instancji GPU.

Mamy również próbkę kodu w GitHub repo, gdzie pokazujemy dwie próbki rozproszonego szkolenia DeepFM w SageMakerze. Jeden to serwer parametrów TensorFlow na instancjach CPU, drugi to Horovod na instancjach GPU.

O autorach

Yuhui Lianga jest starszym architektem rozwiązań uczenia maszynowego. Koncentruje się na promocji i zastosowaniu uczenia maszynowego i jest głęboko zaangażowany w projekty uczenia maszynowego wielu klientów. Posiada bogate doświadczenie w rozproszonych szkoleniach typu deep learning, systemach rekomendacji i reklamie obliczeniowej.

Shishuai Wanga jest starszym architektem rozwiązań uczenia maszynowego. Współpracuje z klientami AWS, aby pomóc im wdrożyć uczenie maszynowe na dużą skalę. Lubi oglądać filmy i podróżować po świecie.