Kiedy NVENC nie chce wystartować: GPU zapełnione modelami i renderer, który przechodzi w tryb awaryjny
Wideo
Nasz renderer wideo działa na tej samej maszynie co model językowy, który pisze dla niego skrypty. Pewnego wieczoru enkoder sprzętowy po prostu nie chciał się otworzyć: „CUDA_ERROR_OUT_OF_MEMORY: out of memory”, a następnie „No capable devices found”.
Co się stało
Maszyna to desktop NVIDIA GB10, którego CPU i GPU współdzielą jedną pulę pamięci. Obsługuje on nasz lokalny model przez vLLM, a Studio renderuje na tej samej maszynie z użyciem ffmpeg, korzystając z NVENC, gdy tylko może. Podczas testowego przebiegu enkoderowi nie udało się utworzyć kontekstu CUDA. Awaria pojawiała się i znikała w ciągu kilku sekund: krótki test NVENC przechodził, a renderowanie tuż po nim kończyło się błędem; przy następnym przebiegu sam test się nie udawał; przy kolejnym zarówno test, jak i renderowanie przechodziły przez NVENC.
Dlaczego
vLLM rezerwuje stałą część pamięci GPU przy starcie, na model i jego cache. NVENC potrzebuje odrobiny własnej pamięci na kontekst CUDA dla każdej sesji. Gdy serwer modeli i inne zadania nie zostawiają nic wolnego, enkoder nie może wystartować, mimo że jest osobnym silnikiem na chipie i ledwie obciąża obliczenia GPU.
Rozwiązanie: decyduj przy enkodowaniu, a nie przy teście wstępnym
Test przy starcie mówi, że NVENC działał chwilę temu, a nie że zadziała dla następnego pliku. Dlatego Studio próbuje użyć NVENC dla każdego renderowania i, jeśli ffmpeg zawiedzie, ponownie uruchamia ten sam graf filtrów z libx264. Kanał na żywo wykonuje półsekundowy test enkodowania z ustawieniami na żywo przed każdym startem i używa libx264, jeśli NVENC nie zda tego testu; błąd NVENC lub CUDA podczas streamingu przełącza następny start na libx264. Każdy gotowy film zapisuje informację, który enkoder go wygenerował, dzięki czemu przejście w tryb awaryjny jest widoczne w pliku zadania, a nie przechodzi niezauważone.
Ile kosztuje tryb awaryjny
Mniej, niż się spodziewaliśmy. Na 20-rdzeniowym procesorze Arm tej samej maszyny libx264 wyrenderował 12 sekund wideo 1080p, z ruchami kamery, wypalonymi napisami i normalizacją głośności, w 7,6 sekundy. Dla krótkich filmów tworzonych raz dziennie CPU jest całkowicie wystarczającym enkoderem. GPU ma znacznie większe znaczenie dla modelu obrazowego niż dla enkodowania.
Wniosek
Na współdzielonej maszynie traktuj enkoder GPU jako opcjonalny: używaj go, gdy jest dostępny, korzystaj z alternatywy, gdy nie jest, i loguj, którego użyto. Dotyczy to również każdej funkcji GPU wymagającej własnej pamięci na maszynie, na której serwer modeli zajął już większość zasobów. Studio ma to zachowanie domyślnie włączone.