Dlaczego lokalne środowisko uruchomieniowe AI rezerwuje pamięć po zakończeniu żądania?
Lokalne środowisko uruchomieniowe AI rezerwuje pamięć po zakończeniu żądania, aby przyszłe tensory mogły ponownie wykorzystywać bloki urządzenia bez ponoszenia kosztów wielokrotnej alokacji i synchronizacji.
Widoczny efekt może przypominać wyciek pamięci: obciążenie obliczeniowe GPU spada do zera, odpowiedź jest kompletna, ale proces nadal zajmuje większość pamięci akceleratora. Część tego zajęcia mogą stanowić aktywne wagi modelu lub stan KV, a inna część może należeć do alokatora pamięci podręcznej, kontekstu wykonania, przechwyconego grafu, obszaru roboczego biblioteki albo zasad podtrzymywania modelu. Poniższe sekcje rozróżniają aktywne alokacje od wielokrotnego użytku rezerwacji i pokazują, kiedy utrzymywanie pamięci jest normalne, nieefektywne lub wskazuje na rzeczywisty wyciek.
Alokacja pamięci urządzenia jest na tyle kosztowna, że warto ją buforować
Żądania wielokrotnie tworzą i zwalniają tensory. Zwracanie każdego bloku do sterownika może powodować synchronizację i sprawiać, że przy następnym żądaniu trzeba będzie ponownie odtworzyć ten sam układ pamięci.
Alokator CUDA biblioteki PyTorch oddziela bloki alokatora z pamięcią podręczną od tensorów, które pozostają aktywnie zaalokowane.
Przechowywanie wolnych bloków w procesie poprawia opóźnienia przy obsłudze kolejnych żądań, ale inna usługa AI nie może użyć tych bajtów, dopóki alokator nie zwolni ich do sterownika.
Pamięć zaalokowana, zarezerwowana i wolna na urządzeniu to różne miary
Zaalokowana pamięć należy do aktywnych tensorów. Zarezerwowana pamięć jest zarządzana przez alokator środowiska uruchomieniowego i może obejmować zarówno aktywne alokacje, jak i aktualnie niewykorzystywane bloki wielokrotnego użytku.
Dlatego środowisko uruchomieniowe może wykazywać lukę między pamięcią zaalokowaną a zarezerwowaną nawet po zniszczeniu tymczasowych tensorów.
Narzędzia urządzenia, takie jak nvidia-smi, raportują widoczne dla sterownika zajęcie procesu, a nie informację o tym, które bloki są logicznie wolne wewnątrz frameworka.
Stan modelu i środowiska uruchomieniowego może celowo pozostać rozgrzany
Proces może przechowywać wagi modelu, stan tokenizera, kernele, grafy wykonania i konteksty akceleratora w gotowości, ponieważ ich zwolnienie zmieniłoby kolejne żądanie w zimny start.
Wyjaśnienie obecności modelu w pamięci przygotowane przez ZimaSpace pokazuje, dlaczego rozgrzana usługa zużywa pamięć nawet wtedy, gdy żaden użytkownik nie generuje aktualnie tokenów.
To celowy kompromis między pojemnością a opóźnieniem. Z perspektywy obliczeń pamięć jest bezczynna, ale nadal cenna jako gotowy stan.
Fragmentacja może sprawić, że zarezerwowane bloki będą trudne do ponownego wykorzystania
Pula może zawierać łącznie wystarczająco dużo niewykorzystanych bajtów, ale rozmiary jej bloków mogą nie pasować do kolejnego żądania. Zmienne prompty, rozmiary obrazów, partie danych i przełączanie modeli mogą prowadzić do fragmentacji rezerwacji.
Badania GMLake dotyczą fragmentacji alokatora powodowanej nieregularnymi rozmiarami alokacji.
W takim przypadku zatrzymana pamięć nie jest ani aktywnie użyteczna, ani dostępna dla innych procesów, a ponowne uruchomienie procesu może tymczasowo przywrócić uporządkowany układ.
Sprawdź, czy zajęcie pamięci stabilizuje się, czy rośnie
Wielokrotnie wykonaj to samo, niezmienne żądanie i po każdym zakończeniu zapisz wartości pamięci zaalokowanej, zarezerwowanej, pamięci podręcznej KV, wag modelu oraz pamięci wolnej na urządzeniu.
Stabilny wysoki poziom zajęcia sugeruje normalne buforowanie lub działanie funkcji podtrzymywania modelu. Zajęcie rosnące przy każdym identycznym żądaniu i nigdy niewykorzystujące ponownie starych bloków sugeruje wyciek, nieograniczoną pamięć podręczną, zachowaną sesję lub zmienność obciążenia.
Elementy sterujące zwalnianiem pamięci podręcznej testuj dopiero po potwierdzeniu, który stan usuwają. Opróżnienie nieużywanych bloków alokatora nie zwolni aktywnych wag modelu, a wyładowanie modelu może pogorszyć czas odpowiedzi.
W przypadku domowego serwera obsługującego wiele usług określ budżet pamięci i zasady bezczynności dla każdego środowiska uruchomieniowego, aby rezerwacja jednej usługi nie uniemożliwiła po cichu uruchomienia innej.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Dlaczego przewidywania dotyczące inteligentnego domu stają się mniej trafne po sezonowych zmianach rutyny?
Sezonowe rutyny zmieniają zależność między czasem, czujnikami, obecnością domowników a pożądanymi działaniami, przez co model wytrenowany na podstawie wcześniejszych nawyków staje się nieaktualny.
Dlaczego domowy rejestrator NVR pomija krótkie zdarzenia, gdy włączone jest śledzenie obiektów?
Śledzenie wymaga wystarczającej liczby detekcji, aby rozpocząć i potwierdzić trajektorię, dlatego obiekt obecny przez krótki czas może zniknąć, zanim rejestrator NVR utworzy prawidłowe zdarzenie.
Dlaczego etykiety zdjęć generowane przez AI zmieniają się po aktualizacji modelu?
Aktualizacja modelu zmienia sposób reprezentacji i ustalania rankingu używanych do przypisywania etykiet, dlatego to samo zdjęcie może przekroczyć inne granice semantyczne lub poziomy pewności.
