Czy domowy serwer AI może udostępniać jeden model w wielu sesjach użytkowników?

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.

Tak. Jeden domowy serwer AI może załadować model raz i obsługiwać wiele sesji użytkowników. Nowoczesne serwery wnioskowania są projektowane tak, aby współdzielić kosztowne wagi modelu, jednocześnie utrzymując oddzielny stan żądań dla każdej rozmowy. Jest to znacznie oszczędniejsze pod względem pamięci niż ładowanie drugiej kopii tego samego modelu dla każdego członka rodziny.

Głównym ograniczeniem skalowania zwykle nie są wagi. Jest nim rosnąca pamięć podręczna KV, długość kontekstu, jednoczesne generowanie tokenów oraz kolejka tworzona przez aktywnych użytkowników. Obsługa wielu użytkowników jest więc w równym stopniu problemem planowania, co rozmiaru modelu.

Co właściwie jest współdzielone między użytkownikami?

                 Jeden załadowany model
                 wagi w pamięci RAM/VRAM
                         |
       +-----------------+-----------------+
       |                 |                 |
    Sesja A        Sesja B        Sesja C
   pamięć podręczna KV A        pamięć podręczna KV B        pamięć podręczna KV C
   historia A         historia B         historia C

Wagi transformera są tylko do odczytu podczas zwykłego wnioskowania, więc wiele żądań może korzystać z tej samej kopii. Każda sekwencja nadal wymaga własnego stanu tokenów i pamięci podręcznej mechanizmu uwagi.

Zasób Współdzielone? Dlaczego
Wagi modelu Tak Te same parametry obsługują wszystkie żądania
Pamięć podręczna KV Nie, z wyjątkiem kontrolowanego ponownego użycia prefiksu Zależy od każdej sekwencji
Historia rozmowy Nie Dane aplikacji/użytkownika
Tokenizer Tak To samo słownictwo modelu
Obliczenia GPU Zaplanowane Żądania współdzielą przepustowość
Uwierzytelnianie Nie Musi identyfikować każdego wywołującego

Jak serwery wnioskowania obsługują równoczesne żądania?

Różne środowiska wykonawcze udostępniają różne elementy sterujące planowaniem, ale zasada jest podobna: dopuścić kilka sekwencji, grupować zadania, gdy jest to możliwe, i umieszczać nadmiarowe żądania w kolejce.

FAQ Ollama opisuje ustawienia równoległego przetwarzania żądań i informuje, że równoległy kontekst zwiększa wymagania dotyczące pamięci. Przykład równoległego działania llama.cpp pokazuje wielu symulowanych klientów korzystających z jednego serwera modelu.

Serwery o wyższej przepustowości, takie jak vLLM, używają grupowania żądań i planowania uwzględniającego pamięć podręczną KV, aby utrzymać akceleratory w ciągłej pracy dla wielu przychodzących sekwencji.

Dlaczego długość kontekstu może zużywać więcej pamięci, niż sugeruje inny użytkownik

Załóżmy, że wagi modelu mieszczą się w pamięci VRAM z dużym zapasem. Czterech użytkowników otwiera bardzo długie rozmowy. Wagi nie zwiększają się czterokrotnie, ale pamięć podręczna KV może znacznie się powiększyć dla każdej aktywnej sekwencji.

budżet pamięci VRAM
  |
  +-- wagi modelu      stałe
  +-- pamięć podręczna KV użytkownika A    rośnie wraz z kontekstem
  +-- pamięć podręczna KV użytkownika B    rośnie wraz z kontekstem
  +-- pamięć podręczna KV użytkownika C    rośnie wraz z kontekstem
  +-- narzut środowiska wykonawczego

Dlatego stwierdzenie „model się mieści” nie wystarcza do planowania przepustowości. Systemy wieloużytkownikowe powinny ustawić maksymalną długość kontekstu, maksymalną liczbę równoczesnych sekwencji oraz ograniczoną kolejkę.

