抖音视频内容分析：H3 分段长视频生成工作流 V6（Latent 续写）

分析对象：抖音 @Theodore《Latent续写，内存不堆积！H3分段长视频生成工作流V6》 视频文件：../56-抖音视频下载/05_Theodore_Latent续写-内存不堆积-H3分段长视频生成工作流V6_1920x1080.mp4（1080p / 10:44.2） 分析时间：2026-09-29 ｜ 方式：音频全片转写（236 段） + 抽帧读屏 + 屏幕内置说明 + 评论区抓取 ⚠️ 本文只做内容解读，未在 GPU 机上做任何验证或实测（按要求）

---

一、结论速览

1. 方法思路一句话

用「上一段的联合音视频 Latent」做跨段接力，而不是把上一段尾帧当图片塞回模型。 每段仍是独立的一次 Prompt 生成（保留 V4「单次采样」主体），因为承接的是 latent 上下文， 显存/内存开销不随段数累积 —— 生成第 N 段的开销和第 2 段基本一样。

作者原话（视频完整转写-236段.txt [56.3]）：

「不论生成多少段，只要你成功生成了第二段，那么就意味着后面的所有段数你的电脑都能完全带得动， 它并不会因为段数的增加而在你的电脑性能开销上产生堆积。」

2. 有没有提供现成的工作流？——有，在作者的抖音粉丝群

⚠️ 这是本报告第一版说错、现已更正的地方。 视频结尾自己交代了获取渠道（[630.8]）：

「配套的工作流素材等都放在主页的粉丝群中了」

另外评论区有人问「可以分享下工作流么，想试试看」，作者回复也是 「抖音群里」（共 20+ 条「求工作流」的提问，作者公开答过这一点）。

项	结论
公开下载链接 / GitHub 仓库	没有。简介里只有 CDN 播放地址，无任何网盘/仓库链接
获取方式	作者的抖音主页 → 粉丝群（视频结尾明说 + 评论区回复一致）
使用许可	工作流说明面板明写：「仅允许非商业行为以及传播」（非商业使用与传播可以，商业不行）
有人直接问价	评论里有一条「买工作流，多少钱」——侧面说明渠道不公开、且不可随意倒卖
上一版 V5	10:20 处露出旧卡片：H3 分段参考生视频 / 第五版 / **免费分享**（V5 是公开免费分享过的）

所以：想要工作流本体，进作者（Theodore，unique_id q1503623946）的抖音粉丝群拿。

3. 工作流本体的标识信息

项	内容
名称	MiniMax H3 × Impact Pack v6
署名	屏幕说明写「工作流由 酷酷UP南波来的企鹅 与 抖音博主 Theodore 绘制」（协作者 ID 首字模糊，仅供参考）
版本数	共 4 个（作者 [446.9]：「我们的 V6 其实是做了四个版本的」）= 单采 / 双采 × 是否整合提示词 的 2×2 组合
文件	ComfyUI 标签页上见到 Impact_V6_单次采样、Impact_V6_双采
依赖节点包（画布侧栏读出）	Impact-Pack、KJNodes、Easy-Use、comfyui-h3-motion-context、VideoHelperSuite、crystool（状态条）、Resize Image v2 等
模型/权重	H3 ref2v UNET（fp8_scaled 档）+ lightx2v turbo 4 步 LoRA（...h3_f2v_lightx2v_turbo_4step_v0.1_comfy_resized...）→ 自行下载后放 ComfyUI/models/loras

---

二、方法思路拆解

1. 核心机制：联合 AV Latent 跨段接力

屏幕内置说明第 2 条（原文）：

「续接段承载上一段联合 AV Latent，注入 22 帧前面和 24 帧后续上下文，不再传入尾帧图。」

作者口述流程（[336.5]–[357]）：

「在第一段视频生成的时候，把它的最后几十帧给抽取出来并且保存到本地； 然后在第二段视频生成时，这个调度器会读取之前保存的音视频 latent，作为第二段视频的开头参考。 V6 也正是通过这保存到本地的音视频 latent 来确保分段视频生成时的段间一致性。 这也是目前社区验证过的最优方案。」

拆成三个动作：

