Wan2.2文生视频本地部署与ComfyUI显存优化实战

Wan2.2 这套文生视频模型刚开源那阵子，我连着熬了三个晚上。不是因为它难用，恰恰相反——它能跑起来得太容易了，容易到你会低估它：随便下个整合包，点一下生成，五秒后一条 480P 的片子出来了，看着还挺像回事。然后你就开始加分辨率、加帧数、换 720P，下一秒显存爆了；你改参数、换采样器，画面开始扭；你上双专家切换，结果第二段采样接不上，画面直接糊成一片。这几天我被同行问得最多的一句话是：“Wan2.2 到底怎么在本地稳稳跑起来？”

这篇东西就是回答这个问题的。我把 Wan2.2 文生视频从本地部署、ComfyUI 工作流搭建、显存优化到实测数据的整套流程捋一遍，包括那些官方文档里不会写、但你一定会撞上的坑。适合谁看：手里有一张 16G 到 24G 显存的卡、想在本地自己出片、不满足于在线服务那点免费额度的人；也适合已经在跑但总在“爆显存”和“画面崩”之间反复横跳的人。我尽量不写废话，参数给区间、步骤给顺序、坑给原因。

1. 先搞清楚 Wan2.2 到底改了什么

1.1 双专家架构是理解一切的前提

很多人一上手就卡在“为什么有两个模型文件”这件事上。Wan2.2 最核心的变化是把过去一个大模型干到底的思路，换成了两个专家模型接力：一个负责高噪声阶段（画面从纯噪声里长出大致构图和运动趋势），一个负责低噪声阶段（把细节、纹理、光影补完）。这套设计本质上是混合专家（MoE）思路在扩散采样时间轴上的落地——不是按 token 分流，而是按采样步数区间分流。

这个改动带来的直接后果有三个。第一，模型体积翻倍，两个专家加起来权重文件很大，下载和存放要提前规划盘位。第二，采样过程变成两段式，你在 ComfyUI 里需要两次采样或者一条带切换逻辑的采样链路，中间那个切换点（信噪比阈值或者步数边界）设错了，画面就会在两段之间出现明显的“断层感”——前一秒还是构图草稿，后一秒突然变成另一种质感。第三，显存占用不是简单的“两个模型同时加载”，而是要看你的调度策略，能不能做到跑完第一个专家就把它请出显存。

我一开始图省事，把两个专家都常驻显存，24G 卡在 720P 下必炸。后来老老实实做分时加载，峰值才压下来。所以你在动手之前，先把“双专家是分时的，不是并发的”这句话刻进脑子里，后面所有优化都是围绕这一点展开的。

1.2 版本怎么选：先看卡，再看需求

Wan2.2 这一代不是单一模型，而是一个系列，不同规格对硬件的要求差得很远。我按我这边的实际体验整理了一张对照表，参数是经验值，你的具体环境可能有出入，但量级不会偏太多。

选择逻辑很简单：如果你的目标是“先跑通、快速验证创意”，直接上中等参数版，它在消费级卡上的体验最接近“能用”，720P 原生支持，帧率也更顺。如果你追求画面质感和运动自然度，大参数量版是绕不过去的，但你要做好和显存打交道的心理准备。图生视频版适合你已经有一张满意的首帧图、只需要让它动起来的场景，稳定性比纯文生视频高不少，因为构图已经定了，模型不用猜。

我的建议是：先用中等参数版把整个 ComfyUI 链路跑熟、把提示词写法摸清楚，再切大参数量版。别一上来就啃最硬的骨头，那不是学习，那是自虐。

1.3 别急着下模型，先算清楚你的时间成本

这里有个很多人忽略的现实问题：大参数量版在 24G 卡上出一段 5 秒 480P，我这边实测单条在 6 到 9 分钟之间（取决于步数和优化开关），而中等参数版只要 2 到 3 分钟。如果你一天要试二十个提示词方向，这个差距就是两小时和四十分钟的区别。

所以我的实际工作流是双轨制：创意探索阶段全用中等参数版，快速筛出三条满意方向；定稿阶段再上大参数量版精修。这个策略帮我省了大量时间。你在部署之前就把这个分工想好，比后面反复折腾配置划算得多。

