# 2026-09-17 官方 Director「段间引导 / AV latent 续接」两次整机硬挂 —— 相关性与归因更正

> 结论（保守版）：**暂时不要用 `ComfyUI_MiniMaxH3_Director` 的「段间引导」**
> （guide motion context = 上一段 AV latent 尾部钉入下一段）。
> 长视频改用「**每段一个独立任务 + 上一段尾帧作像素参考 + 后期交叉溶像**」。
> ⚠️ 但「是续接本身还是多段单任务导致挂机」**尚未证明**（见第三节归因更正）。

## 一、两次复现（都是整机冻结，必须人工断电）

| # | 时间 | 配置 | 结果 |
|---|---|---|---|
| 1 | 09-16 23:20→23:47 | 3 段单任务、`段间引导 22f`、Singularity ref2va + 二采、780 帧、864×480 | 约 25 分钟（段 2 期间）整机冻结：ARP FAILED / ICMP 100% 丢 / SSH No route to host，`panic=0` 不自愈，人工断电 |
| 2 | 09-17 20:14→20:23 | 同上重跑（机器刚重启、内存 29GB 可用、`--disable-pinned-memory` 已开、RAM 哨兵在线） | 启动后 **约 6 分钟**再次整机冻结；崩溃前日志（`comfyui_8189_opt.log.bak-*`）末行 = 段 1 一采 `25%|1/4 [01:31<04:34, 91.66s/it]`，即**第 1 步采样刚结束就冻死** |
| 对照 | 09-17 18:46→20:11 | **单段独立任务 ×5**（同模型、同二采、同画布） | **全部跑完**，单次 18~36 分钟；期间 `MemAvailable` 稳定 20~25GB，无任何异常 |

**排除了内存窒息**：第 2 次复现时 RAM 充裕（启动 29GB 可用，崩溃瞬间仍 >20GB），
所以这次不是 09-15 那份报告里「pinned 内存 27GB + 换页抖动」的机制。

## 二、用到的确实是 AV Latent 尾部续接（不是像素尾帧）

崩溃任务的 `timeline.output` 实测：
`{"continuityEnabled": true, "continuityOverlapFrames": 22, "continuityKeepTail": false}`，
未设 `continuityMode` → 默认 **`guide`**；日志：`Segment continuity: ON (guide motion context 22f) | Pin from prev: #2, #3`。

`director/h3_motion_context.py::apply_motion_context()` 的动作：把**上一段的 AV latent 尾部**
（视频 latent 22 帧 + 音频 latent 24 帧 @40Hz）作为**永不降噪 conditioning** 钉进下一段、
解码后裁掉钉入前缀（日志原话 `previous AV tail + trim prefix`）。
因二采把画布从 864×480 改成 1280×704，`select_continuity_pin_latent()` 会取**上一段一采的 AV latent**（v9 行为）。

## 三、⚠️ 归因更正：补丁路径**不是**本次挂机的证据

初版结论把挂机归因于 `h3_context_patches.py` 的 monkey-patch，**这条站不住**：

- `apply_motion_context()`（唯一调用 `ensure_layout_patch()` / `ensure_payload_patch()` 的地方）
  只在 `seg.index > 0` 时执行；
- 两次挂机都发生在**段 1 的一采采样**（第二次日志末行 `25%|1/4 [01:31<04:34, 91.66s/it]`），
  此时**没有任何 pin，补丁也尚未装载**。

所以目前只是**相关性**：

| 路径 | 是否有 AV latent 续接 | 结果 |
|---|---|---|
| 3 段单任务 + 段间引导 ×2 | 有 | 整机冻结 ×2 |
| 单段独立任务 ×5（18~36 分钟/次） | 无（纯像素尾帧） | 全部跑通 |

补丁路径的**潜在**风险依然真实（它会从 `comfy.ldm.minimax.model` 层打 layout/payload 补丁，
而本机同时装着自带同类补丁的 `ComfyUI-H3-Motion-Context`），但**本次挂机不能归因于它**。

## 四、尚未排除的差异（下次隔离实验要验证的）

「3 段单任务」与「单段任务」的差别不止续接：`total_frames=780` 的整段导出/缓存路径、
`clear_vram_between_segments`、段缓存落盘、以及一次性长时高负载。隔离实验设计：

1. **3 段单任务 + 关掉段间引导**（`continuityEnabled: false`）——若仍挂 → 责任在「多段单任务」；
2. 若不挂 → 责任在连续性路径（再二分 guide vs continue）。

（每次实验都有挂机风险，需有人在机器旁；用户已知情。）

## 五、行动规则（写进以后的长视频流程）