1. 保存上一段生成完的联合音视频 latent（av_latent → 拆成 video_latent + audio_latent 分别落盘）；
2. 加载时把它当作前缀上下文注入当次采样 —— 具体是 视频 22 帧 / 音频 24 帧的重叠窗口；
3. 不再把上一段尾帧当 <Picture N> 参考图回灌（V1–V5 的做法），因此没有像素域往返损失。

代价（作者主动说明，[362.2]–[401]）：这两个数值（音频截取帧数 / 视频截取帧数）越大 → 连续性越强，但下一段要额外"重复生成"的时长也越多。 举例：第一段 15 秒、第二段用 22 帧保连续 → 第二段实际 15 秒里有约 1 秒（≈24 帧）和上一段末尾重复。 作者还说屏幕上会给一张推荐 latent 帧数参考表。

2. 编排层：Impact-Pack 队列循环，一段一次生成

画布上有独立的 「Impact循环总控」 分组，含 校验完成后才放行本段生成、是否为第 1 段、 当前片段序号（自动更新，0=第一段，请勿手动改）（初值 0）、以及 合并字符串/整数运算/任务队列字符串 等。

作者口述（[275.1]–[318.7]）：

• 这个值 0 = 第一段，会自动更新，自动更新的值直接决定下一次循环从哪开始；
• 正常生成中不要手动改；
• 中途取消后想接着跑：在运行名称不变的前提下，把 value 改成"已完成的段数"。 例：第六段中断（1–5 已完成）→ 把 value 改为 5 → 它就接着生成第六段。

保存顺序固定（说明第 7 条原文）：

「保存顺序为 Latent → 尾帧完成标记 → 更新段号 → Queue。」

跑完最后一段后段号自动重置为 0（说明第 3 条）。

3. 输入设计：分段数量 + 各段时长表 + 结构化提示词

入口参数（作者 [83.3]–[125.8]）：

输入	说明
分段数量	要生成 N 段就填 N（示例 12）
随机种子	—
各段时长表	英文逗号分隔，最后一个数字后不加逗号；数字个数必须等于分段数量（示例给了 12 个，要 10 段就删掉两个）
运行名称	就是输出视频和中间产物存放的文件夹名，每次换任务必须改名，避免输出混放、避免读到旧 Latent 缓存
提示词输入框（非整合版）	只预留了 12 个；分段数 >12 时要把 12 改成需要的数字并点「更新输入」，会多出接口；多出来的框要复制一个、改名、有序连到对应位置

整合提示词版（4 个版本里的另外两个）只改提示词输入方式，后面全部内容不变（[456.8]「后面所有的内容都是没有变化的」）：

• 用 ===（三个等号）作为段间分隔；
• 用 ##（井号）+ 段号 + 描述 做用户提示（作者口述「这个井号后的内容是仅做用户提示的」）；
• 用 &（and 符号）框取该段的时长，例：& 15 秒（作者口述「用两个 and 符号框取一个每段的时长」，屏幕示例可见的是行首一个 &，取值时以实际工作流为准）；
• 之后写该段故事正文；后续脚本会自动解析出「当前段时长」和「提示词正文」，正文还会回显在文本框里做预览；
• 注意：这部分其它参数都不要改。

屏幕上看到的模板长这样（证据图 证据-十二段提示词模板格式.jpg）：

## 第 04 段
& 5 秒
在这里填写第 04 段完整的 H3 提示词。
===
## 第 05 段
& 5 秒
……

参考素材接法（作者 [164.4]–[240.6]）：

• 图像：把预制好的图像桥接接口拉出来 → 下拉菜单选「加载图像」→ 选文件上传；
• 视频（"视频升视频"）：加载视频 → 接「获取视频元素 / get video components」→ 图像序列接 Ref Video 0； 视频音轨接 Ref Video Audio 0；还能继续加 Ref Video 1、Ref Video Audio 1/2；
• 纯音频（如音色参考）：加载音频 → 接单独的 Ref Audio（另有 Ref Audio 1/2）；
• ⚠️ 作者专门提醒：Ref Video Audio 是视频的音轨，别和 Ref Audio 弄混。
• 分辨率选择（长宽比 + 百万像素）与官方模板一模一样，参考官方质量表格。

4. 二采高清精修（双采）

画布下方 「二采高清精修」 分组的组说明原文：

「设定使用 RTX 视频超分 1.5×，超分画面重新编码后进入同一 H3 基础…」