2. 本地部署：从裸机到跑出第一条片

2.1 环境依赖的取舍，坑都在版本号上

部署这件事，最容易出问题的不是模型本身，是 Python 环境和 CUDA 版本。我踩过的最典型的坑是：系统里装了两个 Python，pip 装到了 A，启动脚本用的是 B，然后报“找不到模块”，查了半小时。

给一套我这边验证过能跑通的组合思路：Python 用 3.10 或 3.11（3.12 部分依赖还没跟上，别当小白鼠）；PyTorch 版本要和你的 CUDA 驱动匹配，不是越新越好，大版本对齐就行；ComfyUI 本体用最近两三个月的版本，太老的版本对 Wan2.2 的原生节点支持不全，你可能得装一堆自定义节点来补。

# 创建独立环境，别污染系统 Python python -m venv venv_wan source venv_wan/bin/activate # Windows 用 venv_wan\Scripts\activate # 安装 PyTorch，版本按你驱动来，这里只是示例组合 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124 # 验证是否真的装对了 python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

最后那行验证一定要跑。cuda.is_available()返回False的话，后面全是白忙活，先解决这个再往下走。常见原因是驱动版本太旧，或者装成了 CPU 版 wheel。

注意：不要在一个环境里同时装多个 CUDA 版本的 PyTorch，卸载重装比修依赖快得多。我第一次图省事直接覆盖安装，结果各种奇怪的符号错误报了两小时。

2.2 模型文件的目录约定，别自己发明

ComfyUI 的目录结构是有约定的，模型放错位置，界面里就是空的。Wan2.2 相关的文件大致分三类，各自有归属：

• 扩散模型权重（两个专家各一个文件）放进ComfyUI/models/diffusion_models/，部分旧版本是models/unet/，看你界面的加载节点提示。
• 文本编码器（umt5 这一类的编码器权重）放进ComfyUI/models/text_encoders/。这个文件不小，好几个 G，第一次加载慢是正常的。
• VAE 解码器放进ComfyUI/models/vae/。

文件命名建议保留原始名字，别改成“wan大模型_最终版_真的最终.bin”这种。ComfyUI 的模板工作流里节点是按文件名索引的，改名字会让你每次都要手动重选，批量跑的时候特别烦。

我第一次部署时把两个专家权重放同一个目录但名字太像，结果在节点下拉框里选错了一个，跑了半天画面全是噪点，一度以为是采样器参数问题。后来发现是加载了低噪声专家去跑第一步。这个教训写下来给你：两个专家文件的命名一定要在下载时就做好区分，比如带high和low标识，别信自己的记性。

2.3 启动参数，从保守开始

第一次启动不要贪心，用保守参数先跑通，再逐步放开。

python main.py --listen 127.0.0.1 --port 8188 --reserve-vram 1.0

--reserve-vram这个参数值得单说。它给系统预留一部分显存，避免生成到一半被系统其他进程抢走导致崩溃。我一般设 0.8 到 1.5 之间，卡越紧张设得越保守。不设的话，你在跑图的同时开个浏览器看文档都可能把任务顶掉。

如果显存实在紧张，ComfyUI 还有--lowvram这类分级卸载参数，但我的建议是先别用。这类参数会把模型层拆到内存和显存之间来回搬，速度掉得很明显，而且有些情况下会引入额外的数值误差。正确的顺序是：先用正常模式，通过工作流层面的块交换和量化来解决，实在不行再上启动参数。

启动后浏览器打开界面，先加载一个最简的文生视频模板工作流，分辨率设 480P、帧数设最小值（比如 33 帧），步数设 10，跑一条看看。这条片子质量不用管，只要它能完整输出、不报错、不 OOM，环境就算通了。

3. ComfyUI 工作流：节点怎么连，参数怎么调

3.1 最小可用链路的节点顺序

一个能跑通的文生视频工作流，主干链路是这样的：

模型加载（扩散模型，分高噪声/低噪声两个加载节点）→ 文本编码器加载 → VAE 加载 → 文本编码节点（正向/负向各一个）→ 空 latent 视频节点（设定分辨率、帧数、batch）→ 采样节点（两段）→ VAE 解码 → 视频合成/保存节点。

