选卡时先别只盯着编码单元数量。视频转码集群显卡编码能力选型方法的核心，是用真实工作负载测出“能持续跑多少路”，再确认画质、延迟和资源余量都达标。单卡峰值吞吐高，不代表多路并发时仍然稳定。
编码单元数量能筛选，不能直接换算路数
编码引擎是硬件并行处理视频编码任务的资源，数量和代际可以帮助判断大致能力。但不同显卡的引擎设计、频率、支持的编码格式与档次不同；同一张卡改用不同分辨率、帧率、码率、预设或位深，吞吐也会变化。因此，不能简单按“编码单元数翻倍，转码路数翻倍”估算。
例如，NVIDIA T4 与 L4 都可用于硬件视频处理，但代际和支持能力并不相同；若业务要求 AV1 编码，更要核对具体型号、驱动和编码软件是否支持，不能只看产品名称。Intel Quick Sync 则依赖处理器及其媒体引擎，适合一并纳入对比，但要确认主板、系统和软件确实能调用它。
把实测吞吐做成可复现的对比
测试应从生产任务抽取代表性素材，而不是只跑一段轻负载演示片。视频转码集群显卡编码能力选型方法落到执行，可按下面步骤进行：
- 列出工作负载：统计常用输入输出组合，例如 H.264 转 H.264、HEVC 转 H.264，以及 1080p、4K 等分辨率；标明帧率、目标码率、编码预设和是否需要缩放、去隔行或叠加水印。
- 固定测试条件：在相同素材、软件版本、驱动、参数和存储路径下测试候选卡。记录输出帧率、单路延迟、GPU 编码与解码占用、CPU 使用率及显存占用。
- 逐级增加并发：从单路开始，再按 2、4、8 路等梯度增加任务；每档保持一段足以覆盖波动的运行时间，观察吞吐是否持续、是否掉帧，以及延迟是否超出业务要求。
- 测混合任务：按实际比例同时运行不同分辨率或编码格式，并加入常用滤镜。很多工作流会先解码、缩放再编码，若解码引擎、CPU 或内存带宽先到瓶颈，单看编码吞吐会高估整机能力。
测试记录建议同时列出“每秒处理帧数”和“满足时延要求的稳定并发路数”。如果直播或交互任务重视延迟，不能仅用离线批处理的总吞吐作结论；如果主要是夜间文件转码，则可更看重单位时间完成量和资源利用率。
并发选型要留余量，也要看瓶颈在哪里
按业务峰值规划，而非追求满载
先估算峰值同时运行的任务数，再用实测得到单卡稳定路数。规划时可先预留约 10%—20% 的资源空间作为起点；实际余量要随任务波动、故障切换和服务等级调整。最终容量应按持续运行测试确定，避免把短时峰值当成可承诺产能。
区分编码瓶颈与整机瓶颈
若编码单元占用很高而 CPU、磁盘和网络尚有余量，换更强的视频引擎可能有效；若 CPU 已满，先检查软件解码、滤镜和任务调度；若读写等待明显，则应先优化存储和输入输出路径。容器或虚拟机部署还要验证设备透传、驱动和并发会话限制，否则硬件规格再合适也未必能被任务稳定调用。
所以，视频转码集群显卡编码能力选型方法不是在“数单元”和“看吞吐”之间二选一：先用编码能力及格式支持做初筛，再以目标参数下的多路实测定容量，并把解码、滤镜、CPU 与系统余量一起纳入验收。
常见问题
编码单元多的显卡一定更适合转码吗？
不一定。单元数量不能代表所有编码格式、预设和分辨率下的表现，须用目标任务验证。
测试只跑 1080p 可以吗？
只有当生产任务几乎都为 1080p 时才够用。存在 4K、混合格式或滤镜任务，就应加入对应样本。
应该按单路速度还是并发路数采购？
按业务目标决定，但都要在目标延迟和画质要求下测量；集群容量通常更应关注稳定并发路数。
换显卡后是否还要重新测？
要。型号、驱动、编码软件和参数变化都可能影响吞吐及稳定性，应在实际部署环境复测。