1. **暂停**在 timeline 里开 `output.continuityEnabled`，即暂停使用 `段间引导 / motion context`。
2. 长视频 = N 个**独立** ComfyUI 任务，每段任务：
   - 参考图 `<Picture 1>` = 上一段的**尾帧**（variant c，实测比作 `<Picture 3>` 续接 MAD 低 14%）
   - `<Picture 2>` = 角色图，`<Picture 3>` = 场景背景图
   - 固定 seed，段长用 17k+5 网格（260 帧 = 10.833s）
3. 接缝用 ffmpeg `xfade` 交叉溶像（12 帧 = 0.5s）+ `acrossfade` 隐藏比例跳变；或设计成硬切分镜。
4. 复现用脚本：`~/Downloads/h3-tasks/bg-corridor/{h3_run.py,h3_seg.py,rtx_upscale.py,assemble_film.sh}`。
5. RTX VSR 放大**不要**对整片做，按 130 帧分块（单块输出张量 2560×1408×130 ≈ 5.6GB）。

## 六、现场取证要点（下次再挂时照做）

- 崩溃前日志在 `~/comfyui_8189_opt.log`（重启前会被 `restart_comfy.sh` 备份成
  `comfyui_8189_opt.log.bak-<月日-时分>`）——**这是唯一能看出「挂在哪一步」的东西**。
- 崩溃时 `ping`：DSH 机侧 `ip neigh` 显示 `192.168.31.31 … FAILED`，路由器可达 → 判定整机挂而非网络故障。
- 本机 `kernel.panic=0 / hung_task_panic=0 / softlockup_panic=0`，**硬挂后不会自愈**，只能人工断电；
  要自愈需打开 `kernel.panic=10` + `hardlockup_panic=1`（用户 09-17 选择暂不改）。

## 七、相关文件

- 本次任务报告：`dl-hub/10-视频生成流水线/20260916_2340_仙宫玉廊_汉服女子背影行走/生成报告.md`
- 内存哨兵：GPU 机 `~/ram_guard.sh`（MemAvailable < 2.5GB 连续两次 → `POST /interrupt`），日志 `~/ram_guard.log`
- 历史同类：`2026-09-15-连续生成6小时后整机硬挂-取证报告.md`（内存窒息版）、
  09-14 SageAttention 掉总线结论（见 `10-视频生成流水线/H3换人视频-部署与实测报告-20260914.md`）

---

## 八、2026-09-18 补充：新图（无任何补丁）同样挂 → 归因更新为「长时满载硬挂」

### 8.1 新证据（01:00:41 第三次挂机）

用**完全自建图**重跑官方质量基线（1344×768 / 20 步 / res_multistep / 无 LoRA），
链路只用官方 H3 节点 + 独立 `ComfyUI-H3-Motion-Context` 0.5.1：

- **没有** Director、**没有** `h3_context_patches`、**没有** SageAttention、**没有** Sol-Attn
  （Motion Context 0.5.1 明确「不再 patch 任何 ComfyUI 代码」，只做 layout 契约自检）
- 段 1（260 帧，88 分钟）**跑通**；段 2（294 帧）在 **13/20 步、耗时 1:18:05** 时整机硬挂
- **内存哨兵全程只有心跳**（`MemAvailable` 20~25GB、`SwapFree` 70GB），
  **从未触发 LOW/INTERRUPT** → 排除内存窒息
- 崩溃前每步耗时**从 253s 劣化到 360s（+42%）**，显存 15.1/16.3GB、GPU 76℃

### 8.2 更新后的结论

**这台机器在 H3 长时间满载下会整机硬挂，与软件路径无关**（Director 补丁只是其中一次的共同点，
不是必要条件）。目前观察到的经验边界：

| 单次连续满载时长 | 结果 |
|---|---|
| 9~12 分钟 × 3 段连跑（480P/4 步） | ✅ 安全 |
| 36 分钟（480P/4 步 + 二采） | ✅ 安全 |
| 88 分钟（1MP/20 步，Singularity） | ✅ 侥幸跑通 |
| 84 分钟（1MP/20 步，294 帧） | ❌ 硬挂 |

→ **工程红线：单次连续满载控制在 ≤60 分钟**。

### 8.3 关键性能事实（决定配方，别再踩）

- **每步耗时与底座大小无关**：`Singularity(21GB) 253 s/步` ≈ `w4a8(11.8GB) 262 s/步`
  → 瓶颈是**纯算力**，不是权重流式搬运。换小底座**不提速**（只降显存压力）。
- 1344×768 × 260 帧 ≈ 26 万 token，本卡（RTX 5060 Ti）~260 s/步 → **20 步 = 88 分钟/段**，
  天然跨过挂机区间。
- 想要 1MP 清晰度又要落在 ≤60 分钟：**步数 12 步（≈57 分钟/段）** 或把段切得更短。
- 分辨率是清晰度的主导项：实测 1344×768/20 步 比 864×480/4 步 锐度（拉普拉斯方差）
  **高 4.0 倍**（3 帧独立测量 3.95/4.01/4.00），而把 480P 单纯放大到同尺寸只有插值收益。