企业官网建设流程全解析

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 这个模型家族内部差异挺大，不是简单的"大小号"关系，架构上就有区别，选错了会很痛苦。我整理成一张表，你可以对着自己的显卡和需求直接挑。

这里有个很容易搞混的点：MoE 版本不是"跑两个模型"，而是高噪和低噪两个专家在采样过程的不同阶段接力——前段步数用高噪专家负责构图和运动趋势，后段步数切换到低噪专家负责细节收敛。这个设计直接决定了 ComfyUI 里必须串两个采样器，也是很多人第一次搭工作流时发现"只有一个 KSampler 效果很怪"的原因。

另外，5B 版本用的 VAE 跟 14B 不是同一个。14B 沿用 16×16×4 压缩比的旧版 VAE，5B 用的是高压缩比的新 VAE，解码速度更快、显存占用更低，但两者不能混用。把 5B 的 VAE 喂给 14B 的 latent，出来的就是一坨彩色噪点，这个坑我踩过，排查了半小时才反应过来。

1.3 显存账本：为什么 24G 是道分水岭

很多人对显存的理解停留在"模型多大就要多少显存"，实际远不止。跑一次 720P 视频推理，显存消耗大致分四块：

• 模型权重：fp16 下 14B 专家约 28GB，fp8 量化后约 14GB；文本编码器 umt5-xxl 约 5.6B 参数，fp8 下约 6GB。
• 激活值：这是被严重低估的部分。视频 latent 的序列长度跟分辨率、帧数强相关，1280×704、81 帧的 latent 展开大约是 4 万到 7 万个 token 量级，注意力层的中间结果能吃光十几 G。
• KV 缓存：单次推理不涉及多轮，但长序列下的注意力缓存本身就不小。
• 解码阶段峰值：VAE 解码要把整个 latent 一次性铺开，这一步的峰值往往比采样阶段还高。

粗略估一下：fp8 权重 14GB + 文本编码器（可以先编码完卸载）6GB + 激活 8GB 至 12GB，24G 卡基本贴着上限走，稍微加点分辨率或者多几帧就 OOM。这就是为什么分块解码、顺序卸载、分块交换这些技术不是"可选项"，而是 24G 卡的生存必需品。48G 的卡会舒服很多，可以完整跑一遍不卸载，速度也快，因为卸载本身是有代价的——权重在 CPU 和 GPU 之间来回搬，PCIe 带宽会成为新的瓶颈。

2. 环境搭建与命令行跑通第一段视频

我不建议一上来就用 ComfyUI。先用命令行把最朴素的推理跑通，你会对输入输出、显存曲线、每一步耗时建立起最直观的感受，后面搭工作流时出问题才知道该怀疑哪一环。这一节按顺序走一遍。

2.1 驱动与运行时环境，别在这上面省时间

显卡驱动尽量新，但不要追最新。经验是选一个发布两三个月以上、社区反馈稳定的版本，太新的驱动偶尔会有显存管理上的小毛病。CUDA 版本按你装的深度学习框架要求走，不要手动去凑——让它自己带。

Python 环境强烈建议用独立虚拟环境，不要装在系统 Python 里。我见过太多人因为环境里同时装了多个版本的 torch，出现"明明装了却导入失败"或者"跑起来莫名很慢"的情况。命令大概是这样：

conda create -n wan22 python=3.10 -y conda activate wan22 pip install torch torchvision --index-url <对应CUDA版本的源> pip install -r requirements.txt

Python 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 首次运行最容易踩的五个坑

我把自己和别人遇到过的首次运行问题列一下，基本都是环境层面的，跟模型本身没关系。

还有一个隐性问题：某些发行版的显卡驱动会默认开启一些省电策略，跑长任务时频率掉下来，导致后半段明显变慢。如果你发现同一条视频前半段快后半段慢，可以查一下是不是这个原因。

3. ComfyUI 工作流：从节点链路到参数手感

命令行跑通之后，转到 ComfyUI。这不是为了好看，而是因为视频生成真正难的地方在于控制——你想让第二段视频接上第一段的尾巴，想让角色的脸保持一致，想局部改一个物体，这些在纯命令行里做起来极其别扭，在工作流里就是拖几个节点的事。

3.1 安装与插件选型：原生节点够用，别一上来就堆插件