Istniejący przewodnik ZimaSpace dotyczący planowania akceleratora dla wieloużytkownikowej domowej AI omawia szerzej tę samą granicę zasobów.

Czy każdy użytkownik powinien otrzymać dedykowany proces modelu?

Zwykle nie. Osobne procesy powielają wagi i zmniejszają liczbę modeli, które mieszczą się w pamięci. Nadal mogą mieć sens, gdy:

  • użytkownicy potrzebują różnych dostrojonych modeli lub kwantyzacji;
  • silna izolacja procesów jest ważniejsza niż wydajność;
  • jedno obciążenie korzysta z niestandardowego środowiska uruchomieniowego;
  • chcesz zapewnić ścisły przydział GPU na użytkownika;
  • jeden model ma niekompatybilne wymagania dotyczące kontekstu lub próbkowania.

W przypadku rodziny lub małego zespołu korzystających z tego samego modelu zwykle prostsza jest jedna usługa wnioskowania za uwierzytelnioną aplikacją.

Przechowuj pamięć rozmów poza serwerem modelu

Serwer wnioskowania nie powinien być autorytatywną bazą danych określającą „kto co powiedział”. Historię czatów i preferencje użytkowników należy przechowywać w warstwie aplikacji przy użyciu jawnego identyfikatora użytkownika/sesji.

Przeglądarka / aplikacja
    |
    | uwierzytelniony user_id
    v
Aplikacja czatu
    |
    +-- baza historii (na użytkownika)
    +-- uprawnienia RAG
    |
    v
Współdzielony serwer modeli

Przed każdym generowaniem aplikacja zestawia wyłącznie historię i prywatny kontekst wyszukiwania, które bieżący użytkownik ma prawo przeglądać.

Ma to szczególne znaczenie w przypadku prywatnego asystenta AI na serwerze NAS, na którym ten sam serwer może zawierać osobiste dokumenty należące do kilku członków gospodarstwa domowego.

Współdzielenie pamięci podręcznej wspólnego prefiksu nie oznacza współdzielenia pamięci rozmów

Niektóre środowiska uruchomieniowe mogą ponownie wykorzystywać pamięć podręczną KV lub inne wyniki obliczeń dla wspólnych prefiksów promptów. Wspólna instrukcja systemowa lub powtarzający się prefiks dokumentu może więc zostać obliczony raz i efektywnie wykorzystany ponownie.

Tej optymalizacji nie należy mylić z zezwalaniem na włączenie prywatnego kontekstu jednego użytkownika do promptu innego użytkownika. Systemy pamięci podręcznej wymagają prawidłowej izolacji i semantyki haszowania; to uprawnienia aplikacji nadal decydują, jakie treści można przekazać do żądania.

Korzystaj ze sprawiedliwego planowania, aby jeden użytkownik nie mógł zająć całego serwera

Pojedyncze żądanie wymagające bardzo długiego wyniku może zająć moc obliczeniową dekodowania, podczas gdy inni użytkownicy czekają. Dodaj mechanizmy kontroli przyjmowania żądań, takie jak:

  • limit równoczesnych żądań na użytkownika;
  • maksymalna liczba tokenów wyjściowych;
  • maksymalne okno kontekstu;
  • globalny maksymalny limit aktywnych sekwencji;
  • limit czasu oczekiwania w kolejce;
  • priorytet dla krótkich żądań interaktywnych;
  • osobna kolejka wsadowa dla zadań wykonywanych w tle.

Interaktywny czat i nocne podsumowywanie dokumentów nie powinny konkurować przy identycznej polityce planowania.

Co się dzieje, gdy serwerowi zabraknie pamięci?

Dobra usługa odrzuca nowe zadania lub umieszcza je w kolejce, zanim akcelerator ulegnie awarii. Elementy sterujące pojemnością powinny korzystać z rzeczywiście skonfigurowanego kontekstu, a nie tylko z optymistycznej średniej.

