Wanneer NVENC niet start: een GPU vol modellen en een renderer die terugvalt
Video
Onze videorenderer draait op dezelfde machine als het taalmodel dat de scripts schrijft. Op een avond wilde de hardware-encoder simpelweg niet openen: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", daarna "No capable devices found".
Wat er gebeurde
De machine is een NVIDIA GB10-desktop, waarbij CPU en GPU één geheugenpool delen. Hij bedient ons lokale model via vLLM, en Studio rendert op dezelfde box met ffmpeg, waarbij NVENC wordt gebruikt wanneer mogelijk. Tijdens een testrun kon de encoder zijn CUDA-context niet aanmaken. De fout kwam en ging binnen enkele seconden: een korte NVENC-probe slaagde en de render direct daarna mislukte; bij de volgende run mislukte de probe zelf; bij de run daarna gingen zowel probe als render via NVENC.
Waarom
vLLM reserveert bij het opstarten een vast deel van het GPU-geheugen voor het model en de cache. NVENC heeft voor elke sessie een beetje eigen geheugen nodig voor de CUDA-context. Wanneer de modelserver en andere taken niets overlaten, kan de encoder niet starten, ook al is het een aparte engine op de chip die de GPU-compute nauwelijks zou belasten.
De oplossing: beslissen bij de encode, niet bij de probe
Een probe bij het opstarten vertelt je dat NVENC even geleden werkte, niet dat het voor het volgende bestand zal werken. Daarom probeert Studio NVENC voor elke render en voert, als ffmpeg faalt, hetzelfde filtergraph opnieuw uit met libx264. Het live-kanaal voert vóór elke start een test-encode van een halve seconde uit met de live-instellingen en gebruikt libx264 als NVENC faalt; een NVENC- of CUDA-fout tijdens de stream schakelt de volgende start over naar libx264. Elke voltooide video registreert welke encoder deze heeft gemaakt, zodat een fallback zichtbaar is in het jobbestand in plaats van onopgemerkt te blijven.
Wat de fallback kost
Minder dan verwacht. Op de 20-core Arm-CPU van dezelfde machine rendert libx264 12 seconden 1080p-video, met camerabewegingen, ingebrande ondertitels en loudness-normalisatie, in 7,6 seconden. Voor korte video's die één keer per dag worden gemaakt, is de CPU een prima encoder. De GPU is veel belangrijker voor het beeldmodel dan voor de encode.
De conclusie
Behandel op een gedeelde machine de GPU-encoder als optioneel: gebruik hem als hij beschikbaar is, val terug als dat niet het geval is, en log welke je hebt gebruikt. Hetzelfde geldt voor elke GPU-functie die eigen geheugen nodig heeft op een machine waar een modelserver al het grootste deel heeft ingenomen. Studio heeft dit gedrag standaard ingeschakeld.