Pipeline Parallelism

Pipeline Parallelism (PP) rozdziela kolejne grupy warstw modelu między urządzenia. Wynik pierwszej grupy staje się wejściem drugiej, więc pojedyncza porcja danych przechodzi przez etapy po kolei. Równoczesna praca pojawia się wtedy, gdy różne etapy obsługują różne porcje.

GPipe, §2.1–2.2 dzieli sekwencję warstw na grupy, a batch przykładów na mniejsze micro-batches. GPU przekazują aktywacje na granicach grup. W opisanym treningu gradienty są sumowane z micro-batches, a aktualizacja wag następuje po całym batchu. To konkretny harmonogram GPipe; PP obejmuje również inne harmonogramy.

Pierwszy wynik nadal musi przejść całą drogę

Własny model czasu: trzy etapy po jednej umownej jednostce, cztery niezależne porcje danych. Przy przepuszczaniu każdej osobno koniec przypada po 12 jednostkach. Gdy etapy pracują równocześnie nad różnymi porcjami, ostatnia wychodzi po 6 jednostkach. Pierwsza nadal potrzebuje trzech.

Zmień liczbę porcji i przechodź przez harmonogram. Przy jednej porcji nie ma skrócenia czasu: pozostałe GPU czekają na dane albo kończą już pracę. Te puste miejsca to pipeline bubbles. Włącz wolniejszy środkowy etap i zobacz, gdzie powstaje następna kolejka.

Dla $K$ równych etapów i $M$ porcji ten uproszczony forward trwa $M+K-1$ jednostek, zamiast $KM$ bez nakładania pracy. Tu $K=3$. Pomijamy transfery i backward; porcja zachowuje stały rozmiar, więc zwiększenie $M$ zwiększa też całkowitą pracę. To nie jest pomiar przy stałym batchu. GPipe, §2.3 omawia koszt pustych przebiegów i nierównego podziału pracy w pełnym treningu.

Co jest dzielone?

PP korzysta z następstwa warstw w Transformerze. Tensor Parallelism może dodatkowo podzielić operacje wewnątrz każdego etapu. Samo PP nie usuwa zależności między kolejnymi tokenami jednej odpowiedzi w Autoregressive Language Modeling: w demonstracji porcje są niezależnymi wejściami, nie przyszłymi tokenami tego samego strumienia.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.