北京
视频描述是很多行业的常见任务，用来描述视频里正在发生什么。自动驾驶训练系统用它来描述和分类危险场景，也能生成人类可读、可搜索的元数据。
此前vLLM处理这类数据集，视频只能通过基于CPU的OpenCV+FFMPEG后端解码。在多GPU节点上（每个GPU跑一个vLLM服务器），CPU要在VLM推理开始前完成视频帧解码，压力陡增。视频描述任务的输出相对较短（100-200个token），解码视频占用的时间比例因此更大，CPU解码很快成为瓶颈，即使只有2或4块GPU，也能把CPU核心跑满。
通过集成PyNvVideoCodec——NVIDIA硬件视频解码器（也叫NVDEC）的Python接口——vLLM把视频解码负载从CPU转移出去，移除了上述瓶颈，即便扩展到8块GPU也能保持良好伸缩性。
怎么在vLLM里用上硬件解码
标准CUDA版vLLM发布包里已经包含了PyNvVideoCodec的功能。如果你用的是自定义安装的vLLM，确保项目里加上对PyNvVideoCodec==2.0.4的PyPi依赖。
启动vLLM时，有几个点需要注意：
- CUDA MPS对多进程高并发场景（比如批量VLM推理）的性能至关重要，建议在vllm serve之前确认MPS守护进程已启动。
- --mm-ipc-gpu-memory-gb用于为视频解码预留显存。可以在不同取值下测试吞吐量，只预留不影响吞吐量的最小值。
- 扩展到多GPU时，通常建议每个vLLM服务器副本跑一个容器，每个容器只暴露一块GPU；也可以用CUDA_VISIBLE_DEVICES给每个vLLM副本暴露单块GPU。请求分发用反向代理完成。
关于PyNvVideoCodec解码器后端的参数文档，可以参考vLLM的相关文档。
多GPU视频描述任务的伸缩表现
NVIDIA自动驾驶团队用视频描述任务做了测试。这些系统要处理数十万小时的视频片段，对应数亿次视频描述请求。
这类任务通常用相对轻量的模型，比如Qwen/Qwen3-VL-8B-Instruct，输入提示词指定想要的描述类型，输出在100-200个token量级。
在8块H100、8个vLLM副本各配一块GPU的配置下，基于GPU的视频解码吞吐量是CPU解码的两倍以上。
另一个值得注意的变化是：此前使用最多8块GPU的大规模工作负载，在不到4块GPU时就会先撞上CPU利用率瓶颈。现在有了硬件视频解码支持，这个CPU瓶颈被移除了。
需要说明的是，视频解码确实需要预留一部分显存。如果你的用例已经把全部显存用于KV缓存，可能会看到一些影响。但在实际测试中，还没有遇到使用PyNvVideoCodec带来性能下降的情况。
一个输入提示词的例子是这样的：分析这段前向行车记录仪视频，简要描述驾驶环境、相关道路使用者和交通控制，以及自车的动作，只报告清晰可见的细节，避免推测。
对应的输出则是：自车在白天沿多车道城市道路行驶，能见度清晰。前方同车道和相邻车道有多辆车，可见一个信号灯路口。自车保持车道，接近车流时减速，并与前车保持距离继续行驶。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