关键在于采样这一段。Wan2.2 的双专家不是自动切换的，你得手动设计接力：第一个采样节点用高噪声专家，跑前面若干步；第二个采样节点用低噪声专家，从第一步的结束位置接着跑。ComfyUI 里的KSamplerAdvanced就是干这个的，它有两个关键字段：start_at_step和end_at_step，加上return_with_leftover_noise开关来控制是否保留噪声状态交给下一个节点。

假设总步数 20，我的配法是：第一个采样节点start_at_step=0、end_at_step=10、return_with_leftover_noise=enable；第二个节点start_at_step=10、end_at_step=10000（表示跑到底）、return_with_leftover_noise=disable。这样两段刚好接上，不重叠也不留空。

有个细节：两个节点里的种子必须一致，且第二个节点的add_noise要关掉（因为噪声已经在第一段产生了）。我第一次配的时候两边种子不同，结果第二段相当于重新起了一遍噪声，画面前后完全对不上，像是两条视频硬拼在一起。

3.2 切换点设在哪里，直接影响画面稳定度

那个 10 步的切分点不是随便定的。原则是：高噪声专家负责的步数要覆盖构图确立的阶段，低噪声专家负责细节收敛。切太早，低噪声专家拿到的是还没成型的噪声，它不知道要画什么，容易出扭曲；切太晚，高噪声专家把细节做了一半，低噪声专家接手后质感会跳变。

我试过的几个切分比例（总步数 20 的前提下）：6/14 偏早，画面容易“糊”；10/10 是最稳的通用值；13/7 会偏晚，运动幅度大的场景容易出现局部僵硬。如果你赶时间不想调，直接用对半切，绝大多数场景都能接受。

总步数本身也有讲究。低于 16 步，画面细节明显不足，尤其是皮肤质感和大面积渐变天空会出现色块；高于 30 步，收益递减但时间线性增长，不划算。20 到 24 步是我这边性价比最高的区间。

3.3 提示词写法：动作用动词，场景用名词，别写小作文

文生视频的提示词和文生图不是一回事。图片模型吃形容词，视频模型更吃运动描述。我总结的写法是三层结构：

第一层，主体与场景（谁，在哪，什么环境）。第二层，动作与镜头（在做什么，镜头怎么动）。第三层，质感与光线（什么风格，什么光线条件）。

举个例子，写一个人在海边散步：

一个穿浅色风衣的人沿着海岸线行走，中景，镜头缓慢横向跟随，海浪在身后退去，傍晚侧逆光，色调偏冷，胶片颗粒感。

对比一下不推荐的写法：“一幅非常美丽、令人惊叹、极致细节的、超高清的、8K 的海边散步画面”——这类堆砌形容词的写法在视频模型上效果很差，因为模型没接收到任何运动信息，出来大概率是个人杵在那儿轻微抖动。

另外，负向提示词要写，但别写太长。我的常用负向词就几个：模糊、低质量、变形、多余肢体、闪烁、水印。写一长串负向词反而会让模型过度抑制，画面变得死板。

心得：如果你发现生成的视频人物动作幅度太小，别急着改采样器，先在正向提示词里加一个明确的运动动词，比如“转身”“挥手”“快步走”。Wan2.2 对动词的响应比对形容词敏感得多。

3.4 常用参数速查表

我把常用参数的推荐区间整理成表，方便你对照着调。这些是我在中等参数版和大参数量版上反复试出来的经验值，不是绝对标准，但作为起点够用了。

那个shift参数值得单独提一句。它控制采样过程中噪声分布的偏移程度，直观表现就是“模型多早开始认真画细节”。480P 下用默认值就行，上到 720P 如果不调高，你会发现画面构图特别容易塌成一团、主体位置飘忽。这个参数不是玄学，很多人在 720P 下抱怨“模型变笨了”，其实就差这一个数。

4. 显存优化：把不可能变成能跑

4.1 量化：fp8 几乎是必选项

