Når NVENC ikke starter: et GPU fullt av modeller, og en gjengiver som faller tilbake

Video

Vår videogjengiver kjører på samme maskin som språkmodellen som skriver manusene. En kveld ville maskinvarekoderen rett og slett ikke åpne seg: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", deretter "No capable devices found".

Hva som skjedde

Maskinen er en NVIDIA GB10-desktop, der CPU og GPU deler ett minnebasseng. Den tjener vår lokale modell via vLLM, og Studio gjengir på samme boks med ffmpeg, og bruker NVENC når det kan. Under en testkjøring klarte ikke koderen å opprette sin CUDA-kontekst. Feilen kom og gikk innen få sekunder: et kort NVENC-probe bestod, og gjengivingen rett etter mislyktes; ved neste kjøring mislyktes selve proben; ved kjøringen etter det gikk både probe og gjengivelse via NVENC.

Hvorfor

vLLM reserverer en fast andel av GPU-minnet når det starter, for modellen og dens cache. NVENC trenger litt minne av seg selv for CUDA-konteksten i hver sesjon. Når modellserveren og andre jobber ikke lar noe være igjen, kan ikke koderen starte, selv om den er en separat motor på brikken og knapt ville belaste GPU-beregningen.

Løsningen: avgjør ved koding, ikke ved probe

En probe ved oppstart forteller deg at NVENC virket et øyeblikk siden, ikke at det vil virke for neste fil. Derfor prøver Studio NVENC for hver gjengivelse, og hvis ffmpeg mislykkes, kjører den samme filtergrafikken på nytt med libx264. Den live-kanalen kjører en halvsekunds testkoding med sine live-innstillinger før hver start og bruker libx264 hvis NVENC feiler; en NVENC- eller CUDA-feil under strømmen bytter neste start til libx264. Hver ferdig video registrerer hvilken koder som lagde den, slik at en tilbakefall vises i jobbfilen i stedet for å gå ubemerket hen.

Hva tilbakefallet koster

Mindre enn vi forventet. På den samme maskinens 20-kjerners Arm-CPU gjenga libx264 12 sekunder med 1080p-video, med kamerabevegelser, innbrente undertekster og normalisering av lydstyrke, på 7,6 sekunder. For korte videoer som lages én gang om dagen, er CPU-en en helt god nok koder. GPU-en betyr mye mer for bilde-modellen enn for kodingen.

Konklusjonen

På en delt maskin bør du behandle GPU-koderen som valgfri: bruk den når den åpner seg, gå tilbake til alternativet når den ikke gjør det, og logg hvilken du brukte. Det samme gjelder alle GPU-funksjoner som trenger sin egen minneplass på en maskin der en modelltjener allerede har tatt mesteparten av den. Studio leveres med denne atferden aktivert som standard.

Oppdatert: