Co się dzieje, gdy domowy serwer AI utrzymuje wiele modeli w gotowoś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 Happens When a Home AI Server Keeps Many Models Warm? - Zima Store Online

Utrzymywanie wielu domowych modeli AI w stanie gotowości ogranicza zimne starty, ale zamienia współdzieloną pamięć w trwałe zobowiązania dotyczące wag, środowiska uruchomieniowego, pamięci podręcznej i obszaru roboczego.

Domowy serwer może utrzymywać osobne modele gotowe do obsługi czatu, embeddingów, mowy, obrazu, generowania obrazów, kodowania i automatyzacji. Każdy gotowy proces wydaje się bezczynny między żądaniami, jednak jego wagi i kontekst środowiska uruchomieniowego pozostają w pamięci, aby kolejne wywołanie mogło rozpocząć się szybko. Łączny zajmowany obszar ogranicza pamięć dostępną dla długich kontekstów, równoczesnych użytkowników, tymczasowych tensorów i usług niezwiązanych ze sztuczną inteligencją. Gdy pojemność zaczyna się kończyć, system zaczyna usuwać dane z pamięci, przenosić je do innych poziomów pamięci lub odmawiać wykonania zadań, zamieniając próbę wyeliminowania zimnych startów w nowe źródło niestabilnych opóźnień.

Każdy gotowy model zajmuje trwałą bazową część pamięci

Rezydentny model przechowuje swoje wagi w pamięci GPU, pamięci zunifikowanej lub systemowej pamięci RAM. Proces obsługujący model może również zachowywać biblioteki, konteksty wykonania, skompilowane kernele i pule alokatora.

WarmServe traktuje wstępne rozgrzewanie modelu jako problem rozmieszczania, ponieważ przygotowanie jednego modelu może zakłócać ścieżkę pamięci i uruchamiania innych modeli.

Wykorzystanie mocy obliczeniowej może być bliskie zeru, podczas gdy pamięć nadal pozostaje zajęta. Bezczynny pulpit nie oznacza więc, że urządzenie ma wystarczającą pojemność dla kolejnego gotowego modelu.

Łączna obecność modeli ogranicza zapas na kontekst i współbieżność

Wagi modeli to tylko stała baza. Aktywne prompty nadal wymagają pamięci podręcznej KV, aktywacji i tymczasowych obszarów roboczych, oprócz gotowych modeli już obecnych w pamięci.

MuxServe umieszcza modele razem na podstawie popularności modeli oraz charakterystyki wykorzystania zasobów, zamiast zakładać, że każdy model powinien pozostać w pełni niezależny i stale obecny w pamięci.

Serwer, który może przechowywać trzy bezczynne modele, może zawieść, gdy jeden użytkownik prześle długi kontekst lub uaktywni się kilku użytkowników. Bezpieczne planowanie obecności modeli musi uwzględniać dynamiczne maksimum, a nie tylko pomieścić pliki wag.

Przewodnik ZimaSpace dotyczący konkurencji o pamięć akceleratora wyjaśnia, dlaczego oddzielne usługi mogą kolidować, zanim którykolwiek proces osiągnie własny skonfigurowany limit.

Oddzielne środowiska uruchomieniowe duplikują stan, który modele mogłyby współdzielić

Jeden kontener na model może uprościć aktualizacje i izolację awarii, ale każdy proces może ładować własny kontekst akceleratora, biblioteki frameworka, rezerwę alokatora, zasoby tokenizera i współdzielone komponenty modelu.

Efektywna kosztowo obsługa wielu modeli wykorzystuje dynamiczny przydział pamięci, aby ograniczyć marnotrawstwo wynikające ze statycznych rezerwacji dla poszczególnych modeli.

Ujednolicony serwer wnioskowania może ograniczyć duplikację i koordynować obecność modeli w pamięci, ale tworzy również kompromisy związane ze zgodnością i zakresem awarii. Właściwa granica zależy od rodzin modeli, bezpieczeństwa i obsługi środowiska uruchomieniowego.

-15% OFF

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

Single board computer zimaboard2

Eksmisja zamienia presję na pamięć w opóźnienie pierwszego żądania

Gdy nowy model lub żądanie potrzebuje więcej miejsca, środowisko uruchomieniowe może wyładować nieaktywny model. Kolejne wywołanie tego modelu musi ponownie załadować wagi i odtworzyć stan wykonania.

ZimaSpace opisuje powstający w ten sposób skok opóźnienia, gdy wcześniej gotowy model przestaje być obecny w pamięci.

Jeśli kilka modeli przełącza się między sobą przy niewystarczającej ilości pamięci, serwer może wejść w stan ciągłego przeładowywania: każde żądanie usuwa z pamięci model potrzebny przy następnym żądaniu.

Dłuższe czasy utrzymywania modelu w gotowości mają sens tylko wtedy, gdy prawdopodobieństwo ponownego użycia jest wystarczająco wysokie, aby uzasadnić zajętą pamięć.

Gotowe modele mogą zakłócać działanie jeszcze przed eksmisją

Rezydentne procesy mogą zachowywać pofragmentowane bloki alokatora, zużywać przepustowość pamięci podczas równoczesnych żądań oraz zmniejszać dostępną dla aktywnych usług pojemność partii lub pamięci podręcznej KV.

AlpaServe wykorzystuje multipleksowanie statystyczne, aby rozmieszczać modele zgodnie ze skokowym zapotrzebowaniem, zamiast przeznaczać pojemność na każdy indywidualny szczyt.

Gotowy model ma również koszt alternatywny: pamięć zarezerwowana dla sporadycznie używanego modelu obrazowego nie może jednocześnie obsługiwać większej liczby użytkowników czatu ani dłuższego kontekstu.

Obecność modeli w pamięci powinna zależeć od zapotrzebowania i kosztu ponownego uruchomienia

Klasyfikuj modele według częstotliwości żądań, wrażliwości na opóźnienia, czasu ładowania, zajmowanej pamięci i akceptowalnego rozwiązania awaryjnego. Utrzymuj w pamięci małe, często używane modele głosowe lub czatowe, a rzadkie modele ładuj na żądanie.

WarmServe wykorzystuje rozmieszczanie uwzględniające eksmisję, dzięki czemu decyzje o wstępnym rozgrzewaniu uwzględniają powodowane przez nie zakłócenia.

Mierz zimne starty poszczególnych modeli, współczynnik trafień dla modeli gotowych, liczbę zajętych bajtów, maksymalne wartości aktywnego zużycia pamięci, liczbę eksmisji i częstotliwość przełączania modeli. Stosuj oddzielne limity bezczynności zamiast jednej globalnej wartości utrzymywania modelu w gotowości.

Celem nie jest wyeliminowanie wszystkich zimnych startów. Chodzi o stabilny układ, w którym modele wymagające natychmiastowej odpowiedzi pozostają gotowe, bez powodowania powtarzających się eksmisji i ograniczania pojemności potrzebnej aktywnym obciążeniom domowym.