Jak transfer peer-to-peer przez PCIe wpływa na lokalne wnioskowanie z użyciem wielu GPU?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Does PCIe Peer-to-Peer Transfer Affect Multi-GPU Local Inference? - Zima Store Online

Transfer peer-to-peer przez PCIe może zmniejszyć narzut wnioskowania na wielu GPU, przenosząc tensory bezpośrednio między pamięciami zgodnych GPU zamiast przechowywać je tymczasowo w pamięci RAM hosta.

Model lokalny podzielony między dwa GPU musi przesyłać aktywacje, bloki KV lub wyniki ekspertów za każdym razem, gdy wykonywanie przekracza granicę urządzenia. Bez bezpośredniego dostępu peer-to-peer dane mogą przepływać z jednego GPU do pamięci hosta, a następnie z powrotem do drugiego, obciążając połączenia z CPU i dodając operacje kopiowania. P2P skraca tę ścieżkę, ale jego wartość zależy od topologii, rozmiaru transferu, synchronizacji oraz częstotliwości komunikacji modelu.

Dostęp peer-to-peer zastępuje ścieżkę kopiowania przez hosta

Po włączeniu dostępu peer-to-peer jeden GPU może adresować dane w pamięci innego GPU lub kopiować je za pośrednictwem obsługiwanej ścieżki połączenia. Transfer omija jawny bufor pośredni w stronicowanej lub przypiętej pamięci systemowej i może ograniczyć udział CPU.

Przewodnik programowania CUDA wyjaśnia, że dostęp do pamięci peer musi być obsługiwany i włączony między parami urządzeń. Możliwość ta jest kierunkowa i zależna od topologii, dlatego oprogramowanie powinno sprawdzać każdą parę zamiast zakładać, że każdy GPU w jednym hoście może komunikować się bezpośrednio.

Model nadal wymaga synchronizacji, aby GPU odbierający dane nie odczytał niekompletnych aktywacji. P2P usuwa etap przechowywania pośredniego, ale nie eliminuje kosztów związanych z kolejnością, uruchamianiem kerneli ani komunikacją zbiorową. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Topologia PCIe określa rzeczywistą przepustowość bezpośredniej ścieżki

Dwa GPU znajdujące się za tym samym przełącznikiem PCIe często mogą wymieniać dane bez przechodzenia przez gniazdo CPU, podczas gdy urządzenia za różnymi kompleksami głównymi mogą wymagać ścieżki przez hosta albo utracić obsługę P2P. Generacja łącza, szerokość magistrali, przeciążenie przełącznika oraz jednoczesny ruch wyznaczają limit.

NCCL dokumentuje, że preferuje bezpośrednią komunikację GPU, gdy CUDA zgłasza zgodne GPU, wykorzystując PCIe lub NVLink zgodnie z dostępną topologią. Jego narzędzia topologii pokazują, czy każda para urządzeń może korzystać z bezpośredniego dostępu przez PCIe. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie na nim bazować.

W przypadku małych transferów dominować może opóźnienie uruchamiania i synchronizacji, podczas gdy duże transfery tensorów zbliżają się do przepustowości łącza. Potok z częstymi, wąskimi granicami może zyskać mniej niż konstrukcja komunikująca mniej, ale większych bloków. Tę granicę należy mierzyć osobno w realistycznych warunkach pracy.

Podział modelu decyduje o tym, czy szybsze kopiowanie ma znaczenie

Równoległość tensorów wymaga komunikacji w obrębie wielu warstw, równoległość potokowa przesyła aktywacje między granicami etapów, a równoległość ekspertów wymienia kierowane tokeny. To samo łącze P2P może więc być słabo wykorzystywane albo stać się głównym ograniczeniem, zależnie od strategii podziału.

Omówienie projektu NVIDIA GPUDirect pokazuje, jak rozmieszczenie w topologii PCIe i położenie przełączników wpływają na bezpośredni przepływ danych w porównaniu ze ścieżkami przez hosta. Zasada ta ma zastosowanie, mimo że frameworki wnioskowania dodają własne warstwy komunikacji zbiorowej i planowania. Praktyczne konsekwencje pojawiają się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Granica awarii obejmuje nieobsługiwaną topologię, ograniczenia IOMMU lub wirtualizacji albo komunikację, która już przekracza budżet PCIe. Oprogramowanie przechodzi wtedy na buforowanie przez hosta lub doświadcza rywalizacji o łącze, a dodanie drugiego GPU może spowolnić wnioskowanie mimo większej mocy obliczeniowej.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Mierz każdą parę GPU i każdą granicę modelu

Odwzoruj GPU, gniazdo CPU, główny kontroler PCIe, przełącznik, generację łącza, szerokość, możliwości P2P oraz pamięć NUMA. Zmierz jednokierunkowe i dwukierunkowe kopiowanie peer oraz kopiowanie przez hosta dla reprezentatywnych rozmiarów transferów. Ta zależność powinna pozostać jawna w końcowym interfejsie.

Połącz wynik z rozmieszczeniem uwzględniającym NUMA. Profiluj czas obliczeń, czas komunikacji, synchronizację, przepustowość komunikacji zbiorowej, liczbę tokenów na sekundę oraz opóźnienie żądań p99 dla każdego podziału modelu przy włączonym i wyłączonym P2P. Wynik należy zatem porównać z pierwotnymi danymi.

Zachowaj plan wykorzystujący wiele GPU tylko wtedy, gdy poprawia opóźnienie całościowe lub przepustowość. Jeśli bezpośrednie kopiowanie jest szybkie, ale wnioskowanie nadal jest ograniczone komunikacją, zmniejsz liczbę przekroczeń granic podziału albo wybierz rozmieszczenie uwzględniające topologię, zamiast uznawać samą obsługę P2P za wystarczającą.