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 重新執行相同的濾鏡圖。即時頻道在每次啟動前，會使用即時設定進行半秒的測試編碼，若 NVENC 失敗則改用 libx264；若串流過程中發生 NVENC 或 CUDA 錯誤，則將下一次啟動切換為 libx264。每支完成的影片都會記錄是由哪個編碼器製作，因此降級情況會顯示在工作檔案中，而不會無聲無息地發生。
降級的代價
比我們預期的低。在同一台機器的 20 核心 Arm CPU 上，libx264 在 7.6 秒內渲染了 12 秒的 1080p 影片，包含鏡頭移動、燒錄字幕與響度正規化。對於每天製作一次的短片而言，CPU 是一個相當合格的編碼器。對於影像模型而言，GPU 的重要性遠高於編碼。
重點整理
在共用機器上，請將 GPU 編碼器視為選配項目：能開啟時就使用，無法開啟時則退回其他方案，並記錄實際使用了哪一種。在模型伺服器已佔用大部分記憶體的機器上，任何需要獨立記憶體的 GPU 功能也應遵循相同原則。Studio 預設即啟用此行為。