直播片段集中提交生成请求时，队列变长并不一定代表模型运行变慢。更常见的情况是任务到达速度超过可用推理能力，或单个任务占用资源太久，后续请求只能等待。做好视频生成应用的推理资源配置，需要把等待、执行、解码和输出分开观察，才能判断瓶颈在哪里。
资源不足会引发哪些排队问题？
短任务被长任务挡住
如果队列按提交顺序处理，一个需要较长生成时间的请求可能占着执行位置，后来的短片段也无法及时开始。这种“队首阻塞”会让平均等待时间看起来尚可，但部分请求的等待时间明显偏长。混合不同片段时，按预计耗时分组或设置时效优先级，通常比单纯扩大队列更有效。
显存紧张导致反复等待或失败
视频生成任务会占用显存存放模型权重和推理中间数据。并发数升高后，显存不足可能触发任务失败、释放资源后重试，或让服务端延迟接收新任务。重试若没有次数上限和退避间隔，还会把原有拥堵放大。不能只看显存总量，也要记录任务运行时的峰值占用。
推理结束后，输出环节仍可能排队
生成帧完成不代表视频已经可交付。若系统还要调用 FFmpeg 编码、写入存储或上传文件，CPU、磁盘和网络都可能形成独立队列。此时继续增加模型并发，未必缩短用户等待时间，反而可能让待编码文件越积越多。
如何定位瓶颈并调整调度
视频生成应用的推理资源配置应依据实测，而不是只按显卡型号估算。先拆出任务各阶段的耗时与资源占用，再逐步调整并发和队列规则。
- 记录分阶段时间。分别采集排队等待、模型推理、解码编码、文件写入的开始与结束时间，并按短片段、长片段等实际任务类型分组。
- 测出并发上限。在固定模型、输入规格和运行环境下，从并发 1 开始，再逐步测试 2、4、8 等档位；每档记录显存峰值、失败率和高分位完成时间。测试档位只是排查起点，具体上限取决于模型和硬件。
- 设定准入和队列规则。当显存或执行槽位接近实测安全上限时，暂缓接收新任务；可为有明确交付时限的片段设置优先级，并限制单个请求的重试次数，避免失败任务反复占用资源。
- 分开扩容判断。若等待主要发生在模型执行前，检查推理实例与显存；若模型已完成而文件迟迟未就绪，则单独检查编码、磁盘和上传队列，不要把所有问题都归因于 GPU。
避免把队列长度当成唯一指标
队列长度只能说明有多少任务在等待，不能说明用户还要等多久。建议同时看等待时间的中位数和高分位数、任务超时率、重试率、显存峰值，以及编码队列的积压量。统计窗口可按业务波动选取，例如每分钟观察突发情况，并用更长时段判断持续拥堵。视频生成应用的推理资源配置最终要服务于完成时效，而不只是提高设备利用率。
常见问题
队列越短，服务就一定越好吗？
不一定。限制队列可减少过期请求，但高峰时可能更早拒绝任务；应结合等待时长、超时率和业务可接受的排队时间设置上限。
提高并发能否直接解决等待？
只有执行资源仍有余量时才可能有效。若显存已紧张或编码环节拥堵，提高并发可能增加失败和下游积压。
什么时候应该拆分队列？
当短任务频繁被长任务挡住，或不同任务有明显不同的时效要求时，可按耗时、规格或优先级拆分，并分别监控完成时间。
应该优先扩展哪类资源？
先根据分阶段监控找到瓶颈：模型执行受限时评估推理资源，编码或写入受限时评估对应处理能力。按测量结果扩展，比统一增加资源更稳妥。
