RTX 5090 跑 Wan 2.2 生成 12 秒 720×1280 视频，为什么看起来要 2 小时？一次完整排查实录
我最近做了一个口播的Agent，从一张照片，一篇文章，一段语音生成完整的口播。本来，没要求分辨率，只生成了480左右的角度。于是想着生成720精度的，试片效果很好，可是：使用Wan 2.2 S2V 14B时，遇到了一个很有意思的问题：
RTX 5090 + FP8 + Lightning 4 Steps
生成一个约 12 秒、720×1280（9:16）、16fps 的视频
居然感觉要接近 2 小时？
直觉上看，这很反常：
- 5090 是目前消费级顶级显卡
- 模型已经使用 FP8 Scaled
- 已经挂载 Lightning LoRA
- Steps 从 10 降到 4
为什么还这么慢？
经过一轮完整排查后，我发现问题并没有想象中的简单。
环境配置
模型
wan2.2_s2v_14B_fp8_scaled.safetensors
文本编码器：
umt5_xxl_fp8_e4m3fn_scaled.safetensors
LoRA：
wan2.2_t2v_lightx2v_4steps_lora_v1.1_high_noise.safetensors
视频参数
分辨率：720 × 1280
FPS：16
时长：12 秒
总帧数：192 Frames
Steps：4（之前是10）
CFG：3
第一反应：是不是 FP8 没生效？
很多时候文件名写着 FP8，但实际运行时可能回退到 BF16。
先检查模型：
wan2.2_s2v_14B_fp8_scaled
检查文本编码器：
umt5_xxl_fp8_e4m3fn_scaled
同时本机根本没有：
wan2.2_s2v_14B_bf16``
版本。
因此可以确认：
确实在跑 FP8
排除：
BF16导致速度变慢
第二反应：是不是 CPU Offload？
很多视频工作流耗时长，本质上不是 GPU 慢，而是：
显存不够
↓
CPU Offload
↓
频繁搬运数据
↓
速度暴跌
于是查看运行状态：
nvidia-smi
``
得到：
GPU Util : 100%
Power : 600W / 600W
Memory : 25.3GB / 32GB
Temperature: 83℃
``
这是一个极其重要的证据。
说明什么？
GPU 100%
代表：
GPU一直在计算
不是等待。
排除：
CPU瓶颈
IO瓶颈
功耗 600W
更关键。
很多所谓的：
GPU 100%
其实是假满载。
例如：
GPU Util =100%
Power=200W
说明并没有真正把 Tensor Core 喂满。
但这里：
600W / 600W
已经接近满血 Blackwell 输出。
说明：
GPU在真正干活
显存还有 7GB 空余
25GB / 32GB
说明：
没有爆显存
排除：
显存交换
CPU Offload
低显存模式
第三反应：是不是 SageAttention 没开？
检查发现：
No module named 'sageattention'
也就是说：
未安装 SageAttention
同时启动参数没有：
--use-sage-attention
实际运行的是：
PyTorch Attention
``
很多人会立刻得出结论：
找到了！就是因为没开 SageAttention！
但这其实是个误区。
SageAttention 真有那么神吗？
答案：
有帮助
但不是决定性因素
原因很简单。
整个视频生成链路包括：
Attention
Transformer
Temporal计算
VAE
视频拼接
编码
Attention 只是其中一部分。
根据阿姆达尔定律：
如果某个模块只占总耗时 40%，即使加速 2 倍：
整体提升也远达不到 2 倍
因此：
PyTorch Attention
↓
SageAttention
通常属于：
10%
20%
30%
级别优化。
而不是：
120分钟
↓
30分钟
这种神话。
真正关键的信息：Chunk Length
接下来发现了最关键的配置。
Wan 2.2 S2V 使用：
Chunk Length = 77 Frames
一个 Chunk：
77 Frames
对应：
77 / 16 FPS
≈ 4.81 秒
而我的视频：
12 秒
192 Frames
必须拆成：
3个Chunk
日志中也能看到：
3 × 77 Frames
更大的隐藏成本：Motion Reference
S2V工作流还会保留前段参考信息。
代码中：
最多参考 73 Frames Motion
也就是说：
Chunk之间存在大量重叠计算
虽然最终输出：
192 Frames
但实际参与计算的帧数明显更多。
Sampling 速度实测
ComfyUI 显示：
10 Steps
53.7 ~ 58.8 s/it
4 Steps
53.6 ~ 59.1 s/it
注意这里非常关键：
很多人误以为：
降低Steps
↓
每步会更快
实际上不会。
真正情况是：
单步耗时基本固定
约：
55 秒/Step
算一下实际耗时
10 Steps
每个 Chunk：
55 × 10
≈ 550秒
≈ 9.2分钟
3 个 Chunk：
≈27.6分钟
纯 Sampling。
4 Steps
每个 Chunk：
55 × 4
≈220秒
≈3.7分钟
3 个 Chunk：
≈11分钟
纯 Sampling。
那为什么会感觉像 2 小时？
排查到这里，我发现一个有趣的事实：
从数学上看：
Sampling并不支持
2小时这个结论
实际上：
4 Steps
192 Frames
``
更接近：
10~20分钟
量级。
因此需要重新区分：
Sampling Time
``
和
Workflow Time
很多时间可能花在这里
除了扩散采样，还有：
VAE Decode
192 Frames
720 × 1280
VAE并不便宜。
视频编码
例如：
H264
H265
CRF
``
编码参数不同，耗时差异巨大。
FFmpeg
高质量编码经常吃掉大量时间。
多批次生成
很多时候：
Batch > 1
或者：
多个Seed
用户没注意到。
最终结论
经过完整排查：
不是这些原因
❌ FP8失效
❌ BF16回退
❌ CPU Offload
❌ 显存不足
❌ GPU没有跑满
因为实际状态是：
GPU Util : 100%
Power : 600W
Memory : 25GB
已经是标准的满血运行状态。
更可能的原因
1. Wan 2.2 S2V 14B 本身计算量巨大
尤其：
720×1280
192 Frames
属于重型任务。
2. Chunk机制增加了实际计算量
77 Frame Chunk
+
73 Frame Motion Reference
导致实际计算帧数高于表面数字。
3. 2小时未必都是 Sampling
从实测：
≈55 s/it
推算，
4 Steps 的采样时间更接近：
10~20分钟
剩余时间很可能消耗在：
VAE
视频编码
FFmpeg
后处理
环节。
一句话总结
当 RTX 5090 在 Wan 2.2 S2V 14B 下表现为 GPU 100%、600W 满功耗、FP8 正常加载时，生成 10 秒左右视频的耗时问题，更多是模型架构、Chunk 切分和后处理流程带来的复杂度，而不是显卡性能不足或配置错误。
