企业官网建设流程全解析

前言：从“能跑通”到“懂为什么这么跑”

在上一篇《V100 16G 部署 Wan2.2：从环境配置到首次出片》中，我们终于在 16G 显存的老将上，用 14B FP8 跑通了首次出片。很多朋友问：为什么选这个分辨率？为什么开启 Turbo 还要加 Lightning LoRA？KSampler 里的步数到底怎么设？

今天这篇，我们不只扒主节点，更要点进每一个子图，把 Wan2.2 文生视频工作流的底层逻辑扒干净。这是属于 16G 显存玩家的"极限拉扯"实录。

我们测试运行参数如下：运行期间不做优化更改

python /home/jjj/ComfyUI/main.py --listen 0.0.0.0 --port 8188--fast fp16_accumulation--enable-manager --output-directory /mnt/data_160g/ComfyUI_Outputs

一、 分辨率与时长：实测数据说话

所有测试都是重新启动，然后开始测试，避免测试条件变化，特别是缓存

1、分辨率选择：832×480 vs 640×640

我实际测试了两个分辨率在 V100 16G + 14B FP8 + Lightning 4步 下的表现：

结论与配置理由：

1. 832×480 才是 V100 16G 的最优解。16:9 比例天然适合视频展示。我上一篇用 640×640 纯粹是测试阶段保守选择，实际数据证明宽屏更优。

2. 时长 5 秒的考量：Wan2.2 默认约 16fps（图中 FPS 设为 16），5 秒约 80 帧。这是测试"动作连贯性"的黄金时长——再短像 GIF 看不出运动质量，再长 V100 等待时间线性增长。学习阶段 80 帧足够验证提示词和参数效果。

2、为什么不用更高分辨率？

生图时别直接无脑填 1920×1080，很多模型/VAE 更爱吃8 的倍数，视频模型常要32 倍数。

*注：严格 16:9 下 1280×720 已对齐 8/32；上表“对齐 32”列里若写 1280×736 是某些节点把总像素当锚点算出来的近似，不是标准 720p。

视频模型（LTX / Hunyuan / WAN / MiniMax 等，要 32 对齐）

• 864×480（0.4MP）

• 1280×720（0.92MP）

• 1920×1088（2.0MP）

• 2560×1440（3.5MP）

时长5秒，我一直以为分辨率加大，显存峰值会增加，但是事实是显存峰值没有变化，都是13858.62 MB,这个统计数据使用molbals-stats 节点统计，据说比较准，和我观察的显存变化也差不多，都在81%以内。注意测试我都是后台也退出comfyui,重启启动，再测试，时间会长些。这样缓存会恢复

1920*1088直接OOM了，添加参数--lowvram --cuda-malloc,也是一样OOM,

我们添加了启动参数

python /home/jjj/ComfyUI/main.py --listen 0.0.0.0 --port 8188 --fast fp16_accumulation --lowvram --cuda-malloc --enable-manager --output-directory /mnt/win_data_jd/ComfyUI_Outputs

将clip模型放在cpu,估计慢，看能不能跑，一样OOM

3、核心反常点：为什么 720p 显存比 480p 低？

通常认为分辨率越高显存越大，但这里出现了反转，核心原因在于隐空间（Latent）尺寸的非线性对齐与内存碎片。

1. 32 对齐的隐空间计算

视频模型（WAN/Hunyuan/LTX等）的 VAE 通常将像素空间下采样 32 倍，且必须32对齐（即长宽必须是32的倍数）。

• 864×480：

  • 像素：864×480 = 0.41MP

  • 隐空间：864/32 =27，480/32 =15​ → Latent 尺寸27×15

• 1280×720：

  • 像素：1280×720 = 0.92MP（像素量是480p的2.2倍）

  • 隐空间：1280/32 =40，720/32 =22.5（非32对齐，实际取整/补边为24）→ Latent 尺寸40×24

2. 显存反转的底层逻辑

• 864×480 的“隐性消耗”：宽度 864 是 32 的奇数倍（27），在 VAE 编码/解码及注意力计算时，容易产生非标准内存块，导致显存碎片或额外的 padding 开销。虽然像素少，但“无效计算”多。

