Jak Ai2 naprawiło kolejkowanie zadań na tysiącach GPU H100, B200 i B300

Ten news ukazał się 10 min po komunikacie źródła.

👁 117 przeczytań

Allen Institute for AI (Ai2) opublikował szczegółowy opis przebudowy systemu kolejkowania zadań na własnych klastrach GPU - i to, co w nim opisano, to klasyczna historia o tym, jak dobrze zaprojektowana infrastruktura potrafi rozpaść się pod presją prawdziwego użytkowania.

Ai2 zarządza tysiącami kart NVIDIA H100, B200 i B300, zorganizowanych w klastry o rozmiarach od 88 do 1024 GPU. Z tej infrastruktury korzysta około 150 wewnętrznych badaczy zajmujących się bardzo różnymi zadaniami: od trenowania dużych modeli językowych (LLM) i modeli wizualno-językowych (VLM), przez symulacje reinforcement learning dla robotyki, aż po post-training dla naukowych zastosowań agentowych. To zakres prac, który wymaga zarówno długich, stabilnych sesji treningowych, jak i szybkiego dostępu do debugowania w czasie rzeczywistym - a te dwa wymagania trudno pogodzić jednym mechanizmem priorytetów.

Tragedia wspólnych zasobów

Problem nie był nowy ani zaskakujący - popyt na czas GPU przekraczał podaż od dawna. W każdej chwili w kolejce czekały zadania wymagające łącznie 2 do 3 razy więcej kart, niż było dostępnych. Innymi słowy, na każdą wolną godzinę obliczeniową przypadały dwa lub trzy różne projekty badawcze ubiegające się o te same zasoby.

Stary system opierał się na priorytetach i pozwalał zadaniom rezygnować z preemptowalności, czyli możliwości wymuszenia ich przerwania na rzecz ważniejszego zadania. Każdy zespół miał limit jednoczesnych GPU chronionych przed przerwaniem; preemptowalne zadania mogły natomiast korzystać z bezczynnych kart ponad ten limit. Na papierze brzmi to rozsądnie. W praktyce pojawiły się przewidywalne patologie.

Pierwsza to tzw. GPU squatting - badacze „parkowali” puste zadania (no-op workloads), do których mogli się szybko podłączyć, gdy potrzebowali debugować kod. Robili to, bo uruchomienie nowego zadania z wystarczająco niskim opóźnieniem po prostu nie było możliwe. Druga patologia to inflacja priorytetów: w pewnym momencie 100% zaplanowanych zadań używało najwyższego poziomu priorytetu HIGH. Niższe priorytety zostały całkowicie wygłodzone z czasu GPU. Trzecia - może najbardziej kosztowna operacyjnie - to fakt, że inżynierowie dyżurni spędzali większość czasu odpowiedzi na zgłoszenia na ręcznym negocjowaniu wyłączenia niepreemptowalnych zadań biegnących na hostach z wykrytymi problemami sprzętowymi.

Ai2 przyznaje, że przez pewien czas nie dostrzegało źródłowej przyczyny tych problemów. Pierwsze próby naprawcze skupiały się na ściślejszej kontroli nadawania priorytetów, a następnie na obchodzeniu schedulera przez ręczne przyznawanie wybranych klastrów konkretnym projektom jako monopolu GPU. Dopiero później zespół rozpoznał w tym układzie klasyczną tragedię wspólnych zasobów - sytuację, w której każdy uczestnik, działając racjonalnie we własnym interesie, degraduje zasób wspólny w sposób, którego nikt indywidualnie nie chciał.

Rozwiązaniem okazało się zastąpienie priorytetowego schedulera systemem złożonym z trzech elementów: budżetów czasu GPU przydzielanych projektom z góry, hierarchicznego fair-share allocation oraz tzw. kontraktu na time-slicing - jawnej umowy o tym, w jakich oknach czasowych dany projekt ma prawo do zasobów. Kluczowa zmiana była jednak organizacyjna, nie tylko techniczna: debata o tym, ile czasu GPU należy się danemu projektowi badawczemu, przestała być doraźną negocjacją operacyjną, a stała się przejrzystym procesem budżetowania administracyjnego.

To rozróżnienie jest ważne dla każdego, kto zarządza współdzieloną infrastrukturą obliczeniową. Problem Ai2 nie był problemem złego algorytmu szeregowania zadań - był problemem błędnie zaprojektowanych bodźców. Kiedy badacz może zablokować GPU bez ponoszenia widocznego kosztu, zrobi to. Kiedy priorytet nie ma żadnej ceny, wszyscy ustawiają go na maksimum. Nowy system sprawia, że te decyzje mają mierzalne konsekwencje budżetowe widoczne dla całej organizacji - a to zmienia zachowanie skuteczniej niż jakikolwiek algorytm preempcji.