ComfyUI 本体建议用官方仓库的版本，跟着更新走。视频相关的节点，近几个版本官方已经原生支持了 Wan 系列，包括两个专家接力所需的采样器串联，所以新手阶段完全不需要装额外插件。

等你遇到原生节点解决不了的问题，再考虑第三方封装。常见的扩展方向有三类：一类是更灵活的显存管理，支持按块把权重交换到内存；一类是更快的注意力实现，能明显降低长序列的显存和耗时；一类是视频合成与后处理，比如直接输出带音频的容器格式、批量拼接。

装插件的原则我总结成一句话：每装一个，都要知道自己为什么装。插件冲突导致的报错往往发生在很底层的地方，报错信息毫无指向性，一装一堆插件然后到处求人是最浪费时间的做法。

启动参数上，如果你显存紧张，可以在启动时加低显存模式；如果显存宽裕，加一个保留显存的参数，避免系统其他程序抢占导致推理中途失败。

3.2 文生视频主链路拆解，两个采样器为什么要串起来

这是整个工作流的核心，搞懂这一段，剩下的都是变体。链路大致是：

1. UNETLoader加载高噪专家权重；
2. 文本编码节点，正负提示词各一个，接CLIPLoader加载的 umt5 编码器；
3. 空 latent 节点生成初始噪声，参数是宽、高、帧数、批大小；
4. 第一个采样器从第 0 步跑到分界步，用高噪专家；
5. 把中间结果交给UNETLoader加载的低噪专家；
6. 第二个采样器从分界步接着跑到结束；
7. VAEDecode解码成像素帧；
8. 视频合成节点输出文件。

关键在于第 4 和第 6 步之间。分界步一般取总步数的 87.5% 左右的位置附近做切换——这个数值不是拍脑袋，是因为高噪专家负责的是"从纯噪声到结构成型"这个阶段，低噪专家负责"结构到细节"，切早了细节没出来，切晚了结构已经被高噪专家带偏。实践中常见的做法是总步数 40 步，前 35 步高噪、后 5 步低噪，或者 20 步加 20 步的对称分配，具体看你手上的模型卡说明。

提示：两个采样器之间的 latent 必须直接相连，中间不要插任何缩放或者重采样节点。很多人为了让画面"更清晰"在这里加一个 latent 放大，结果就是运动完全断裂。

另外别忘了ModelSamplingSD3这个节点，它负责设置采样偏移量。这个参数影响噪声调度曲线的形状，视频模型上通常设得比图像模型大一些。调小了运动幅度不足，画面像定格；调大了运动剧烈但容易崩。

3.3 采样参数的手感：步数、引导强度、偏移量

参数没有标准答案，但有明确的调节方向。我按自己实测的经验给一组起点，你在上面微调。

我的习惯是：先用 40 步、CFG 4.0、shift 6.0 跑一条基线，看构图对不对。构图不对就调提示词，别急着调参数——提示词的问题调参数是治不好的。构图对了但细节糊，加步数或者延后切换点。画面过饱和、颜色发焦，降 CFG。

3.4 图生视频与首尾帧：真正能用的控制手段

纯文生视频的随机性很大，同一个提示词跑十次能出十种构图，做内容生产基本没法用。真正能落地的是图生视频——给一张首帧，让模型接着往下推。

接法上，把空 latent 节点换成专门的图生视频 latent 节点，输入一张参考图，节点内部会把这张图编码进 latent 的第一帧位置，然后后续帧在采样中生成。这里有个细节：参考图的分辨率比例最好和目标尺寸一致，不一致时节点会做裁剪或填充，填充出来的黑边会被模型当成画面内容，第一条生成的视频里就会出现莫名其妙的黑框。

首尾帧的玩法更进一步：同时给第一帧和最后一帧，模型在中间插值生成过渡。这个能力做转场、做循环视频特别好用。要注意的是首尾两帧的构图差异不能太大，差异过大时中间帧会出现明显的形变扭曲，因为模型在强行把两个不相干的结构连起来。实践中跨度控制在机位小幅移动、物体轻微变化的程度比较稳。

3.5 提示词写法与批量出片

视频模型的提示词和图像模型不太一样，它多了时间维度。有效的写法是分成三层：主体与场景、镜头运动、光线与质感。

比如"一个穿深色外套的人站在雨夜的巷口"是主体；"镜头缓慢推近，从全身到半身"是运动；"湿滑地面反射霓虹光，电影感冷色调"是质感。三层写全，出片稳定性会明显提升。

