Arc A770 长视频链式生成

16GB 显存跑 I2V 的真实瓶颈

Wan2.2 14B I2V 是效果很好的图生视频方案，但放到 Intel Arc A770 16GB 上并不轻松：权重加载容易顶满显存，更重要的是 attention KV cache 会随 frames × resolution² 增长，无法卸载，只能压低帧数或分辨率。

一旦把 num_frames 拉到 81（约 5 秒），首帧条件往往会明显衰减，表现为人物在 1 秒后消失；10 秒直出在这张卡上基本不现实。于是只剩一条路：把长视频拆成多段短段，再用首尾帧串起来。

技能如何解决这个问题

本技能围绕“短段直出 + 链式续写 + 去重叠拼接”组织流程，适合已有 Wan2.2 14B I2V 与 ComfyUI-WanVideoWrapper 环境的人直接落地：

• 模型与路径固化：scripts/download_models.py 负责拉取 5 个权重，包括高/低噪声 fp8 模型、umt5、CLIP Vision 与 WanVideo VAE，明确放到 models/diffusion_models/、models/text_encoders/ 等目录，避免在错误的目录里找文件。
• 单段上限设为 ~3 秒：推荐 448×832 + num_frames=49，两个 Sampler 各 20 步（高噪声 0–12、低噪声 12–最后一步）。2 秒（33 帧）可稳跑，3 秒是单段天花板，更长只会更容易丢人物。
• BlockSwap 缓解权重占用：WanVideoBlockSwap 默认偏 CUDA 假设，本技能给出 model.py 的关键 patch（拼接前 y=[v.to(x[0].device) ...]、去掉 CUDA-only 判断），让 XPU 能真正分块换出。
• 首尾帧链式，而不是 loop：每段跑完后用 next_segment.py 从 mp4 抽末帧（ffmpeg -sseof -1 -i segN.mp4 -update 1 ...），写回成 _segs/input/_segN.png，同时改掉工作流的 LoadImage 与输出前缀；下一段再由用户在 ComfyUI 里重新 Load 工作流并 Queue。拼回长视频时，concat_segments.py 去掉每段非末尾段的最后一帧，避免接缝重复。
• 交付可判定的基准：文档给出实测 9.06 秒成品（3 段 × 3 秒）对应的抽帧大小与码率区间（约 1300–2900 kb/s），生成后可直接对照判断是参数问题还是模型固有限制。

适用边界与注意点

这套方案解决的是“显存有限 + 要 5–10 秒连续 I2V”，并不适用于所有场景：只有 2–3 秒的短片直接单段生成即可；24GB 以上显存可以把 num_frames 调大，没必要分段；需要文生视频应走 T2V 工作流，本技能只处理 I2V。

几个容易踩的坑：end_image 一旦接回首帧会导致动作冻结，应保持断开；WanVideoImageToVideoEncode 的 end_image 断开后仍异常慢，通常是步数被调到 25 且双图编码；save_metadata=true 会让 ffmpeg 封装崩；不要用 python main.py 或注入 oneAPI setvars.bat，只能用本机启动脚本手动拉起 ComfyUI。ffmpeg 优先用 imageio_ffmpeg 自带的 7.1 二进制，并使用 Windows 原生路径（E:/...），Git-Bash 的 /e/ 路径经常读不到文件。

另外，脚本假设工作流里 LoadImage 是第一个被遍历到的同类节点、VideoCombine 用 dict 存 filename_prefix。结构不同就会找不到节点，这时手动改首帧与前缀也可以，流程不变。