Obserwowalność infrastruktury AI dla klastrów GPU
Pełna widoczność czynników spowalniających każde obciążenie treningowe i wnioskowania.
Sensaka łączy dane GPU, kontenerów, węzłów, sieci, pamięci masowej, zasilania, temperatury, chłodzenia cieczą i kondycji sprzętu w jednym widoku operacyjnym. Zamiast jedynie potwierdzać niskie wykorzystanie GPU, zespoły infrastruktury mogą analizować warunki towarzyszące obciążeniu i ustalić, czy prawdopodobne ograniczenie wynika z mocy obliczeniowej, komunikacji, dostarczania danych czy węzła fizycznego.
Niskie wykorzystanie GPU to zwykle objaw
GPU może być przydzielone i aktywne, wykonując niewiele użytecznej pracy. Obciążenie może oczekiwać na dane, być blokowane przez komunikację sieciową, dotknięte opóźnieniami pamięci masowej, rywalizować z innym kontenerem lub działać na węźle z problemami temperatury, zasilania lub sprzętu.
Gdy każdy obszar jest monitorowany w osobnym narzędziu, zespoły widzą różne fragmenty tego samego zdarzenia. Administratorzy GPU analizują metryki akceleratorów. Zespoły sieciowe sprawdzają liczniki RoCE lub RDMA. Zespoły pamięci masowej analizują przepustowość i opóźnienia. Zespoły centrum danych obserwują zasilanie i chłodzenie. Zespoły aplikacyjne przeglądają logi obciążeń.
Sensaka porządkuje te sygnały, dzięki czemu zespoły mogą analizować pełną ścieżkę infrastruktury stojącą za obciążeniem AI.
Jedna oś czasu dla mocy obliczeniowej, sieci i pamięci masowej
Sensaka koreluje metryki operacyjne z głównych obszarów infrastruktury wpływających na wydajność obciążeń AI.
Widoczność GPU i węzłów
Śledzenie wykorzystania akceleratorów, zużycia pamięci, temperatury, poboru mocy, stanu ECC oraz kondycji węzłów. Analiza wydajności według modelu akceleratora, węzła, klastra lub projektu pozwala zidentyfikować różnice we wzorcach wykorzystania.
Kontekst kontenerów i obciążeń
Powiązanie obciążeń i kontenerów z wykorzystywanymi przez nie GPU. Śledzenie zależności od zadania, przez kontener, GPU, węzeł fizyczny i port sieciowy, aż po zależność od pamięci masowej. Taki kontekst pomaga odróżnić rzeczywiście obciążony akcelerator od nadmiernie przydzielonego lub niedostatecznie wykorzystywanego.
Obserwowalność sieci o wysokiej przepustowości
Monitorowanie ruchu RoCE i RDMA, w tym utraty pakietów, retransmisji, opóźnień i stanu portów. Wskaźniki sieciowe można analizować razem z wykorzystaniem GPU, aby ustalić, czy opóźnienia komunikacyjne ograniczają trening rozproszony.
Obserwowalność pamięci masowej i dostarczania danych
Analiza przepustowości, IOPS, opóźnień odczytu i zapisu, czasu wczytywania danych oraz czasu zapisu punktów kontrolnych. Te sygnały pomagają ustalić, czy GPU oczekują na dane treningowe dostarczane zbyt wolno.
Stan infrastruktury fizycznej
Łączenie danych wydajnościowych in-band z informacjami sprzętowymi out-of-band z interfejsów BMC. Temperatura, pobór mocy, stan ECC i kondycja komponentów pozostają istotne, gdy widok systemu operacyjnego lub obciążenia nie wyjaśnia problemu.
Od metryk do ścieżki analizy
Sensaka porządkuje obserwowalność infrastruktury AI w czterech powiązanych etapach.
Monitorowanie
Zbieranie danych o stanie GPU i węzłów, utracie pakietów i opóźnieniach sieciowych, wydajności pamięci masowej, poborze mocy, temperaturze, chłodzeniu cieczą oraz kondycji sprzętu.
Korelacja
Powiązanie zadań z kontenerami, kontenerów z GPU, GPU z węzłami fizycznymi oraz węzłów z zasobami sieciowymi i pamięci masowej. Powiązanie dotkniętego obciążenia z jego projektem i kontekstem usługowym.
Diagnoza
Porównanie sygnałów uporządkowanych w czasie w celu znalezienia dowodów na ograniczenie mocy obliczeniowej, problem z komunikacją sieciową, wąskie gardło w dostarczaniu danych z pamięci masowej lub stan sprzętowy węzła. Platforma prezentuje powiązane wskaźniki i prawdopodobny zakres wpływu, aby operatorzy mogli podjąć świadomą decyzję.
Optymalizacja
Przekształcenie diagnozy w rekomendację operacyjną, taką jak weryfikacja priorytetu obciążenia, ponowna alokacja zasobów GPU, izolacja wadliwego węzła, ponowne uruchomienie dotkniętego zadania lub zmiana polityki kolejkowania i szeregowania. Wykonanie może wymagać zatwierdzenia i być rejestrowane na potrzeby audytu.
Analiza typowych problemów infrastruktury AI
Spadek wykorzystania GPU podczas treningu
Zestawienie wykorzystania GPU, opóźnień sieciowych i czasu oczekiwania na pamięć masową na wspólnej osi czasu. Analiza wczytywania danych i opóźnień komunikacyjnych w okresie wystąpienia problemu, a następnie określenie, który obszar infrastruktury wykazuje najsilniejsze dowody wąskiego gardła.
Spowolnienie treningu rozproszonego
Analiza utraty pakietów RoCE lub RDMA, retransmisji i stanu portów razem z aktywnością GPU. Ustalenie, czy problem komunikacyjny dotyczy jednego węzła, jednego portu, czy większej części klastra.
Zbyt długi czas zapisu punktów kontrolnych
Porównanie przepustowości pamięci masowej, IOPS i opóźnień zapisu z czasem zapisu punktów kontrolnych obciążenia. Ustalenie, czy wydajność pamięci masowej opóźnia obciążenie i pozostawia akceleratory bezczynne.
Kontener wykorzystuje mniej GPU niż zażądano
Porównanie zażądanych zasobów z rzeczywistym wykorzystaniem w czasie. Identyfikacja obciążeń, które zajmują kosztowną pojemność przy niewielkiej aktywności, a następnie ocena, czy należy zmienić specyfikacje zasobów lub reguły szeregowania.
Węzeł wygląda na sprawny w Kubernetes, ale obciążenia kończą się niepowodzeniem
Wykorzystanie monitoringu sprzętu out-of-band do analizy temperatury, poboru mocy, stanu ECC i komponentów niezależnie od systemu operacyjnego. Stanowi to dodatkowe źródło dowodów, gdy monitoring na poziomie oprogramowania nie ujawnia usterki.
Jak zmieniają się wymagania DCIM dla klastrów AI i GPU
Model zarządzania infrastrukturą centrum danych, który dobrze sprawdza się w konwencjonalnych serwerowniach, zwykle wymaga rozszerzenia, zanim stanie się przydatny dla klastra AI. Dyscypliny pozostają te same. Gęstość, tempo zmian i zasięg pojedynczej awarii — już nie.
| Wymaganie | Konwencjonalne serwery | Klastry AI i GPU |
|---|---|---|
| Moc na szafę rack | Konwencjonalną szafę rack planuje się wokół stabilnego zapotrzebowania na moc, a pobór mocy na poziomie szafy analizuje się zwykle okresowo, a nie w sposób ciągły. | Szafa AI skupia znacznie większą moc na tej samej powierzchni, a pobór zmienia się wraz z zadaniem. Dane o mocy trzeba zbierać na poziomie szafy i obwodu na tyle często, aby ujawnić skokowe zmiany wywoływane przez obciążenia. |
| Chłodzenie | Chłodzenie powietrzem wraz z monitoringiem temperatury w pomieszczeniu i korytarzach zwykle wystarcza, a średnia dla pomieszczenia jest rozsądnym przybliżeniem warunków, w jakich pracuje każdy serwer. | Gęsto upakowane szafy z akceleratorami często łączą chłodzenie powietrzem i cieczą. Temperatura zasilania i powrotu chłodziwa, różnica ciśnień, wskaźniki przepływu oraz zdarzenia wycieku stają się danymi operacyjnymi, a średnia dla pomieszczenia może ukryć szafę, w której problem już występuje. |
| Model pojemności | W większości konwencjonalnych pomieszczeń wolne jednostki U są użyteczną miarą pozostałej pojemności. | Jednostki U, zapas mocy i wydajność chłodzenia trzeba oceniać łącznie. Szafa rack może mieć wolne miejsce, podczas gdy warunki zasilania lub termiczne uniemożliwiają zainstalowanie w niej czegokolwiek więcej. |
| Ewidencja zasobu | Serwer, jego lokalizacja, konfiguracja i status gwarancji wystarczająco opisują zasób. | Ewidencja musi obejmować także akceleratory wewnątrz obudowy, ich kondycję, obsługującą je ścieżkę chłodzenia oraz obciążenia i dzierżawców, którzy od nich zależą. |
| Charakterystyka awarii | Awarie komponentów, takie jak uszkodzony dysk, uszkodzony zasilacz czy błąd pamięci, ograniczają się zwykle do jednej maszyny. | Pojedynczy węzeł o obniżonej sprawności może zablokować rozproszone zadanie treningowe obejmujące wiele węzłów, dlatego pytanie operacyjne brzmi: które obciążenia zostały dotknięte, a nie który serwer uległ awarii. |
| Interwał zbierania danych | Interwały odpytywania zaprojektowane dla obciążeń w stanie ustalonym są na ogół wystarczające. | Obciążenie pojawia się i znika skokowo wraz z uruchamianiem i kończeniem zadań. Interwały odpowiednie dla środowiska w stanie ustalonym mogą pominąć przejściowe warunki termiczne i zasilania, które mają największe znaczenie. |
| Zakres korelacji | Dane obiektowe i monitoring IT są często zarządzane przez odrębne zespoły i odrębne narzędzia, co zwykle nie powoduje większych trudności. | Dane o mocy obliczeniowej, sieci, pamięci masowej i obiekcie trzeba odczytywać na jednej osi czasu, ponieważ wyjaśnienie zmiany wydajności często znajduje się w innym obszarze niż objaw. |
Praktyczna konsekwencja jest taka, że DCIM dla klastra AI nie może pozostać wyłącznie dyscypliną obiektową. Zasilanie szaf rack, stan chłodzenia i pojemność fizyczną trzeba odczytywać obok kondycji akceleratorów i kontekstu obciążeń — na tym polega model korelacji opisany na tej stronie.
Stworzone do współpracy między zespołami
Wydajność obciążeń AI obejmuje wiele obszarów technicznych. Sensaka zapewnia zespołom GPU, platformy, sieci, pamięci masowej i centrum danych wspólny widok analityczny.
Zespoły mogą pracować na tej samej osi czasu zdarzeń, tych samych powiązaniach infrastruktury i tym samym kontekście dotkniętego obciążenia. Zmniejsza to konieczność powtarzania zbierania danych i pomaga każdemu zespołowi zrozumieć, jak jego część infrastruktury wpływa na ostateczny wynik obciążenia.
Wszystko, czego potrzebuje model korelacji
Obserwowalność sięgająca warstwy fizycznej
Wiele platform obserwowalności zaczyna się powyżej systemu operacyjnego. Sensaka rozszerza widok operacyjny na fizyczną warstwę infrastruktury AI. Platforma łączy metryki programowe z danymi serwerów, akceleratorów, sieci, pamięci masowej, zasilania, chłodzenia i BMC od wielu producentów. Pomaga to operatorom dostrzec stan sprzętu i obiektu, który może pozostać niewidoczny dla samego monitoringu Kubernetes lub aplikacji.
Sensaka łączy również obserwowalność z powiązaniami infrastruktury, kontekstem obciążeń i procesami operacyjnymi. Celem jest praktyczna ścieżka analizy prowadząca od objawu problemu z wydajnością do dotkniętych zasobów, prawdopodobnej przyczyny i kolejnego działania.
Najczęściej zadawane pytania
Czym jest obserwowalność infrastruktury AI?
Obserwowalność infrastruktury AI to zdolność do rozumienia, w jaki sposób stan GPU, kontenerów, węzłów, sieci, pamięci masowej i infrastruktury fizycznej wpływa na obciążenia treningowe i wnioskowania AI. Wymaga korelacji między tymi obszarami, a nie odizolowanych pulpitów monitoringu.
Czym różni się to od monitoringu GPU?
Monitoring GPU koncentruje się przede wszystkim na metrykach akceleratorów. Sensaka dodaje powiązania obciążeń, komunikację sieciową, dostarczanie danych z pamięci masowej, kondycję sprzętową węzłów oraz kontekst zasilania, temperatury i chłodzenia, aby pomóc wyjaśnić przyczyny zmian wydajności GPU.
Czy Sensaka monitoruje sieci RoCE i RDMA?
Sensaka obsługuje zbieranie i analizę parametrów sieciowych, takich jak utrata pakietów, retransmisja, opóźnienia i stan portów. Dokładne wskaźniki i sposób integracji zależą od sprzętu sieciowego oraz interfejsów telemetrycznych dostępnych w środowisku klienta.
Czy Sensaka automatycznie identyfikuje przyczynę źródłową?
Sensaka koreluje dowody, wskazuje prawdopodobne obszary wąskich gardeł i udostępnia ścieżkę analizy oraz rekomendacji. Ostateczna diagnoza i wszelkie działania operacyjne powinny być zgodne z wymaganiami klienta dotyczącymi zatwierdzania, zmian i audytu.
Czy sprzęt można monitorować, gdy system operacyjny jest niedostępny?
Tam, gdzie obsługuje to serwer, Sensaka może zbierać informacje sprzętowe za pomocą interfejsów zarządzania out-of-band, takich jak Redfish i IPMI. Ta ścieżka monitoringu działa niezależnie od produkcyjnego systemu operacyjnego.
Dla jakich środowisk przeznaczone jest to rozwiązanie?
Rozwiązanie zostało zaprojektowane dla korporacyjnych centrów danych AI, publicznych centrów obliczeniowych, klastrów badawczych oraz wielodzierżawczych środowisk GPU, które potrzebują wspólnego widoku operacyjnego obejmującego moc obliczeniową, sieć, pamięć masową i infrastrukturę fizyczną.
Znajdowanie rzeczywistej przyczyny problemów z wydajnością GPU
Przejście od odizolowanych wykresów wykorzystania do połączonego widoku infrastruktury stojącej za każdym obciążeniem.
Powiązane: Pomiar zużycia GPU, CMDB infrastruktury AI, Monitoring chłodzenia cieczą