先说结论：消费级显卡跑 Wan2.2，权重用 fp8 量化版本，这是基线，不是可选项。fp16 原版权重在大参数量版上对显存的需求远超 24G，靠块交换也救不回来，因为单个层加载进来就已经溢出了。

fp8 的代价是什么？理论上精度损失会体现在细节和色彩过渡上，但实际观感差异比我预期小很多。我在同一提示词、同种子下做过 fp16（小分辨率验证用）和 fp8 的对比，主要差异在暗部细节和大面积渐变区域，fp8 版本偶尔会出现轻微的色阶断层，快速运动的帧上几乎看不出来。对于绝大多数用途，这个代价完全可以接受。

需要注意的一点：文本编码器建议单独考虑精度。有些整合包会把编码器也一起量化，导致提示词理解能力下降，表现为“你说东它画西”。我的做法是编码器保留较高精度，扩散模型用 fp8，这样显存大头省下来了，语义理解又没受损。

4.2 块交换的顺序陷阱

块交换（block swap）的原理是把模型的一部分层留在内存里，需要时再搬到显存，用时间换空间。这个机制在 Wan2.2 上尤其重要，因为双专家本身就不能并存。

但这里有个顺序陷阱：文本编码器必须在扩散模型加载之前完成运算并释放。如果你让编码器一直挂在显存里，等你切换两个专家的时候，那点被占用的空间就是压垮骆驼的最后一根稻草。我在 24G 卡上跑 720P 时，就是因为编码器没卸载，反复 OOM，查了很久才定位到。

具体做法：在编码节点之后、采样节点之前，加一个卸载/清理节点（不同版本的工作流里名字不一样，有的叫Unload Model，有的在编码节点自带unload_after_encode开关）。开启后你会发现峰值显存能降 1 到 2G，这个量在临界点上就是能不能跑的区别。

块交换的数量怎么定？没有通用答案，得试。一般从“能跑通的最大值往下调”，找到一个不 OOM 且速度可接受的点。我这边 24G 卡跑 720P 大参数量版，块交换开到 20 到 30 个块（具体看你的层数）能跑，但单条时间会拉长到十几分钟，所以我更愿意在 480P 下做创意迭代。

4.3 分辨率、帧数、分块解码的三角平衡

显存占用的三个大头：分辨率、帧数、解码时的中间张量。前两个是平方级和线性级增长，第三个经常被忽略。

VAE 解码阶段是很多人 OOM 的地方——采样跑完了，到解码一步崩了，白等十分钟。原因是解码要把整个视频的潜变量一次性还原成像素，那一瞬间的峰值显存可能比采样还高。解决办法是开分块解码（tiling），把视频按时间或空间切块，逐块解码再拼起来。代价是块与块的交界处可能出现轻微接缝，把重叠区域调大一点能缓解。

分辨率和帧数的取舍有个实用原则：宁可降分辨率，不要减帧数。因为帧数少了，运动就不连贯，视频的“视频感”就没了，看着像幻灯片。而 480P 在手机上看完全够用，缩放一下观感损失不大。我自己对外发的片子，大部分是 480P 出的，只有需要大屏播放才上 720P。

4.4 注意力后端与缓存加速

如果你的卡支持，换一个更高效的注意力实现能同时改善速度和显存。这类后端在不同的卡上表现差异很大，没有普适最优，得自己试。我的经验是：在同一条工作流、同参数下分别跑一次，对比单条耗时和峰值显存，选那个综合最好的，别迷信网上的“某某后端快 30%”的说法，那是别人的卡。

另外还有一类缓存加速手段，思路是相邻采样步之间的计算结果变化不大，跳过一部分重复计算。这类方案在短视频上效果不错，能省 20% 到 30% 的时间，但在运动剧烈的场景里可能出现细节丢失或者轻微闪烁。我的用法是：草稿阶段开，定稿阶段关。别为了省那点时间牺牲最终成片质量。

5. 实测数据：不同配置到底差多少

5.1 测试条件说明

