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 默认启用了此行为。