Spis treści
W klastrach AI sieć łącząca serwery z akceleratorami GPU jest równie istotna, jak moc obliczeniowa. Przy rozproszonym trenowaniu modeli wiele GPU wykonuje zsynchronizowane operacje komunikacyjne, dlatego opóźnienia, przeciążenia lub nierównomierne wykorzystanie łączy mogą ograniczać wydajność całego środowiska. Przy projektowaniu infrastruktury w naszym polskim Data Center wybór między InfiniBand a RoCEv2 powinien więc uwzględniać nie tylko maksymalną przepustowość, ale także latencję, zachowanie podczas przeciążenia, możliwość skalowania oraz sposób zarządzania siecią. Z artykułu dowiesz się, jakie parametry mają największe znaczenie przy budowie sieci dla klastra AI oraz czym różnią się pod tym względem oba te rozwiązania.
Co decyduje o „wąskich gardłach” w sieci?
Wąskie gardło nie musi oznaczać całkowicie wysyconego łącza. W klastrze AI problemem może być również chwilowe przeciążenie kolejki, nierównomierne rozłożenie ruchu albo zwiększenie opóźnień podczas zsynchronizowanej wymiany danych. Szczególne znaczenie mają operacje kolektywne, takie jak AllReduce, AllGather czy All-to-All. W ich trakcie wiele akceleratorów komunikuje się jednocześnie. Jeżeli część transmisji zostanie opóźniona, pozostałe GPU mogą oczekiwać na jej zakończenie. W efekcie problem dotyczący pojedynczego fragmentu sieci będzie ograniczać wykorzystanie znacznie większej liczby akceleratorów.
Przy projektowaniu sieci dla AI należy więc analizować jednocześnie takie parametry, jak:
- opóźnienie i jego zmienność,
- rzeczywistą przepustowość osiąganą przez aplikację,
- zachowanie sieci przy przeciążeniu,
- sposób rozłożenia ruchu na dostępne ścieżki,
- możliwość skalowania wraz ze wzrostem liczby GPU.
Warto też pamiętać, że parametry portu, np. 400 czy 800 Gb/s, opisują możliwości interfejsu, a nie wydajność całego klastra.
Kryteria wyboru sieci dla AI – latencja, jitter, efektywna przepustowość i rzeczywista wydajność
RoCEv2 i InfiniBand wykorzystują RDMA, czyli mechanizm pozwalający na bezpośrednią wymianę danych z pamięcią hosta przy mniejszym udziale procesora. Pierwsze z tych rozwiązań realizuje RDMA przez Ethernet i wykorzystuje routowanie IP, natomiast drugie korzysta z wyspecjalizowanej architektury sieciowej. Przy wyborze technologii warto zwrócić uwagę na trzy kwestie.
- Latencja i jitter – określają nie tylko średni czas przesyłania danych, ale również jego zmienność. W zsynchronizowanych operacjach kolektywnych istotne są także pojedyncze transmisje, które trwają znacznie dłużej od pozostałych.
- Efektywna przepustowość – pokazuje, ile danych aplikacja faktycznie jest w stanie przesłać w określonym czasie. Sama przepustowość interfejsu nie uwzględnia wpływu protokołów, kolejek, przeciążeń czy sposobu routowania.
- Charakter ruchu – sieć może bardzo dobrze wypadać w teście pojedynczego dużego przepływu, ale osiągać gorsze wyniki, gdy wiele GPU jednocześnie wykonuje operacje kolektywne. Dlatego testy powinny odwzorowywać rzeczywiste obciążenie środowiska AI.
Organizacja pracy i ryzyko błędów wdrożenia
InfiniBand jest rozwiązaniem wyspecjalizowanym pod kątem komunikacji o wysokiej wydajności. RoCEv2 wykorzystuje natomiast Ethernet, a to ułatwia integrację z kompetencjami i częścią infrastruktury znanej z tradycyjnych sieci. Jednocześnie wymaga poprawnej konfiguracji mechanizmów kontroli przepływu, przeciążenia, kolejek, buforów i routingu. Błąd w jednym z tych obszarów może ujawnić się dopiero podczas dużego obciążenia.
Nie oznacza to, że RoCEv2 nie nadaje się do dużych klastrów. Przykłady produkcyjnych środowisk obejmujących tysiące GPU pokazują, że przy właściwym projekcie może zapewnić wysoką wydajność.
Latencja i jitter – porównanie InfiniBand vs. RoCEv2
InfiniBand od początku projektowano z myślą o bardzo szybkiej komunikacji między urządzeniami. Dlatego technologia ta jest szeroko wykorzystywana w środowiskach HPC i AI. RoCEv2 może osiągać podobnie wysoką wydajność, ale większa część odpowiedzialności za zachowanie sieci spoczywa na prawidłowo zaprojektowanej infrastrukturze Ethernet.
Znaczenie mają tutaj między innymi topologia, długość ścieżek, kolejki, bufory i sposób rozłożenia ruchu. Dlatego nie należy porównywać wyłącznie średniej latencji obu rozwiązań. Dla klastra AI ważniejsze jest to, jak zmienia się czas komunikacji pod obciążeniem oraz czy pojedyncze opóźnione transmisje nie zaburzają synchronizacji.
Przepustowość efektywna sieci dla AI w praktyce
Wysoka przepustowość pojedynczego portu nie gwarantuje dobrej wydajności dla całego klastra. Jeżeli serwery dedykowane korzystają z tego samego przeciążonego odcinka sieci, problem wystąpi niezależnie od parametrów kart sieciowych.
Duże klastry wymagają więc odpowiedniej topologii sieci – najczęściej wielopoziomowej – oraz właściwego stosunku przepustowości pomiędzy poszczególnymi warstwami. Ważne jest ograniczenie nadsubskrypcji, czyli sytuacji, w której przepustowość niższej warstwy przekracza możliwości połączeń prowadzących dalej. Istotne jest również równomierne rozłożenie ruchu. Przy komunikacji AI nawet niewielka liczba bardzo dużych przepływów może powodować przeciążenie konkretnej ścieżki. W praktycznych wdrożeniach RoCEv2 problemy z rozłożeniem ruchu mogą znacząco obniżyć wydajność treningu.
Zatory i kontrola przeciążenia – mechanizmy kontroli ruchu, kolejki i wymagania dotyczące ograniczenia strat pakietów w RoCEv2
Kontrola przeciążenia jest jednym z najważniejszych elementów sieci wykorzystujących RoCEv2. W praktycznych wdrożeniach stosuje się między innymi PFC (Priority Flow Control) i ECN (Explicit Congestion Notification). PFC pozwala zatrzymać transmisję określonego priorytetu przed przepełnieniem kolejki, a ECN sygnalizuje przeciążenie urządzeniom końcowym.
RoCEv2 wymaga więc odpowiedniego zaprojektowania środowiska ograniczającego utratę pakietów. Nie oznacza to jednak, że samo włączenie PFC rozwiązuje problem. Nieprawidłowo dobrane progi i bufory mogą powodować propagowanie zatorów albo blokowanie innych transmisji.
InfiniBand również posiada mechanizmy kontroli przepływu i przeciążenia, ale są one elementem wyspecjalizowanego stosu tej technologii. W RoCEv2 administrator musi natomiast prawidłowo skonfigurować większą liczbę elementów infrastruktury Ethernet.
Skalowanie sieci do dużej liczby węzłów i kompatybilność ze stosem AI/HPC
Wraz ze wzrostem liczby GPU rośnie znaczenie topologii, routingu oraz sposobu wykonywania operacji kolektywnych. Przy dużym klastrze nawet niewielka nierównowaga w sieci pod AI może przekładać się na dłuższy czas wykonywania zadań.
InfiniBand ma silną pozycję w środowiskach HPC i AI, natomiast RoCEv2 pozwala budować duże sieci w oparciu o Ethernet. Nie ma więc prostej zasady, według której jedna technologia nadaje się wyłącznie do małych, a druga do dużych klastrów. RoCEv2 jest wykorzystywane również w środowiskach obejmujących tysiące GPU. Ważna jest też zgodność całego stosu. Karty sieciowe, sterowniki, biblioteki komunikacyjne, oprogramowanie GPU i narzędzia AI powinny być testowane jako jeden system. Szczególne znaczenie ma to w przypadku bibliotek odpowiedzialnych za komunikację kolektywną, takich jak NCCL.
Kontrola sieci pod AI – zarządzanie, diagnostyka i telemetria
Sieć projektowana pod AI wymaga dokładnego monitorowania. Sam poziom wykorzystania portów nie wystarcza bowiem do tego, aby móc odnaleźć źródła wszystkich potencjalnych problemów.
W tym celu należy obserwować także:
- opóźnienia i ich zmienność,
- wykorzystanie poszczególnych ścieżek,
- zapełnienie kolejek,
- błędy transmisji,
- zdarzenia PFC i ECN,
- nierównomierne rozłożenie ruchu.
W przypadku RoCEv2 szczególnie przydatna jest telemetria pozwalająca analizować sygnały przeciążenia oraz reakcję urządzeń końcowych. Dzięki temu można odróżnić niepoprawność działania sieci od problemu sterownika, karty sieciowej czy samej aplikacji. Przy dużej liczbie węzłów możliwość szybkiego wskazania przeciążonego elementu ma bezpośrednie znaczenie dla czasu diagnostyki.
TCO oraz złożoność wdrożenia i utrzymania sieci pod AI
TCO, czyli całkowite koszty wdrożenia oraz utrzymania sieci AI obejmuje znacznie więcej niż tylko zakup serwerów dedykowanych. Trzeba uwzględnić też m.in. karty sieciowe, okablowanie, moduły optyczne, licencje, wsparcie producenta, części zapasowe oraz czas pracy administratorów.
RoCEv2 może korzystać z szerokiego ekosystemu Ethernetu, a to ułatwia dobór sprzętu i wykorzystanie istniejących kompetencji zespołu pracowników. Jednocześnie poprawne skonfigurowanie PFC, ECN, buforów, kolejek i routingu zwiększa złożoność wdrożenia. InfiniBand jest bardziej wyspecjalizowany, a więc eliminuje część problemów związanych z przystosowaniem sieci do ruchu RDMA, ale jednocześnie ogranicza wybór komponentów i wymaga znajomości konkretnego ekosystemu.
Uzależnienie od dostawcy i elastyczność rozbudowy sieci
InfiniBand jest technologią wyspecjalizowaną i silnie związaną z określonym ekosystemem sprzętowym. Zapewnia ścisłą integrację komponentów, ale może ograniczać swobodę wyboru urządzeń różnych producentów. RoCEv2 korzysta z Ethernetu, a więc daje większą elastyczność w zakresie doboru sprzętu. Nie oznacza to jednak pełnej zamienności wszystkich komponentów. Różnice w implementacji PFC, ECN, telemetrii, sterownikach czy funkcjach przełączników mogą wpływać na kompatybilność i rzeczywistą wydajność. Przed wyborem technologii warto więc określić, czy infrastruktura będzie rozbudowywana etapami, jakie kompetencje posiada zespół odpowiedzialny za jej obsługę oraz czy w przyszłości planowana jest zmiana dostawcy sprzętu.
InfiniBand i RoCEv2 mogą stanowić podstawę wydajnych klastrów AI. InfiniBand będzie szczególnie interesujący tam, gdzie priorytetem są niskie opóźnienia, przewidywalność komunikacji i ścisła integracja infrastruktury. RoCEv2 daje możliwość wykorzystania Ethernetu do budowy dużych środowisk, ale wymaga większej uwagi przy projektowaniu mechanizmów kontroli przeciążenia i monitorowania.
Jeżeli klaster AI ma być uruchamiany w zewnętrznej infrastrukturze, znaczenie ma również sposób organizacji całego środowiska. Jeśli interesuje Cię kolokacja serwerów lub ich wynajem u zewnętrznego dostawcy, istotne są nie tylko parametry pojedynczych maszyn. Należy zwrócić uwagę również na przepustowość i redundancję połączeń, możliwość rozbudowy infrastruktury IT oraz kompetencje zespołu technicznego operatora. Sprint Data Center oferuje oba rozwiązania – zapoznaj się z naszą ofertą. Dysponujemy nowoczesnym, doskonale zabezpieczonym Data Center, ciesząc się ogromnym zaufaniem Klientów. Z naszym wsparciem zbudujesz efektywną sieć pod AI.
FAQ – odpowiedzi na często zadawane pytania
1. Czy można wykorzystać istniejącą sieć Ethernet do uruchomienia RoCEv2?
Technicznie jest to możliwe, ale zwykła konfiguracja sieci Ethernet nie zapewnia automatycznie warunków wymaganych przez intensywny ruch RDMA. Przed wykorzystaniem istniejącej infrastruktury IT trzeba sprawdzić możliwości przełączników, obsługę PFC i ECN, wielkość buforów oraz sposób zarządzania ruchem.
2. Jakie znaczenie ma okablowanie w sieci dla klastra AI?
Bardzo duże. Rodzaj modułów nadawczo-odbiorczych, długość przewodów, typ łącza sieciowego oraz liczba połączeń wpływają na koszt, zasięg i możliwości rozbudowy infrastruktury IT. Przy dużej liczbie portów koszt optyki i okablowania może stanowić istotną część całego budżetu.
3. Czy do klastra AI potrzebna jest osobna sieć dla pamięci masowej?
Niekoniecznie. Zależy to od architektury systemu i sposobu dostarczania danych do GPU. Przy intensywnych operacjach wejścia/wyjścia oddzielenie ruchu pamięci masowej od komunikacji między akceleratorami może jednak ułatwić zarządzanie przepustowością i ograniczyć wzajemne oddziaływanie obciążeń.
4. Jak często należy testować wydajność sieci klastra?
Nie ma jednej uniwersalnej częstotliwości. Testy warto wykonywać po zmianach konfiguracji, rozbudowie klastra, aktualizacjach sterowników lub oprogramowania oraz wtedy, gdy zmienia się charakter obciążenia. W środowisku produkcyjnym pomocne jest także okresowe porównywanie wyników z wcześniejszymi pomiarami.
5. Czy liczba portów na serwerze ma wpływ na wydajność klastra?
Tak. Większa liczba interfejsów może zwiększyć dostępną przepustowość i liczbę ścieżek, ale tylko wtedy, gdy reszta infrastruktury jest przygotowana na obsługę dodatkowego ruchu. Samo dodanie kolejnej karty sieciowej nie rozwiąże problemu, jeżeli wąskie gardło znajduje się w przełączniku lub wyższej warstwie topologii.