配套节点：二采 Sage Attention / 二采 LowVRAM Attention / 二采 FeedForward 切换 (4)（chunks=4）/ 二采 Sigma Shift（视频 / 音频）。

作者口述参数（[540.9]–[618.1]）：

参数	取值
二采模型	lightx2v（转写误听为 "Light S2V"）→ 自行下载放 models/loras
加速节点	和上面（V3 添加的那套）用法完全一样
LoRA 模型强度	推荐 0.3–0.55；视频里用的是 0.5
基础调度器降噪强度	推荐 0.2–0.35；视频里用的是 0.3
超分节点	控制二采的分辨率提升：一采 480p × 1.5 ⇒ 720p；值可自调
兼容性	「RTX Nodes 不可用时的兼容方案」见作者往期视频

调参口诀（作者原话）：强度越高 → 细节修复越强，但画面出问题的概率也越高；越低 → 二采越接近一采。

5. V3 就加进去的加速节点

作者 [254.6]–[271.6]：V3 版本开始加的加速三件套 = turbo LoRA + SageAttention + 低显存用的 LowVRAM 关组注意力机制； LoRA 放 ComfyUI/models/loras，并安装 turbo lora 节点（要更新到 nightly，见评论区）。

6. 尾帧在 V6 里的角色变了（重要）

作者 [408.2]–[441.2]）：

• V1–V5 都是靠保存的尾帧做下一段的首帧参考；
• V6 已全面改用音视频 latent 做跨段移植；
• 所以尾帧在此处只做「预览」或「完成标记」：尾帧落盘 = 这一段彻底完成；
• ⚠️ 不要随意删除落盘的尾帧，它会影响工作流的校验。

7. 其它整合项逐条对应

简介里的说法	画布/讲解中的落点
双采	「二采高清精修」分组 + 二采 Sage/LowVRAM/FeedForward/Sigma Shift
RTX 1.5× 超分	二采组内 RTX VSR 节点（480p→720p 例）+ rtxnodes 兼容方案
重复头裁剪	latent 重叠窗口（22 帧视频 / 24 帧音频）导致的重复头部，合并前裁掉
音画尾部校准	二采 Sigma Shift 分视频/音频两路；音频尾部单独对齐
失败停止	说明第 8 条：「任一极大失败都不会继续排队；修复后再次 Queue 即可重试当前段」
自动 Queue	Impact 循环总控 + 段号自增 + 第 7 条保存顺序

8. 作者自述的注意事项（屏幕说明面板 8 条，逐字辨认）

1. 保留 v4 单次采样主体；每段作为独立 Prompt 运行。
2. 续接段承载上一段联合 AV Latent，注入 22 帧前面和 24 帧后续上下文，不再传入尾帧图。
3. 当前片段序号从 0 开始自动更新，最后一段完成后自动重置为 0。
4. ImagePass 全部屏蔽必选参考图后置，提示词按实际连接顺序使用 <Picture 1>、<Picture 2>。
5. 每次迭代运行需使用新的运行名称，避免读取旧 Latent 缓存。
6. 运行前关闭其它 ComfyUI 页面，避免多个前端客户端重复排队。
7. 保存顺序为 Latent → 尾帧完成标记 → 更新段号 → Queue。
8. 任一极大失败都不会继续排队；修复后再次 Queue 即可重试当前段。

9. 作者对已知缺点的坦白（评论区原话）

问题	作者回复
段数多了画质递减、白平衡偏移	「lora 导致的，降低一下 lora 强度」
衔接顺畅吗	「目前社区最优，流畅性较好，但肉眼仍然可以辨认」
提示词里怎么描述传递内容	「不用描述，latent 自带上一段的信息」
多段参考图怎么放	「放的 9 张，每段都能参考，具体参考哪几张，用提示词去提示模型」
显存门槛	「最低 3060 都行」；3050 6G「估计只能 0.2 分辨率」；笔记本 5070 8G「可以，比台式机慢一点」
turbo lora 报错	「turbo lora 节点没更新，要更新到 nightly」
sage 加速报错	「allow compile 得设置 false」
报错怎么解	「换兼容节点，视频中有提到」

---

三、与我们现有能力的对照（重要）

这个 V6 的核心机制，我们自己的链路里其实已经有等价物。

本机 10-视频生成流水线/H3长视频分段合成方法-20260914.md 记录过 H3 官方/社区的 motion_context：

