Dlaczego fragmentacja pamięci GPU może zablokować lokalny model AI?

Fragmentacja pamięci GPU może zablokować lokalny model AI, gdy wolna pamięć jest podzielona na obszary, które nie mogą spełnić kolejnego wzorca alokacji wymaganego przez środowisko uruchomieniowe.

Awaria często pojawia się po przełączaniu modeli, zmianie długości kontekstu, jednoczesnym uruchamianiu zadań związanych z obrazami i językiem lub obsłudze żądań, których tymczasowe tensory zwiększają się i zmniejszają. Monitorowanie może wskazywać nieużywaną pamięć VRAM, ale alokator nadal nie jest w stanie umieścić dużego obszaru roboczego, fragmentu modelu ani rozszerzenia pamięci podręcznej KV bez zwolnienia lub reorganizacji istniejących bloków. Poniższe sekcje rozróżniają rzeczywisty brak pojemności od fragmentacji alokatora i wyjaśniają, dlaczego ponowne uruchomienie środowiska może tymczasowo sprawić, że ten sam model znów się zmieści.

Całkowita wolna pamięć VRAM to nie to samo co dostępna przestrzeń alokacji

Monitor pamięci pokazuje łączną dostępną pojemność, ale alokator musi spełniać żądania za pomocą zarządzanych bloków i mapowań wirtualnych. Kilka małych wolnych obszarów może łącznie mieć większy rozmiar niż żądany blok, a mimo to pozostawać bezużytecznych przy zasadzie ciągłej alokacji.

Analiza operacyjna LLM opisuje ten brak zgodności wolnej pamięci, gdy pamięci podręczne KV i tensory o zmiennym rozmiarze pozostawiają luki mniejsze niż kolejne żądanie. Widoczny błąd OOM dotyczy więc nie tylko liczby bajtów, ale także ich układu.

Sterowniki i frameworki mogą również odmiennie raportować pamięć wolną na urządzeniu, zarezerwowaną, zaalokowaną i nieaktywną. Porównuj widok alokatora środowiska uruchomieniowego z użyciem pamięci na poziomie urządzenia, zamiast ufać jednej wartości zbiorczej.

Zmieniające się rozmiary tensorów z czasem tworzą luki

Obciążenia AI wielokrotnie alokują i zwalniają tensory o różnych rozmiarach na potrzeby promptów, partii, wymiarów obrazów, obszarów roboczych mechanizmu uwagi i tymczasowych konwersji. Alokator buforujący zachowuje bloki do ponownego użycia, ponieważ wielokrotne zwracanie ich sterownikowi jest kosztowne.

Badania GMLake pokazują, że nieregularne alokacje mogą pogarszać działanie pul pamięci opartych na dzieleniu bloków i powodować znaczną fragmentację w dużych modelach. Ponowne używanie bloków o dokładnie takich samych rozmiarach jest wydajne, natomiast wielokrotne dzielenie i łączenie bloków o niedopasowanych rozmiarach jest trudniejsze.

Domowy serwer, na którym przełącza się modele, jest szczególnie narażony, ponieważ środowiska językowe, dyfuzyjne, wizyjne i dźwiękowe żądają od tego samego GPU bloków o bardzo różnych kształtach.

Fragmentacja może narastać bez wycieku pamięci. Każda alokacja może ostatecznie zostać zwolniona do puli, ale kształt puli może pozostać niedopasowany do kolejnego obciążenia.

Rosnąca pamięć podręczna KV sprawia, że fragmentacja podczas inferencji jest dynamiczna

Wagi LLM pozostają względnie stabilne po załadowaniu, natomiast pamięć podręczna KV rośnie wraz z liczbą aktywnych użytkowników, długością promptu i liczbą wygenerowanych tokenów. Żądania również kończą się w różnym czasie, zwalniając nierównomiernie rozmieszczone obszary.

Mechanizm PagedAttention zaprojektowano w celu ograniczenia fragmentacji pamięci podręcznej KV poprzez przechowywanie stanu żądania w mniejszych blokach zamiast rezerwowania jednego dużego, ciągłego obszaru dla nieznanej końcowej długości sekwencji.

Problem ten różni się od fragmentacji w ogólnym alokatorze tensorów frameworka, ale oba zjawiska mogą występować jednocześnie. Menedżer stronicowanej pamięci KV nie może automatycznie kompaktować obszarów roboczych modelu ani alokacji należących do innego procesu.

Omówienie jednoczesnych kontekstów pokazuje, dlaczego model mieszczący się dla jednego użytkownika może przekroczyć granicę pamięci, gdy kilka rozmów jednocześnie się rozrasta.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zarezerwowana pamięć może sprawiać wrażenie wycieku

Alokatory frameworków często zachowują zwolnione bloki, aby przyspieszyć obsługę kolejnych żądań. Narzędzia urządzenia zaliczają te bloki do pamięci używanej przez proces, nawet jeśli bieżący model nie przechowuje w nich aktywnych tensorów.

Praktyczny poradnik dotyczący błędów OOM rozróżnia zarezerwowaną pamięć od aktywnych wymagań modelu i pamięci podręcznej. Duża różnica może wskazywać na możliwe do ponownego użycia bloki alokatora, fragmentację lub obciążenie, którego szczytowe zapotrzebowanie było wyższe niż obecne.

Wyczyszczenie pamięci podręcznej może zwrócić część bloków sterownikowi, ale nie zwolni aktywnych wag, bieżącego stanu KV, kontekstu innego procesu ani obszaru roboczego wymaganego przez kolejną operację.

Stabilne rozmiary alokacji i stronicowanie ograniczają powtarzające się awarie

Odtwórz awarię z jednym modelem, stałym limitem kontekstu, stałym rozmiarem partii i bez konkurujących usług AI. Rejestruj zaalokowaną i zarezerwowaną pamięć na poziomie procesu, wolną pamięć urządzenia, rozmiar największego żądania oraz sekwencję obciążenia poprzedzającą błąd OOM.

Mechanizm vAttention wykorzystuje mapowanie pamięci wirtualnej, aby oddzielić ciągłą wirtualną przestrzeń KV od alokacji fizycznej. Podobne rozwiązania oparte na stronicowaniu i alokacji segmentowej zmniejszają zależność od jednego fizycznie ciągłego obszaru.

W przypadku domowego serwera praktyczne rozwiązania obejmują pozostawienie zapasu VRAM, ograniczenie przełączania modeli, stosowanie stabilnych limitów kontekstu i partii, koordynowanie usług za pośrednictwem jednego środowiska uruchomieniowego oraz ponowne uruchamianie sfragmentowanego procesu podczas prac konserwacyjnych, zamiast czekania na nieudane żądanie użytkownika.

Jeśli po czystym ponownym uruchomieniu model nadal się nie mieści, głównym problemem jest prawdopodobnie rzeczywista pojemność, a nie nagromadzona fragmentacja. Zmniejsz rozmiar modelu, zajętość pamięci wynikającą z kwantyzacji, kontekst, partię lub liczbę konkurujących alokacji.