Czy lokalna usługa AI może przełączyć się awaryjnie na procesor, gdy pamięć GPU jest pełna?

Tak, ale niezawodne przełączanie awaryjne na CPU trzeba zaprojektować, zanim pamięć GPU się zapełni; większość procesów inferencji nie odzyskuje automatycznie działania po nieoczekiwanym błędzie OOM.

Domowy serwer AI może szybko odpowiadać na GPU, dopóki dłuższy prompt, większy batch, żądanie obrazu lub drugi model nie zużyje pozostałej pamięci VRAM. Następna alokacja może się nie powieść, mimo że pamięć RAM i procesor pozostają bezczynne. To, czy żądanie zostanie zrealizowane, zależy od środowiska uruchomieniowego: niektóre mogą od początku umieszczać wagi na CPU, podczas gdy inne wymagają osobnego workera CPU i routera, który bezpiecznie ponowi próbę.

Offload na CPU i przełączanie awaryjne na CPU rozwiązują różne problemy

Offload na CPU to strategia rozmieszczania modelu. Wybrane warstwy, tensory lub komponenty potoku znajdują się w pamięci RAM i w razie potrzeby są przenoszone do akceleratora, co zmniejsza ilość pamięci VRAM potrzebną do obsługi standardowego żądania. Przełączanie awaryjne na CPU to zachowanie usługi: gdy ścieżka GPU jest niedostępna lub odrzuca żądanie, inny worker je przyjmuje i uruchamia model zgodny z CPU, nie tracąc zadania.

Biblioteka Hugging Face Accelerate udostępnia metody offloadu na CPU, które celowo przenoszą stan modelu między pamięcią CPU a urządzeniem wykonawczym. To zaplanowane wykonywanie heterogeniczne, a nie awaryjna reakcja po nieokreślonej awarii stanu CUDA. Model, mapa urządzeń, hooki i budżet pamięci są przygotowywane przed rozpoczęciem inferencji.

Model częściowo przeniesiony na CPU może już korzystać z CPU, a jednocześnie nadal wymagać GPU przy generowaniu każdego tokenu. Jeśli GPU ulegnie awarii, taki proces niekoniecznie będzie mógł kontynuować działanie na CPU od przerwanego tokenu. Prawdziwe przełączanie awaryjne zwykle uruchamia żądanie ponownie na workerze gotowym do pracy na CPU. To wyjaśnia, dlaczego aplikacja może deklarować obsługę CPU, a mimo to zwracać błąd OOM zamiast dokończyć bieżące żądanie.

Pamięć VRAM może zapełnić się po pomyślnym załadowaniu modelu

Wagi modelu to tylko jeden z elementów budżetu pamięci. Pamięć klucz-wartość rośnie wraz z aktywną długością sekwencji i współbieżnością, tymczasowe kernele potrzebują przestrzeni roboczej, enkodery obrazu lub dźwięku dodają tensory, a alokator pamięci może rezerwować bloki do ponownego użycia. Dlatego model, który mieści się podczas uruchamiania, może zawieść przy długim kontekście lub kilku jednoczesnych użytkownikach.

PyTorch korzysta z alokatora pamięci z pamięcią podręczną, dlatego pamięć zgłaszana jako zarezerwowana nie jest tym samym co pamięć aktywnych tensorów. Fragmentacja i alokacje wykonywane poza frameworkiem mogą dodatkowo zmniejszyć dostępną rezerwę. Wyzwalacz przełączania awaryjnego powinien monitorować odrzucone alokacje i stan workera, a nie oceniać bezpieczeństwo na podstawie jednej liczby z panelu ani samego faktu, że ładowanie modelu zakończyło się powodzeniem.

Dlatego statyczna zasada „rozmiar modelu jest mniejszy niż VRAM” jest niepełna. Usługa może ustawić niższy limit kontekstu, ograniczyć liczbę współbieżnych sekwencji lub pozostawić niewykorzystany procent pamięci VRAM, aby chronić alokacje wykonywane w czasie działania. Te mechanizmy zapobiegają większej liczbie awarii niż reaktywne przełączanie na CPU, ponieważ utrzymują proces GPU w znanym stanie i zapewniają przewidywalne opóźnienia zaakceptowanych żądań.

Automatyczne ponowienie jest bezpieczne tylko wtedy, gdy żądanie można odtworzyć

