12GB 显卡跑本地 AI 视频：Wan 2.2 加 SeedVR2 的真实数据
所有讲本地 AI 视频的文章对 12GB 显卡的说法都差不多：小模型能跑,勉强。没有一篇说清楚”勉强”折算成多少分钟,也没人说产出到底是不是真的 1080p,更没人说最先崩的是哪一环。
我用一个晚上把这些问题问清楚了。硬件是 RTX 3060 12GB（i9-13900K、48GB 内存,ComfyUI 0.41.2 跑在 Windows 虚拟机里,显卡直通）。最后拿到一条流水线：一个提示词加一张起始图,就能产出真正的 1920×1080 镜头,不用按秒付钱给任何人。但它是在连续五次失败、而且崩在四个不同位置之后才跑通的。
这篇就是那晚的记录。
我要的东西,以及它和什么在竞争
目标很具体：每个镜头 5 秒,拼成更长的片子,分辨率 1080p。商业方案并不稀奇——Kling 的参考图生视频大约 $0.112/秒,5 秒镜头约 $0.56。如果一次就过,这个价格很便宜。
问题在于镜头不会一次就过。生成视频是个反复试的过程：改提示词、换起始帧、换种子、再跑一次。真正花钱的不是最后那一条,是教会我”最后一条该长什么样”的那三十条。这正好是本地显卡擅长的事。
12GB 能装下的模型
| 文件 | 作用 | 大小 |
|---|---|---|
wan2.2_ti2v_5B_fp16.safetensors | 视频模型 | 9.99 GB |
umt5_xxl_fp8_e4m3fn_scaled.safetensors | 文本编码器 | 6.74 GB |
wan2.2_vae.safetensors | 视频 VAE | 1.41 GB |
seedvr2_3b_int8_convrot.safetensors | 放大器 | 3.46 GB |
seedvr2_ema_vae_fp16.safetensors | 放大器 VAE | 0.50 GB |
能用的是 Wan 2.2 TI2V-5B。它围绕 1280×704 训练,同一套权重同时做文生视频和图生视频,Apache-2.0 意味着产出归我。14B 版本更好,但装不下;LTX-2.3 是 22B,能跑,但那个速度会让”反复试”变成一种折磨。
时间成本（全部实测,不是估算）
5 秒片段,121 帧、24fps、20 步采样：
| 分辨率 | 总计 | 采样 | 解码 | 显存峰值 |
|---|---|---|---|---|
| 832×480 | 6.1 分钟 | 4.8 分钟 | 1.3 分钟 | 10.3 GB |
| 1280×704 | 17.9 分钟 | 15.1 分钟 | 2.9 分钟 | 12.1 GB |
像素数减半,时间不是减半,而是降到约三分之一。这是扩散 Transformer 典型的超线性关系,也正是 480p 这档草稿存在的理由。
第一次失败：解码把主机内存吃光
第一次 720p 采样很顺利,然后死在 VAE 解码：
RuntimeError: DefaultCPUAllocator: not enough memory:
you tried to allocate 1308426240 bytes这不是显存错误。121 帧的 Wan VAE 解码需要一次性开出约 1.3GB 的 CPU 侧缓冲,而虚拟机 48GB 里当时只剩约 12GB 空闲。改用分块解码——tile 272、overlap 32、temporal 32、temporal overlap 8——解码显存从 11.9GB 降到 3.9GB,跑通了。
教训不是”一律用分块解码”。25 帧时普通解码只要约 0.27GB,更快也更简单。解码方式应该跟着帧数走,而不是条件反射地选分块。
第二次失败：放大器把整个服务打死
SeedVR2 3B 的 1.5× 输出确实不错,但在 121 帧上它稳定地把进程干掉：
Windows fatal exception: access violation
comfy/ldm/seedvr/vae.py ... decode_tiled这不是可以 catch 的异常,是原生崩溃,顺手把 HTTP 服务一起带走,端口直接死掉。装上 triton-windows 消掉了更早的那个 PatchTritonVAE requires triton 导入错误,但对崩溃毫无帮助。121 帧复现三次,41 帧一次都没崩。
所以绕过方式是切：把片段切成不超过 41 帧的段,分别放大,再拼接。难看,但可靠;只要每刀都落在精确的帧边界上,接缝看不出来。
第三次失败,以及那条解决问题的命令
在一条干净的 5 秒渲染之后两小时,同一个脚本开始失败。然后又失败,而且报的错不一样。五次下来：
aimdo: xfer_file_read_at: GetOverlappedResult failed error=1450
HostBuffer.read_file_slice failed ← 采样阶段
hostbuf_file_reader_read failed ← 解码阶段
Windows fatal exception: access violation ← 模型加载阶段我做了任何人都会做的事：怪到刚改过的东西头上——分辨率。于是跑了一次同帧数的 704p 对照。它也失败。分辨率从来就不是问题。
真正的原因：ComfyUI 在作业结束后把 10GB 模型留在显存里常驻。空闲时显存占着 9.7GB。下一次提交装不下,加载器就退回”从磁盘流式读权重切片”的路径,而那条路径在这台机器上是坏的——error 1450 是 ERROR_NO_SYSTEM_RESOURCES,属于主机侧资源失败,不是采样失败。
一个请求就解决,而且应该放在每次跑之前：
curl -X POST http://127.0.0.1:8188/free \
-H "Content-Type: application/json" \
-d '{"unload_models": true, "free_memory": true}'显存从 9.7GB 掉到 1.1GB,那个已经失败三次的作业下一次就过了。
还有一个”修复”必须点名,因为多数教程会推荐它：加 --disable-dynamic-vram 启动。它把崩溃提前了——9.99GB 的模型塞不进文本编码器剩下的 8.45GB,加载器转去切内存映射,在 torch.storage 里直接崩。同一堵墙,更糟的一面。
1080p 的陷阱：720 不是 32 的倍数
Wan22ImageToVideoLatent 要求宽高都是 32 的倍数。720 不是——720 ÷ 32 = 22.5——所以 720 以下最近的合法高度是 704,而 1280×704 是 16:8.8,不是 16:9。乘 1.5 之后,诚实的产出是 1920×1056,这不是 1080p,后面某处一定会出现黑边或被拉伸。
三条路：
| 做法 | 结果 | 代价 |
|---|---|---|
| 生成 1280×736（23×32）,放大 1.5× → 1920×1104,裁 24px | 精确 1920×1080 | 无黑边、无变形 |
| 保持 704,补边 | 1920×1080 | 上下各 12px 黑边 |
| 保持 704,放大 1.534 后裁宽 | 1920×1080 | 损失约 2% 画面宽度 |
我选第一条。736 是合法的 32 倍数,比 704 更接近 16:9,而上下裁掉 24 行只是去掉模型本来就没用上的边缘。
不要把 1056 拉伸成 1080。人脸会横向宽 2.3%,一眼就看得出不对。
完整的流水线
先用 480p 出草稿,判断动作和构图——480p 的判断不了清晰度,所以别在那档评估画质。通过的镜头再走：
# 每次跑之前先清显存
curl -X POST http://127.0.0.1:8188/free -d '{"unload_models":true,"free_memory":true}'
# 1. 按每秒 25 帧在 1280x736 生成
python bench_wan.py --w 1280 --h 736 --frames 25 --steps 20 --tag final_1s --cold
# 2. 每段不超过 41 帧,分别放大到 1920x1104
python bench_upscale.py --file segment.mp4 --scale 1.5 --tsize 21 --chunk 21
# 3. 裁成精确 1080p
ffmpeg -i upscaled.mp4 -vf "crop=1920:1080:0:12" -c:v libx264 -crf 16 final.mp4下面这条就是在本地生成的输出,放在我自己的 CDN 上：1 秒、1920×1080、24fps,只给了一张起始图。
Wan 2.2 TI2V-5B,1280×736 → SeedVR2 → 裁到 1920×1080。采样 2 分 13 秒,放大 2 分 49 秒,没有一帧是别人渲染的。
放大到底买到了什么
用拉普拉斯方差量,放大把细节能量从 673 提到 766,大约 14%。边缘、头发、霓虹招牌在 1:1 下确实更锐。
皮肤没有。3B 的放大器只是把画面里已有的信息锐化,它不会凭空造出毛孔或布料颗粒。把 SeedVR2 当成”修复”会失望;把它当成”让 720p 级的渲染在 1080p 下站得住”,才准确。
结果
| 镜头长度 | 生成 | 放大 | 合计 | 成本 |
|---|---|---|---|---|
| 1 秒（25 帧） | 3.4 分钟 | 2.8 分钟 | 约 6 分钟 | $0 |
| 5 秒（121 帧） | 17.9 分钟 | 14.1 分钟 | 约 32 分钟 | $0 |
8 个镜头、60 秒的片子,本地大约半天算力;走商业 API 大约 $5,40 分钟。两个数字都是真的,回答的是不同问题。本地机器负责那三十条没人付钱的试错,API 负责最后那一条要交付的。
如果重来一次
三件事,按能省的时间排序。
先量显存,再怀疑代码。 那五次失败的弯路,是因为我相信”这套配置两小时前还能跑”,于是开始改参数。中间跑一次 nvidia-smi 就会看见 9.7GB 常驻,当场结束排查。
设计流水线之前先读尺寸约束。 1920×1056 那个意外,来自没先确认 latent 节点要求 32 的倍数。这是五秒钟的检查,代价是一整轮重渲。
一开始就把放大切成段。 41 帧这个上限听起来很随意,直到第一次崩溃为止。现在它就是工作单位。
诚实的总结：12GB 足够在本地做 1080p AI 视频,大约每完成 1 秒成片要 6 分钟;但它不足以让人对内存掉以轻心。
如果你想把这类东西搬进自己的生意——本地视频生成、自托管的 AI 流水线,或者让一张显卡持续干活又不用工程师盯着的那套管道——这些我都做：
- 📱 WhatsApp: +60 12-797 2969
- 📧 邮件： [email protected]
- 🌐 网站： hoelee.com
