Jak domowy serwer AI dobiera modele na podstawie zapotrzebowania na 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.

How Does a Home AI Server Route Models by Memory Footprint?

Domowy serwer AI kieruje modele na podstawie zajmowanej pamięci, dopasowując każde żądanie do modelu, którego kompletny zestaw roboczy mieści się w dostępnej pamięci urządzenia.

Lokalny router może wybierać spośród małych i dużych modeli językowych, modeli embeddingowych, enkoderów obrazu, systemów mowy oraz ścieżek wykonywania na CPU lub GPU. Plik checkpointu to dopiero wartość wyjściowa. Rzeczywiste dopuszczenie zależy również od metadanych kwantyzacji, kontekstu środowiska uruchomieniowego, pamięci podręcznej KV, długości promptu, współbieżności, tokenów obrazu, tymczasowych obszarów roboczych oraz pamięci zarezerwowanej już przez inne usługi. Dobry router profiluje te koszty przed wykonaniem i wybiera model, precyzję, limit kontekstu oraz ścieżkę sprzętową, które mogą pozostać stabilne przez cały czas obsługi żądania.

Rozmiar checkpointu to tylko stała część zajmowanej pamięci

Wagi i metadane kwantyzacji tworzą przewidywalną podstawową zajętość pamięci. Środowisko uruchomieniowe dodaje następnie biblioteki, pule alokatora, grafy wykonywania, bufory wejściowe, aktywacje i stan żądania.

Przewodnik sprzętowy ZimaSpace traktuje pełne zapotrzebowanie AI na pamięć jako coś więcej niż rozmiar pliku modelu.

Router korzystający wyłącznie z rozmiaru pliku może dopuścić model, który ładuje się pomyślnie, ale zawodzi podczas długiego przetwarzania wstępnego, żądania multimodalnego lub równoczesnej rozmowy.

Każdy model potrzebuje empirycznego profilu pamięci

Dla każdego modelu i poziomu kwantyzacji należy zapisać zajętość pamięci w stanie bezczynności, szczytowe zużycie pamięci podczas przetwarzania wstępnego, liczbę bajtów na token kontekstu, precyzję KV, limity batcha, koszt tokenów wizualnych oraz rezerwę środowiska uruchomieniowego.

Badanie planowania wielomodelowego z 2026 roku charakteryzuje zachowanie modeli pod względem pamięci w różnych architekturach i na heterogenicznym sprzęcie, zamiast zakładać, że jeden wzór rozmieszczenia pasuje do każdego modelu.

Profile powinny obejmować stany zimny i ciepły, ponieważ pamięci podręczne kompilacji oraz najwyższe poziomy zajętości alokatora mogą zmienić dostępną pamięć po wcześniejszych żądaniach.

Profil należy odtworzyć po zmianie środowiska uruchomieniowego, sterownika, ustawienia kontekstu, kwantyzacji lub formatu modelu.

Router musi zarezerwować dynamiczny zapas pamięci przed dopuszczeniem żądania

Żądanie dostarcza dodatkowych informacji: długości promptu, przewidywanej długości odpowiedzi, liczby i rozdzielczości obrazów, żądanego batcha oraz bieżącej współbieżności użytkowników.

Globalny scheduler pamięci Prism dostosowuje aktywację i eksmisję modeli na podstawie informacji o obciążeniu i kolejce, zamiast korzystać ze stałych rezerwacji.

Domowy router może używać prostszego wzoru dopuszczania: wolna pamięć urządzenia pomniejszona o margines bezpieczeństwa musi być większa niż podstawowe zapotrzebowanie modelu powiększone o szacowany stan żądania i obszar roboczy.

Jeśli oszacowanie się nie mieści, router może skrócić kontekst, zmniejszyć batch, wybrać mniejszy model, zastosować niższą precyzję pamięci podręcznej, umieścić żądanie w kolejce lub przekierować je na inne urządzenie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Pełne dopasowanie do GPU, częściowe odciążenie i wykonywanie na CPU to różne ścieżki

Model, który w całości mieści się w pamięci VRAM, zwykle pozwala uniknąć powtarzających się transferów wag między pamięcią hosta a urządzeniem. Większy model może działać dzięki częściowemu odciążeniu na CPU lub pamięci współdzielonej, ale wiąże się to z innymi ograniczeniami opóźnień i przepustowości.

