Когато NVENC не стартира: GPU, натоварен с модели, и рендерер, който преминава в резервен режим

Видео

Нашият рендерер за видео работи на същата машина като езиковия модел, който пише неговите скриптове. Една вечер хардуерният енкодер просто отказа да се отвори: „CUDA_ERROR_OUT_OF_MEMORY: out of memory“, след което „No capable devices found“.

Какво се случи

Машината е десктоп NVIDIA GB10, чийто CPU и GPU споделят един пул от памет. Тя обслужва нашия локален модел чрез vLLM, а Studio рендира на същата машина с ffmpeg, използвайки NVENC, когато може. По време на тестово изпълнение енкодерът не успя да създаде своя CUDA контекст. Отказът идваше и изчезваше за секунди: кратък NVENC пробен запуск минаваше, а рендирането веднага след него се проваляше; при следващото изпълнение самият пробен запуск се провали; при изпълнението след това и пробният запуск, и рендирането минаха през NVENC.

Защо

vLLM резервира фиксирана част от паметта на GPU-то при стартиране, за модела и неговия кеш. NVENC се нуждае от малко собствена памет за CUDA контекста на всяка сесия. Когато сървърът на модела и другите задачи не оставят нищо свободно, енкодерът не може да стартира, въпреки че е отделен двигател на чипа и би натоварил изчислителната мощ на GPU-то съвсем малко.

Решението: решаване при кодирането, а не при пробния запуск

Пробният запуск при стартиране ви казва, че NVENC е работил преди миг, а не че ще работи за следващия файл. Затова Studio опитва NVENC за всяко рендиране и, ако ffmpeg се провали, изпълнява отново същата филтърна графа с libx264. Каналът на живо изпълнява пробен запуск за кодиране за половин секунда с настройките си за живо излъчване преди всяко стартиране и използва libx264, ако NVENC не мине теста; грешка в NVENC или CUDA по време на стрийма превключва следващото стартиране на libx264. Всяко завършено видео записва кой енкодер го е направил, така че преминаването в резервен режим се вижда в файла на задачата, вместо да остане незабелязано.

Какво струва резервният режим

По-малко, отколкото очаквахме. На 20-ядрения Arm CPU на същата машина libx264 рендира 12 секунди видео с резолюция 1080p, с движения на камерата, вградени надписи и нормализация на силата на звука, за 7.6 секунди. За кратки видеоклипове, правени веднъж на ден, CPU-то е напълно добър енкодер. GPU-то е много по-важно за модела за изображения, отколкото за кодирането.

Изводът

На споделена машина разглеждайте GPU енкодера като опционален: използвайте го, когато е наличен, прибягвайте към алтернатива, когато не е, и записвайте в логовете кой сте използвали. Същото важи за всяка GPU функция, която изисква собствена памет на машина, където сървър за модели вече е зает по-голямата част от нея. Studio идва с тази функционалност, активирана по подразбиране.

Обновено: