Czym jest rezydencja modelu i kiedy lokalna usługa AI powinna przechowywać wagi w pamięci?

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 Is Model Residency, and When Should a Local AI Service Keep Weights Loaded? - Zima Store Online

Rezydencja modelu oznacza utrzymywanie wag modelu w pamięci hosta lub akceleratora między żądaniami, dzięki czemu następna inferencja może pominąć część lub całość operacji ładowania.

Asystent domowy używany co kilka minut działa zupełnie inaczej, gdy model o rozmiarze ośmiu gigabajtów pozostaje w pamięci GPU, niż gdy za każdym razem jest odczytywany z pamięci masowej. Rezydencja może występować na kilku poziomach: w pamięci podręcznej systemu plików, mapowanych stronach hosta, przypiętej pamięci RAM lub pamięci VRAM gotowej dla jąder obliczeniowych. Utrzymywanie rozgrzanych wag skraca opóźnienie uruchamiania, ale rezerwuje deficytową pamięć i może uniemożliwić działanie innych modeli lub obciążeń.

Rezydencja wskazuje, gdzie pozostaje wielokrotnie używany stan modelu

Zimny model istnieje wyłącznie w pamięci masowej i przed inferencją musi zostać odczytany, zaalokowany, przekształcony i skopiowany. Wagi rezydujące w hoście eliminują odczyty z pamięci masowej, natomiast wagi rezydujące w akceleratorze eliminują również transfer z hosta do urządzenia i ścieżkę inicjalizacji środowiska wykonawczego. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Analiza strumieniowania modeli firmy NVIDIA oddziela ścieżkę ładowania modelu od transferu i prac inicjalizacyjnych, pokazując, dlaczego lokalizacja wag dominuje w wielu zimnych startach. Rozgrzany proces nadal może wymagać inicjalizacji tokenizera, grafu, adaptera lub pamięci podręcznej. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Rezydencja nie jest tym samym co aktywne żądanie. Model może pozostać załadowany bez pamięci podręcznej KV ani danych użytkownika, gotowy do obsługi przy jednoczesnym zużywaniu pamięci i części zasobów działających w tle. Tę granicę należy mierzyć oddzielnie, w realistycznych warunkach pracy.

Rozgrzanie występuje w całej hierarchii pamięci

System operacyjny może zachować strony modelu w pamięci podręcznej stron nawet po zakończeniu procesu, mapowanie pamięci może powodować ładowanie stron na żądanie, a proces obsługujący może przechowywać tensory w pamięci RAM lub VRAM. Każdy cieplejszy poziom zwykle zmniejsza opóźnienie, jednocześnie zużywając bardziej ograniczony zasób.

ServerlessLLM analizuje warstwowe ładowanie modeli obejmujące pamięć masową, pamięć hosta i pamięć GPU oraz planuje ładowanie w celu ograniczenia kosztu zimnego startu. Hierarchia wyjaśnia, dlaczego pozornie wyładowany model może zostać szybko uruchomiony ponownie, dopóki presja na pamięć nie usunie jego stron z pamięci podręcznej.

Kwantyzacja zmniejsza liczbę bajtów potrzebnych do utrzymania rezydencji i może pozwolić kilku wyspecjalizowanym modelom współistnieć. Może także zmieniać jądra wykonawcze i jakość, dlatego oszczędności pamięci nie należy traktować jako bezpłatnego zwiększenia pojemności. Praktyczne konsekwencje pojawiają się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Polityka eksmisji zamienia presję na pamięć w opóźnienie uruchamiania

Usługa może utrzymywać często używane modele w pamięci i usuwać te mniej aktualne według czasu ostatniego użycia, przewidywanego zapotrzebowania, priorytetu lub kosztu ładowania. Routing wielu modeli wymaga reguł dopuszczania, aby zadania działające w tle nie wypierały modelu głosowego, który musi natychmiast odpowiedzieć.

FlexGen demonstruje przenoszenie wag między GPU, CPU i pamięcią masową na potrzeby inferencji przy ograniczonych zasobach. Choć rozwiązanie jest ukierunkowane na przepustowość, jasno pokazuje podstawowy kompromis: przenoszenie wag między poziomami oszczędza deficytową pamięć, ale zwiększa koszt transferu i planowania.

Granica awarii pojawia się wtedy, gdy presja na pamięć wywołuje wymianę, restarty po błędzie braku pamięci lub ciągłe eksmisje i ponowne ładowanie. Utrzymywanie zbyt wielu wag w pamięci może sprawić, że każdy model będzie działał wolniej i mniej niezawodnie niż przy celowym rozgrzaniu mniejszego zestawu roboczego. Zależność tę należy jednoznacznie zachować w końcowym interfejsie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Ustalaj rezydencję na podstawie odstępu między ponownymi użyciami i marginesu pamięci

Zmierz czas zimnego startu oraz startu z rozgrzanym hostem i akceleratorem dla każdego modelu, a następnie zapisz odstęp między żądaniami, liczbę ładowanych bajtów, zajętość VRAM i RAM, pobór mocy w stanie bezczynności, liczbę eksmisji oraz zapotrzebowanie konkurencyjnych obciążeń. Wynik należy zatem sprawdzić względem pierwotnych danych.

Porównaj mechanizm uruchamiania z uruchamianiem z mapowaniem pamięci. Odtwórz tygodniowy przebieg żądań przy użyciu proponowanych okien podtrzymywania i priorytetów, uwzględniając skoki obciążenia, długie okresy bezczynności oraz jednoczesne żądania wielu modeli. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Utrzymuj model w pamięci, gdy uniknięte opóźnienie ładowania i częstotliwość ponownego użycia uzasadniają ochronę zajmowanej przez niego pamięci. Usuń go, gdy zarezerwowana pojemność powoduje kolejkowanie lub ciągłe eksmisje i ponowne ładowanie, zachowując awaryjny margines dla pamięci podręcznej KV i tymczasowych alokacji.