• 1280×720 的“规整优势”：1280 是 64 的倍数，高度 720 补边到 768（24×32）后，整体张量极其规整。在 FP8 和 Flash-Attention 优化下，规整的张量计算效率极高，内存分配更连续，反而峰值显存更低。

• 耗时差异：720p 像素量是 480p 的 2.2 倍，潜空间面积也更大（960 vs 405），因此耗时从 200秒增加到 15分钟是正常的时间成本增加，但空间（显存）被优化得更好。

4、1920×1088 必然 OOM 的原因

• 对齐与像素：1920×1088（注意 1088=34×32，强行32对齐），像素高达 2.09MP。隐空间为60×34。

• 显存瓶颈：14B 模型即使 FP8 也有 ~7-8G 基础显存。加上 VAE（~1G）、CLIP（~2.5G）、中间激活值。在 720p 时，动态显存约 11.8G，留了 4G 余量；而 1080p 级别，隐空间面积激增，注意力矩阵呈平方级放大，动态显存会突破 16G 上限。

• 参数尝试（lowvram/cuda-malloc）：表中尝试了--lowvram、--cuda-malloc、clip放cpu，这些只能缓解模型加载（如把 CLIP 放 CPU 省 2.5G），但无法解决前向传播时高分辨率特征图的激活显存，因此依然 OOM。

5、 V100 16G 分辨率选型建议

6、结论：

在 V100 16G 上跑 Wan2.2 14B FP8，1280×720 是“画质与显存”的甜点区。虽然耗时久（15分钟），但显存反而比 480p 更稳，且画质提升巨大。864×480 因非对齐特性，实际性价比不如 832×480 或 1280×720。不过学习测试可以考虑832×480,快速出图，加快学习速度

二、 提示词（text）：中文 vs 英文提示词对照实验设计

1、实验原则

1. 种子固定：所有对比组使用同一个随机种子（比如81453361874802，你之前截图中那个），确保只有提示词变量在变化。

2. 参数完全一致：分辨率 832×480、5秒、16fps、Lightning 4步、CFG 1.0/3.5、Turbo 开启。

3. 评判维度：语义准确度（是否理解意图）、画面质量（细节/光影）、运动合理性（动作是否自然）、中文特有优势（如成语/诗句/文化意象）。

2、由浅入深一共5组对比测试

第一组：基础描述（测试基础语义理解）

评判重点：Wan2.2 能否正确理解"微风吹过"这个动态描述？中英文在动作描述上是否有差异？

中文：结果还可以，有明显树枝摇动，花瓣落下

英文：有树枝摇动，花瓣落下，不明显

结论 ：基础描述层面，中英文差距极小，图形基本都能表达意思，不过八卦一下，中文出了个外国女人，英文确是中国美女

Wan2.2 的 UMT-XXL 文本编码器对中文基础物体、颜色、简单动作的理解已经非常到位，日常使用完全可以用中文。

第二组：镜头运动与电影感（测试复杂指令）

评判重点："镜头缓慢推进"这种镜头语言，中英文哪个执行得更准确？"浅景深"这种摄影术语呢？

中文：

英文：图片场景更丰富，

结论 ：镜头语言/摄影术语，英文略占优

"camera push in""shallow depth of field" 这类专业术语，英文训练数据更多，执行精度略高，而且感觉画面会精彩一些，但中文"镜头推进""浅景深"也能工作的很好，差距很小。个人感觉对于wan2.2来说，中文更具前景

第三组：中文文化意象（测试中文独有优势）

评判重点：这是关键组！"水墨画""气势磅礴"这类中文文化概念，英文翻译后是否丢失韵味？龙的形态、水墨风格的中英文表现差异。

中文：有雷电，感觉缺点意思，但是表达出了提示词的意思

英文：把雷电理解为了，口吐雷电，而且是一条长了翅膀的龙，中国龙是没有翅膀的

结论 ：中文文化意象，中文碾压

水墨提示词生成结果明显更有"那味儿"。这是国产模型的核心优势，也是未来中文 AI 内容生态的护城河。

第四组：成语/诗意描述（测试抽象语义）

