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 这一代不是单一模型而是一个系列不同规格对硬件的要求差得很远。我按我这边的实际体验整理了一张对照表参数是经验值你的具体环境可能有出入但量级不会偏太多。版本规格参数量级原生分辨率典型帧数建议显存fp8 量化24G 卡体感大参数量版A14B 级激活约 14B480P / 720P81 帧20G 起需块交换480P 顺畅720P 需要调优中等参数版5B 级约 5B720P121 帧12G 起720P 直接跑出片快图生视频版与大参数量版同级480P / 720P81 帧同上首帧锁定后稳定性更好选择逻辑很简单如果你的目标是“先跑通、快速验证创意”直接上中等参数版它在消费级卡上的体验最接近“能用”720P 原生支持帧率也更顺。如果你追求画面质感和运动自然度大参数量版是绕不过去的但你要做好和显存打交道的心理准备。图生视频版适合你已经有一张满意的首帧图、只需要让它动起来的场景稳定性比纯文生视频高不少因为构图已经定了模型不用猜。我的建议是先用中等参数版把整个 ComfyUI 链路跑熟、把提示词写法摸清楚再切大参数量版。别一上来就啃最硬的骨头那不是学习那是自虐。1.3 别急着下模型先算清楚你的时间成本这里有个很多人忽略的现实问题大参数量版在 24G 卡上出一段 5 秒 480P我这边实测单条在 6 到 9 分钟之间取决于步数和优化开关而中等参数版只要 2 到 3 分钟。如果你一天要试二十个提示词方向这个差距就是两小时和四十分钟的区别。所以我的实际工作流是双轨制创意探索阶段全用中等参数版快速筛出三条满意方向定稿阶段再上大参数量版精修。这个策略帮我省了大量时间。你在部署之前就把这个分工想好比后面反复折腾配置划算得多。2. 本地部署从裸机到跑出第一条片2.1 环境依赖的取舍坑都在版本号上部署这件事最容易出问题的不是模型本身是 Python 环境和 CUDA 版本。我踩过的最典型的坑是系统里装了两个 Pythonpip 装到了 A启动脚本用的是 B然后报“找不到模块”查了半小时。给一套我这边验证过能跑通的组合思路Python 用 3.10 或 3.113.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_step0、end_at_step10、return_with_leftover_noiseenable第二个节点start_at_step10、end_at_step10000表示跑到底、return_with_leftover_noisedisable。这样两段刚好接上不重叠也不留空。有个细节两个节点里的种子必须一致且第二个节点的add_noise要关掉因为噪声已经在第一段产生了。我第一次配的时候两边种子不同结果第二段相当于重新起了一遍噪声画面前后完全对不上像是两条视频硬拼在一起。3.2 切换点设在哪里直接影响画面稳定度那个 10 步的切分点不是随便定的。原则是高噪声专家负责的步数要覆盖构图确立的阶段低噪声专家负责细节收敛。切太早低噪声专家拿到的是还没成型的噪声它不知道要画什么容易出扭曲切太晚高噪声专家把细节做了一半低噪声专家接手后质感会跳变。我试过的几个切分比例总步数 20 的前提下6/14 偏早画面容易“糊”10/10 是最稳的通用值13/7 会偏晚运动幅度大的场景容易出现局部僵硬。如果你赶时间不想调直接用对半切绝大多数场景都能接受。总步数本身也有讲究。低于 16 步画面细节明显不足尤其是皮肤质感和大面积渐变天空会出现色块高于 30 步收益递减但时间线性增长不划算。20 到 24 步是我这边性价比最高的区间。3.3 提示词写法动作用动词场景用名词别写小作文文生视频的提示词和文生图不是一回事。图片模型吃形容词视频模型更吃运动描述。我总结的写法是三层结构第一层主体与场景谁在哪什么环境。第二层动作与镜头在做什么镜头怎么动。第三层质感与光线什么风格什么光线条件。举个例子写一个人在海边散步一个穿浅色风衣的人沿着海岸线行走中景镜头缓慢横向跟随海浪在身后退去傍晚侧逆光色调偏冷胶片颗粒感。对比一下不推荐的写法“一幅非常美丽、令人惊叹、极致细节的、超高清的、8K 的海边散步画面”——这类堆砌形容词的写法在视频模型上效果很差因为模型没接收到任何运动信息出来大概率是个人杵在那儿轻微抖动。另外负向提示词要写但别写太长。我的常用负向词就几个模糊、低质量、变形、多余肢体、闪烁、水印。写一长串负向词反而会让模型过度抑制画面变得死板。心得如果你发现生成的视频人物动作幅度太小别急着改采样器先在正向提示词里加一个明确的运动动词比如“转身”“挥手”“快步走”。Wan2.2 对动词的响应比对形容词敏感得多。3.4 常用参数速查表我把常用参数的推荐区间整理成表方便你对照着调。这些是我在中等参数版和大参数量版上反复试出来的经验值不是绝对标准但作为起点够用了。参数480P 推荐值720P 推荐值说明采样器uni_pc / dpm 2muni_pc前者通用后者在 720P 更稳调度器simple / betasimplebeta 在低步数下细节更好总步数2022-24720P 建议多给两步CFG3.5-4.53.5-4.0太高会过曝和僵硬shift 参数5.08.0-12.0高分辨率必须调高否则构图塌帧数8181 或模型原生档位非原生帧数尾帧易跳变那个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。优化手段显存节省幅度速度影响画质影响建议fp8 量化约 40-50%略快轻微必开块交换20-40%明显变慢无显存紧张时开编码器用完即卸1-2G无无必开VAE 分块解码高峰值降 30%略慢接缝需注意720P 必开降分辨率 720P→480P约 50%快一倍以上明显迭代阶段用4.4 注意力后端与缓存加速如果你的卡支持换一个更高效的注意力实现能同时改善速度和显存。这类后端在不同的卡上表现差异很大没有普适最优得自己试。我的经验是在同一条工作流、同参数下分别跑一次对比单条耗时和峰值显存选那个综合最好的别迷信网上的“某某后端快 30%”的说法那是别人的卡。另外还有一类缓存加速手段思路是相邻采样步之间的计算结果变化不大跳过一部分重复计算。这类方案在短视频上效果不错能省 20% 到 30% 的时间但在运动剧烈的场景里可能出现细节丢失或者轻微闪烁。我的用法是草稿阶段开定稿阶段关。别为了省那点时间牺牲最终成片质量。5. 实测数据不同配置到底差多少5.1 测试条件说明先把变量说清楚不然数据没意义。我这边的测试环境单卡 24G 显存内存 64G系统盘是固态模型放在另一块固态上这点重要机械盘加载大模型会让你怀疑人生。统一提示词、统一种子、统一 81 帧、采样器 uni_pc、CFG 4.0只改分辨率和优化开关。每条跑三次取中位数。要提醒的是这些数字是我这边环境的实测你的卡、你的驱动、你的散热状态都会让结果浮动看趋势别看绝对值。5.2 速度与显存对照配置分辨率总步数单条耗时峰值显存备注中等参数版 fp8720P20约 2 分 40 秒约 13G无需块交换中等参数版 fp8480P20约 1 分 30 秒约 9G迭代首选大参数量版 fp8480P20约 7 分钟约 21G开少量块交换大参数量版 fp8720P22约 16 分钟约 23.5G块交换 20接近极限大参数量版 fp8 缓存加速480P20约 5 分钟约 21G质量略有损失从数据能看出一个很现实的结论大参数量版在 720P 下的时间成本是指数级上升的从 480P 的 7 分钟跳到 16 分钟翻了一倍多而画质提升是线性的、有限的。这就是我坚持“480P 迭代、720P 定稿”的原因。5.3 画质对照什么时候值得上大模型我做了几组同提示词的对照结论是大参数量版的优势主要体现在三件事上——人物手部和面部在运动中的稳定性、复杂场景多主体、有遮挡的空间关系正确性、以及慢镜头下的质感细腻度。而在“一个人走路”“风景空镜”这类简单场景上中等参数版和它的差距肉眼可见但不算决定性。所以判断标准很简单如果你的片子涉及人物特写、多主体互动、快速运镜值得花那个时间如果只是风景、产品展示、简单动作中等参数版足够省下的时间够你多试十个创意。6. 常见问题速查我踩过的那些坑6.1 报错与显存问题现象最可能原因排查顺序采样到一半 OOM峰值在解码或专家切换瞬间先开 VAE 分块解码再开块交换最后降分辨率加载模型时直接 OOM编码器未卸载或同时加载了两个专家检查加载节点是否分时确认编码器释放报“找不到模型文件”目录放错或文件名被改对照节点下拉框里的实际文件名进度条卡住不动显存换页频繁或磁盘读取慢看任务管理器磁盘占用模型换到固态盘生成速度异常慢块交换设太多或走了内存交换逐项关闭优化开关做对照有个特别隐蔽的情况显存看起来没满但还是 OOM。这往往是显存碎片导致的不是总量不够。解决办法是重启 ComfyUI 进程从干净状态跑。我现在的习惯是每跑十几条就重启一次比出问题再排查省事。6.2 画面问题排查画面表现可能原因处理方向前后半段质感断层专家切换点设置不当调整 start_at_step往中间靠人物肢体扭曲提示词动作描述与训练分布差距大简化动作描述改用更常见的动作整体闪烁抖动步数过低或 CFG 过高步数提到 20 以上CFG 降到 4 以下尾帧突然跳变帧数不是模型原生档位改用原生帧数如 81画面发灰、对比度低负向提示词过强或 CFG 偏低精简负向词CFG 提到 3.5 以上主体位置漂移高分辨率下 shift 未调整720P 时把 shift 提到 8 以上最后一条我要多说两句。主体漂移这个问题困扰了我很久一开始以为是种子问题换了几十个种子都一样。后来才想明白是 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 这类模型的参数调优最忌讳的是“追求一套万能配置”。同一个参数在不同场景下的最优值能差出一倍因为视频内容本身差异太大。真正省时间的做法是建立自己的对照组习惯——每次只动一个变量跑两三条对比把结论记下来。跑上二三十轮之后你对这套模型的手感会比任何教程都可靠。