ATSInfer wykorzystuje rozmieszczanie na poziomie tensorów do koordynowania przechowywania, transferu i obliczeń między pamięcią konsumenckich procesorów CPU i GPU.

Router powinien odróżniać „może się wykonać” od „spełnia wymagania czasowe procesu”. Częściowo odciążony model może być odpowiedni do nocnej analizy, ale nieakceptowalny w interakcji głosowej.

Popularność i koszt ponownego ładowania wpływają na to, które modele pozostają w pamięci

Często żądane modele mogą pozostawać w stanie ciepłym, natomiast duże, rzadko używane modele mogą być przechowywane na dysku do czasu, gdy zadanie uzasadni koszt ich załadowania.

Weaver analizuje modele często i rzadko używane w systemach obsługujących wiele punktów końcowych o nierównomiernej popularności.

Żądanie może zostać skierowane do nieco mniejszego, ciepłego modelu, jeśli spełnia on wymagania jakościowe i pozwala uniknąć długiego cyklu eksmisji oraz ponownego ładowania. Trudne zadanie może uzasadniać załadowanie większego modelu, gdy oczekiwany wzrost jakości przewyższa opóźnienie.

Wymagania zadania muszą ograniczać decyzje oparte wyłącznie na pamięci

Najmniejszy ślad pamięci nie zawsze oznacza właściwą ścieżkę. Programowanie, tekst wielojęzyczny, złożone rozumowanie, OCR i planowanie narzędzi mogą wymagać funkcji niedostępnych w mniejszym modelu.

MuxServe łączy rozmieszczanie i planowanie, ponieważ wydajne udostępnianie zależy zarówno od zapotrzebowania na modele, jak i od zachowania zasobów.

Najpierw należy zdefiniować minimalny poziom wymaganych funkcji, a następnie wybrać model o najmniejszym śladzie pamięci spośród tych, które przechodzą testy jakości, bezpieczeństwa, opóźnienia i formatu wymagane w danym procesie.

Zadanie deterministycznego wyodrębniania danych może zostać skierowane do małego modelu stale obecnego w pamięci, natomiast trudne żądanie planowania może trafić do większego modelu lub zaczekać na dostępność zasobów.

Routing powinien reagować na bieżącą pamięć i historię niedawnego wykonywania

Statyczne profile nie uwzględniają każdej rezerwacji alokatora, fragmentacji pamięci, konkurencyjnego kontenera ani spowolnienia termicznego. Router potrzebuje również informacji o bieżącej wolnej pamięci, długości kolejki, modelach obecnych w pamięci i ostatnich awariach.

Badania nad planowaniem agentowych zadań CPU-GPU łączą ślady pamięci, koszt zimnego startu, historię wykonywania i dane o sprzęcie podczas przydzielania heterogenicznych zadań AI.

Należy rejestrować wybraną ścieżkę, przewidywane zużycie pamięci, rzeczywiste zużycie szczytowe, czas ładowania, opóźnienie do pierwszego tokena, szybkość generowania oraz każde przełączenie awaryjne. Profil modelu należy aktualizować, gdy błąd prognozy przekroczy zdefiniowany margines.

Routing świadomy pamięci odnosi sukces, gdy żądania pozostają w granicach stabilnej przepustowości, a serwer nadal wybiera najsilniejszy model, który może spełnić wymagania obsługi bieżącego zadania.

FAQ

Czy router może używać rozmiaru pliku modelu jako szybkiego oszacowania?

To przydatna wartość bazowa, ale przed dopuszczeniem żądania router nadal musi uwzględnić narzut środowiska uruchomieniowego, pamięć podręczną KV, prompt, batch oraz zapas bezpieczeństwa.

Czy model powinien być kierowany na CPU, gdy pamięć VRAM jest pełna?

Tylko wtedy, gdy wykonywanie na CPU lub w trybie hybrydowym spełnia wymagania zadania dotyczące opóźnienia i pamięci. Lepszym rozwiązaniem może być umieszczenie żądania w kolejce lub wybranie mniejszego modelu.

Czy routing świadomy pamięci wymaga kilku GPU?

Nie. Może wybierać między jednym GPU, wykonywaniem na CPU, częściowym odciążeniem, różnymi poziomami kwantyzacji i wieloma rozmiarami modeli na jednym domowym serwerze.