Co powoduje stopniowy wzrost zużycia pamięci przez lokalny serwer modeli między żądaniami?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Causes Local Model Server Memory to Creep Up Between Requests?

Pamięć lokalnego serwera modeli zwykle rośnie stopniowo, ponieważ pamięci podręczne i alokatory zachowują wielokrotnego użytku bloki, choć nieograniczone referencje lub wycieki natywne mogą powodować rzeczywisty wzrost.

Po każdym żądaniu do serwera domowego pulpit może pokazywać wzrost użycia RAM-u lub VRAM-u bez powrotu do pierwotnego poziomu bazowego. Środowisko uruchomieniowe może zachowywać bloki KV, wpisy prefiksów, kernele, grafy, obszary robocze i zwolnione bloki tensorów do ponownego użycia. Zmienne długości promptów mogą fragmentować pule, a logowanie, sesje, bufory obrazów lub rozszerzenia mogą bezterminowo utrzymywać obiekty, dlatego te mechanizmy wymagają odmiennych dowodów i limitów.

Alokatory pamięci podręcznej rezerwują zwolnione bloki do ponownego użycia

Frameworki GPU unikają kosztownych alokacji urządzenia, zachowując zwolnione bloki w puli należącej do procesu. Tensory aplikacji mogą już nie istnieć, podczas gdy sterownik nadal zgłasza zarezerwowaną pulę jako używaną przez serwer modeli. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Analiza alokatora wyjaśnia, jak buforowane bloki pamięci GPU zaokrąglają, dzielą, łączą i buforują bloki CUDA. Charakterystyczny sygnał to spadek pamięci zaalokowanej na tensory po żądaniu, podczas gdy pamięć zarezerwowana pozostaje wysoka, a kolejne żądania ponownie wykorzystują te bloki.

To wypłaszczenie nie oznacza automatycznie wycieku. Staje się szkodliwe, gdy pula uniemożliwia innej usłudze alokację pamięci lub nadal się powiększa przy powtarzanych żądaniach o identycznym kształcie po rozgrzaniu. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Pamięci podręczne obsługi i kształty żądań zwiększają zamierzony zestaw roboczy

Pamięci podręczne KV rosną wraz z aktywnym kontekstem, pamięci podręczne prefiksów zachowują wielokrotnego użytku prompty, a skompilowane grafy lub kernele obejmują zaobserwowane kształty partii. Nowe długości kontekstu, modalności i profile współbieżności mogą dodawać wpisy między żądaniami. Tę granicę należy mierzyć osobno w realistycznych warunkach pracy.

Badania nad fragmentacją pamięci LLM wskazują na fragmentację między przestrzeniami pamięci aktywacji i pamięci podręcznej KV podczas obsługi LLM. Ta obserwacja wyjaśnia, dlaczego całkowita zajętość może rosnąć, nawet gdy żadne pojedyncze aktywne żądanie nie jest duże. Praktyczna konsekwencja pojawia się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Rejestruj liczbę wpisów pamięci podręcznej i klasy kształtów. Wzrost, który ustaje po ustabilizowaniu się rozkładu obciążenia, oznacza ograniczone rozgrzewanie; wzrost proporcjonalny do całkowitej liczby żądań lub unikalnych identyfikatorów sesji sugeruje brak eksmisji. Ta zależność powinna pozostać jawna w końcowym interfejsie.

Zachowane obiekty CPU i bufory natywne powodują rzeczywisty, stopniowy wzrost

Historie żądań, kolejki strumieniowania, etykiety metryk, wyniki tokenizera, przesłane obrazy, przypięte bufory hosta i alokacje rozszerzeń mogą pozostać utrzymywane przez referencje po zakończeniu żądania. Migawki GPU mogą wyglądać stabilnie, podczas gdy RSS procesu nadal rośnie. Wynik należy zatem porównać z pierwotnymi dowodami.

Praktyczne badanie pamięci zaalokowanej i zarezerwowanej rozdziela sygnały pamięci zaalokowanej, zarezerwowanej i pamięci procesu. Taki warstwowy widok zapobiega błędnemu rozpoznaniu problemu z utrzymywaniem pamięci po stronie CPU jako działania alokatora GPU. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Granica awarii to jednorazowy wzrost, po którym następuje stabilny wysoki poziom. Nazywaj to wyciekiem tylko wtedy, gdy kontrolowane, identyczne żądania powodują ciągły wzrost pamięci utrzymywanej po uwzględnieniu limitów pamięci podręcznej, odśmiecania i oczekiwanych pul.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zbuduj krzywą utrzymywania pamięci dla każdego żądania

Odtwórz setki identycznych żądań, a następnie żądania o mieszanych długościach i modalnościach, rejestrując liczbę bajtów pamięci GPU zaalokowanej i zarezerwowanej, wpisy KV i prefiksów, pamięć podręczną grafów, pamięć przypiętą, RSS procesu, liczbę obiektów, sesje żądań, restarty procesów roboczych i migawki alokatora.

Użyj rezerwacji pamięci po żądaniu, aby odróżnić zamierzoną rezerwację po żądaniu. Powtórz test z każdym opcjonalnym buforem, rozszerzeniem, ścieżką przesyłania i etykietą metryki wyłączanymi osobno, utrzymując model i współbieżność bez zmian. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Zaakceptuj ograniczone rozgrzewanie, które stabilizuje się w ramach zadeklarowanego budżetu pamięci. Dodaj eksmisję, gdy liczba elementów pamięci podręcznej rośnie bez korzyści, ujednolicaj kształty żądań, gdy dominuje fragmentacja, i izoluj rzeczywisty wyciek dopiero wtedy, gdy stosy zachowanych alokacji wskażą właściciela.