Co powoduje, że lokalne środowisko uruchomieniowe AI ładuje duplikaty modeli?
Zduplikowane kopie modelu pojawiają się, gdy oddzielne procesy, repliki, sesje lub konteksty urządzeń nie mogą współdzielić jednej załadowanej alokacji wag.
Domowy serwer AI może wykazywać mniej więcej dwukrotnie większe użycie pamięci RAM lub VRAM po dodaniu interfejsu webowego, procesu roboczego działającego w tle, usługi głosowej, indeksatora dokumentów lub drugiego punktu końcowego API. Plik modelu na dysku może pozostać pojedynczy, podczas gdy kilka obiektów środowiska wykonawczego przechowuje niezależne wagi, przekonwertowane tensory, wstępnie spakowane kernele, pamięci podręczne i konteksty urządzeń. Część duplikacji jest przypadkowa, a inne kopie są celowymi replikami tworzonymi na potrzeby współbieżności, izolacji lub wykonywania równoległego.
Jeden plik modelu może utworzyć kilka niezależnych obiektów środowiska wykonawczego
Wczytanie z tej samej ścieżki nie oznacza, że dwie aplikacje odwołują się do jednego modelu w pamięci. Każda instancja środowiska wykonawczego może przeanalizować punkt kontrolny i przydzielić własne tensory.
Wskazówki Google Cloud dotyczące wnioskowania rozróżniają konfiguracje, które wczytują jedną kopię modelu na proces lub na maszynę wirtualną.
Jeśli użycie pamięci rośnie skokami odpowiadającymi rozmiarowi modelu wraz ze zwiększaniem liczby procesów roboczych, główną przyczyną jest replikacja instancji. Mniejsze przyrosty wskazują raczej na pamięci podręczne, alokatory lub konteksty wykonywania przypisane do poszczególnych procesów roboczych.
Serwery webowe i procesy robocze zadań często uruchamiają oddzielne procesy
Serwer frontendu, konsument kolejki, harmonogram, usługa transkrypcji i proces roboczy RAG mogą każdy importować moduł wczytujący model, nawet jeśli należą do jednego stosu Compose.
Izolacja procesów zapewnia każdej usłudze własną przestrzeń adresową. Strony pamięci CPU mogą czasami być współdzielone za pomocą mechanizmów systemu operacyjnego, ale zwykłe obiekty frameworków i alokacje GPU nie stają się automatycznie jednym współdzielonym serwerem modelu.
Duplikacja przebiega zgodnie z identyfikatorami procesów i granicami usług. Jeśli zatrzymanie jednego kontenera zwalnia w przybliżeniu jedną kopię modelu, kontener nie przekazywał jedynie żądań do centralnego środowiska wykonawczego.
Repliki obsługujące model są z założenia pojedynczymi kopiami
Systemy automatycznego skalowania zwiększają przepustowość, uruchamiając więcej replik. Replika to niezależny proces roboczy zdolny do obsługi żądań, gdy inne procesy są zajęte.
Ray Serve definiuje repliki jako niezależne kopie działające w oddzielnych procesach aktorów.
Wzrost użycia pamięci odpowiadający skokom ruchu lub zdarzeniom automatycznego skalowania jest celową replikacją, a nie wyciekiem. Przyczyną jest wybrany model współbieżności, nawet jeśli dodatkowe repliki potrzebują później czasu na zmniejszenie liczby.
Wiele sesji wnioskowania może duplikować inicjalizatory i wstępnie spakowane wagi
Aplikacja może utworzyć kilka sesji w jednym procesie na potrzeby różnych wątków, punktów końcowych, profili lub dostawców wykonywania.
Dokumentacja ONNX Runtime opisuje współdzielenie alokatorów, inicjalizatorów i wstępnie spakowanych wag między sesjami, ponieważ oddzielne sesje w przeciwnym razie zwiększają zużycie pamięci.
Jeśli jeden proces posiada kilka obiektów sesji, a użycie pamięci rośnie podczas inicjalizacji każdej sesji, zduplikowany stan znajduje się wewnątrz aplikacji, a nie między kontenerami.
Rozgałęzianie procesu nie gwarantuje współdzielenia wag akceleratora
Proces nadrzędny może wczytać model przed utworzeniem procesów roboczych i sprawiać wrażenie, że współdzieli strony pamięci CPU dzięki mechanizmowi kopiowania przy zapisie. Inicjalizacja akceleratora i zmienny stan środowiska wykonawczego komplikują to założenie.
Wskazówki PyTorch dotyczące wieloprocesowości wyjaśniają, że tensory mogą korzystać z mechanizmów pamięci współdzielonej między procesami, ale współdzielenie wymaga jawnie zaprojektowanego, zgodnego rozwiązania.
Proces roboczy, który przenosi model do GPU, zmienia wagi, tworzy pamięć podręczną lub inicjalizuje się po utworzeniu przez spawn, może przydzielić nową kopię, nawet jeśli pierwotne strony punktu kontrolnego CPU były współdzielone.
Oddzielne konteksty CUDA dodają stan urządzenia przypisany do procesu
Dwa procesy korzystające z jednego GPU zwykle działają za pośrednictwem oddzielnych kontekstów CUDA, chyba że używana jest specjalna architektura współdzielenia.
Firma NVIDIA zauważa, że wiele procesów aplikacji CUDA zazwyczaj tworzy wiele kontekstów z narzutem pamięci.
Narzut związany z kontekstem sam w sobie nie jest drugą pełną kopią modelu, ale może towarzyszyć zduplikowanym wagom, kernelom, obszarom roboczym i pamięciom podręcznym. Dlatego wzrost pamięci mniejszy niż rozmiar punktu kontrolnego również może wynikać z duplikacji procesów.
Dwie instancje środowiska wykonawczego na jednym GPU niezależnie rezerwują pamięć
Panel może uruchamiać jeden serwer modelu, podczas gdy usługa automatyzacji uruchamia drugi — oba wskazują ten sam punkt kontrolny i urządzenie.
Dokumentacja vLLM wyjaśnia, że wykorzystanie pamięci GPU jest limitem przypisanym do instancji i podaje przykład dwóch instancji dzielących pojemność jednego GPU.
Jeśli każdy punkt końcowy ma własny nasłuchujący proces, logi, harmonogram i pamięć podręczną KV, oba procesy są niezależnymi silnikami wnioskowania. Współdzielony katalog modeli zapobiega ponownemu pobieraniu plików, ale nie zapobiega duplikowaniu alokacji środowiska wykonawczego.
Przeładowania mogą pozostawić stary proces obok nowego
Mechanizmy automatycznego przeładowywania, nadzorcy, aktualizacje kroczące, nieudane zamknięcia i restarty kontroli stanu mogą uruchomić zastępczy proces, zanim stary proces roboczy zwolni model.
Ta przyczyna objawia się tymczasową lub trwałą parą niemal identycznych procesów o różnych godzinach uruchomienia. Żądania mogą trafiać tylko do nowszego procesu, podczas gdy starszy nadal zajmuje RAM lub VRAM.
Artykuł ZimaSpace wyjaśniający, dlaczego należy oddzielać stan środowiska wykonawczego AI od plików modeli, wyznacza tę granicę: jedna pamięć podręczna punktu kontrolnego może obsługiwać wiele wdrożeń, ale topologia usług nadal określa liczbę załadowanych kopii.
Najczęściej zadawane pytania
Czy jeden plik modelu na dysku oznacza, że w pamięci RAM znajduje się tylko jedna kopia?
Nie. Kilka procesów lub sesji może niezależnie odczytać ten sam plik i przydzielić własne tensory, pamięci podręczne oraz stan wykonywania.
Czy każda dodatkowa kopia jest wyciekiem pamięci?
Nie. Repliki, procesy równoległe tensorowo, środowiska awaryjne i izolowane usługi mogą celowo przydzielać dodatkowy stan. Wyciek rośnie bez odpowiadającego mu aktywnego obiektu środowiska wykonawczego.
Czy kontenery mogą automatycznie współdzielić jeden model GPU?
Nie. Kontenery mogą uzyskiwać dostęp do tego samego urządzenia i plików, ale do ponownego wykorzystania jednej załadowanej alokacji modelu potrzebują współdzielonego procesu obsługującego żądania lub jawnie zaprojektowanego rozwiązania międzyprocesowego.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Jakie funkcje umożliwiają utworzenie domowej granicy zaufania AI wokół wrażliwych plików?
Domowa granica zaufania dla AI łączy szyfrowanie danych w spoczynku, uprawnienia zgodne z zasadą najmniejszych przywilejów, sandboxing w czasie działania oraz zakresowe pobieranie danych...
Co powoduje, że prywatne wyniki wyszukiwania faworyzują często edytowane pliki?
Często edytowane pliki zyskują przewagę w rankingu, gdy każda aktualizacja dodaje sygnały świeżości, fragmentów, wersji lub interakcji bez normalizacji względem źródła.
Co powoduje, że modele obecności w inteligentnym domu mylą gości z mieszkańcami?
Goście mogą wyglądać jak domownicy, gdy system obserwuje wzorce aktywności gospodarstwa domowego, ale nie ma stabilnego sygnału tożsamości osoby, która je generuje.
