NVIDIA 多路视频 AI 的资源预算与容量规划
多路视频 AI 的容量，首先是计算与编解码资源如何分配的问题。NVDEC 能持续解码，不代表每帧都能运行模型；CV 平均计算量不高，也不代表 VLM 突发请求不会挤占推理时间。显存、数据搬运和 CPU 调度还会把这些原本不同的阶段连接起来。
因此，容量应按持续解码、抽帧计算、事件复判和必要的重新编码分别预算，再在混合负载下验证。原始选型材料中的具体设备路数属于规划估计，缺少目标设备完整压测，本文保留计算方法，不把估计写成实测容量。
一、先拆开硬件资源与流水线
| 阶段 | 主要资源 | 需要统计的负载 |
|---|---|---|
| 接入、解复用、重连 | 网卡、CPU、系统内存 | 流数、码率、包率与重连峰值 |
| 硬件解码 | NVDEC、解码 surface 与显存带宽 | 编码格式、分辨率、帧率、位深 |
| 缩放、颜色转换与组 batch | CUDA 或平台预处理单元、内存与拷贝 | 实际处理像素量与数据流向 |
| CV 推理与后处理 | GPU 计算、workspace，部分 CPU | 模型任务率、batch、候选数 |
| VLM 复判 | 视觉编码、prefill/decode、KV cache | 请求率、图像规模、输出长度与并发 |
| 绘制、转码与输出 | GPU/CPU、NVENC、网络与存储 | 实际重新编码的输出路数与规格 |
NVDEC 与 NVENC 是区别于 CUDA 核心的专用引擎，可以与模型计算并行推进，但仍会共享显存带宽、缓冲区与平台功耗资源。部分编码功能还会使用 CUDA，不能把“专用引擎”理解为对其他工作负载完全没有影响。
一个解码 session 对应一条视频的状态，并不意味着独占一个物理解码器。多路 session 可以共享硬件，多个引擎的调度由驱动管理；容量既受总吞吐和内存约束，也受具体编码能力约束，不能只按引擎数量换算路数。
编码预算只计真正重新编码的链路。原始 H.264/H.265 码流直接转发、封装或录像，通常不需要 NVENC；叠加结果到视频、改变分辨率或编码格式后重新输出，才需要相应编码预算。JPEG 抓图也应按实际图像编码实现单独统计，不能直接套用视频 NVENC 的容量。
二、把流数换成各阶段的任务率
2.1 解码看源视频，模型看抽帧频率
对于宽高为
它适合做同类码流的一阶比较，不是通用解码成本模型。同样像素率下，codec、profile、位深、参考帧结构和视频时钟不同，吞吐可能不同。编码格式不受硬件支持而回退软件解码时，还会改变 CPU 预算。
100 路 1080p30 持续解码，对应 3000 帧/s，约 62.2 亿像素/s。即使每路只抽 1 帧/s 做检测，解码后的抽帧一般也不会把解码量降成原来的 1/30，因为后续帧可能依赖前面的参考帧。
如果需要降低解码压力，应评估低帧率或低分辨率子码流、源端配置，或解码器明确支持的跳帧策略，并确认对检测效果和时间采样的影响，不能简单在压缩包队列中任意丢帧。
设视频流数为
多个规则复用同一次模型输出时，
| 算术示例 | 对应负载 |
|---|---|
| 100 路、30 FPS，持续解码 | 3000 解码帧/s |
| 每路每秒一帧、共享一个检测模型 | 100 次 CV 前向/s |
| 每路两秒一帧、平均两个独立模型 | 合计 100 次 CV 前向/s |
| 其中 20 路需要叠加结果并以 15 FPS 输出 | 300 编码帧/s |
以上只是负载换算，不是任何 GPU 的承载承诺。
抽帧与转码如何改变实际输入和时间定位，见 视频转码、抽帧与时间定位的一致性。
2.2 复判按合并后的事件计数
VLM 入口应从候选事件数计算，而不是机械地对每次模型前向各发一个请求。设候选事件到达率为
单模型 100 次/s、候选比例 5%、合并后保留 20% 时，复判约为 1 请求/s。多模型命中同一事件时，先合并再统计，否则会高估有效任务数，也会产生不必要的重复计算。
候选合并前的持续确认、冷却和恢复条件，见 CV 视频场景策略的触发与恢复，应先固定这些规则再统计事件到达率。
三、共享 GPU 要同时限制计算与内存
同卡运行 CV 与 VLM 时，至少分别限制 CV 任务率、在途 batch、VLM 活跃请求、视觉输入规模和生成长度。只设置一个显存比例，不能保证 CV 获得固定的计算时间；多个服务各自的内存配置也不会自动组成全卡统一预算。
显存按常驻与峰值拆分：
其中解码包含参考帧与输出 surface，CV 包含上下文、激活与 workspace，VLM 包含视觉编码临时量、图捕获和 KV cache。只加模型权重体积，会漏掉并发升高时增长最快的部分。
以紧密排列的 8 bit NV12 为例，一帧 1080p 约为：
100 路每路额外保留 4 帧，约为 1.24 GB；若保留全部视频 5 秒的原始帧，则约为 46.7 GB。这里使用十进制单位，实际还有 stride、对齐和解码参考帧开销。缓冲区在哪里分配，就消耗哪一侧内存；事件录像可优先保留压缩码流，避免长期保存大量原始帧。
同一 GPU 上的缩放、推理与输出尽量直接传递设备侧缓冲区，减少 GPU→CPU→GPU 往返。引用同一个解码 surface 也不等于零成本：下游长期持有它，会阻止缓冲区复用，让解码等待或迫使系统增加内存。
资源分配可以从三个动作开始：
- 共享模型实例与调度器，使用有限的执行上下文和在途 batch，避免每路重复加载权重。
- 优先满足持续检测的延迟目标，为复判设置独立入口和并发上限；提高并发后重新测量 CV 尾延迟。
- 混合负载无法满足目标时，再评估分卡部署；把解码与推理拆到不同 GPU 会新增帧传输，需要一并计入。
NUMA 绑定按实际 PCIe、网卡和内存拓扑决定，不硬性规定“一张 GPU 必须配一颗 CPU”。优先让同一组视频的接入、帧缓冲与执行靠近对应设备，扩卡后再验证本地内存和传输路径。
VLM 的 KV 容量、低位宽表示与实际 attention 路径见 NVIDIA KV Cache 量化中的 NVFP4 与 TurboQuant。缓存池扩大后，仍需重新测量混合负载下的服务率和尾延迟。
四、排队预算要与时效一起设置
设稳定状态下的平均到达率为
这里的
实际应测量并发数
队列按任务性质分别处理：
| 队列 | 容量与过期策略 |
|---|---|
| 解码前压缩数据 | 限制缓存时长，保留重连与参考帧恢复所需逻辑 |
| 解码后实时检测帧 | 有界缓存，过载时按规则保留较新的采样帧 |
| 复判事件 | 合并重复事件，设置优先级和最大等待时间 |
| 编码与输出 | 独立限流，避免慢网络或存储拖住整条流水线 |
100 路不应在同一毫秒同时抽帧，可按流打散采样时刻。实时检测更关注当前画面，积压旧帧通常比跳过过期采样更差；但跟踪和时序策略需要接收真实时间戳与丢帧信息，不能在丢帧后继续按连续帧数计算持续时间。
队列上限最终应由允许的等待时间和突发恢复能力决定。过期复判可以丢弃、延后或转交其他执行资源，但要保留降级状态，不能把“没有执行”写成模型判断为否。
五、用混合负载确认瓶颈
先建立纯解码、CV、VLM 和编码的分项基线，再逐项叠加，最后模拟真实流接入、断流重连、事件突发与慢输出。编码测试保留目标 codec、分辨率、帧率、质量 preset 和输出配置，不用最快编码模式的成绩代替实际链路。
| 观测 | 优先检查 |
|---|---|
| 解码输出跟不上源帧率，检测队列尚空 | NVDEC、CPU 解复用、码流支持与 surface 复用 |
| 解码正常，CV 队列持续增长 | 预处理、模型计算、batch 等待与 CPU 后处理 |
| 开启 VLM 后 CV p95 明显上升 | 共享计算、显存带宽与内存峰值 |
| 模型计算稳定，输出端积压 | NVENC、质量配置、网络和存储 |
| GPU 指标不高但端到端变慢 | CPU 串行阶段、拷贝、锁等待、NUMA 与排队 |
在支持的独立 GPU 上，可以用以下查询区分计算、编解码与显存状态：
nvidia-smi dmon -s u -d 1 -c 5
nvidia-smi --query-gpu=index,memory.used,memory.total --format=csvdmon 中的 sm、enc、dec 分别提供相应活动指标，mem 反映内存控制器活动，不是显存已分配比例；不同设备或驱动可能不提供某些指标。采样利用率也不能替代各阶段的吞吐和队列测量。
最终记录实际解码/编码 FPS、CV 吞吐、复判完成率、队列等待、端到端 p95/p99、丢帧/过期率及内存峰值。容量取队列不持续增长、时效仍满足目标的稳定区间，并保留重连与突发余量，而不是取纯引擎测试的最高 FPS。
六、一些反思
视频容量不是一个 GPU 利用率数字。NVDEC、NVENC、计算和内存可以在不同位置先达到限制，而抽帧、事件合并与输出方式又决定每条路径实际承担多少工作。
资源规划最有价值的结果，是明确“接多少路、每路算多少、复判允许多少、过期后怎么办”。这些入口边界比无上限增加并发更容易维持稳定，也能让扩卡与降级有可验证的依据。