Quando NVENC non parte: una GPU piena di modelli e un renderer che fa il fallback
Video
Il nostro renderer video gira sulla stessa macchina del modello linguistico che ne scrive gli script. Una sera l'encoder hardware semplicemente non si apriva: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", poi "No capable devices found".
Cosa è successo
La macchina è un desktop NVIDIA GB10, la cui CPU e GPU condividono un unico pool di memoria. Serve il nostro modello locale tramite vLLM, e Studio renderizza sulla stessa macchina con ffmpeg, usando NVENC quando possibile. Durante un test run l'encoder non è riuscito a creare il suo contesto CUDA. Il fallimento andava e veniva in pochi secondi: una breve sonda NVENC passava e il render subito dopo falliva; alla run successiva falliva la sonda stessa; alla run ancora dopo, sonda e render passavano entrambi tramite NVENC.
Perché
vLLM riserva una quota fissa della memoria della GPU all'avvio, per il modello e la sua cache. NVENC ha bisogno di un po' di memoria propria per il contesto CUDA di ogni sessione. Quando il server del modello e altri job non lasciano nulla di libero, l'encoder non può avviarsi, anche se è un motore separato sul chip e toccherebbe a malapena il compute della GPU.
La soluzione: decidere alla codifica, non alla sonda
Una sonda all'avvio ti dice che NVENC ha funzionato un momento fa, non che funzionerà per il file successivo. Quindi Studio prova NVENC per ogni render e, se ffmpeg fallisce, riesegue lo stesso filtro grafico con libx264. Il canale live esegue una codifica di prova di mezzo secondo con le sue impostazioni live prima di ogni avvio e usa libx264 se NVENC fallisce; un errore NVENC o CUDA durante lo stream commuta l'avvio successivo a libx264. Ogni video finito registra quale encoder lo ha prodotto, così un fallback compare nel file del job invece di passare inosservato.
Quanto costa il fallback
Meno del previsto. Sulla CPU Arm a 20 core della stessa macchina, libx264 ha renderizzato 12 secondi di video 1080p, con movimenti di camera, sottotitoli incisi e normalizzazione del loudness, in 7,6 secondi. Per video brevi fatti una volta al giorno, la CPU è un encoder perfettamente valido. La GPU conta molto di più per il modello di immagini che per la codifica.
Il punto chiave
Su una macchina condivisa, considera l'encoder GPU come opzionale: usalo quando è disponibile, ripiega su un'alternativa quando non lo è e registra quale hai usato. Lo stesso vale per qualsiasi funzione GPU che richieda memoria dedicata su una macchina dove un server di modelli ne ha già occupata la maggior parte. Studio include questo comportamento attivo per impostazione predefinita.