Dlaczego skonteneryzowane modele AI uruchamiają się ponownie, nawet gdy host zgłasza dostępną pamięć?

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.

Why Do Containerized AI Models Restart Even When the Host Reports Free Memory? - Zima Store Online

Konteneryzowane modele AI mogą się restartować mimo wolnej pamięci hosta, ponieważ ich limity cgroup, akceleratora lub nadzorcy są węższe niż obejmujący całą maszynę widok pamięci RAM.

Panel serwera domowego może pokazywać kilka gigabajtów wolnej pamięci, podczas gdy kontener inferencyjny znika i wraca z nowym identyfikatorem procesu. Kontener może osiągnąć własny limit pamięci, nie przejść kontroli stanu podczas odzyskiwania pamięci, wyczerpać pamięć GPU lub zakończyć działanie po błędzie alokacji. Polityka restartu zamienia wtedy tę lokalną awarię w pozornie samoczynny restart modelu.

Kontener ma inną granicę pamięci niż host

Grupy kontrolne Linuksa ewidencjonują pamięć i nakładają jej limity na wybraną grupę procesów. Kontener może osiągnąć memory.max lub limit środowiska uruchomieniowego, gdy niezwiązana z nim pamięć RAM hosta pozostaje dostępna dla jądra, dlatego ogólnosystemowa wartość wolnej pamięci nie opisuje granicy alokacji narzuconej tej usłudze.

Szczegółowe wyjaśnienie ewidencjonowania pamięci cgroup rozdziela pamięć anonimową, mapowane pliki i pamięć podręczną obciążającą grupę kontrolną. Ta ewidencja pokazuje, dlaczego wagi mapowane z dysku, tymczasowe bufory modelu i pamięć podręczna stron mogą zużywać budżet kontenera, nawet gdy prosty widok RSS procesu wskazuje mniejszą wartość.

Limity mogą być również zagnieżdżone: kontener modelu może znajdować się w usłudze Compose, wycinku systemd, maszynie wirtualnej lub grupie orkiestracji. Najwęższa aktywna granica może uruchomić odzyskiwanie pamięci lub zakończenie procesu z powodu braku pamięci, zanim fizyczny host zbliży się do globalnego wyczerpania zasobów.

Presja pamięci może opóźnić kontrole stanu przed zakończeniem procesu z powodu OOM

W miarę zbliżania się do limitu jądro może odzyskiwać pamięć podręczną, skanować pamięć i ograniczać alokacje. Model może nadal działać, ale odpowiadać zbyt wolno dla sondy stanu, co skłania nadzorcę do jego zakończenia i uruchomienia zastępstwa bez zarejestrowania zakończenia kontenera z powodu OOM.

Struktura informacji o przestojach z powodu presji mierzy czas tracony, gdy zadania oczekują z powodu presji pamięci, CPU lub operacji wejścia-wyjścia, zamiast polegać wyłącznie na wykorzystaniu zasobów. Informacje o przestojach z powodu presji wyjaśniają, dlaczego liczba wolnych bajtów i responsywność usługi mogą się rozchodzić podczas intensywnego odzyskiwania pamięci.

Ładowanie AI powoduje skokowe piki: deserializacja może tymczasowo przechowywać skompresowane i rozwinięte wagi, kwantyzacja może alokować przestrzeń roboczą, a równoległe procesy robocze mogą duplikować bufory. Stałe zużycie po załadowaniu zaniża więc krótkotrwały szczyt, który może pokrywać się z nieudaną sondą.

Awaria GPU i polityka restartu mogą przypominać OOM hosta

Metryki pamięci hosta zwykle nie obejmują dedykowanej pamięci VRAM. Model może nie uzyskać alokacji GPU, ponieważ wagi, pamięć podręczna KV, jądra i inne obciążenie zajmują akcelerator, a następnie zakończyć działanie z błędem aplikacji, podczas gdy host nadal zgłasza dużą ilość dostępnej pamięci systemowej.

Wytyczne dotyczące zarządzania zasobami odróżniają limity pamięci kontenera od niedoboru pamięci w całym węźle i wyjaśniają, że limity są egzekwowane przez środowisko uruchomieniowe i jądro, a nie przez etykietę wolnej pamięci w panelu. Restart jest wtedy określany przez politykę restartu obciążenia, a nie przez sam pomiar pamięci.

Błędem jest zakładanie, że każdy nowy identyfikator kontenera dowodzi wystąpienia OOM. Aktualizacje obrazów, przekroczenia czasu działania watchdogów, ręczne ponowne wdrożenia, reset urządzenia i awarie aplikacji powodują ten sam widoczny objaw. Zanim przypiszesz przyczynę pamięci, muszą się ze sobą zgadzać przyczyna zakończenia, dziennik jądra, zdarzenia cgroup i błędy GPU.

-15% OFF

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

Single board computer zimaboard2

Powiąż przyczynę zakończenia z każdą granicą pamięci

Odtwórz jedno ładowanie modelu, rejestrując na jednym zegarze container memory.current, memory.max, memory.events, RSS procesu i mapowane pliki, MemAvailable hosta, wartości skumulowane informacji o przestojach z powodu presji, pamięć GPU, opóźnienie sondy stanu, kod zakończenia procesu oraz liczbę restartów nadzorcy.

Wykorzystaj konkurencję między kontenerami jako kontekst, a następnie powtórz test z tym samym modelem przy wyższym limicie kontenera, wyłączonej polityce restartu i bez konkurencyjnego obciążenia akceleratora. Zmieniaj tylko jedną granicę podczas każdego uruchomienia, aby udany restart nie ukrył pierwotnej awarii.

Przed zmianą limitów sklasyfikuj zdarzenie jako OOM cgroup, globalny OOM, błąd alokacji GPU, zakończenie przez kontrolę stanu lub zakończenie aplikacji. Jeśli szczytowe zużycie jest uzasadnione, zachowaj zapas; jeśli sonda zabija odzyskujący pamięć, ale sprawny model, dostosuj czas sondy bez maskowania rzeczywistych zawieszeń.