Kapag hindi makapagsimula ang NVENC: punong-puno ng mga model ang GPU, at isang renderer na bumabalik sa fallback
Video
Ang video renderer namin ay tumatakbo sa parehong makina kung saan tumatakbo ang language model na sumusulat ng mga script nito. Isang gabi, biglang hindi na lang mabuksan ang hardware encoder: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", pagkatapos ay "No capable devices found".
Ano ang nangyari
Ang makina ay isang NVIDIA GB10 desktop, kung saan ang CPU at GPU ay nagbabahagi ng iisang pool ng memory. Pinaglilingkuran nito ang local model namin sa pamamagitan ng vLLM, at nagre-render ang Studio sa parehong box gamit ang ffmpeg, na gumagamit ng NVENC kapag kaya. Sa isang test run, nabigong makabuo ng CUDA context ang encoder. Pumasok at lumabas ang failure sa loob ng ilang segundo: nakapasa ang maikling NVENC probe ngunit nabigo ang render kaagad pagkatapos nito; sa susunod na run, nabigo ang probe mismo; sa run pagkatapos nito, parehong nakapasa ang probe at render sa pamamagitan ng NVENC.
Bakit
Nag-re-reserve ang vLLM ng fixed share ng memory ng GPU kapag nagsisimula ito, para sa model at sa cache nito. Kailangan ng NVENC ng kaunting memory nito para sa CUDA context ng bawat session. Kapag wala nang natitirang memory ang model server at iba pang jobs, hindi makapagsimula ang encoder, kahit na ito ay hiwalay na engine sa chip at halos hindi naman hahawakan ang compute ng GPU.
Ang fix: magdesisyon sa encode, hindi sa probe
Ang probe sa start-up ay nagsasabi sa iyo na gumana ang NVENC noong sandali lang, hindi na gagana ito para sa susunod na file. Kaya sinusubukan ng Studio ang NVENC para sa bawat render, at kung mabigo ang ffmpeg, pinapatakbo nito ang parehong filter graph muli gamit ang libx264. Ang live channel ay nagpapatakbo ng half-second test encode gamit ang live settings nito bago ang bawat start at gumagamit ng libx264 kung mabigo ang NVENC; ang NVENC o CUDA error habang nagse-stream ay nagpapalit ng susunod na start sa libx264. Ang bawat tapos na video ay nire-record kung anong encoder ang gumawa nito, kaya ang fallback ay lalabas sa job file sa halip na dumaan nang hindi napapansin.
Ano ang gastos ng fallback
Mas mababa kaysa inaasahan namin. Sa 20-core Arm CPU ng parehong makina, na-render ng libx264 ang 12 segundo ng 1080p video, kasama ang mga camera moves, burned-in captions at loudness normalisation, sa loob ng 7.6 segundo. Para sa mga maikling video na ginagawa isang beses sa isang araw, ang CPU ay isang mahusay na encoder. Mas mahalaga ang GPU para sa image model kaysa sa encode.
Ang takeaway
Sa isang shared machine, ituring ang GPU encoder bilang optional: gamitin ito kapag available, bumalik sa fallback kapag hindi, at i-log kung alin ang ginamit. Ang parehong prinsipyo ay naaangkop sa anumang GPU feature na nangangailangan ng sarili nitong memory sa isang box kung saan kinuha na ng model server ang karamihan nito. Studio ay may default na ganitong behaviour.