Wenn NVENC nicht startet: eine GPU voller Modelle und ein Renderer mit Fallback
Video
Unser Video-Renderer läuft auf derselben Maschine wie das Sprachmodell, das seine Skripte schreibt. Eines Abends ließ sich der Hardware-Encoder einfach nicht öffnen: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", danach "No capable devices found".
Was passiert ist
Die Maschine ist ein NVIDIA GB10 Desktop, dessen CPU und GPU sich einen Speicherpool teilen. Sie bedient unser lokales Modell über vLLM, und Studio rendert auf derselben Box mit ffmpeg und nutzt NVENC, wenn möglich. Während eines Testlaufs konnte der Encoder seinen CUDA-Kontext nicht erstellen. Der Fehler trat sporadisch auf und verschwand innerhalb von Sekunden: Ein kurzer NVENC-Test bestand, und das direkt folgende Rendering schlug fehl; beim nächsten Lauf schlug bereits der Test fehl; beim Lauf danach liefen Test und Rendering beide über NVENC.
Warum
vLLM reserviert beim Start einen festen Anteil des GPU-Speichers für das Modell und seinen Cache. NVENC benötigt für den CUDA-Kontext jeder Sitzung etwas eigenen Speicher. Wenn der Modellserver und andere Jobs nichts übrig lassen, kann der Encoder nicht starten, obwohl er eine separate Engine auf dem Chip ist und die GPU-Rechenleistung kaum beansprucht.
Die Lösung: beim Encoding entscheiden, nicht beim Test
Ein Test beim Start zeigt nur, dass NVENC vor einem Moment funktioniert hat, nicht dass es für die nächste Datei funktionieren wird. Deshalb versucht Studio bei jedem Rendering NVENC und führt bei einem ffmpeg-Fehler denselben Filtergraphen erneut mit libx264 aus. Der Live-Kanal führt vor jedem Start einen halbssekündigen Test-Encode mit den Live-Einstellungen durch und nutzt libx264, falls NVENC diesen nicht besteht; ein NVENC- oder CUDA-Fehler während des Streams stellt den nächsten Start auf libx264 um. Jedes fertige Video protokolliert, welcher Encoder es erstellt hat, sodass ein Fallback in der Job-Datei sichtbar wird, statt unbemerkt zu bleiben.
Was der Fallback kostet
Weniger als erwartet. Auf der 20-Kern-Arm-CPU derselben Maschine renderte libx264 12 Sekunden 1080p-Video mit Kamerabewegungen, eingebrannten Untertiteln und Loudness-Normalisierung in 7,6 Sekunden. Für kurze Videos, die einmal täglich erstellt werden, ist die CPU ein völlig ausreichender Encoder. Die GPU ist für das Bildmodell weitaus wichtiger als für das Encoding.
Das Fazit
Behandle den GPU-Encoder auf einer gemeinsam genutzten Maschine als optional: Nutze ihn, wenn er verfügbar ist, falle zurück, wenn nicht, und protokolliere, welchen du verwendet hast. Dasselbe gilt für jede GPU-Funktion, die eigenen Speicher benötigt, wenn ein Modellserver auf dem Rechner bereits den größten Teil davon belegt hat. Studio bringt dieses Verhalten standardmäßig mit.