1. 先把需求摆清楚本地跑视频模型到底图什么去年这个时候想在本地生成一段三秒的像样视频基本上得有张 80G 的卡才敢开高分辨率。现在情况变了Wan2.2 这类开源文生视频模型把门槛压到了消费级显卡能够到的位置ComfyUI 那边的工作流也成熟到可以当生产力工具用。但真动手的人都知道能跑和好用之间隔着一条显存和参数的鸿沟——网上大部分教程只教你把 demo 跑出来不告诉你为什么这里要开分块、为什么那一步步数不能再加。这篇内容就是把我这段时间折腾 Wan2.2 的完整过程摊开讲从本地部署的环境踩坑、ComfyUI 工作流怎么搭、显存怎么省到不同参数组合下的实测耗时与画质对照。看完你应该能做到三件事在自己的机器上把 Wan2.2 跑通并稳定出片知道显存不够时该砍哪一刀、不该砍哪一刀面对画面糊成一团人物手脚变形跑一半 OOM这些高频故障能自己定位而不是到处问人。适合谁看手里有 12G 到 48G 显卡、想搞清楚本地视频生成全流程的个人创作者和小团队已经在用 ComfyUI 做图、想往视频方向延伸的人以及被各种一键整合包坑过、想弄明白底层到底发生什么的人。不要求你会训练模型但基础的 Python 环境操作、命令行执行、ComfyUI 的基本概念得有一点底子否则后面几节会读得比较吃力。1.1 三种典型需求对应三套完全不同的方案我把找过来问怎么本地跑视频的人大致分成三类他们的最优解其实差别很大很多人一开始就没搞清楚自己属于哪一类结果在错误的方案上耗了一两周。第一类是验证性需求想看看开源模型到底能做到什么程度产出主要给自己看画质差一点无所谓重要的是快、免费、不用等额度。这类人最该走的是 5B 版本的文生视频720P、24fps一张 12G 到 16G 的卡配上 CPU 卸载就能出片一分钟左右的单条耗时完全可以接受。第二类是内容生产需求需要稳定产出可发布的素材可能要批量生成、要控制构图、要保持角色一致性。这类人绕不开 14B 的 MoE 版本和 ComfyUI 工作流因为只有工作流形态才能做首尾帧衔接、图生视频、局部重绘这些精细控制。显卡建议 24G 起步最好 48G不然每条视频都在跟显存搏斗。第三类是研究/微调需求要改结构、要 LoRA、要做自己的数据。这类基本得 80G 级别的卡或者多卡本文不展开但显存优化的那几节对你同样有用。提示先想清楚自己属于哪一类再决定下载哪个版本的权重。14B 的两个专家模型加起来接近 60GB 的原始权重下载和解压的时间成本不低很多人下完才发现自己的卡根本带不动。1.2 Wan2.2 的版本矩阵别下错权重Wan2.2 这个模型家族内部差异挺大不是简单的大小号关系架构上就有区别选错了会很痛苦。我整理成一张表你可以对着自己的显卡和需求直接挑。版本架构典型分辨率帧数/时长推荐显存适合场景T2V-A14BMoE 双专家总参数约 27B单次激活约 14B1280×704 / 704×128081 帧 / 约 3.4 秒24G 起需卸载追求画质的文生视频I2V-A14B同上的图生视频版本同上同上24G 起需卸载首帧控制、角色延续TI2V-5B稠密 5B1280×704121 帧 / 约 5 秒12G 至 16G个人尝鲜、快速迭代这里有个很容易搞混的点MoE 版本不是跑两个模型而是高噪和低噪两个专家在采样过程的不同阶段接力——前段步数用高噪专家负责构图和运动趋势后段步数切换到低噪专家负责细节收敛。这个设计直接决定了 ComfyUI 里必须串两个采样器也是很多人第一次搭工作流时发现只有一个 KSampler 效果很怪的原因。另外5B 版本用的 VAE 跟 14B 不是同一个。14B 沿用 16×16×4 压缩比的旧版 VAE5B 用的是高压缩比的新 VAE解码速度更快、显存占用更低但两者不能混用。把 5B 的 VAE 喂给 14B 的 latent出来的就是一坨彩色噪点这个坑我踩过排查了半小时才反应过来。1.3 显存账本为什么 24G 是道分水岭很多人对显存的理解停留在模型多大就要多少显存实际远不止。跑一次 720P 视频推理显存消耗大致分四块模型权重fp16 下 14B 专家约 28GBfp8 量化后约 14GB文本编码器 umt5-xxl 约 5.6B 参数fp8 下约 6GB。激活值这是被严重低估的部分。视频 latent 的序列长度跟分辨率、帧数强相关1280×704、81 帧的 latent 展开大约是 4 万到 7 万个 token 量级注意力层的中间结果能吃光十几 G。KV 缓存单次推理不涉及多轮但长序列下的注意力缓存本身就不小。解码阶段峰值VAE 解码要把整个 latent 一次性铺开这一步的峰值往往比采样阶段还高。粗略估一下fp8 权重 14GB 文本编码器可以先编码完卸载6GB 激活 8GB 至 12GB24G 卡基本贴着上限走稍微加点分辨率或者多几帧就 OOM。这就是为什么分块解码、顺序卸载、分块交换这些技术不是可选项而是 24G 卡的生存必需品。48G 的卡会舒服很多可以完整跑一遍不卸载速度也快因为卸载本身是有代价的——权重在 CPU 和 GPU 之间来回搬PCIe 带宽会成为新的瓶颈。2. 环境搭建与命令行跑通第一段视频我不建议一上来就用 ComfyUI。先用命令行把最朴素的推理跑通你会对输入输出、显存曲线、每一步耗时建立起最直观的感受后面搭工作流时出问题才知道该怀疑哪一环。这一节按顺序走一遍。2.1 驱动与运行时环境别在这上面省时间显卡驱动尽量新但不要追最新。经验是选一个发布两三个月以上、社区反馈稳定的版本太新的驱动偶尔会有显存管理上的小毛病。CUDA 版本按你装的深度学习框架要求走不要手动去凑——让它自己带。Python 环境强烈建议用独立虚拟环境不要装在系统 Python 里。我见过太多人因为环境里同时装了多个版本的 torch出现明明装了却导入失败或者跑起来莫名很慢的情况。命令大概是这样conda create -n wan22 python3.10 -y conda activate wan22 pip install torch torchvision --index-url 对应CUDA版本的源 pip install -r requirements.txtPython 3.10 是我用得最稳的版本3.12 上个别依赖会有编译问题不建议新手去趟。装完先验证一下import torch print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))cuda.is_available()返回 False 的话先别急着装模型八成是驱动版本和 torch 的 CUDA 版本对不上。这一步不通过后面全是白费功夫。另外提醒一句磁盘空间要留足。权重、VAE、文本编码器、加上推理输出的视频一套下来一百多 G 很正常机械硬盘上做这件事会很痛苦尽量放固态。2.2 权重组织目录结构错了脚本就找不到东西官方脚本通常要求一个固定的目录结构权重文件按名字去对应位置找。我见过最常见的报错就是找不到某个 safetensors本质是放错了位置或者文件名改过。我的做法是建一个统一的模型根目录内部按类型分文件夹脚本里用一个--ckpt_dir指向它。大致长这样models/ ├── Wan2.2-T2V-A14B/ │ ├── config.json │ ├── diffusion_pth_high_noise.safetensors │ ├── diffusion_pth_low_noise.safetensors │ ├── models_t5_umt5-xxl-enc-bf16.pth │ └── Wan2.1_VAE.pth └── Wan2.2-TI2V-5B/ ├── config.json ├── diffusion_pth.safetensors ├── models_t5_umt5-xxl-enc-bf16.pth └── Wan2.2_VAE.pth注意文件名不要去改也不要为了省空间把 fp16 权重手动转成别的格式后沿用原名。脚本按名字加载类型不匹配时报错信息往往很含糊你会以为是显存问题实际是精度问题。下载完记得校验文件大小。大文件断点续传中断导致权重不完整加载时不会报文件损坏而是加载成功后跑出一堆毫无意义的画面这种问题最难查。2.3 命令行推理跑通第一段七秒钟的视频官方仓库一般会提供一个generate.py之类的入口脚本。以 14B 文生视频为例最小可用的命令形态大致是python generate.py \ --task t2v-A14B \ --size 1280*704 \ --ckpt_dir ./models/Wan2.2-T2V-A14B \ --offload_model True \ --convert_model_dtype \ --prompt a slow dolly shot through a rainy neon alley, reflections on wet asphalt, cinematic lighting几个参数值得单独说--size写成1280*704而不是1280x704是因为脚本内部按*分割。分辨率不是随便填的14B 版本在 1280×704 和 704×1280 这两个尺寸上是训练对齐的你填个 1024×1024 出来的画面很容易构图崩坏。--offload_model True的意思是把不参与当前计算的模块先挪到 CPU 内存需要时再搬回来。24G 卡上基本必开代价是速度慢一截。48G 卡可以关掉实测能快 20% 到 30%。--convert_model_dtype用于把权重在实际计算时转成合适的精度配合 fp8 权重使用时要注意别和量化设置打架。第一次跑建议把帧数调小比如先用 33 帧试试水。等确认整条链路通了、显存曲线也看过了再上 81 帧。第一次就直接冲满帧数然后 OOM你连哪一步炸的都看不清。跑完输出一般在outputs/目录下是 mp4 或者一组帧序列。第一次看到自己机器里蹦出来一段能动的视频那种感觉还是挺上头的。2.4 首次运行最容易踩的五个坑我把自己和别人遇到过的首次运行问题列一下基本都是环境层面的跟模型本身没关系。现象大概率原因处理方式启动即 OOM还没开始采样文本编码器和主模型同时加载开--offload_model或先单独跑编码再推理采样到一半 OOM激活峰值超出尤其 VAE 解码阶段降分辨率或帧数开分块解码报找不到权重目录结构或文件名不匹配严格按官方 README 的组织方式画面全是噪点/雪花VAE 版本用错5B 配 2.2 的 VAE14B 配 2.1 的 VAE速度慢到离谱权重放在机械盘或走了 CPU 推理换固态确认cuda.is_available()为真还有一个隐性问题某些发行版的显卡驱动会默认开启一些省电策略跑长任务时频率掉下来导致后半段明显变慢。如果你发现同一条视频前半段快后半段慢可以查一下是不是这个原因。3. ComfyUI 工作流从节点链路到参数手感命令行跑通之后转到 ComfyUI。这不是为了好看而是因为视频生成真正难的地方在于控制——你想让第二段视频接上第一段的尾巴想让角色的脸保持一致想局部改一个物体这些在纯命令行里做起来极其别扭在工作流里就是拖几个节点的事。3.1 安装与插件选型原生节点够用别一上来就堆插件ComfyUI 本体建议用官方仓库的版本跟着更新走。视频相关的节点近几个版本官方已经原生支持了 Wan 系列包括两个专家接力所需的采样器串联所以新手阶段完全不需要装额外插件。等你遇到原生节点解决不了的问题再考虑第三方封装。常见的扩展方向有三类一类是更灵活的显存管理支持按块把权重交换到内存一类是更快的注意力实现能明显降低长序列的显存和耗时一类是视频合成与后处理比如直接输出带音频的容器格式、批量拼接。装插件的原则我总结成一句话每装一个都要知道自己为什么装。插件冲突导致的报错往往发生在很底层的地方报错信息毫无指向性一装一堆插件然后到处求人是最浪费时间的做法。启动参数上如果你显存紧张可以在启动时加低显存模式如果显存宽裕加一个保留显存的参数避免系统其他程序抢占导致推理中途失败。3.2 文生视频主链路拆解两个采样器为什么要串起来这是整个工作流的核心搞懂这一段剩下的都是变体。链路大致是UNETLoader加载高噪专家权重文本编码节点正负提示词各一个接CLIPLoader加载的 umt5 编码器空 latent 节点生成初始噪声参数是宽、高、帧数、批大小第一个采样器从第 0 步跑到分界步用高噪专家把中间结果交给UNETLoader加载的低噪专家第二个采样器从分界步接着跑到结束VAEDecode解码成像素帧视频合成节点输出文件。关键在于第 4 和第 6 步之间。分界步一般取总步数的 87.5% 左右的位置附近做切换——这个数值不是拍脑袋是因为高噪专家负责的是从纯噪声到结构成型这个阶段低噪专家负责结构到细节切早了细节没出来切晚了结构已经被高噪专家带偏。实践中常见的做法是总步数 40 步前 35 步高噪、后 5 步低噪或者 20 步加 20 步的对称分配具体看你手上的模型卡说明。提示两个采样器之间的 latent 必须直接相连中间不要插任何缩放或者重采样节点。很多人为了让画面更清晰在这里加一个 latent 放大结果就是运动完全断裂。另外别忘了ModelSamplingSD3这个节点它负责设置采样偏移量。这个参数影响噪声调度曲线的形状视频模型上通常设得比图像模型大一些。调小了运动幅度不足画面像定格调大了运动剧烈但容易崩。3.3 采样参数的手感步数、引导强度、偏移量参数没有标准答案但有明确的调节方向。我按自己实测的经验给一组起点你在上面微调。参数常用区间调高的效果调低的效果采样步数30 至 50细节更实耗时线性增加出片快易糊、易断引导强度 CFG3.5 至 5.0更贴合提示词过高会过饱和、动作僵硬更自由过低会无视提示词采样偏移 shift5.0 至 8.0前期噪声主导更强构图更敢更保守画面更平切换分界比例0.8 至 0.9低噪专家介入晚细节收敛不足介入早结构容易没成型我的习惯是先用 40 步、CFG 4.0、shift 6.0 跑一条基线看构图对不对。构图不对就调提示词别急着调参数——提示词的问题调参数是治不好的。构图对了但细节糊加步数或者延后切换点。画面过饱和、颜色发焦降 CFG。3.4 图生视频与首尾帧真正能用的控制手段纯文生视频的随机性很大同一个提示词跑十次能出十种构图做内容生产基本没法用。真正能落地的是图生视频——给一张首帧让模型接着往下推。接法上把空 latent 节点换成专门的图生视频 latent 节点输入一张参考图节点内部会把这张图编码进 latent 的第一帧位置然后后续帧在采样中生成。这里有个细节参考图的分辨率比例最好和目标尺寸一致不一致时节点会做裁剪或填充填充出来的黑边会被模型当成画面内容第一条生成的视频里就会出现莫名其妙的黑框。首尾帧的玩法更进一步同时给第一帧和最后一帧模型在中间插值生成过渡。这个能力做转场、做循环视频特别好用。要注意的是首尾两帧的构图差异不能太大差异过大时中间帧会出现明显的形变扭曲因为模型在强行把两个不相干的结构连起来。实践中跨度控制在机位小幅移动、物体轻微变化的程度比较稳。3.5 提示词写法与批量出片视频模型的提示词和图像模型不太一样它多了时间维度。有效的写法是分成三层主体与场景、镜头运动、光线与质感。比如一个穿深色外套的人站在雨夜的巷口是主体镜头缓慢推近从全身到半身是运动湿滑地面反射霓虹光电影感冷色调是质感。三层写全出片稳定性会明显提升。反过来堆砌形容词是无效的。极致清晰、超高清、8K、大师作品这类词在视频模型上基本不起作用反而挤占了提示词的空间。负面提示词也不用写太长通用的几条就够写多了会误伤正常内容。批量出片时固定种子做参数扫描是最高效的方法种子不变只改一个参数跑四到六条横向对比。这样你能快速建立起对某个参数的手感比随机试快得多。4. 显存优化把 24G 用出 40G 的效果这一节是全文最实用的部分。显存不够是绝大多数人卡住的地方但绝大多数优化手段都有代价你得知道每一刀砍下去损失的是什么。4.1 显存到底被谁吃掉了再细化一下前面提的四块因为优化要对着具体来源下手。权重常驻这块最好理解fp16 的 14B 专家 28GBfp8 的 14GB。文本编码器 6GB 左右。这部分是静态的可以用量化、可以用卸载。激活值是动态的跟序列长度成正比。1280×704、81 帧的 latent 展开后序列很长注意力层的 QKV 中间结果、MLP 的中间激活都得留在显存里。这部分只能靠降分辨率、降帧数、或者用更省显存的注意力实现来压。VAE 解码峰值经常被忽略。解码时要把整个 latent 一次性展开成像素1280×704×81 帧的 RGB 数据本身就有几个 G中间层更多。分块解码就是专门治这个的。碎片化也很要命。长时间反复推理显存里会出现大量不连续的小块明明总空闲够却分配不出连续大块。解决办法是定期重启进程或者用固定形状的输入让分配器复用。4.2 量化fp8 是性价比最高的一刀权重从 fp16 降到 fp8显存直接减半画质损失在视频上其实很不明显——视频有时域冗余单帧的细微精度损失在运动中被眼睛平均掉了。这是我最推荐的优化手段优先级最高。再往下走是更激进的量化比如 4bit。我的实测结论是4bit 在文生视频上还能接受在图生视频和首尾帧任务上会出现明显的细节丢失尤其是人脸和手部。如果你做的是风景、抽象、慢镜头4bit 可以一试做人物特写就别碰了。精度转换的时候有个坑不要把文本编码器也一起压到很低。文本编码器负责理解提示词量化过度会导致模型听不懂你在说什么表现是画面元素缺失而不是画质变差——这个现象很容易被误判成提示词写得不好。4.3 分块解码与卸载慢但是能救命分块解码的原理是把画面切成若干块逐块解码再拼起来。显存峰值从整张画面降到一块画面代价是块与块交界处可能出现细微的接缝。控制接缝的办法是让块之间有重叠重叠比例一般设 1/8 到 1/4。重叠越大越平滑速度越慢。做静态镜头时重叠可以小一点快速运动镜头建议加大因为运动模糊本身会掩盖接缝。权重卸载分两种粒度整模块卸载和分块交换。整模块卸载实现简单就是用完就扔回内存但粒度粗来回搬运的数据量大分块交换更细可以指定把多少层放到内存里剩下多少留在显存灵活度高很多。24G 卡跑 14B 时我一般会交换掉一部分层保留足够的部分在显存里以保证计算效率。注意卸载的前提是主机内存要够。权重在内存里也要占地方内存不够时系统会开始用交换分区速度会掉到令人绝望。跑之前先看一眼内存余量16G 内存跑 14B 模型是很吃力的建议 32G 起步。4.4 不同显卡的配置模板直接给结论省得你自己试。显存推荐版本分辨率帧数关键设置12GTI2V-5B960×54449低显存模式 全量卸载 分块解码16GTI2V-5B1280×70481部分卸载 分块解码24GT2V-A14B fp81280×70481分块交换 分块解码 文本编码器用完即卸48GT2V-A14B fp8 或 bf161280×70481关闭卸载开更快的注意力实现12G 那一档要有心理准备出片速度会比较慢一条五秒视频跑十几分钟很正常。但它是能出片的而且画质对于社交平台发布够用了。5. 实测数据耗时、质量和参数的对应关系数据都是在同一台机器上、同一批提示词、同一套工作流下跑出来的横向可比。绝对数字跟你的硬件强相关看趋势比看数值有用。5.1 测试方法说明测试集用了 12 条提示词覆盖人物特写、风景航拍、物体运动、抽象流体四类每类三条。每条在同一配置下跑两次取平均避免单次波动。质量评价用主观打分五个维度构图合理性、运动自然度、细节清晰度、提示词遵循度、时序稳定性每个维度 1 到 5 分。这种打分不严谨但对自己做决策足够了。真要严谨评估得上客观指标和人工双盲那是另一个话题。5.2 分辨率与帧数对耗时的影响在 24G 卡、14B fp8、40 步固定配置下我测了几组尺寸组合分辨率帧数单条耗时显存峰值备注832×48049约 3 分 20 秒18G迭代调试首选1280×70449约 5 分 10 秒21G画质与速度平衡点1280×70481约 8 分 40 秒23.5G接近上限容易波动1280×704121溢出—24G 跑不动需要更强卸载这个表透露的信息是耗时跟分辨率基本成平方关系跟帧数接近线性。所以想省时间先降分辨率而不是先降帧数——帧数少了视频会变短促观感损失比分辨率下降更明显。另外注意 81 帧那一行显存峰值已经 23.5G意味着没有任何余量后台开个浏览器都可能把它挤爆。这种贴着上限跑的配置只适合专门跑批的机器。5.3 步数与引导强度存在明显的收益拐点固定分辨率和帧数只改步数主观质量评分大概是这样20 步时构图已经成型但细节糊30 步明显改善40 步进入平台期50 步相比 40 步的提升几乎感觉不到耗时却多了 25%。40 步是性价比拐点再往上加不太划算除非你在做最终的成片输出。引导强度上CFG 从 3.0 加到 4.0 时提示词遵循度提升最明显4.0 到 5.0 之间提升趋缓但色彩饱和度明显上升超过 5.5 之后画面开始发焦、动作变僵硬。我的默认值定在 4.0需要更强控制时最多到 4.8。偏移量 shift 的影响比较微妙。调高会让前期噪声更强构图更大胆适合需要冲击力的镜头调低则更稳适合产品展示这类需要可控性的内容。这个参数没有普适最优值得对着你的内容类型试。5.4 运动的自然度最容易被忽视的质量维度所有维度里运动自然度是最难调、也最能拉开差距的。我观察到几个规律运动幅度过小时画面像一张被轻微扰动的照片缺乏活着的感觉运动幅度过大时物体边缘会出现拖影和撕裂尤其是快速横向移动的物体。合适的区间比较窄而且跟提示词里描述的运动速度强相关——你写缓慢推近模型就真的动得很慢写快速穿梭边缘就容易崩。人物类内容还有个特殊问题手部和面部在运动中最容易变形。我的经验是提示词里避免让手部成为画面主体或者用构图把手部裁掉成片率会高很多。这不是模型能力的问题是当前阶段所有视频模型的共性。6. 常见问题速查与避坑经验最后一节整理故障排查。我把问题分成画面类、性能类两组每组的排查顺序都是先怀疑最便宜的环节。6.1 画面类问题先怀疑提示词和 VAE画面出问题很多人第一反应是调采样参数这是错的。排查顺序应该是VAE 版本对不对 → 提示词有没有歧义 → 分辨率比例是否对齐训练分布 → 最后才是采样参数。现象排查顺序全屏噪点VAE 版本错配 → latent 通道数不匹配画面发灰、对比度低引导强度偏低 → 负面提示词过强人物多手多脚提示词里动作描述过复杂 → 降分辨率重试运动断裂、跳帧两个采样器之间插了额外节点 → 分界步设置不合理局部模糊VAE 分块解码接缝 → 加大重叠比例首帧和参考图不一致参考图比例与输出比例不一致被裁剪有一个反直觉的经验画面糊的时候先检查是不是步数太少而不是分辨率太低。分辨率低只是整体不清晰但糊成一团、结构都看不清往往是采样不充分。6.2 性能类问题慢和崩是两回事跑得慢和跑崩了要分开处理。慢的话看是不是走了 CPU 卸载、权重是不是在机械盘、有没有开更快的注意力实现、批量大小是不是设成了 1 以上。崩的话看显存峰值出现在哪个阶段采样阶段崩就降分辨率或帧数解码阶段崩就开分块解码。还有个高频情况是跑了几条之后突然变慢。这通常是显存碎片化导致的重启进程就能恢复。如果长期出现考虑在两条推理之间做一次显存清理或者干脆用脚本控制进程周期性重启。6.3 我踩过的最深的三个坑第一个是把文本编码器的输出缓存搞混了。批量生成时为了省时间我把提示词编码结果缓存下来复用结果换了提示词之后忘记刷新缓存跑出来的十几条视频全是同一个内容。这种问题不会报错只会让你怀疑人生。第二个是在 24G 卡上关掉了卸载去追求速度。当时觉得峰值 23G 应该能撑住实际跑起来因为系统占了一点显存十条里崩三条。稳定比快重要尤其是批量任务。第三个是忽略了输出编码的开销。视频合成节点如果用了高码率编码CPU 会成为瓶颈GPU 明明跑完了却要等很久才出文件。这个环节的耗时在总时长里能占到一成以上批量跑的时候尤其明显。我个人在实际操作中的体会是这类工具真正的门槛不在能不能跑起来而在能不能稳定地重复跑出想要的东西。前者一两天就能解决后者得靠大量的参数试错积累手感。别急着追求一次出片先用低分辨率、少帧数把参数空间摸清楚把提示词模板打磨好再上高配出片整体效率反而更高。手上有闲置显卡的话可以挂个脚本夜里批量跑参数组合第二天早上看结果比白天守着屏幕一条条试快得多。 Wan2.2本地部署实战：ComfyUI工作流与显存优化
1. 先把需求摆清楚本地跑视频模型到底图什么去年这个时候想在本地生成一段三秒的像样视频基本上得有张 80G 的卡才敢开高分辨率。现在情况变了Wan2.2 这类开源文生视频模型把门槛压到了消费级显卡能够到的位置ComfyUI 那边的工作流也成熟到可以当生产力工具用。但真动手的人都知道能跑和好用之间隔着一条显存和参数的鸿沟——网上大部分教程只教你把 demo 跑出来不告诉你为什么这里要开分块、为什么那一步步数不能再加。这篇内容就是把我这段时间折腾 Wan2.2 的完整过程摊开讲从本地部署的环境踩坑、ComfyUI 工作流怎么搭、显存怎么省到不同参数组合下的实测耗时与画质对照。看完你应该能做到三件事在自己的机器上把 Wan2.2 跑通并稳定出片知道显存不够时该砍哪一刀、不该砍哪一刀面对画面糊成一团人物手脚变形跑一半 OOM这些高频故障能自己定位而不是到处问人。适合谁看手里有 12G 到 48G 显卡、想搞清楚本地视频生成全流程的个人创作者和小团队已经在用 ComfyUI 做图、想往视频方向延伸的人以及被各种一键整合包坑过、想弄明白底层到底发生什么的人。不要求你会训练模型但基础的 Python 环境操作、命令行执行、ComfyUI 的基本概念得有一点底子否则后面几节会读得比较吃力。1.1 三种典型需求对应三套完全不同的方案我把找过来问怎么本地跑视频的人大致分成三类他们的最优解其实差别很大很多人一开始就没搞清楚自己属于哪一类结果在错误的方案上耗了一两周。第一类是验证性需求想看看开源模型到底能做到什么程度产出主要给自己看画质差一点无所谓重要的是快、免费、不用等额度。这类人最该走的是 5B 版本的文生视频720P、24fps一张 12G 到 16G 的卡配上 CPU 卸载就能出片一分钟左右的单条耗时完全可以接受。第二类是内容生产需求需要稳定产出可发布的素材可能要批量生成、要控制构图、要保持角色一致性。这类人绕不开 14B 的 MoE 版本和 ComfyUI 工作流因为只有工作流形态才能做首尾帧衔接、图生视频、局部重绘这些精细控制。显卡建议 24G 起步最好 48G不然每条视频都在跟显存搏斗。第三类是研究/微调需求要改结构、要 LoRA、要做自己的数据。这类基本得 80G 级别的卡或者多卡本文不展开但显存优化的那几节对你同样有用。提示先想清楚自己属于哪一类再决定下载哪个版本的权重。14B 的两个专家模型加起来接近 60GB 的原始权重下载和解压的时间成本不低很多人下完才发现自己的卡根本带不动。1.2 Wan2.2 的版本矩阵别下错权重Wan2.2 这个模型家族内部差异挺大不是简单的大小号关系架构上就有区别选错了会很痛苦。我整理成一张表你可以对着自己的显卡和需求直接挑。版本架构典型分辨率帧数/时长推荐显存适合场景T2V-A14BMoE 双专家总参数约 27B单次激活约 14B1280×704 / 704×128081 帧 / 约 3.4 秒24G 起需卸载追求画质的文生视频I2V-A14B同上的图生视频版本同上同上24G 起需卸载首帧控制、角色延续TI2V-5B稠密 5B1280×704121 帧 / 约 5 秒12G 至 16G个人尝鲜、快速迭代这里有个很容易搞混的点MoE 版本不是跑两个模型而是高噪和低噪两个专家在采样过程的不同阶段接力——前段步数用高噪专家负责构图和运动趋势后段步数切换到低噪专家负责细节收敛。这个设计直接决定了 ComfyUI 里必须串两个采样器也是很多人第一次搭工作流时发现只有一个 KSampler 效果很怪的原因。另外5B 版本用的 VAE 跟 14B 不是同一个。14B 沿用 16×16×4 压缩比的旧版 VAE5B 用的是高压缩比的新 VAE解码速度更快、显存占用更低但两者不能混用。把 5B 的 VAE 喂给 14B 的 latent出来的就是一坨彩色噪点这个坑我踩过排查了半小时才反应过来。1.3 显存账本为什么 24G 是道分水岭很多人对显存的理解停留在模型多大就要多少显存实际远不止。跑一次 720P 视频推理显存消耗大致分四块模型权重fp16 下 14B 专家约 28GBfp8 量化后约 14GB文本编码器 umt5-xxl 约 5.6B 参数fp8 下约 6GB。激活值这是被严重低估的部分。视频 latent 的序列长度跟分辨率、帧数强相关1280×704、81 帧的 latent 展开大约是 4 万到 7 万个 token 量级注意力层的中间结果能吃光十几 G。KV 缓存单次推理不涉及多轮但长序列下的注意力缓存本身就不小。解码阶段峰值VAE 解码要把整个 latent 一次性铺开这一步的峰值往往比采样阶段还高。粗略估一下fp8 权重 14GB 文本编码器可以先编码完卸载6GB 激活 8GB 至 12GB24G 卡基本贴着上限走稍微加点分辨率或者多几帧就 OOM。这就是为什么分块解码、顺序卸载、分块交换这些技术不是可选项而是 24G 卡的生存必需品。48G 的卡会舒服很多可以完整跑一遍不卸载速度也快因为卸载本身是有代价的——权重在 CPU 和 GPU 之间来回搬PCIe 带宽会成为新的瓶颈。2. 环境搭建与命令行跑通第一段视频我不建议一上来就用 ComfyUI。先用命令行把最朴素的推理跑通你会对输入输出、显存曲线、每一步耗时建立起最直观的感受后面搭工作流时出问题才知道该怀疑哪一环。这一节按顺序走一遍。2.1 驱动与运行时环境别在这上面省时间显卡驱动尽量新但不要追最新。经验是选一个发布两三个月以上、社区反馈稳定的版本太新的驱动偶尔会有显存管理上的小毛病。CUDA 版本按你装的深度学习框架要求走不要手动去凑——让它自己带。Python 环境强烈建议用独立虚拟环境不要装在系统 Python 里。我见过太多人因为环境里同时装了多个版本的 torch出现明明装了却导入失败或者跑起来莫名很慢的情况。命令大概是这样conda create -n wan22 python3.10 -y conda activate wan22 pip install torch torchvision --index-url 对应CUDA版本的源 pip install -r requirements.txtPython 3.10 是我用得最稳的版本3.12 上个别依赖会有编译问题不建议新手去趟。装完先验证一下import torch print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))cuda.is_available()返回 False 的话先别急着装模型八成是驱动版本和 torch 的 CUDA 版本对不上。这一步不通过后面全是白费功夫。另外提醒一句磁盘空间要留足。权重、VAE、文本编码器、加上推理输出的视频一套下来一百多 G 很正常机械硬盘上做这件事会很痛苦尽量放固态。2.2 权重组织目录结构错了脚本就找不到东西官方脚本通常要求一个固定的目录结构权重文件按名字去对应位置找。我见过最常见的报错就是找不到某个 safetensors本质是放错了位置或者文件名改过。我的做法是建一个统一的模型根目录内部按类型分文件夹脚本里用一个--ckpt_dir指向它。大致长这样models/ ├── Wan2.2-T2V-A14B/ │ ├── config.json │ ├── diffusion_pth_high_noise.safetensors │ ├── diffusion_pth_low_noise.safetensors │ ├── models_t5_umt5-xxl-enc-bf16.pth │ └── Wan2.1_VAE.pth └── Wan2.2-TI2V-5B/ ├── config.json ├── diffusion_pth.safetensors ├── models_t5_umt5-xxl-enc-bf16.pth └── Wan2.2_VAE.pth注意文件名不要去改也不要为了省空间把 fp16 权重手动转成别的格式后沿用原名。脚本按名字加载类型不匹配时报错信息往往很含糊你会以为是显存问题实际是精度问题。下载完记得校验文件大小。大文件断点续传中断导致权重不完整加载时不会报文件损坏而是加载成功后跑出一堆毫无意义的画面这种问题最难查。2.3 命令行推理跑通第一段七秒钟的视频官方仓库一般会提供一个generate.py之类的入口脚本。以 14B 文生视频为例最小可用的命令形态大致是python generate.py \ --task t2v-A14B \ --size 1280*704 \ --ckpt_dir ./models/Wan2.2-T2V-A14B \ --offload_model True \ --convert_model_dtype \ --prompt a slow dolly shot through a rainy neon alley, reflections on wet asphalt, cinematic lighting几个参数值得单独说--size写成1280*704而不是1280x704是因为脚本内部按*分割。分辨率不是随便填的14B 版本在 1280×704 和 704×1280 这两个尺寸上是训练对齐的你填个 1024×1024 出来的画面很容易构图崩坏。--offload_model True的意思是把不参与当前计算的模块先挪到 CPU 内存需要时再搬回来。24G 卡上基本必开代价是速度慢一截。48G 卡可以关掉实测能快 20% 到 30%。--convert_model_dtype用于把权重在实际计算时转成合适的精度配合 fp8 权重使用时要注意别和量化设置打架。第一次跑建议把帧数调小比如先用 33 帧试试水。等确认整条链路通了、显存曲线也看过了再上 81 帧。第一次就直接冲满帧数然后 OOM你连哪一步炸的都看不清。跑完输出一般在outputs/目录下是 mp4 或者一组帧序列。第一次看到自己机器里蹦出来一段能动的视频那种感觉还是挺上头的。2.4 首次运行最容易踩的五个坑我把自己和别人遇到过的首次运行问题列一下基本都是环境层面的跟模型本身没关系。现象大概率原因处理方式启动即 OOM还没开始采样文本编码器和主模型同时加载开--offload_model或先单独跑编码再推理采样到一半 OOM激活峰值超出尤其 VAE 解码阶段降分辨率或帧数开分块解码报找不到权重目录结构或文件名不匹配严格按官方 README 的组织方式画面全是噪点/雪花VAE 版本用错5B 配 2.2 的 VAE14B 配 2.1 的 VAE速度慢到离谱权重放在机械盘或走了 CPU 推理换固态确认cuda.is_available()为真还有一个隐性问题某些发行版的显卡驱动会默认开启一些省电策略跑长任务时频率掉下来导致后半段明显变慢。如果你发现同一条视频前半段快后半段慢可以查一下是不是这个原因。3. ComfyUI 工作流从节点链路到参数手感命令行跑通之后转到 ComfyUI。这不是为了好看而是因为视频生成真正难的地方在于控制——你想让第二段视频接上第一段的尾巴想让角色的脸保持一致想局部改一个物体这些在纯命令行里做起来极其别扭在工作流里就是拖几个节点的事。3.1 安装与插件选型原生节点够用别一上来就堆插件ComfyUI 本体建议用官方仓库的版本跟着更新走。视频相关的节点近几个版本官方已经原生支持了 Wan 系列包括两个专家接力所需的采样器串联所以新手阶段完全不需要装额外插件。等你遇到原生节点解决不了的问题再考虑第三方封装。常见的扩展方向有三类一类是更灵活的显存管理支持按块把权重交换到内存一类是更快的注意力实现能明显降低长序列的显存和耗时一类是视频合成与后处理比如直接输出带音频的容器格式、批量拼接。装插件的原则我总结成一句话每装一个都要知道自己为什么装。插件冲突导致的报错往往发生在很底层的地方报错信息毫无指向性一装一堆插件然后到处求人是最浪费时间的做法。启动参数上如果你显存紧张可以在启动时加低显存模式如果显存宽裕加一个保留显存的参数避免系统其他程序抢占导致推理中途失败。3.2 文生视频主链路拆解两个采样器为什么要串起来这是整个工作流的核心搞懂这一段剩下的都是变体。链路大致是UNETLoader加载高噪专家权重文本编码节点正负提示词各一个接CLIPLoader加载的 umt5 编码器空 latent 节点生成初始噪声参数是宽、高、帧数、批大小第一个采样器从第 0 步跑到分界步用高噪专家把中间结果交给UNETLoader加载的低噪专家第二个采样器从分界步接着跑到结束VAEDecode解码成像素帧视频合成节点输出文件。关键在于第 4 和第 6 步之间。分界步一般取总步数的 87.5% 左右的位置附近做切换——这个数值不是拍脑袋是因为高噪专家负责的是从纯噪声到结构成型这个阶段低噪专家负责结构到细节切早了细节没出来切晚了结构已经被高噪专家带偏。实践中常见的做法是总步数 40 步前 35 步高噪、后 5 步低噪或者 20 步加 20 步的对称分配具体看你手上的模型卡说明。提示两个采样器之间的 latent 必须直接相连中间不要插任何缩放或者重采样节点。很多人为了让画面更清晰在这里加一个 latent 放大结果就是运动完全断裂。另外别忘了ModelSamplingSD3这个节点它负责设置采样偏移量。这个参数影响噪声调度曲线的形状视频模型上通常设得比图像模型大一些。调小了运动幅度不足画面像定格调大了运动剧烈但容易崩。3.3 采样参数的手感步数、引导强度、偏移量参数没有标准答案但有明确的调节方向。我按自己实测的经验给一组起点你在上面微调。参数常用区间调高的效果调低的效果采样步数30 至 50细节更实耗时线性增加出片快易糊、易断引导强度 CFG3.5 至 5.0更贴合提示词过高会过饱和、动作僵硬更自由过低会无视提示词采样偏移 shift5.0 至 8.0前期噪声主导更强构图更敢更保守画面更平切换分界比例0.8 至 0.9低噪专家介入晚细节收敛不足介入早结构容易没成型我的习惯是先用 40 步、CFG 4.0、shift 6.0 跑一条基线看构图对不对。构图不对就调提示词别急着调参数——提示词的问题调参数是治不好的。构图对了但细节糊加步数或者延后切换点。画面过饱和、颜色发焦降 CFG。3.4 图生视频与首尾帧真正能用的控制手段纯文生视频的随机性很大同一个提示词跑十次能出十种构图做内容生产基本没法用。真正能落地的是图生视频——给一张首帧让模型接着往下推。接法上把空 latent 节点换成专门的图生视频 latent 节点输入一张参考图节点内部会把这张图编码进 latent 的第一帧位置然后后续帧在采样中生成。这里有个细节参考图的分辨率比例最好和目标尺寸一致不一致时节点会做裁剪或填充填充出来的黑边会被模型当成画面内容第一条生成的视频里就会出现莫名其妙的黑框。首尾帧的玩法更进一步同时给第一帧和最后一帧模型在中间插值生成过渡。这个能力做转场、做循环视频特别好用。要注意的是首尾两帧的构图差异不能太大差异过大时中间帧会出现明显的形变扭曲因为模型在强行把两个不相干的结构连起来。实践中跨度控制在机位小幅移动、物体轻微变化的程度比较稳。3.5 提示词写法与批量出片视频模型的提示词和图像模型不太一样它多了时间维度。有效的写法是分成三层主体与场景、镜头运动、光线与质感。比如一个穿深色外套的人站在雨夜的巷口是主体镜头缓慢推近从全身到半身是运动湿滑地面反射霓虹光电影感冷色调是质感。三层写全出片稳定性会明显提升。反过来堆砌形容词是无效的。极致清晰、超高清、8K、大师作品这类词在视频模型上基本不起作用反而挤占了提示词的空间。负面提示词也不用写太长通用的几条就够写多了会误伤正常内容。批量出片时固定种子做参数扫描是最高效的方法种子不变只改一个参数跑四到六条横向对比。这样你能快速建立起对某个参数的手感比随机试快得多。4. 显存优化把 24G 用出 40G 的效果这一节是全文最实用的部分。显存不够是绝大多数人卡住的地方但绝大多数优化手段都有代价你得知道每一刀砍下去损失的是什么。4.1 显存到底被谁吃掉了再细化一下前面提的四块因为优化要对着具体来源下手。权重常驻这块最好理解fp16 的 14B 专家 28GBfp8 的 14GB。文本编码器 6GB 左右。这部分是静态的可以用量化、可以用卸载。激活值是动态的跟序列长度成正比。1280×704、81 帧的 latent 展开后序列很长注意力层的 QKV 中间结果、MLP 的中间激活都得留在显存里。这部分只能靠降分辨率、降帧数、或者用更省显存的注意力实现来压。VAE 解码峰值经常被忽略。解码时要把整个 latent 一次性展开成像素1280×704×81 帧的 RGB 数据本身就有几个 G中间层更多。分块解码就是专门治这个的。碎片化也很要命。长时间反复推理显存里会出现大量不连续的小块明明总空闲够却分配不出连续大块。解决办法是定期重启进程或者用固定形状的输入让分配器复用。4.2 量化fp8 是性价比最高的一刀权重从 fp16 降到 fp8显存直接减半画质损失在视频上其实很不明显——视频有时域冗余单帧的细微精度损失在运动中被眼睛平均掉了。这是我最推荐的优化手段优先级最高。再往下走是更激进的量化比如 4bit。我的实测结论是4bit 在文生视频上还能接受在图生视频和首尾帧任务上会出现明显的细节丢失尤其是人脸和手部。如果你做的是风景、抽象、慢镜头4bit 可以一试做人物特写就别碰了。精度转换的时候有个坑不要把文本编码器也一起压到很低。文本编码器负责理解提示词量化过度会导致模型听不懂你在说什么表现是画面元素缺失而不是画质变差——这个现象很容易被误判成提示词写得不好。4.3 分块解码与卸载慢但是能救命分块解码的原理是把画面切成若干块逐块解码再拼起来。显存峰值从整张画面降到一块画面代价是块与块交界处可能出现细微的接缝。控制接缝的办法是让块之间有重叠重叠比例一般设 1/8 到 1/4。重叠越大越平滑速度越慢。做静态镜头时重叠可以小一点快速运动镜头建议加大因为运动模糊本身会掩盖接缝。权重卸载分两种粒度整模块卸载和分块交换。整模块卸载实现简单就是用完就扔回内存但粒度粗来回搬运的数据量大分块交换更细可以指定把多少层放到内存里剩下多少留在显存灵活度高很多。24G 卡跑 14B 时我一般会交换掉一部分层保留足够的部分在显存里以保证计算效率。注意卸载的前提是主机内存要够。权重在内存里也要占地方内存不够时系统会开始用交换分区速度会掉到令人绝望。跑之前先看一眼内存余量16G 内存跑 14B 模型是很吃力的建议 32G 起步。4.4 不同显卡的配置模板直接给结论省得你自己试。显存推荐版本分辨率帧数关键设置12GTI2V-5B960×54449低显存模式 全量卸载 分块解码16GTI2V-5B1280×70481部分卸载 分块解码24GT2V-A14B fp81280×70481分块交换 分块解码 文本编码器用完即卸48GT2V-A14B fp8 或 bf161280×70481关闭卸载开更快的注意力实现12G 那一档要有心理准备出片速度会比较慢一条五秒视频跑十几分钟很正常。但它是能出片的而且画质对于社交平台发布够用了。5. 实测数据耗时、质量和参数的对应关系数据都是在同一台机器上、同一批提示词、同一套工作流下跑出来的横向可比。绝对数字跟你的硬件强相关看趋势比看数值有用。5.1 测试方法说明测试集用了 12 条提示词覆盖人物特写、风景航拍、物体运动、抽象流体四类每类三条。每条在同一配置下跑两次取平均避免单次波动。质量评价用主观打分五个维度构图合理性、运动自然度、细节清晰度、提示词遵循度、时序稳定性每个维度 1 到 5 分。这种打分不严谨但对自己做决策足够了。真要严谨评估得上客观指标和人工双盲那是另一个话题。5.2 分辨率与帧数对耗时的影响在 24G 卡、14B fp8、40 步固定配置下我测了几组尺寸组合分辨率帧数单条耗时显存峰值备注832×48049约 3 分 20 秒18G迭代调试首选1280×70449约 5 分 10 秒21G画质与速度平衡点1280×70481约 8 分 40 秒23.5G接近上限容易波动1280×704121溢出—24G 跑不动需要更强卸载这个表透露的信息是耗时跟分辨率基本成平方关系跟帧数接近线性。所以想省时间先降分辨率而不是先降帧数——帧数少了视频会变短促观感损失比分辨率下降更明显。另外注意 81 帧那一行显存峰值已经 23.5G意味着没有任何余量后台开个浏览器都可能把它挤爆。这种贴着上限跑的配置只适合专门跑批的机器。5.3 步数与引导强度存在明显的收益拐点固定分辨率和帧数只改步数主观质量评分大概是这样20 步时构图已经成型但细节糊30 步明显改善40 步进入平台期50 步相比 40 步的提升几乎感觉不到耗时却多了 25%。40 步是性价比拐点再往上加不太划算除非你在做最终的成片输出。引导强度上CFG 从 3.0 加到 4.0 时提示词遵循度提升最明显4.0 到 5.0 之间提升趋缓但色彩饱和度明显上升超过 5.5 之后画面开始发焦、动作变僵硬。我的默认值定在 4.0需要更强控制时最多到 4.8。偏移量 shift 的影响比较微妙。调高会让前期噪声更强构图更大胆适合需要冲击力的镜头调低则更稳适合产品展示这类需要可控性的内容。这个参数没有普适最优值得对着你的内容类型试。5.4 运动的自然度最容易被忽视的质量维度所有维度里运动自然度是最难调、也最能拉开差距的。我观察到几个规律运动幅度过小时画面像一张被轻微扰动的照片缺乏活着的感觉运动幅度过大时物体边缘会出现拖影和撕裂尤其是快速横向移动的物体。合适的区间比较窄而且跟提示词里描述的运动速度强相关——你写缓慢推近模型就真的动得很慢写快速穿梭边缘就容易崩。人物类内容还有个特殊问题手部和面部在运动中最容易变形。我的经验是提示词里避免让手部成为画面主体或者用构图把手部裁掉成片率会高很多。这不是模型能力的问题是当前阶段所有视频模型的共性。6. 常见问题速查与避坑经验最后一节整理故障排查。我把问题分成画面类、性能类两组每组的排查顺序都是先怀疑最便宜的环节。6.1 画面类问题先怀疑提示词和 VAE画面出问题很多人第一反应是调采样参数这是错的。排查顺序应该是VAE 版本对不对 → 提示词有没有歧义 → 分辨率比例是否对齐训练分布 → 最后才是采样参数。现象排查顺序全屏噪点VAE 版本错配 → latent 通道数不匹配画面发灰、对比度低引导强度偏低 → 负面提示词过强人物多手多脚提示词里动作描述过复杂 → 降分辨率重试运动断裂、跳帧两个采样器之间插了额外节点 → 分界步设置不合理局部模糊VAE 分块解码接缝 → 加大重叠比例首帧和参考图不一致参考图比例与输出比例不一致被裁剪有一个反直觉的经验画面糊的时候先检查是不是步数太少而不是分辨率太低。分辨率低只是整体不清晰但糊成一团、结构都看不清往往是采样不充分。6.2 性能类问题慢和崩是两回事跑得慢和跑崩了要分开处理。慢的话看是不是走了 CPU 卸载、权重是不是在机械盘、有没有开更快的注意力实现、批量大小是不是设成了 1 以上。崩的话看显存峰值出现在哪个阶段采样阶段崩就降分辨率或帧数解码阶段崩就开分块解码。还有个高频情况是跑了几条之后突然变慢。这通常是显存碎片化导致的重启进程就能恢复。如果长期出现考虑在两条推理之间做一次显存清理或者干脆用脚本控制进程周期性重启。6.3 我踩过的最深的三个坑第一个是把文本编码器的输出缓存搞混了。批量生成时为了省时间我把提示词编码结果缓存下来复用结果换了提示词之后忘记刷新缓存跑出来的十几条视频全是同一个内容。这种问题不会报错只会让你怀疑人生。第二个是在 24G 卡上关掉了卸载去追求速度。当时觉得峰值 23G 应该能撑住实际跑起来因为系统占了一点显存十条里崩三条。稳定比快重要尤其是批量任务。第三个是忽略了输出编码的开销。视频合成节点如果用了高码率编码CPU 会成为瓶颈GPU 明明跑完了却要等很久才出文件。这个环节的耗时在总时长里能占到一成以上批量跑的时候尤其明显。我个人在实际操作中的体会是这类工具真正的门槛不在能不能跑起来而在能不能稳定地重复跑出想要的东西。前者一两天就能解决后者得靠大量的参数试错积累手感。别急着追求一次出片先用低分辨率、少帧数把参数空间摸清楚把提示词模板打磨好再上高配出片整体效率反而更高。手上有闲置显卡的话可以挂个脚本夜里批量跑参数组合第二天早上看结果比白天守着屏幕一条条试快得多。