AI 视频本地部署实战:一张 24G 显卡能跑到什么程度
先说结论,省得看半天:24 GB 显存是这条线的分水岭。跨过去,主流的 140 亿参数级视频模型可以量化后跑,5 秒 720P 十几分钟出一条;卡在 16 GB,只能玩 10 亿到 50 亿参数那一档,画质和运动幅度都要让步。
再说明一点:本地部署的意义不是「省钱」,而是 无限次试错。云 GPU 按小时收费,你调一次 prompt 等十分钟,一小时能试六次;本地卡着你自己的电费,可以整夜跑着一百条候选,早上起来挑。创作这件事,出片数量和最终质量是正相关的。
一、先算清楚一条视频的真实成本
很多人只算了显卡钱,没算时间成本。按 24 GB 卡、5 秒 720P 出片算:
| 方式 | 单条耗时 | 单条成本 | 适合 |
|---|---|---|---|
| 自购 4090(约 1.5 万元) | 8–15 分钟 | 电费几毛钱 | 长期做,每天出片 |
| 云 GPU 按小时(约 2–4 元/时) | 同上 | 0.5–1 元 | 偶尔做,验证选型 |
| 商用 API | 1–3 分钟 | 几元到几十元 | 要快、不要可控性 |
算下来一个反直觉的结论:每月出片超过 50 条,自己买卡就回本了,还没算上不用排队、不用等审核、素材不出本地的隐性收益。
二、硬件门槛
| 显存 | 能跑什么 | 5 秒 720P 出片 |
|---|---|---|
| 8 GB | 10 亿参数级、480P 档 | 超时或极慢,勉强可用 |
| 12 GB | 50 亿参数级(量化) | 8–15 分钟 |
| 16 GB | 50 亿参数级原生、130 亿级量化 | 6–12 分钟 |
| 24 GB | 140 亿级(4-bit)、130 亿级(fp8) | 6–15 分钟 |
| 48 GB | 140 亿级 fp8 常驻,不用 offload | 4–6 分钟 |
| 80 GB / 多卡 | 300 亿级、原生精度 | 不适合单卡作业 |
除了显存,还有两个容易忽略的指标:显存带宽和磁盘。视频模型的瓶颈常在带宽而不是算力,同代卡里带宽高的那个更快;模型文件单个 7–28 GB,放机械盘每次加载几分钟,直接毁掉你的迭代节奏,必须上 NVMe。
三、环境搭建
用 ComfyUI 做底座,理由很简单:它把模型加载、采样、解码、视频封装做成了可视化链路,改参数不用改代码,而且所有主流视频模型都有现成节点。
# 准备好源码目录后进入(Windows 用官方一键包更省事)
cd ComfyUI
python -m venv venv && source venv/bin/activate
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
pip install -r requirements.txt
# 启动(24G 卡建议先不加任何省显存参数,跑通了再说)
python main.py --listen 0.0.0.0 --port 8188
目录要提前分好,模型按类型放,别全塞一个文件夹:
models/
├── diffusion_models/ 主模型(UNet/DiT),单个 7–28 GB
├── text_encoders/ 文本编码器,约 5–11 GB
├── vae/ 解码器,1 GB 以内
├── loras/ 风格与角色
└── upscale_models/ 放大
四、跑通第一条视频
先用 50 亿参数那一档跑通,别一上来就啃 140 亿。节点链是这样的:
LoadImage ──► ImageScale(短边 720) ─┐
CLIPTextEncode(正向) ───────────────┤
CLIPTextEncode(负向) ───────────────┼─► 视频潜空间构建 ─► KSampler ─► VAEDecode ─► SaveVideo
UNETLoader ─► ModelSamplingSD3 ─────┤
CLIPLoader(type=wan) ───────────────┘
关键参数,这几个错了画质直接崩:
| 参数 | 建议 | 为什么 |
|---|---|---|
| 分辨率 | 1280×704 或竖屏反过来 | 必须是 32 的倍数,否则边缘撕裂 |
| 帧数 | 121(24fps × 5 秒) | 一般是 4n+1,帧数比分辨率更吃显存 |
| steps | 30 | 低于 25 细节明显掉 |
| cfg | 5.0 | 超过 7 会过饱和、运动僵硬 |
| shift | 8–12 | 控制运动幅度,越大越「动」 |
五、上 140 亿:为什么要分两段采样
这一档的模型是「双噪声专家」结构——高噪声阶段负责构图和运动,低噪声阶段负责细节和质感,是两个独立的权重文件。所以采样必须拆成两段:
UNETLoader(高噪声) ─► KSampler#1 steps 0→10 (start 0, end 0.5)
UNETLoader(低噪声) ─► KSampler#2 steps 10→20 (start 0.5, end 1)
└─► VAEDecode
最常见的翻车点:两个采样器的 start/end 不互补。写成 0→0.5 和 0.6→1,中间那段没人负责,出来就是糊的;写成 0→0.6 和 0.4→1,重叠那段被采样两次,出来全是噪点。必须严格 0.5 对 0.5。
六、显存不够的三条补救路线
按性价比排序,从上到下试:
- 降步数:30 → 20,速度提升 33%,画质损失很小。这是第一选择。
- 4-bit 量化:把主模型权重压到 4 位,140 亿参数的 28 GB 变 7 GB,从「必须分层换入换出」变成「常驻显存」,速度反而更快。现在的量化方案有低秩补偿,画质损失肉眼不可见。
- INT8 注意力:视频的注意力计算占整体 60% 以上,把 QK 用 INT8 算,端到端 2 倍左右。装好对应的加速库,启动加一个参数就行。
- 跳步缓存:相邻去噪步的输出高度相似,判断「这步可以复用上一步」,再快 1.5 倍。草稿开、终稿关。
三个可以叠加。千万别一上来就用 offload(把权重换进内存),那是最后手段——PCIe 往返的代价比量化大得多,很多人第一天就被它劝退。
七、OOM 排查表
| 现象 | 原因 | 处理 |
|---|---|---|
| 一开始就崩 | 模型没装下 | 换 fp8/4-bit,或加 --lowvram |
| 采样到一半崩 | 序列太长 | 先降帧数,再降分辨率 |
| 最后一步崩 | VAE 解码爆显存 | 用分块解码,块大小 256 |
| 跑几批后越来越慢 | 显存碎片 | 每批之间重启进程,或关掉内存优化 |
| 速度只有别人三分之一 | 没开加速后端 | 装注意力加速库 + 启动加参数 |
八、什么时候该上云
如果只是验证「这个模型适不适合我的题材」,别买卡。租一张按小时计费的 4090,把模型下到数据盘(别用系统盘,会被清理),跑完就退。
真正要长期做,可以把本地当草稿机、云端当终稿机:本地用 50 亿参数快速试构图,确定之后再上云用 140 亿原生精度渲染。要远程操作那台云机器,用内网穿透把服务暴露出来就行,具体做法可以看 frp 内网穿透实战 那篇。
九、几个反直觉的经验
- 提示词写景别和光线,比堆形容词有用。「中景,侧逆光,浅景深」比「超级唯美电影级画质」有效得多。
- 图生视频永远优于文生视频。先用图像模型把构图做死,再让视频模型动起来,可控性差一个量级。
- 固定种子做 A/B。换参数不换种子,才能对比出到底是哪个参数起作用。
- 别追新模型。生态(节点、量化包、LoRA)成熟度比模型本身的跑分更重要,一个没人做量化的新模型对 24G 卡等于不存在。





