Quando o NVENC não inicia: uma GPU cheia de modelos e um renderizador que recorre a uma alternativa
Vídeo
Nosso renderizador de vídeo roda na mesma máquina que o modelo de linguagem que escreve seus roteiros. Uma noite, o codificador de hardware simplesmente não abriu: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", seguido de "No capable devices found".
O que aconteceu
A máquina é um desktop NVIDIA GB10, cuja CPU e GPU compartilham um único pool de memória. Ele atende nosso modelo local via vLLM, e o Studio renderiza na mesma máquina com ffmpeg, usando NVENC quando possível. Durante uma execução de teste, o codificador falhou ao criar seu contexto CUDA. A falha ia e vinha em segundos: uma breve sondagem NVENC passava e a renderização logo em seguida falhava; na execução seguinte, a própria sondagem falhava; na execução seguinte, sondagem e renderização passavam pelo NVENC.
Por quê
O vLLM reserva uma parcela fixa da memória da GPU ao iniciar, para o modelo e seu cache. O NVENC precisa de um pouco de memória própria para o contexto CUDA de cada sessão. Quando o servidor de modelos e outros trabalhos não deixam nada sobrando, o codificador não consegue iniciar, mesmo sendo um motor separado no chip e mal tocando o poder de computação da GPU.
A correção: decidir na codificação, não na sondagem
Uma sondagem na inicialização diz que o NVENC funcionou há um instante, não que funcionará para o próximo arquivo. Assim, o Studio tenta o NVENC para cada renderização e, se o ffmpeg falhar, executa novamente o mesmo grafo de filtros com libx264. O canal ao vivo roda uma codificação de teste de meio segundo com suas configurações ao vivo antes de cada início e usa libx264 se o NVENC falhar; um erro NVENC ou CUDA durante a transmissão muda o próximo início para libx264. Cada vídeo concluído registra qual codificador o produziu, para que uma alternativa apareça no arquivo do trabalho em vez de passar despercebida.
O custo da alternativa
Menos do que esperávamos. Na CPU Arm de 20 núcleos da mesma máquina, o libx264 renderizou 12 segundos de vídeo 1080p, com movimentos de câmera, legendas embutidas e normalização de loudness, em 7,6 segundos. Para vídeos curtos feitos uma vez por dia, a CPU é um codificador perfeitamente bom. A GPU importa muito mais para o modelo de imagem do que para a codificação.
A conclusão
Em uma máquina compartilhada, trate o codificador de GPU como opcional: use-o quando estiver disponível, recorra a uma alternativa quando não estiver, e registre qual foi utilizado. O mesmo se aplica a qualquer recurso de GPU que precise de sua própria memória em uma máquina onde um servidor de modelos já consumiu a maior parte dela. O Studio já vem com esse comportamento ativado por padrão.