部署视频生成服务，先买多大显卡并不是最有效的起点。更稳妥的做法是先描述请求，再测单次生成成本，最后用压测确认容量。视频生成应用的推理资源配置，主要受模型、分辨率、帧数、采样设置和并发影响；只看模型参数量，无法直接得出需要几张卡。
先把流量换成并发需求
整理一段时间内的请求总量，并单独观察高峰时段。至少记录每分钟到达请求数、用户允许的等待时间、目标视频时长，以及请求是否集中在某些时段。日均请求适合估算总工作量，峰值请求才更接近在线服务需要承受的压力。
可用“平均在途任务数≈每秒到达任务数×单任务平均处理秒数”做初步估算。这是容量起点，不是最终机器数量：排队策略、失败重试和任务时长差异都会改变实际结果。例如，若规划假设高峰每分钟到达 8 个任务，基准环境实测单任务耗时 75 秒，平均在途任务约为 10 个。这里的耗时只是示例输入，实际应以目标模型和目标配置的测量值替换。
视频生成应用的推理资源配置还要区分交互式请求与后台批量任务。前者通常更重视首帧延迟和排队时间；后者可以通过队列平滑流量，但用户可能需要等待更久。不要把这两类服务的时延目标混为一谈。
用小规模测试测显存，而非按参数量猜
显存占用不仅包括模型权重，还包括推理过程中的中间张量、注意力计算缓存、解码组件和框架开销。分辨率、帧数、批量大小及精度设置变化，都可能推高峰值显存。即使同一模型，在不同推理实现或硬件上，结果也可能不同。
例如，可把 LTX-Video 作为开源视频生成模型的测试对象，先固定模型版本、推理代码、精度和输出规格，再逐项改变分辨率或帧数。记录空闲显存、模型加载后显存、生成期间峰值显存以及任务耗时。峰值显存应以实际监控结果为准，不能只用权重文件大小代替。
为并发和波动留出余量。可以先把实测峰值与设备可用显存比较，并预留约 15%–25% 作为初始安全空间；这只是规划参考，驱动、同机其他进程和显存碎片会影响可用余量。若任务偶发失败或峰值贴近上限，应降低并发、减小生成规格，或换用更大显存设备后复测。
按这套流程逐步定配置
- 确定基准请求。选取实际会用到的模型、输出分辨率、视频时长、帧率和采样设置，并固定软件版本。可以先用 LTX-Video 跑通流程；若后续更换模型，原有测量结果不能直接照搬。
- 测单任务基线。在目标硬件上重复运行代表性请求，记录生成耗时、峰值显存和失败情况。分别测量模型冷启动与已加载状态，避免把加载时间误认为稳定推理耗时。
- 逐级增加并发数。从单任务开始，逐档增加同时运行的任务，记录吞吐量、等待时间、峰值显存和错误率。吞吐量是单位时间完成的任务数；并发继续增加后，如果吞吐不再提升而排队变长，就应停止盲目加并发。
- 模拟真实流量压测。测试持续请求和短时突发两种情况，并加入任务失败后的重试行为。至少覆盖常见规格与较重规格，观察服务是否出现显存溢出、超时或队列持续增长。
- 按瓶颈扩容或降配。显存先到上限时，优先降低单卡并发或调整输出规格；算力繁忙但显存有余量时，可试测更高并发或增加工作进程。每次改动只调整一个主要变量，再复测确认。
采购与上线时看清取舍
单卡部署便于控制成本、排查问题，适合流量可排队且模型能装入设备显存的服务；多卡或多实例更适合需要分担峰值、减少排队的场景，但会增加调度、监控和运维复杂度。批处理可能提高设备利用率，却可能拉长单个请求的等待时间；降低精度或使用量化模型有机会减少显存占用，但输出质量和速度需针对目标任务验证。
因此，视频生成应用的推理资源配置应以“目标请求规格下的实测吞吐和显存余量”作为决策依据。上线后持续观察队列长度、失败率、平均耗时和峰值显存；当流量或模型版本变化时重新压测，而不是只沿用首次估算。
常见问题
显存够用，为什么仍然排队？
显存充足不代表算力能及时处理请求。若计算单元持续繁忙、单任务耗时较长，或并发任务多于服务能力，队列仍会增长。
能否直接按日请求量购买设备？
不建议。日总量不能反映请求集中程度；还需结合高峰到达速度、实测生成耗时、可接受等待时间和故障余量估算。
更换分辨率后需要重新压测吗？
需要。输出尺寸和帧数会影响计算量与中间数据规模，不能假设新规格的耗时、显存占用与原规格成比例变化。
什么时候需要增加设备？
当持续压测显示高峰吞吐达不到目标、等待时间超限，且降低并发或调整规格仍无法满足需求时，再比较扩容与降配的成本和效果。