Przeciążenie Bezpieczniejsza reakcja
Wszystkie miejsca na sekwencje są zajęte Tymczasowo umieść w kolejce
Kolejka jest zbyt długa Zwróć sygnał zajętości / ponowienia próby
Kontekst przekracza zasady Podsumuj lub odrzuć
Aktywne przetwarzanie wsadowe w tle Wstrzymaj to lub obniż jego priorytet
Pamięć bliska limitu Zmniejsz współbieżność przed wystąpieniem błędu braku pamięci

Nie zmniejszaj po cichu okna kontekstu każdego użytkownika, aż serwer przestanie się zawieszać. Zasady dotyczące kontekstu powinny być widoczne, aby użytkownicy wiedzieli, jakie informacje system może zachować.

Prywatność i uwierzytelnianie mają większe znaczenie w trybie wieloużytkownikowym

Gdy jeden model obsługuje jednego administratora, punkt końcowy dostępny wyłącznie lokalnie może wystarczyć. Gdy zaczyna z niego korzystać kilka osób, aplikacja powinna uwierzytelniać użytkowników i autoryzować ich źródła danych.

Chroń:

  • historie czatów;
  • kolekcje RAG i listy kontroli dostępu do dokumentów;
  • zapisane prompty;
  • dane uwierzytelniające narzędzi;
  • wygenerowane pliki;
  • logi i ślady.

Współdzielony proces modelu powinien widzieć wyłącznie kontekst bieżącego żądania i nie powinien stawać się wygodnym sposobem obchodzenia zwykłego modelu uprawnień serwera NAS.

Ilu użytkowników może obsłużyć jeden domowy serwer AI?

Nie ma jednej użytecznej, stałej liczby. Serwer może obsługiwać wielu zarejestrowanych użytkowników, jeśli aktywny jest tylko jeden lub dwóch, podczas gdy dwóch jednoczesnych użytkowników z długim kontekstem może wyczerpać zasoby małej karty GPU.

Przetestuj trzy scenariusze:

  1. jednego użytkownika interaktywnego;
  2. przewidywane jednoczesne obciążenie domowników;
  3. jednego intensywnego użytkownika oraz kilku krótkich żądań.

Mierz czas do wygenerowania pierwszego tokenu, liczbę tokenów na sekundę dla użytkownika, czas oczekiwania w kolejce, wykorzystanie pamięci podręcznej KV, użycie pamięci RAM/VRAM oraz odsetek nieudanych żądań.

Najczęstsze pytania

Czy użytkownicy zobaczą nawzajem swoje rozmowy, ponieważ model jest współdzielony?

Nie, jeśli aplikacja przechowuje historię rozmowy i kontekst wyszukiwania oddzielnie. Współdzielenie wag modelu nie oznacza automatycznego współdzielenia historii czatu.

Czy równoległe wnioskowanie przyspiesza działanie dla każdego użytkownika?

Może to zwiększyć całkowitą przepustowość, ale każde pojedyncze żądanie może otrzymać mniej mocy obliczeniowej, gdy aktywnych jest kilka sekwencji. Celem jest zazwyczaj lepsza łączna obsługa i krótszy czas oczekiwania w kolejce.

Czy jeden serwer może również obsługiwać kilka modeli?

Tak, jeśli pozwala na to pamięć. Niektóre środowiska uruchomieniowe ładują i wyładowują modele w razie potrzeby, podczas gdy inne są zaprojektowane wokół jednego lub kilku trwałych procesów obsługujących. Planowanie wielu modeli dodaje kolejną warstwę zarządzania przepustowością ponad planowanie dla wielu użytkowników.

Ostateczny werdykt

Jeden załadowany model to zazwyczaj dokładnie zasób, który mała domowa usługa AI powinna współdzielić. Współdziel wagi modelu, odizoluj historię sesji i stan KV, uwierzytelniaj każdego użytkownika, ograniczaj kontekst i współbieżność oraz planuj zadania w tle oddzielnie od interaktywnego czatu. Wieloużytkownikowa sztuczna inteligencja staje się niezawodna, gdy uwzględnisz stan poszczególnych sesji i zachowanie kolejki, zamiast zwielokrotniać proces modelu.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.