Jak lokalność NUMA wpływa na wnioskowanie AI na wielu procesorach GPU w warunkach domowych?

Lokalność NUMA wpływa na wnioskowanie, gdy wątki CPU, pamięć hosta i procesory GPU komunikują się między nielokalnymi domenami zamiast pozostawać blisko swojej ścieżki PCIe.

Domowy serwer AI z dwoma gniazdami procesorów może udostępniać dwie duże pule pamięci RAM i kilka procesorów GPU jako jedna maszyna, jednak dostęp do nich nie jest jednakowy. Wątek roboczy zaplanowany na jednym gnieździe może przygotowywać tensory w pamięci podłączonej do drugiego, a następnie przesyłać je do procesora GPU znajdującego się za innym głównym kontrolerem PCIe. Wpływ zależy od rozmieszczenia modelu, buforowania po stronie hosta, ruchu związanego z równoległością tensorów, topologii połączeń, przetwarzania wsadowego oraz tego, czy obciążenie jest ograniczone mocą obliczeniową, czy transferem danych.

NUMA zamienia jedną pulę pamięci w dostęp zależny od odległości

W systemie NUMA każde gniazdo procesora lub domena obliczeniowa ma pamięć, która znajduje się bliżej niektórych rdzeni niż innych. Oprogramowanie może adresować połączoną pojemność, ale dostęp zdalny musi przechodzić przez interkonekt. Taka ścieżka ma zwykle inne opóźnienia i dostępną przepustowość niż pamięć lokalna.

Topologia NUMA wpływa również na DMA procesora GPU, ponieważ strony pamięci hosta mogą znajdować się daleko od głównego kontrolera PCIe tego procesora. Planowanie zadań CPU i rozmieszczenie pamięci to odrębne decyzje, a maszyna wirtualna może nie widzieć automatycznie topologii hosta potrzebnej do ich dopasowania.

Wpływ jest niewielki, gdy ruch pamięci hosta ma małe znaczenie w porównaniu z obliczeniami GPU. Rośnie podczas ładowania modelu, przenoszenia obliczeń na CPU, tokenizacji, kopiowania do przypiętych buforów, częstej synchronizacji lub obsługi obciążeń przekraczających pamięć VRAM. Pojemność NUMA nie gwarantuje lokalności NUMA.

Rozmieszczenie GPU dodaje do ścieżki modelu drugą topologię

Wiele procesorów GPU może być podłączonych do różnych gniazd CPU, przełączników PCIe lub partycji w układzie. Tensor przemieszczający się między dwoma akceleratorami może korzystać z bezpośredniej ścieżki peer-to-peer, dedykowanego łącza GPU, przełącznika PCIe albo trasy obejmującej pamięć hosta i przeskok między gniazdami. Te ścieżki nie są równoważne.

Badania nad procesorami GPU z wieloma partycjami pokazują, że niejednolity dostęp i komunikacja między partycjami mogą nasilać rywalizację o zasoby oraz zwiększać opóźnienia jąder. Strategie rozmieszczania różnią się w zależności od tego, czy dane są współdzielone globalnie, częściowo czy tylko w obrębie jednej grupy roboczej lub partycji.

Podział modelu powinien uwzględniać topologię, przez którą przebiega najwięcej powtarzalnego ruchu. Sąsiednie warstwy lub stan mechanizmu uwagi rozmieszczone po dwóch stronach wolnej granicy mogą komunikować się przy każdym tokenie, podczas gdy mniej intensywny podział może tolerować większą odległość. Samo liczenie procesorów GPU bez mapowania ich połączeń ukrywa istotne zależności.

First-touch i migracja wątków mogą zaburzyć zamierzone rozmieszczenie

Systemy operacyjne często umieszczają pamięć blisko wątku, który jako pierwszy uzyskuje dostęp do każdej strony. Jeśli inicjalizacja działa na jednym gnieździe, a wątki wnioskowania później wykonują się na innym, strony mogą pozostać zdalne. Migracja przez harmonogram również może przenieść wątki przygotowujące dane CPU z dala od pamięci i procesora GPU, któremu miały służyć.

Świadomość NUMA łączy lokalne banki pamięci z gniazdami CPU, które uzyskują do nich dostęp najwydajniej. Przypisanie wątków CPU bez kontrolowania alokacji pamięci albo przypisanie pamięci bez dopasowania procesora GPU rozwiązuje tylko część problemu.

Stabilny układ może wymagać ustawienia powinowactwa CPU, zasad alokacji pamięci, przypisania urządzeń oraz uruchamiania procesów z uwzględnieniem topologii. Kontenery i maszyny wirtualne dodają kolejną warstwę mapowania. Celem nie jest bezrefleksyjne przypinanie wszystkiego, lecz utrzymanie ścieżek producent–bufor–konsument o dużym natężeniu w obrębie najbliższej praktycznej domeny.

Lokalność ma największe znaczenie w określonych fazach wnioskowania

Ładowanie modelu obciąża transfer ze źródła danych do hosta oraz z hosta do procesora GPU. Faza prefill przetwarza wiele tokenów promptu i może wykorzystywać większe operacje macierzowe, natomiast faza decode wielokrotnie przetwarza jeden lub kilka tokenów naraz i może być wrażliwa na przepustowość pamięci, synchronizację oraz narzut uruchamiania jąder. Wpływ NUMA może więc zmieniać się w obrębie jednego żądania.

Efekty NUMA GPU pokazują, że planowanie uwzględniające rozmieszczenie może poprawić działanie mechanizmu uwagi przez dopasowanie zadań do domen pamięci i ponowne wykorzystanie pamięci podręcznej. Wniosek jest węższy niż obietnica uniwersalnego przyspieszenia: zysk pojawia się tam, gdzie sposób współdzielenia danych przez jądro odpowiada mapowaniu uwzględniającemu topologię.

Benchmark, który podaje wyłącznie średnią liczbę tokenów na sekundę, może ukrywać długi czas do wygenerowania pierwszego tokenu lub słabe skalowanie przy określonym rozmiarze partii. Rejestruj osobno czas ładowania, przepustowość fazy prefill, opóźnienie między tokenami, ruch na łączach GPU, zdalne dostępy NUMA oraz przepustowość pamięci CPU.