När NVENC inte startar: ett GPU fullt av modeller och en renderare som faller tillbaka
Video
Vår videorenderare körs på samma maskin som den språkmodell som skriver dess skript. En kväll ville hårdvarukodaren helt enkelt inte öppnas: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", följt av "No capable devices found".
Vad som hände
Maskinen är en NVIDIA GB10-dator, där CPU och GPU delar på ett gemensamt minnespool. Den betjänar vår lokala modell via vLLM, och Studio renderar på samma maskin med ffmpeg, och använder NVENC när det går. Under ett testkörning misslyckades kodaren med att skapa sin CUDA-kontext. Felet kom och gick inom några sekunder: en kort NVENC-provning klarades och renderingen strax därefter misslyckades; vid nästa körning misslyckades själva provningen; vid körningen därefter gick både provning och rendering via NVENC.
Varför
vLLM reserverar en fast andel av GPU:ns minne när det startar, för modellen och dess cache. NVENC behöver lite eget minne för varje sessions CUDA-kontext. När modellservern och andra jobb inte lämnar något över kan kodaren inte starta, även om den är en separat motor på chipset och knappt skulle belasta GPU:ns beräkningskraft.
Åtgärden: besluta vid kodningen, inte vid provningen
En provning vid start talar om att NVENC fungerade för ett ögonblick sedan, inte att det kommer att fungera för nästa fil. Därför försöker Studio med NVENC för varje rendering och, om ffmpeg misslyckas, kör samma filtergraf igen med libx264. Den live-kanalen kör en halvsekunders testkodning med sina live-inställningar före varje start och använder libx264 om NVENC misslyckas; ett NVENC- eller CUDA-fel under strömmen gör att nästa start använder libx264. Varje färdig video registrerar vilken kodare som skapade den, så ett fall-back syns i jobbfilen istället för att passera obemärkt.
Vad fall-back kostar
Mindre än vi förväntade oss. På samma maskins 20-kärniga Arm-CPU renderade libx264 12 sekunder av 1080p-video, med kamerarörelser, inbrända textningar och normalisering av ljudnivå, på 7,6 sekunder. För korta videor som görs en gång om dagen är CPU:n en alldeles utmärkt kodare. GPU:n betyder betydligt mer för bildmodellen än för kodningen.
Slutsatsen
På en delad maskin bör du betrakta GPU-kodaren som valfri: använd den när den är tillgänglig, använd ett alternativ när den inte är det, och logga vilken du använde. Detsamma gäller alla GPU-funktioner som kräver eget minne på en maskin där en modellserver redan har tagit större delen av det. Studio har detta beteende aktiverat som standard.