项	V6（本条视频）	我们的 motion_context 记录
跨段承接物	上一段联合 AV Latent	复用上一段 H3 音视频 latent
视频上下文窗口	22 帧	video_frames ∈ {5,22,39,56}，默认 22
音频上下文窗口	24 帧	audio_frames 0–240，默认 24
重复头部	合并前裁掉	保存前自动裁掉重复头部
显存开销	不随段数堆积	不消耗（表格里明确标"不消耗"）
尺寸约束	未提	相邻段尺寸必须完全一致
支持层级	ComfyUI 工作流（comfyui-h3-motion-context 节点）	仅 API spec（project create）支持，acceptance manifest 不支持

结论：V6 的「Latent 续写」= 把 comfyui-h3-motion-context（Motion Context）套进 ComfyUI 界面，再补上编排壳与二采。 我们缺的不是机制，而是 ComfyUI 侧的编排壳（队列循环 / 段号自增 / 提示词分段解析 / 失败重试 / 双采接线）。 另外 28-H3-Singularity双采样提速方案/ 已覆盖「双采」这块的口径与实测归因，可与 V6 的二采组互相参照。

注：作者口述时把「保存到本地的音视频 latent」和「音视频尾帧」混用了（[351.3] 说的是"音视频尾帧"）； 以屏幕说明和前后文为准，接力的本体是 latent，尾帧只是完成标记。

---

四、可借鉴点（未验证，不建议现在动 GPU）

1. 编排思路值得抄：Impact-Pack 循环 + 自增段号做「一段一次 Queue」，挂了只重跑当前段； 而且支持中途取消后续跑（运行名不变、把段号改成已完成段数）——比我们一次性排 N 段更抗失败。
2. 分段提示词格式（=== 分段 / ## 提示 / & 时长）比我们的 manifest.json 更"人话"，可读性和可维护性都更好。
3. "运行名称必须每次改" 本质是缓存命名空间；我们对应的是每次 project create 生成新 ID，机制不同但目的一样。
4. "失败就不排队" 比"跳过继续"更安全：长链一旦某段质量崩了，后面全是白跑。
5. 尾帧别删这条容易被忽略：删了会破坏校验。
6. ⚠️ 不要盲抄数字：22/24 帧是 community 默认、LoRA 0.3–0.55 / 降噪 0.2–0.35 是他那套模型的推荐区间， 是否符合我们的分镜式 5s 段需要单独测；而且工作流本体在粉丝群里，我们拿不到 JSON，只能照思路自己接线。

---

五、证据与附件

文件	说明
视频完整转写-236段.txt	全片 10:44 语音转写（本机 CPU whisper large-v3，带时间戳），本报告的主要依据
评论区-66条-含作者回复.json	抓取的 66 条评论（含作者 18 条回复）
证据-屏幕内置使用说明8条.png	工作流内嵌说明面板（8 条 + 署名 + 「仅允许非商业行为以及传播」）
证据-Impact循环总控与段号.jpg	「Impact循环总控」分组、校验完成后才放行本段生成、当前片段序号（0=第一段）
证据-十二段提示词模板格式.jpg	## 第 NN 段 / & 5 秒 / === 提示词模板实际样子
证据-二采高清精修说明.png	「二采高清精修」组说明：RTX 视频超分 1.5× → 重新编码 → 进二采
证据-V5免费分享卡片.jpg	10:20 处旧版卡片：第五版 / 免费分享 / 双采高清·无限时长·多重校验
原视频	../56-抖音视频下载/05_Theodore_Latent续写-内存不堆积-H3分段长视频生成工作流V6_1920x1080.mp4

分析方法与局限（如实说明）

• 音频转写：本机 CPU 版 faster-whisper large-v3（int8 / 8 线程 / 不占 GPU），全片 236 段已转写完成并附上。 实测这台 DSH 机 CPU 只有 0.15–0.38× 实时，10:44 的音频跑了约 26 分钟（renice 19 低优先级）。
• 语音识别有同音误听（「井号」→「仅号」、「lightx2v」→「Light S2V」、「latent」→「Layton」、 「Ref Video」→「rev video」等），主报告中凡涉及专有名词处均已按屏幕文字核对更正，未做推测性补全。
• 屏幕小字辨识度有限（1080p 录屏二次缩放），协作者 ID 首字、二采组说明后半句不确定，已在文中标注。