Quand NVENC ne démarre pas : un GPU saturé de modèles et un moteur de rendu qui bascule en secours
Vidéo
Notre moteur de rendu vidéo tourne sur la même machine que le modèle de langage qui écrit ses scripts. Un soir, l'encodeur matériel refusait tout simplement de s'ouvrir : « CUDA_ERROR_OUT_OF_MEMORY : mémoire insuffisante », puis « Aucun périphérique compatible trouvé ».
Ce qui s'est passé
La machine est un desktop NVIDIA GB10, dont le CPU et le GPU partagent un même pool de mémoire. Elle sert notre modèle local via vLLM, et Studio rend sur la même machine avec ffmpeg, en utilisant NVENC quand c'est possible. Lors d'un test, l'encodeur n'a pas réussi à créer son contexte CUDA. L'échec survenait et disparaissait en quelques secondes : une courte sonde NVENC passait et le rendu juste après échouait ; au lancement suivant, la sonde elle-même échouait ; au lancement d'après, la sonde et le rendu passaient tous les deux par NVENC.
Pourquoi
vLLM réserve une part fixe de la mémoire du GPU au démarrage, pour le modèle et son cache. NVENC a besoin d'un peu de mémoire à lui pour le contexte CUDA de chaque session. Quand le serveur de modèle et les autres tâches ne laissent rien disponible, l'encodeur ne peut pas démarrer, même s'il s'agit d'un moteur séparé sur la puce qui solliciterait à peine le calcul du GPU.
La correction : décider à l'encodage, pas à la sonde
Une sonde au démarrage vous indique que NVENC fonctionnait il y a un instant, pas qu'il fonctionnera pour le fichier suivant. Studio essaie donc NVENC pour chaque rendu et, si ffmpeg échoue, relance le même graphe de filtres avec libx264. Le canal en direct effectue un encodage test d'une demi-seconde avec ses paramètres en direct avant chaque démarrage et utilise libx264 si NVENC échoue ; une erreur NVENC ou CUDA pendant le flux bascule le démarrage suivant sur libx264. Chaque vidéo terminée enregistre quel encodeur l'a produite, de sorte qu'un basculement apparaît dans le fichier de tâche au lieu de passer inaperçu.
Le coût du basculement
Moins que prévu. Sur le CPU Arm 20 cœurs de la même machine, libx264 a rendu 12 secondes de vidéo 1080p, avec mouvements de caméra, sous-titres incrustés et normalisation du volume, en 7,6 secondes. Pour des vidéos courtes produites une fois par jour, le CPU est un encodeur tout à fait correct. Le GPU compte bien plus pour le modèle d'image que pour l'encodage.
À retenir
Sur une machine partagée, considérez l’encodeur GPU comme optionnel : utilisez-le lorsqu’il est disponible, basculez vers une autre solution lorsqu’il ne l’est pas, et journalisez celui que vous avez utilisé. Il en va de même pour toute fonctionnalité GPU nécessitant sa propre mémoire sur une machine où un serveur de modèles a déjà occupé la majeure partie de celle-ci. Studio intègre ce comportement par défaut.