Po błędzie OOM router może oznaczyć workera GPU jako niesprawnego, zwolnić go lub uruchomić ponownie, a następnie odtworzyć oryginalne żądanie na workerze CPU. Działa to w przypadku standardowego generowania tekstu, jeśli nie wystąpił żaden zewnętrzny efekt uboczny. Jest trudniejsze w przypadku odpowiedzi strumieniowanych, potoków obrazów z losowymi ziarnami lub agentów, którzy mogli już wywołać narzędzie.

Frameworki mogą również od początku rozdzielać duże modele między urządzenia. Funkcja inferencji dużych modeli w Accelerate obsługuje mapy urządzeń oraz umieszczanie danych na CPU lub dysku, gdy model przekracza możliwości jednego urządzenia. Takie podejście może utrzymać żądanie w ramach jednego zaplanowanego grafu wykonania, ale odbywa się to kosztem szybkości na rzecz pojemności i nie należy mylić go z przekierowaniem nieudanego żądania do osobnej usługi.

Założenie o przełączaniu awaryjnym przestaje obowiązywać, gdy CPU nie ma wystarczającej ilości pamięci RAM, środowisko uruchomieniowe nie ma zgodnych kerneli CPU, żądanie doprowadziło już do nieodwracalnego działania lub oczekiwane opóźnienie CPU przekracza limit czasu klienta. W takich przypadkach należy zwrócić kontrolowany błąd braku zasobów albo umieścić żądanie w kolejce. Ciche ponawianie może powielić skutki uboczne lub sprawić, że użytkownicy będą czekać znacznie dłużej, niż obiecuje interfejs.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź przełączanie awaryjne za pomocą celowego testu pamięci

Uruchom jednego workera GPU i jednego workera CPU za routerem, a następnie wyślij żądanie przekraczające profil GPU, ale mieszczące się w pamięci RAM systemu. Zarejestruj pierwszą awarię, decyzję o ponowieniu, czas rozpoczęcia pracy CPU, końcowy wynik oraz to, czy połączenie z klientem zostało utrzymane. Najpierw powtórz test przy wyłączonym strumieniowaniu, a następnie sprawdź anulowanie, ruch współbieżny i żądanie agenta z zamockowanym narzędziem.

Częściowe wykonywanie na GPU jest przydatnym punktem odniesienia, ponieważ środowiska takie jak inferencja llama.cpp mogą umieszczać konfigurowalną część pracy modelu na akceleratorach, zachowując możliwość wykonywania na CPU. Porównaj profile modelu w całości znajdującego się na GPU, zaplanowanego podziału CPU/GPU oraz niezależnego awaryjnego profilu CPU. Model hybrydowych obciążeń AI pomaga oddzielić awaryjne zwiększanie pojemności od standardowego przekierowywania do chmury.

Uznaj projekt za niezawodny tylko wtedy, gdy ponowienie kończy się dokładnie raz, zachowuje tożsamość żądania, nie powiela działań narzędzi i przywraca workera GPU bez przerywania niezwiązanych z nim zadań. Jeśli wykonanie na CPU jest zbyt wolne, używaj go jako ścieżki bezpieczeństwa zachowującej żądania w kolejce, a nie jako interaktywnego odpowiednika. Celem operacyjnym jest kontrolowane pogorszenie jakości usługi, a nie udawanie, że poziomy usług CPU i GPU są wymienne.

Najczęściej zadawane pytania

Czy wyczyszczenie pamięci podręcznej GPU zapewnia przełączanie awaryjne?

Nie. Zwolnienie pamięci podręcznej może udostępnić niewykorzystane zarezerwowane bloki, ale nie zapewnia wykonywania na CPU, nie naprawia uszkodzonego stanu żądania ani nie gwarantuje wystarczającej ilości ciągłej pamięci do następnej alokacji.

Czy awaryjne wykonanie na CPU zwróci taką samą odpowiedź?

Może, jeśli użyte zostaną te same wagi, precyzja, prompt, tokenizator i stan próbkowania. Różne kernele, kwantyzacja, ziarna losowe lub ponowne uruchomienie stanu strumieniowania nadal mogą zmienić dokładny wynik.

Czy mniejszy model jest lepszy niż przełączanie awaryjne na CPU?

Często w przypadku usług interaktywnych. Mniejszy model GPU może zapewnić przewidywalne opóźnienia, podczas gdy przełączanie awaryjne na CPU chroni dostępność w przypadku wyjątkowych żądań. Te dwa mechanizmy służą różnym celom usługowym i można je łączyć.