反过来，堆砌形容词是无效的。"极致清晰、超高清、8K、大师作品"这类词在视频模型上基本不起作用，反而挤占了提示词的空间。负面提示词也不用写太长，通用的几条就够，写多了会误伤正常内容。

批量出片时，固定种子做参数扫描是最高效的方法：种子不变，只改一个参数，跑四到六条，横向对比。这样你能快速建立起对某个参数的手感，比随机试快得多。

4. 显存优化：把 24G 用出 40G 的效果

这一节是全文最实用的部分。显存不够是绝大多数人卡住的地方，但绝大多数优化手段都有代价，你得知道每一刀砍下去损失的是什么。

4.1 显存到底被谁吃掉了

再细化一下前面提的四块，因为优化要对着具体来源下手。

权重常驻这块最好理解，fp16 的 14B 专家 28GB，fp8 的 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 不同显卡的配置模板

直接给结论，省得你自己试。

12G 那一档要有心理准备，出片速度会比较慢，一条五秒视频跑十几分钟很正常。但它是能出片的，而且画质对于社交平台发布够用了。

5. 实测数据：耗时、质量和参数的对应关系

数据都是在同一台机器上、同一批提示词、同一套工作流下跑出来的，横向可比。绝对数字跟你的硬件强相关，看趋势比看数值有用。

5.1 测试方法说明

测试集用了 12 条提示词，覆盖人物特写、风景航拍、物体运动、抽象流体四类，每类三条。每条在同一配置下跑两次取平均，避免单次波动。质量评价用主观打分，五个维度：构图合理性、运动自然度、细节清晰度、提示词遵循度、时序稳定性，每个维度 1 到 5 分。

这种打分不严谨，但对自己做决策足够了。真要严谨评估得上客观指标和人工双盲，那是另一个话题。

5.2 分辨率与帧数对耗时的影响

在 24G 卡、14B fp8、40 步固定配置下，我测了几组尺寸组合：

这个表透露的信息是：耗时跟分辨率基本成平方关系，跟帧数接近线性。所以想省时间，先降分辨率而不是先降帧数——帧数少了视频会变"短促"，观感损失比分辨率下降更明显。

另外注意 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 版本对不对 → 提示词有没有歧义 → 分辨率比例是否对齐训练分布 → 最后才是采样参数。

有一个反直觉的经验：画面糊的时候，先检查是不是步数太少，而不是分辨率太低。分辨率低只是整体不清晰，但糊成一团、结构都看不清，往往是采样不充分。

6.2 性能类问题：慢和崩是两回事

"跑得慢"和"跑崩了"要分开处理。慢的话，看是不是走了 CPU 卸载、权重是不是在机械盘、有没有开更快的注意力实现、批量大小是不是设成了 1 以上。崩的话，看显存峰值出现在哪个阶段：采样阶段崩就降分辨率或帧数，解码阶段崩就开分块解码。

还有个高频情况是"跑了几条之后突然变慢"。这通常是显存碎片化导致的，重启进程就能恢复。如果长期出现，考虑在两条推理之间做一次显存清理，或者干脆用脚本控制进程周期性重启。

6.3 我踩过的最深的三个坑

第一个是把文本编码器的输出缓存搞混了。批量生成时为了省时间，我把提示词编码结果缓存下来复用，结果换了提示词之后忘记刷新缓存，跑出来的十几条视频全是同一个内容。这种问题不会报错，只会让你怀疑人生。

第二个是在 24G 卡上关掉了卸载去追求速度。当时觉得峰值 23G 应该能撑住，实际跑起来因为系统占了一点显存，十条里崩三条。稳定比快重要，尤其是批量任务。

第三个是忽略了输出编码的开销。视频合成节点如果用了高码率编码，CPU 会成为瓶颈，GPU 明明跑完了却要等很久才出文件。这个环节的耗时在总时长里能占到一成以上，批量跑的时候尤其明显。

我个人在实际操作中的体会是，这类工具真正的门槛不在"能不能跑起来"，而在"能不能稳定地重复跑出想要的东西"。前者一两天就能解决，后者得靠大量的参数试错积累手感。别急着追求一次出片，先用低分辨率、少帧数把参数空间摸清楚，把提示词模板打磨好，再上高配出片，整体效率反而更高。手上有闲置显卡的话，可以挂个脚本夜里批量跑参数组合，第二天早上看结果，比白天守着屏幕一条条试快得多。