先把变量说清楚，不然数据没意义。我这边的测试环境：单卡 24G 显存，内存 64G，系统盘是固态，模型放在另一块固态上（这点重要，机械盘加载大模型会让你怀疑人生）。统一提示词、统一种子、统一 81 帧、采样器 uni_pc、CFG 4.0，只改分辨率和优化开关。每条跑三次取中位数。

要提醒的是，这些数字是我这边环境的实测，你的卡、你的驱动、你的散热状态都会让结果浮动，看趋势别看绝对值。

5.2 速度与显存对照

从数据能看出一个很现实的结论：大参数量版在 720P 下的时间成本是指数级上升的，从 480P 的 7 分钟跳到 16 分钟，翻了一倍多，而画质提升是线性的、有限的。这就是我坚持“480P 迭代、720P 定稿”的原因。

5.3 画质对照：什么时候值得上大模型

我做了几组同提示词的对照，结论是：大参数量版的优势主要体现在三件事上——人物手部和面部在运动中的稳定性、复杂场景（多主体、有遮挡）的空间关系正确性、以及慢镜头下的质感细腻度。而在“一个人走路”“风景空镜”这类简单场景上，中等参数版和它的差距肉眼可见但不算决定性。

所以判断标准很简单：如果你的片子涉及人物特写、多主体互动、快速运镜，值得花那个时间；如果只是风景、产品展示、简单动作，中等参数版足够，省下的时间够你多试十个创意。

6. 常见问题速查：我踩过的那些坑

6.1 报错与显存问题

有个特别隐蔽的情况：显存看起来没满，但还是 OOM。这往往是显存碎片导致的，不是总量不够。解决办法是重启 ComfyUI 进程，从干净状态跑。我现在的习惯是每跑十几条就重启一次，比出问题再排查省事。

6.2 画面问题排查

最后一条我要多说两句。主体漂移这个问题困扰了我很久，一开始以为是种子问题，换了几十个种子都一样。后来才想明白是 shift 参数在 720P 下没跟着调。分辨率上去了，噪声分布也得跟着偏移，否则模型在前几步就定错了构图，后面怎么采样都救不回来。这个道理和拍照一样：焦距变了，对焦也得重来。

7. 几个提效的实操技巧

7.1 批量排队策略：把等待时间用起来

单条几分钟的生成时间，最浪费的做法是盯着进度条看。我的做法是晚上挂机批量跑：准备好十几条提示词变体，用批量节点排进队列，第二天早上收片。这里有个技巧——批量任务里不要混用不同分辨率，因为工作流切换分辨率会触发模型重载，本来 3 分钟一条的任务可能变成 5 分钟。

另外建议把种子固定下来做 A/B 对比。同一个种子、只改一个参数，你才能看清那个参数到底起了什么作用。我见过太多人一次改五个参数，然后说“效果变好了但不知道为什么”，这种经验没法复用。

{ "batch_config": { "seed": 20240501, "fixed_params": ["resolution", "frames", "sampler", "steps"], "variable_param": "cfg_scale", "values": [3.0, 3.5, 4.0, 4.5, 5.0] } }

按这个思路跑一轮，你就能画出自己环境下的 CFG 响应曲线，比看任何教程都准。

7.2 提示词模板与素材管理

我现在维护了一个自己的提示词模板库，按场景分类：人物动作类、风景空镜类、产品展示类、抽象概念类。每类下面有几个经过验证的骨架，用的时候只替换主体和细节。这比每次从零写快得多，而且出片质量的稳定性明显提升。

模板的管理有个小细节：把每条成功出片的完整参数（含种子、步数、CFG、shift）一起记下来。文生视频的随机性比文生图大，你很难凭记忆复现一条满意的片子。我的记录就是一个简单的表格，字段是：日期、提示词、种子、关键参数、评价、文件路径。花十秒钟记录，能省后面半小时的瞎试。

最后再分享一个我在实际操作中的体会：Wan2.2 这类模型的参数调优，最忌讳的是“追求一套万能配置”。同一个参数在不同场景下的最优值能差出一倍，因为视频内容本身差异太大。真正省时间的做法是建立自己的对照组习惯——每次只动一个变量，跑两三条对比，把结论记下来。跑上二三十轮之后，你对这套模型的手感会比任何教程都可靠。