Jakie funkcje umożliwiają przełączanie awaryjne z GPU na CPU w lokalnej usłudze AI?

Przełączenie awaryjne z GPU na CPU działa tylko wtedy, gdy usługa wcześniej zaplanuje zgodną alternatywną ścieżkę wykonywania, zanim wyczerpanie pamięci przerwie aktywne żądanie.

Domowy serwer AI może obsługiwać transkrypcję, wyszukiwanie obrazów i LLM na jednym akceleratorze, dopóki długi prompt nie przekroczy bezpiecznego limitu pamięci. Samo przechwycenie błędu braku pamięci następuje zbyt późno, jeśli stan modelu jest niespójny. Niezawodne przełączanie awaryjne łączy kontrolę przyjmowania żądań, zgodne wagi CPU, możliwy do przeniesienia stan żądania, ograniczone kolejki, sygnały kondycji oraz jasno określoną politykę ograniczonej funkcjonalności usługi.

Kontrola przyjmowania żądań wykrywa przeciążenie przed nieudaną alokacją

Brama szacuje rozmiar wag modelu, wzrost pamięci podręcznej KV, tensory tymczasowe, rozmiar partii i fragmentację pamięci przed zaakceptowaniem żądania GPU. Zarezerwowana rezerwa chroni kernele i równoległe obciążenia, a próg przeciążenia decyduje, czy żądanie opóźnić, zmniejszyć, przenieść do pamięci zewnętrznej lub przekierować.

stronicowana pamięć KV traktuje pamięć GPU jako stronicowane bloki, dzięki czemu obsługa może ograniczyć fragmentację i wydajniej współdzielić pojemność pamięci podręcznej KV. Podnosi to bezpieczny limit działania, ale nie tworzy nieograniczonej pamięci ani nie zastępuje jawnej ścieżki obsługi przepełnienia.

Rzeczywista decyzja o przełączeniu awaryjnym wykorzystuje zarówno przewidywane, jak i zaobserwowane zużycie. Same odczyty wolnej pamięci mogą wprowadzać w błąd, ponieważ alokatory pamięci podręcznej, oczekujące kernele i rezerwa innej usługi mogą zająć miejsce po sprawdzeniu, ale przed następną alokacją.

Ścieżka CPU musi odtworzyć zgodny stan modelu

Wykonywanie na CPU wymaga tego samego tokenizera, tej samej wersji modelu, semantyki kwantyzacji, szablonu promptu, ustawień próbkowania i reguł zatrzymywania co ścieżka GPU. Usługa może utrzymywać ciepłą replikę CPU, mapować wagi do pamięci lub ładować je na żądanie, zależnie od założonego budżetu czasu odzyskiwania.

hybrydowe wnioskowanie CPU-GPU pokazuje hybrydowe wnioskowanie wykorzystujące przewidywalną rzadkość aktywacji między CPU i GPU na sprzęcie konsumenckim. Jego projekt pokazuje, że udział CPU można zaplanować jako tryb wykonywania, zamiast traktować go wyłącznie jako awaryjną kopię.

Żądania, które zdążyły już wygenerować tokeny, trudniej przenieść, ponieważ ich pamięć podręczna KV i stan losowy muszą zostać przesłane albo obliczone ponownie. Wiele usług domowych powinno więc przełączać żądania na granicach ich obsługi i ponawiać je w sposób idempotentny, zamiast obiecywać płynną migrację w połowie generowania tokenu.

Kondycja, kolejki i tryb ograniczonej funkcjonalności ograniczają skutki awarii

Wyłącznik automatyczny oznacza GPU jako niedostępne po powtarzających się błędach alokacji, resetach sterownika lub nieudanych testach kondycji. Nowe zadania trafiają do osobnej kolejki CPU z mniejszą równoległością, krótszymi limitami kontekstu lub mniejszym modelem awaryjnym, aby wolne żądania nie doprowadziły do przeciążenia hosta.

warstwowe rozmieszczanie wnioskowania koordynuje rozmieszczenie na CPU, GPU i w pamięci masowej, aby uruchamiać modele przekraczające pojemność pamięci akceleratora. Wyniki pokazują dużą różnicę opóźnień między zmieszczeniem modelu w szybkiej pamięci a korzystaniem z wolniejszych warstw. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Granica awarii polega na udawaniu, że przełączenie na CPU zachowuje ten sam poziom usług. Model, który na GPU działa przez 20 sekund, może potrzebować na CPU kilku minut, a nieobsługiwane kernele mogą w ogóle nie działać. Interfejs powinien ujawniać model awaryjny, limity, szacowane opóźnienie i możliwość anulowania, zamiast po cichu pozostawiać żądanie w stanie oczekiwania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź przełączanie awaryjne pod kontrolowanym obciążeniem pamięci

Odtwórz krótkie prompty, długie prompty, równoległe żądania oraz inne obciążenie GPU, stopniowo zmniejszając dostępną pamięć. Wywołaj przekierowanie przed przyjęciem żądania, błąd alokacji przed rozpoczęciem generowania, reset sterownika oraz anulowanie podczas oczekiwania w kolejce CPU. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja podejmie dalsze działania.

Porównaj wyniki z granicą awaryjnego przełączania opisaną w awaryjnym przełączaniu przy pełnej pamięci GPU. Zapisz wskaźnik powodzenia, zduplikowane skutki uboczne, zgodność tokenów tam, gdzie jest oczekiwana, opóźnienie p95, wiek żądania w kolejce, zużycie pamięci RAM hosta, czas odzyskiwania oraz informację, czy użytkownik zobaczył status trybu ograniczonej funkcjonalności.

Test uznaj za zaliczony tylko wtedy, gdy żadne zaakceptowane żądanie nie znika, a przekierowanie na CPU nie może wyczerpać pamięci systemowej. Jeśli migracja w trakcie żądania zmienia wynik lub powtarza działanie narzędzia, ogranicz przełączanie awaryjne do bezpiecznych punktów kontrolnych, a w pozostałych przypadkach zwracaj błąd umożliwiający wznowienie.