评判重点：古诗意境是中文大模型的强项还是弱项？英文翻译后"孤""独""寒"的意境是否还在？

中文：意境少了一点，不过我们还可以通过其他提示词来限制，

英文：

结论：和诗词意境、成语密集描述，但是我都没有看到古代那种蓑笠翁，理解都不是很到位，说明wan2.2对于古诗词的理解还是不行，这个问题很典型，不是模型“笨”，而是‌古诗词的意境太凝练，模型擅长理解“画面元素”，但不容易自动脑补“留白和情绪”‌。WAN2.2对具象描述理解很好，但对这种高度抽象的诗句，直接输入原文，它只能抓到“船、老人、钓鱼、雪”这些关键词，很难自己生成“千山鸟飞绝”那种极致的空旷和孤寂感。想让画面更贴近诗的意思，关键是‌把诗句“翻译”成模型能听懂的画面语言‌，也就是在提示词里把构图、氛围、光影都写具体。

所以我们试试：寒冬江面，薄冰浮于墨色水面；一位身披蓑衣、头戴斗笠的老翁，静坐于孤舟船头，钓竿微弯；空中飘落细雪，落在帽檐与肩头积成薄白；远景雪山轮廓模糊，天色铅灰；画面大量留白，仅右下角一点朱砂色渔火。

看下面结果：他就没穿蓑衣，所以还不仅仅需要翻译成现代文这么简单

我们关掉Lightning lora测试一下，显卡峰值高了，时间快半小时了，不理想啊

提示词为：孤舟蓑笠翁，独钓寒江雪，远处山峦朦胧，雪花飘落，宁静致远

继续打开Lightning lora，分辨率改为1280×720，时间改为3秒长，我们看结果依然不理想，目前我们不准备处理，后面单独用一章来研究研究，毕竟古诗和成语也是中文不是。

第五组：复杂动作 + 细节描述（测试长提示词理解）

打开Lightning lora，分辨率改为832×480​。

评判重点：长句理解能力。中文一句话里塞了主体、动作、光线、表情、背景、速度六个要素，Wan2.2 能否全部兼顾

中文：六要素都表现了

英文：

结论 ：长提示词（5+ 要素），中文理解力不输英文

中文的信息密度更高（同样意思中文更短），Wan2.2 对中文长句的多要素兼顾能力令人惊喜，另外，我英文生成了两次视频，都没有体现出在舞台上，都是半身，所以个人觉得，中文更准确些

首先我们通过实验可知，中文支持不好的，英文也一样支持不好，这个就是提示词和模型本身配合的问题了。最终建议：

• 日常创作：直接用中文，Wan2.2 的中文理解已经足够好，且中文提示词更短、token 占用更少。

• 文化/国风内容：必须用中文，这是国产模型最大的差异化优势。

• 对于与自己想法差异很大时，可以用英文，英文用词更准确，中文语境太复杂，意思太多，是优点也是缺点。

• 对于古诗词，文言文支持不友好，后续我们将直接对这些进行研究。

三、 模型链路：14B FP8 + Lightning 是 V100 的救星

这是整个工作流的核心。截图中模型链如下：

为什么必须这么配？（显存与速度对比）

结论：没有 FP8 量化，V100 连模型都加载不了；没有 Lightning 4-step LoRA，原生 20 步要等 20 分钟。这套组合是"慢一点但绝对能出片"的最优解——178 秒，喝口水就出来了。

四、 Turbo 模式：锦上添花

• enable_turbo_mode：开启 (True)

配置理由：Turbo 模式配合 Lightning LoRA，进一步加速推理过程中的潜空间计算。在已经用 LoRA 压缩步数的基础上，Turbo 能让每一步的计算更轻量。代价是偶尔细节微损（如发丝边缘略糊），但学习阶段"快速看到结果"比"死磕细节"更重要。出片时可根据需要关闭 Turbo 对比效果。

五、 子图深度拆解：Wan2.2 的"隐藏引擎"

5.1 Load Diffusion Model 子图

• Load Diffusion Model：unet_name选择wan2.2_t2v_high/low_noise_14B_fp8_scaled.safetensors，weight_dtype默认为fp8_e4m3fn（这是官方为 12-24GB 显存卡预设的量化精度，无需手动修改）。

