Cuando NVENC no arranca: una GPU llena de modelos y un renderizador que recurre a una alternativa
Vídeo
Nuestro renderizador de vídeo se ejecuta en la misma máquina que el modelo de lenguaje que escribe sus guiones. Una noche, el codificador de hardware simplemente no se abrió: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", seguido de "No capable devices found".
Qué ocurrió
La máquina es un escritorio NVIDIA GB10, cuya CPU y GPU comparten un único pool de memoria. Sirve nuestro modelo local mediante vLLM, y Studio renderiza en la misma caja con ffmpeg, usando NVENC cuando es posible. Durante una ejecución de prueba, el codificador no logró crear su contexto CUDA. El fallo aparecía y desaparecía en segundos: una breve prueba de NVENC pasaba y el renderizado inmediatamente posterior fallaba; en la siguiente ejecución, la propia prueba fallaba; en la ejecución siguiente, tanto la prueba como el renderizado pasaron por NVENC.
Por qué
vLLM reserva una parte fija de la memoria de la GPU al iniciarse, para el modelo y su caché. NVENC necesita un poco de memoria propia para el contexto CUDA de cada sesión. Cuando el servidor de modelos y otros trabajos no dejan nada libre, el codificador no puede iniciarse, aunque sea un motor separado en el chip y apenas toque la computación de la GPU.
La solución: decidir en la codificación, no en la prueba
Una prueba al inicio te dice que NVENC funcionó hace un momento, no que funcionará para el siguiente archivo. Así que Studio intenta NVENC para cada renderizado y, si ffmpeg falla, vuelve a ejecutar el mismo grafo de filtros con libx264. El canal en vivo realiza una codificación de prueba de medio segundo con sus ajustes en vivo antes de cada inicio y usa libx264 si NVENC falla; un error de NVENC o CUDA durante la transmisión cambia el siguiente inicio a libx264. Cada vídeo terminado registra qué codificador lo generó, por lo que una alternativa aparece en el archivo de trabajo en lugar de pasar desapercibida.
Qué cuesta la alternativa
Menos de lo esperado. En la CPU Arm de 20 núcleos de la misma máquina, libx264 renderizó 12 segundos de vídeo 1080p, con movimientos de cámara, subtítulos incrustados y normalización de sonoridad, en 7,6 segundos. Para vídeos cortos creados una vez al día, la CPU es un codificador perfectamente válido. La GPU importa mucho más para el modelo de imagen que para la codificación.
La conclusión
En una máquina compartida, trata el codificador de GPU como opcional: úsalo cuando esté disponible, recurre a una alternativa cuando no lo esté y registra cuál has utilizado. Lo mismo se aplica a cualquier función de GPU que necesite su propia memoria en un equipo donde un servidor de modelos ya ha ocupado la mayor parte. Studio incluye este comportamiento activado de forma predeterminada.