• Load CLIP：选择umt5_xxl_fp8_e4m3fn_scaled.safetensors，关键是将type参数设为wan（不是默认的default或sd3），否则文本编码器无法正确解析 Wan2.2 的提示词。

• Load VAE：选择wan_2.1_vae.safetensors，Wan 2.1 的 VAE 兼容 2.2，官方模板已预配置。

这些都不是我手动“魔改”的参数，而是官方模板开箱即用的默认配置。理解这一点很重要——在 ComfyUI 里跑 Wan2.2，只要选对模型文件、选对 CLIP 的type=wan、保持weight_dtype=fp8_e4m3fn，剩下的交给模板就行。

5.2 KSampler Advanced（高级采样器）子图

这是整个工作流最复杂的部分。Wan2.2 的高低噪声分离需要两个 KSampler​ 串联：

第一个 KSampler（High Noise，处理宏观结构）：

• sampler_name:euler—— Euler 是最基础的 ODE 求解器，配合 Lightning 模型反而最稳定。

• scheduler:simple—— 线性噪声调度，与 Lightning 的步数压缩逻辑匹配。

• steps:4—— Lightning LoRA 将 20 步压缩到 4 步，这是 V100 能 178 秒出片的关键。

• cfg:1.0—— 高噪声阶段 CFG 设低，让模型自由发挥宏观构图。

• denoise:1.0—— 全量去噪，从纯噪声开始。

第二个 KSampler（Low Noise，处理细节精炼）：

• steps:4或2—— 低噪声阶段可以更少步数，因为高噪声已经定了大局。

• cfg:3.5—— 低噪声阶段提高引导强度，确保提示词中的细节（如发色、表情）被准确还原。

• denoise:0.3~0.5—— 不完全去噪，保留高噪声阶段的输出作为基础，只做细节精炼。

Split Steps（步数分割）：图中出现Split Steps 2，这是控制高低噪声之间切换的时机。设为 2 表示前 2 步走高噪声逻辑，后 2 步走低噪声逻辑。这个参数需要根据 LoRA 的训练配置来设，Lightning 官方推荐 2:2 分割。

5.3 Empty Latent Video 子图

• width/height:832/480—— 与前面主节点一致。

• length:81—— 注意这里不是帧数，是 latent 的 temporal length。Wan2.2 的 temporal compression ratio 是 4，所以 81 个 latent frame 对应 (81-1)×4+1 =321 个实际帧？不对——实际公式是latent_frames × 4 - 3，但 ComfyUI 内部会自动换算。图中duration 5s × 16fps = 80 frames，latent length 设为81是 ComfyUI 的惯例（多 1 帧用于边界处理）。

• batch_size:1—— 一次生成 1 个视频。

• FPS:16.0—— Wan2.2 的训练帧率。不要随意改，改了会导致动作速度异常。

5.4 CLIP Text Encode 子图

• clip_name:umt_xxl_fp8_scaled—— 这个文本编码器有 ~5GB（BF16），FP8 量化后 ~2.5GB。

• token_length: Wan2.2 支持最长 512 token，但 Lightning 模型在 4 步下对长提示词理解力下降。建议提示词控制在 77 token 以内（约 1-2 句话），把核心描述放前面。

5.5 VAE Decode 子图

• vae_name:wan_2.1_vae—— Wan 2.1 的 VAE 兼容 2.2，解码质量稳定。

• tile_size: 如果显存紧张，可以开启 tiled VAE decode，把解码分成小块进行，代价是边缘可能有接缝。V100 16G 在 832×480 下不需要开。

5.6 视频输出子图

• codec:none—— ComfyUI 内部先输出原始张量，后续用 FFmpeg 或 ComfyUI 的 Video Combine 节点压制成 MP4。V100 上实时编码 H.264 会拖慢整体速度，不如先存 raw 再后处理。

• fps:16—— 与生成时一致。

• bit_depth:auto—— 根据内容自动选择 8bit 或 10bit。

下一篇我们将研究一下遗留问题，古诗句好像不能很好理解，我们将给出答案