# MiniMax H3 社区问题调研 + T8mars 生态 → 本机行动清单（2026-09-15）

> 调研方式：两个后台 agent 只用 `web_search` / `web_fetch`（未 ssh、未改文件），全部结论带 URL；
> 「本机实测核对」一节是我在你 GPU 机（zywpc）上做的确定性验证。
> 引用约定：**【原文】**＝来源明确写的；**【推测】**＝推断；**「未找到」**＝确实没查到。

---

# 第一部分：社区问题与解决办法（调研汇总）

## 1. 口型／唇形不同步

| 问题 | 社区给出的原因 | 解决办法 | 出处 |
|---|---|---|---|
| H3 换人后口型对不上原唱 | 【原文】「只在最终封装时把原声轨接回去，**不足以**保住说话/歌唱同步」 | 把 `video_1` + `audio_1` 作为**成对 `video_audio` 参考块**送进 H3，**同时**把 `audio_1` 写进目标音频流并**冻结为生成时钟**，最终仍还原未改动的原波形（`audio_mode = auto / preserve / preserve_reference`） | [LongMedia AUDIO_MODES_GUIDE](https://raw.githubusercontent.com/vizart-vj/ComfyUI-MiniMax-H3-LongMedia/main/docs/AUDIO_MODES_GUIDE.md) |
| 想用全新配音/换歌驱动口型 | 此时 Audio1 不能谎称是 Video1 原声 | `h3_mode = video_ref_edit` + `audio_mode = lip_sync`（还需 `image_1`），Audio1 作**独立权威时钟** | 同上 |
| H3 到底会不会对口型 | 【原文】T8mars：「H3 可以让视觉表演**受音频条件约束**，但**不强制音素级口型**」「这是音频条件化表演编排，不是音素级 lip solver」 | 最终口型/身份/演技**必须全速人工复核** | [T8 audio docs](https://raw.githubusercontent.com/T8mars/comfyui-minimax-h3-audio-T8/main/docs/README_ComfyUI.md) |
| Vocal Lock 类做法 | — | **两个独立实现**：<br>**[A] animede**：固定 `Ref2VA only / TURBO ON / Vocal Lock ON`，管线含 **Demucs 人声分离**，分离人声作 `<Audio 1>` 驱动口型，**最终音频＝输入原曲**（不是 H3 生成音频）<br>**[B] T8mars MV Vocal Lock V3**：整首歌留在 H3 之外、装配完成后**只混一次**；32 秒/5 场景/768 帧跑通；`features.json` 有 `vocal_lock_audio` 契约经 `lock_source` 驱动每镜 | [animede README](https://raw.githubusercontent.com/animede/Minimax-H3-lipsync-mv/main/README.md)、[T8 features.json](https://github.com/T8mars/comfyui-minimax-h3-audio-T8/blob/main/features.json) |
| SyncNet 量化 | — | **有，且是硬门槛**：【原文】「Official SyncNet measured **isolated-vocal offsets 0/-1/0/-1/0 frames at 25fps**, while a **400ms delayed-video control measured nine frames**」 | [T8 docs](https://raw.githubusercontent.com/T8mars/comfyui-minimax-h3-audio-T8/main/docs/README_ComfyUI.md) |
| 提示词层面 | 不要猜歌词 | 【原文】「**不推测歌词写进 `<d>`**，而是让嘴去对 `<Audio 1>` 本身」；分离人声标 `<Audio 1>: fully_copy` 并关联歌唱的 `<Subject 1> (S1)` | [animede](https://raw.githubusercontent.com/animede/Minimax-H3-lipsync-mv/main/README.md) |
| 唱跳时嘴被挡 | — | 歌唱区间**强制**正面或 3/4 向 medium close-up、**嘴部全程可见** | 同上 |
| 分镜切在字上导致口型断 | — | 按**声学特征**（静音、人声音量谷、换气点、段落、拍、小节）动态规划切分，而不是等长切 | 同上 |
| 长链越唱越闷 | 【原文】每跳拿上一段自己的输出当条件，声音频段会塌：8 段链 `bank_pinned=0` 时 4–10 kHz 掉 **84–92%** | `bank_pinned=1`；`continuity=cut` + `memory_frames=0` | [joeygambino SETTINGS](https://hf-mirror.com/joeygambino/MiniMax-H3-Multishot-Workflow/raw/main/SETTINGS.md) |
| 口型"僵" | sampler/scheduler 影响口型 | 同 seed：`beta57`(RES4LYF) 口型 **10/10** vs 原生 `beta` **8/10**（嘴部发僵） | 同上 |
| **ref2va + 音频参考报错** | 【原文】已知 bug 簇 | Larryvrh：issue #9（ref2va+audio **shape mismatch**）、issue #3（「ref2va 把 audio 当参考时是**坏的**」）、PR #10（audio reference conditioning 的 **adaln 注入行数不匹配**） | [#9](https://github.com/Larryvrh/ComfyUI-MiniMax-H3-Turbo/issues/9)、[#3](https://github.com/Larryvrh/ComfyUI-MiniMax-H3-Turbo/issues/3)、[PR #10](https://github.com/Larryvrh/ComfyUI-MiniMax-H3-Turbo/pull/10) |
| 其他相关节点 | — | LongMedia（`lip_sync`）、LeonQ8 `Audio Drive`、T8 audio 节点、animede Web 应用 | [LeonQ8 README](https://raw.githubusercontent.com/LeonQ8/ComfyUI-ALLinONE-MinimaxH3/main/README.md) |
| SyncNet 节点 | — | **未找到** H3 专用可安装 SyncNet 节点（社区当外部脚本用） | — |

## 2. 显存／内存（16GB 卡 + 32GB 内存）

| 问题 | 原因 | 办法 | 出处 |
|---|---|---|---|
| 进程**无 traceback 直接死** | 【原文】内核 **OOM-killer**，由 ComfyUI 页锁定池触发；锁页不可换出/回收 | `--disable-pinned-memory`（之后再加大 swap 才有意义）；`dmesg -T \| grep -i oom-kill` 确认 | [tonyd2wild](https://raw.githubusercontent.com/tonyd2wild/MiniMax-H3-Local/main/docs/troubleshooting.md) |
| 报 OOM 但 VRAM 看着没事 | 【原文】帧数多→解码请求大→更多权重被逐出到主机 RAM；15 秒那跑峰值 18884 MiB **比 5 秒那跑的 23716 MiB 还低，照样死** | 看 `free -m`，别看 nvidia-smi | 同上 |
| 时长超线性变慢 | 【原文】124 帧 11.5–12.6 s/step；362 帧 64.6–72.3 s/step；**2.9× 帧数 → 每步约 5.6×**；采样占 362 帧整片 ~95% | 优化 DiT，优化解码只碰 5% | 同上 |
| `VAEDecodeTiled` 想省显存 | 【原文】**对 H3 是纯 no-op**（`decode_tiled` 直接 `return self.decode(z)`） | — | 同上 |
| **会让失败更糟的 flag** | 【原文】`--disable-smart-memory`、`--high-ram`、`--reserve-vram`/`--vram-headroom`、`--cache-lru`、`--lowvram`/`--novram`（**dynamic VRAM 下是 no-op**） | 避开；保留 `--disable-pinned-memory` + 开 Dynamic VRAM | 同上 + [cli_args.py](https://raw.githubusercontent.com/comfyanonymous/ComfyUI/master/comfy/cli_args.py) |
| 激活峰值 | 【原文】MLP `8192/4096/2048/1024` ≈ **1970/1228/858/672 MiB**；RoPE ≈ 820/638/550/501 MiB；**attention kernel OOM 分块救不了** | 先降 MLP | [star7](https://raw.githubusercontent.com/star7code/minimax-h3-chunk-star7/main/README.md) |
| 预留反噬 15× | 【原文】预留把权重预算挤掉；实测 960×544：第1段整载 18.8 s/it，第2段差 399 MB → **283 s/it** | 预留上限 ＝ `free − weights − 384 MB`；同链 **36m54s→14m03s**；预留默认 0 | [joeygambino](https://hf-mirror.com/joeygambino/MiniMax-H3-Multishot-Workflow/raw/main/SETTINGS.md) |
| 分辨率口径 | — | 【原文】短边 768、单边 ≤ ~1344；16:9 用 **0.98 MP＝1344×768**（**不要 1.0 MP**）；宽高 32 倍数；帧数 `17k+5`（124≈5s，验证 124–362） | [ComfyUI 官方文档](https://raw.githubusercontent.com/Comfy-Org/docs/main/tutorials/video/minimax/minimax-h3.mdx) |
| 345 帧悬崖 | 【原文】4090 上 7 次里 6 次慢 3–17×，**不是 VRAM**，是个别 step 卡住 | 328 帧稳定 | [matsuo](https://raw.githubusercontent.com/matsuo-koya/minimax-h3-notes/main/README.md) |
| LongMedia 16GB 建议 | 【原文】保持 Dynamic VRAM **开启**、**不要** `--disable-dynamic-vram`；≤18.5GB 原生 INT8 视为受限驻留；**分段起点 5–10 s**；Latent Hi-Res 先 1.2–1.5；`reference_budget=low` | [SAMPLER_OPTIMIZATION](https://raw.githubusercontent.com/vizart-vj/ComfyUI-MiniMax-H3-LongMedia/main/docs/SAMPLER_OPTIMIZATION.md) |
| `--fast-disk` H3 实测 | — | **未找到**正面受控收益；只有一次负面 | [#15488 comments](https://api.github.com/repos/Comfy-Org/ComfyUI/issues/15488/comments) |

## 3. 整机卡死／掉线／自动重启（**与你这次故障同一类**）

| 问题 | 原因／证据 | 办法 | 出处 |
|---|---|---|---|
| GPU 掉总线、`GPU is lost` | 【原文】5070 Ti 16GB + 610.47/610.88 + Win11 + 2×32GB，1–8 次内复现；WER 记录 `LKD_0x141_Tdr:6_IMAGE_nvlddmkm.sys_Blackwell`；**OS 还活着**，死的只是显示驱动 | 【原文】**可见内存限到 32GB → 29 次零事故**；同压力跑 Wan2.1 fp16 → 10 次零事故 → 触发需「H3/量化推理」**且**「大内存可见」 | [ComfyUI #15488](https://api.github.com/repos/Comfy-Org/ComfyUI/issues/15488) |
| 排除项（别再试） | 【原文】610.47/610.88、ComfyUI 0.30.1/0.31.1、kitchen 版本、aimdo 版本、`--disable-pinned-memory`、`--disable-async-offload`、cuda/triton backend、int8_convrot/pruned_int8_convrot/nvfp4、4/6/8 步、dual_clock_euler/er_sde、0.4/0.7 MP、MemTest86、关 XMP | 【原文】**全崩** | 同上 + comments |
| **关键缓解①** | 【原文】Kornifex92：**KJNodes `MiniMax H3 Chunk FeedForward` + `MiniMax H3 Low VRAM Attention`（默认设置）** → 可带 CK/Sage 连续生成，跑出 25 分钟片子 | 加这两个节点 | [comments](https://api.github.com/repos/Comfy-Org/ComfyUI/issues/15488/comments)、[KJNodes 源码](https://raw.githubusercontent.com/kijai/ComfyUI-KJNodes/main/nodes/minimax_nodes.py) |
| **关键缓解②功耗墙** | 【原文】#15480（5090+192GB+610.88）：「運行 minimax h3 文生影片，**nvidia 顯卡的供耗上限如果大於 80%，驅動就會崩潰，整個帶崩 comfyui**」 | 功耗上限 ≤80% | [ComfyUI #15480](https://api.github.com/repos/Comfy-Org/ComfyUI/issues/15480) |
| **关键缓解③** | 【原文】换两根独立 PCIe 供电线、清灰+机箱风扇、功耗上限 83%（回 100% 就崩）、每次推理前卸载模型 → 「MiniMax 可跑一整天」；**生成越长/分辨率越高，风险越高** | comments |
| **关键旁证④注意力后端** | 【原文】ibeuel（**两张 5060 Ti 16GB**）：「只要用 `--use-ck-attention` **或** `--use-sage-attention` 就出 GPU lost，且必须**完全关机再上电**；不用就完全没问题」；Kornifex92：量化注意力崩，**纯 SDPA 与 FA2 从未崩**；Cloudreadypc：H3 上 kitchen 与 sage2 都崩，「任何 8bit 注意力都不行」 | 用纯 SDPA/FA2 | comments |
| 不是 610.x 回归 | 【原文】覆盖 591.74/595.x/610.47/610.88；`ref2va_pruned_fp8_scaled` 在 5070 Ti+610.88 **照样崩** | — | comments |
| 另一类是硬件 | 【原文】PNY 5080：29 次相同 Xid 79→154，0 次 PCIe AER，换平台故障跟着卡走，PSU 遥测显示故障瞬间 +12V **反而升高** → 硅片/GSP 固件级，**该 RMA** | [NVIDIA 论坛](https://forums.developer.nvidia.com/raw/379756/1) |
| **「总主机冻结」取证** | 【原文】DGX Spark 用户：**零法证痕迹**——无 OOM-killer、无 panic、无 NVRM/Xid、无 hung-task 警告，**kdump 从未产出 vmcore**；**已加 `hung_task_panic`+`softlockup_panic`+双向 netconsole，依然什么都没抓到** | 判别器：① 挂起时 `nvidia-smi` 显示 ~96% 利用率但只有 **18–21 W**、显存吞吐 ~0% ＝ **GPU livelock 空转**；② `journalctl -k \| grep -c 0x00000051` 查驱动 memdesc 泄漏 | [NVIDIA 论坛](https://forums.developer.nvidia.com/t/total-host-freeze-not-process-hang-during-multi-node-tp-2-vllm-prefill-on-2x-dgx-spark-gb10-zero-forensic-trace-across-kdump-watchdogs-netconsole/376882) |
| ComfyUI 侧"将死"信号 | 【原文】**采样期间不要轮询 HTTP**（会卡 18–43 s）；CUDA context 真死前会先劣化（同片慢 **1.8×**） | 一出现就重启；排查加 `--debug-hang` | [matsuo](https://raw.githubusercontent.com/matsuo-koya/minimax-h3-notes/main/README.md) |
| netconsole/panic 类 | — | **未找到** `panic_on_lockup` 原词的 H3 记录；社区用 `hung_task_panic`/`softlockup_panic` + netconsole，**结果抓不到** | — |

## 4. 4 步 Turbo LoRA（官方规格）

| LoRA | 任务 | 训练分辨率 | 训练 shift（v/a） | 蒸馏 NFE | **推荐推理 NFE** |
|---|---|---|---|---|---|
| FL2VA Turbo 4-step v0.1 | FL2VA/T2VA | 544p | 12/3 | 4 | **4** |
| FL2VA Turbo 8-step v1.0 | FL2VA/T2VA | 544p | 12/3 | 8 | 8/4 |
| FL2VA Turbo 4-step v1.0 768p | FL2VA/T2VA | 768p | 6/3 | 4 | **4** |
| FL2VA Turbo 8-step v1.0 768p | FL2VA/T2VA | 768p | 6/3 | 8 | 8 |
| **Ref2VA Turbo 4-step v0.1**（你用的） | Ref2VA | 544p | **12/3** | **4** | **4** |

出处：[ModelTC/MiniMax-H3-Turbo](https://raw.githubusercontent.com/ModelTC/MiniMax-H3-Turbo/main/README.md)。
shift 算法：`NFE=N` 时 `q_i=(N-i)/N`；NFE=4/12/3 → video sigma `[1,0.9730,0.9231,0.8000]→0`、audio `[1,0.9,0.75,0.5]→0`。

| 问题 | 结论与出处 |
|---|---|
| **10 步算错吗** | 【原文】兼容节点步数表：4＝快速预览；**8＝推荐平衡**；**10＝额外质量测试（社区反馈接近 20 步）**；20＝原生基线（关 Turbo LoRA）。**灰色地带**。另：另一族 Turbo「超过 8 步不再有帮助并开始引入过锐伪影」。→ [shuaixn](https://raw.githubusercontent.com/shuaixn/ComfyUI-MiniMaxH3DualClockSampler/main/README_EN.md)、[Larryvrh](https://raw.githubusercontent.com/Larryvrh/ComfyUI-MiniMax-H3-Turbo/main/README.md) |
| **sampler 用错** | 【原文】**`Avoid res_multistep`**（用户报告彩色闪光「disco lights」）；4 步基线应配 stock `euler` + `simple`，`denoise=1.0` |
| **双脸/重影** | 【原文】T8mars 推翻自己早期归因：「失败的 r1–r3 路线把**通用 LarryVrh EMA Turbo LoRA** 与**非官方 8 步/shift 6:3** 组合」；正解＝官方 `ref2v_turbo_4step_v0.1`、strength 1.0、**四个 Euler/simple 步**、shift 12/3、1024×768 —— 同 seed 对照后双脸重影消失 |
| 拖影 | 【原文】某家族 v4「静帧增强」的代价只在 **4 步 + 大快运动** 出现；用 6–8 步基本消除 |
| **音频过冲/爆音** | 【原文】视频/音频是两个 flow 调度（12/3），旧路径音频速度已被 `dσa/dσv` 预乘，单时钟采样器用视频 delta 近似 → **4 步大步长严重 overshoot**；对策：用含 `ModelSamplingAV` 的新核 + stock `euler`；并检查 strength 1.0 / **非剪枝底模** / 官方 FP32 audio VAE |
| 强度 1.8–2.2 | 【原文】那是**早期 stock Euler+Beta 权宜方案**的产物；作者 checkpoint `alpha==rank`，原生 scale=1.0；「提高强度无法修复错误的音频调度」 |
| **剪枝底模** | 【原文】剪枝把完整 AdaLN `(96768,2688)` 换成 `(96768,8)`；Turbo LoRA 若针对完整投影 → 50 blocks + final layer shape 不匹配，**部分 LoRA 未应用**、音频变差（报错串 `adaln_proj.linear.weight shape '[96768, 8]' is invalid`）→ **本机实测核对见第二部分** |
| **加载器** | 【原文】作者路径是 `base(x)+B(A(x))`；折进 BF16 会舍入掉小更新、也无法 patch 量化权重 → 用 `Load LoRA (Bypass, Model Only)` @ 1.0 |
| **NFE ≠ UI 步数** | 【原文】vLLM-Omni PR #7219：以前 `num_inference_steps=N` 生成 N 个 sigma 边界 → **N−1 次 DiT 评估**；LightX2V `infer_steps=5` 指 **5 个 sigma 网格点**；Star7 界面「**Sigma 数量减一才是实际步数**」 |
| 加速节点在少步下无效 | 【原文】block_cache 在 **14 步实测 0 命中、完全惰性**，只在 30+ 步有意义 |

## 5. SageAttention / sm120

| 问题 | 结论 |
|---|---|
| H3 专用 Sage 节点在 **5060 Ti（CC 12.x）** 报错 | 【原文】KJNodes issue #721 标题即此；错误串 `sageattention is not new enough version or could not determine CUDA architecture...`；kijai 回「you need newer version of sageattention」→ [KJNodes #721](https://api.github.com/repos/kijai/ComfyUI-KJNodes/issues/721) |
| 官方支持口径 | 【原文】Current Features 只写「Optimized kernels for **Ampere, Ada and Hopper**」；Blackwell 只写 CUDA≥12.8；SA3（Blackwell FP4）是独立目录，且官方说「**SA2 更准**」→ [SageAttention README](https://raw.githubusercontent.com/thu-ml/SageAttention/main/README.md) |
| 量化注意力 → 掉总线 | 【原文】实名报告多条（双 5060 Ti、Kornifex92、Cloudreadypc）→ 换纯 SDPA/FA2 |
| **int32 溢出风险** | 【原文】KJNodes 源码内置告警：H3 是 56×128=7168，`seq_len × 7168 ≥ 2^31`（≈299,593 token）时打印 `over the int32-safe attention range...` |
| **Sage 节点不能被旁路禁用** | 【原文】`PathchSageAttentionKJ` DESCRIPTION：「This doesn't use the model patching system and thus **can't be disabled without running the node again with 'disabled' option**」 |

## 6. ComfyUI 版本兼容（`FLOW_AV` / `ModelSamplingAV`）

- 【原文】`bdcb886a4` ＝ PR #15243（kijai，2026-08-06）：新增 `ModelSamplingAV`（带 `audio_shift`）、`ModelType.FLOW_AV`，**删除 `time_shift_slope`**，节点显示名改 `ModelSamplingMiniMaxH3`。
- 【原文】PR 警告：「**Output changes for MiniMax-H3 at every step count.**」→ **新旧同 seed 结果不可直接比对**。
- 【原文】判断方式：**用 commit 或 `hasattr(comfy.model_sampling, "ModelSamplingAV")`，不要只看版本字符串**。
- 【原文】后续破坏点：`efd4e951a`、`2504e68d4`、**`e308cc73b`（Sol-Attn/top-k SLA/VSA 合并为原生 Block Sparse Attention，替换 H3 全部 DiT block → 与 Block Cache 互斥）**、`804eb5513`。

## 7. 有争议／未解决

1. 掉总线根因**无共识**（量化注意力×DynamicVRAM / 可见内存触发 / 散热 / GSP 固件 / 功耗曲线 / 跨 GPU PCIe）；#15488 仍 open。
2. `--disable-pinned-memory` 是否有效：同一用户先肯定后更正，另两人否定。
3. `MAX_PINNED_MEMORY` 是 `ram*0.40` 还是 `ram*0.90`（版本差异）。
4. Sage 在 sm120 算不算"支持"。
5. **4 步 LoRA 跑 10 步是否算错**：官方 NFE=4；兼容节点列为"额外质量测试"；另一作者说 >8 步过锐——**无权威裁决**。
6. `--fast-disk` / `--cache-lru` 在 H3 上缺正面受控实测。
7. block cache 类加速是否真有用。

---

# 第二部分：本机实测核对（我在 zywpc 上验的，不是社区转述）

| 检查项 | 结果 | 含义 |
|---|---|---|
| **注意力后端** | 日志 `Using pytorch attention` | ✅ 正是社区说「从未崩」的纯 PyTorch 路径；**你不在量化注意力那类故障里** |
| **驱动 memdesc 泄漏判别器** `0x00000051` | 上一 boot **0** 次、本 boot **0** 次 | ❌ 阴性，排除该泄漏型故障 |
| **功耗上限** | `Current = Default = Max = 180 W` | 社区建议 ≤80% → 可试 `nvidia-smi -pl 144`（需 root） |
| **KJNodes 缓解节点** | `MiniMaxChunkFeedForward` ✅ 有、`MiniMaxLowVRAMAttention` ✅ 有（已注册） | **社区那两个关键缓解节点你机器上已经能直接用**，只是没接到模型链里 |
| **T8 自己的低显存节点**（v1.81.0） | `MiniMaxH3ChunkFeedForwardT8Advanced` / `MiniMaxH3LowVRAMAttentionT8Advanced` ❌ 未注册 | 已装的 T8 包早于 v1.81.0 节点集（新克隆的在 `~/h3-t8/`） |
| **你用的 turbo LoRA × pruned 底模** | **624 个张量归组为 208 个目标 → 与 pruned 底模 shape 匹配 208/208，缺 0、不匹配 0**；LoRA 里 **adaln 键 = 0** | ✅ **社区那条「pruned 底模破坏 Turbo LoRA」对你不成立**：这个 LoRA 根本不碰 AdaLN。底模确实是 pruned AdaLN `[96768, 8]`（`minimax_h3_ref2va_pruned_int8_convrot` 与 `w4a8_mixed` 都是） |
| 你用的加载器 | 工作流里是通用 `LoraLoaderModelOnly`；T8 V3 用的是 `LoraLoaderBypassModelOnly`（你机器上**已注册**） | ⚠️ 量化底模建议按社区改用 bypass 加载器 |
| 采样器 | 你的任务：`res_multistep` + `simple` + 10 步 | ⚠️ 社区明确 **avoid res_multistep**（disco lights），4 步基线配 `euler`+`simple` |
| 当前启动参数 | `--lowvram --force-fp16 --reserve-vram 1.0 --fast-disk --cache-lru 2 --disable-pinned-memory` | `--lowvram` 在 dynamic VRAM 下是 **no-op**；`--reserve-vram` 被社区列为"让失败更糟"；`--disable-pinned-memory` ✅ 已加 |
| 底模体积 | `ref2va_pruned_int8_convrot` 20.0 GB / `ref2va_pruned_w4a8_mixed` **11.2 GB** | 你死机时 RSS 28.3 GB 大头就是 stage 20 GB 模型；**11.2 GB 那个是现成的降内存选项** |

---

# 第三部分：给你的优先级行动清单

## P0（免费、有社区实证、且不降低画质）

1. **把 KJNodes 的 `MiniMax H3 Low VRAM Attention` + `MiniMax H3 Chunk FeedForward` 接进模型链**（默认参数）——社区里 5060 Ti 级用户靠这两个把 H3 从「必崩」变成「能连跑 25 分钟」；你机器上已有。
2. **功耗墙降到 ~144 W**（`sudo nvidia-smi -pl 144`，80%）：#15480 原文「供耗上限 >80% 驱动就崩」；这是最省事的一条。
3. **采样器改 `euler` + `simple`**（别用 `res_multistep`），步数先做 **4 / 8 / 10 固定 seed 对照**；记住「UI 步数 ≠ NFE」。
4. **LoRA 加载器改 `LoraLoaderBypassModelOnly` @1.0**（你已有此节点）。

## P1（针对口型，需要多一步素材准备）

5. **做一条「隔离人声」音轨**（Demucs 等）：你机器上**目前没有任何分离工具**（只有 ffmpeg/torchaudio）——这是走 Vocal Lock 路线的前置条件。
6. **两条音频合同**：完整原曲留到最后混一次；隔离人声作驱动（T8 `lock_source` 路线）或按 LongMedia 的 `lip_sync` 把 audio_1 冻结为生成时钟。
7. **段长收紧到 5–8 秒**（你现在 200–230 帧 = 8.3–9.6 s）：LongMedia 对 16GB + 口型/身份迁移场景的建议就是 5–8 s。
8. **验收用 SyncNet 而不是肉眼**：25fps ±1 帧为佳，400 ms 延迟负对照应读 +9 帧。

## P2（可选）

9. 底模换 **`minimax_h3_ref2va_pruned_w4a8_mixed`（11.2 GB）** 试内存占用与速度（注意它同样 pruned，需重验画质/音频）。
10. 装 T8 新版节点包（v1.81.0 的低显存节点）或直接用 KJNodes 的等价节点（已具备）。
11. 别在采样期间轮询 HTTP/刷页面；发现同一片段慢 ~1.8× 就先重启 ComfyUI。

## ⚠️ 对之前结论的两处修正

- **netconsole + `panic_on_lockup` 未必有用**：社区那例「总主机冻结」在装了 `hung_task_panic` + `softlockup_panic` + 双向 netconsole 后**依然什么都没抓到**（连网络日志都没发出去）。所以那套是「尽力而为」，不是保险。
- **「pruned 底模破坏 Turbo LoRA」对你不适用**（本机逐键验证 208/208 匹配）——但**加载器**和**采样器**这两条仍然成立。

---

# 第四部分：T8mars 作者本人发帖 + 上游坑（追加，2026-09-15 晚）

> 来源：第二个调研 agent 全量拉取 4 个重点仓库共 **64 条 issue/PR** + 作者文档逐条检索 + 第三方仓库 issue + HF Discussions + B站/论坛。
> 说明：4 个仓库**全部未启用 Discussions**；Reddit（API/jina 均被封）、贴吧、X/Twitter、知乎（403）**均未找到**针对这些包的讨论。

## 4.1 ⚠️ 最重要的一条：作者建议「4 步加速 LoRA 实际跑 8–10 步」

- 【原文·作者本人发帖 @T8star-Aix】**4 步加速 LoRA 会爆音，根因是 video/audio shift 不一致（12/3）**；作者建议**实际跑 8–10 步**，并且**不要在低步数上再叠加跳步/跳层/BlockCache**。
  出处：<https://bbs.monster/thread-4626-1-1.html>
- **对本机的直接含义**：
  - 你现在跑 **10 步 —— 与作者建议一致，不要因为「官方 NFE=4」就去改成 4 步**（我在第一部分写的「4 步基线」需要按这条修正：官方规格是 NFE=4，但实践上作者为了音频质量推荐 8–10）。
  - 但你的工作流里**挂着 `MiniMaxH3Cache` 跳步缓存**，正好撞上作者明确警告的「低步数 + 跳步/BlockCache」组合 → **建议关掉它做 A/B**。

## 4.2 Block Cache 是近似缓存，不是无损（有量化数字）

- 【原文】作者实测 OFF vs ON：**SSIM 0.8432 / 0.7577、音频 SNR 7.99 dB、audio corr 0.9207** —— **非 bit-exact**；但提速真实（**23.98% 全流程 / 27.99% 采样**）。
- 【原文】默认阈值在 2080Ti 上 **0/4 命中**，需把阈值调到 1.0 才有 2/4。
- 【原文】issue #4（v1.0.4 已修）：FinalLayer 七参数崩溃。
- **含义**：任何「缓存/跳步」类节点（含你在用的 `MiniMaxH3Cache`）都会改变输出。你在追口型和音频质量时，**应该先关缓存做基准**，再决定要不要用它换时间。

## 4.3 Prompt Relay 的 tokenizer 校验 bug 至今未修

- 【原文】#13 在 v1.52.3 号称修好，**#20（ComfyUI 0.35.0）又复现且至今 open、作者 0 回复**；错误串含 **`native MiniMax H3 tokenizer lacks the byte-token contract`**。
- **含义**：你现在是 ComfyUI **v0.34.0-29-gec803fc9**；**升到 0.35 再上 Prompt Relay 有踩这个坑的风险**。

## 4.4 ComfyRegistry 安装链路是坏的

- 【原文】Manager 只能装到 **1.47.0**，**v1.80.0 被 Flagged**；作者已向官方提工单 `Comfy-Org/registry-backend#233`，**至今未解决**。
- **含义**：**别用 Manager 装 T8 的包**（装到的会是旧版）。我们这次是 `git clone` 直接拿 main，正确做法。

## 4.5 sm120 上游坑（与 AGENTS.md「掉总线元凶」记录一致）

- 【原文】`Comfy-Org/ComfyUI#15263`：**SageAttention FP8 在 sm_120 上、>160k token 出纯噪声**。
- 【原文】`KJNodes#729`：**`MiniMaxH3MemoryEfficientSageAttentionPatch` 在长提示词下 C++ 断言直接 abort 整个进程** —— 与我们 09-14 记录的「Studio 硬编码插入该节点 → 掉总线」方向一致，等于**上游独立佐证**。
- 【原文】T8 自己的 `environment_audit` 里就有 `sage_sm120_high_token_output_corruption_risk` 守卫。
- **含义**：你目前是**纯 PyTorch attention**，不在这条风险里；**继续不要开 Sage/量化注意力**。

## 4.6 追加后的行动清单修订

| 原建议 | 修订 |
|---|---|
| 「4 步基线配 euler+simple，做 4/8/10 A/B」 | **保留 A/B**，但先说清：作者本人推荐 **8–10 步**（为音频质量），所以 **10 步不是错**；要动的是**关掉 Cache 跳步** |
| 「采样器避开 res_multistep」 | 仍然成立（用户报 disco lights），但**优先级低于关缓存** |
| 装 T8 新版包 | **不要走 Manager**（只到 1.47.0）；用 `git clone`（已做，在 `~/h3-t8/`） |
| 升级 ComfyUI 到 0.35 用 Prompt Relay | **先别升**：tokenizer 校验 bug #20 在 0.35 复现且 open |

---

# 第五部分：作者本人四篇论坛帖 + 64 条 issue 全量 + 本机 LoRA 全量核对（追加，2026-09-15 深夜）

> 第二个 agent 全量拉取 4 个仓库 **64 条 issue/PR**（audio 20 / blockcache 4 / prompt-enhancer 19 / prompt-skill 21）+ 作者文档逐条检索 + B站评论 + HF Discussions + 第三方仓库。
> 作者身份核实：`T8mars` = `T8star-Aix`（id 96167788，49 仓库，569 followers，China/Shanghai）。**4 个仓库 `has_discussions` 全部 false**（所以"Discussions 反馈"源头为空）。

## 5.1 作者本人 bbs.monster 四帖（比之前转述更精确）

**①《4步加速LoRA适配ComfyUI：8步设置与爆音规避》**（作者本人，2026-08-06，浏览 4195）<https://bbs.monster/thread-4626-1-1.html>
- 【原文】「音频与视频采用不同 shift，四步最后阶段可能出现音频未充分收敛而发生**爆音**」
- 【原文】「作者虽然使用名为『4步』的 LoRA，**仍建议实际跑 8 步**；遇到**小脸或音频收敛不足时可尝试 10 步**」
- 【原文】设置要求 **Euler 采样器 + Beta 调度器**
- 【原文】「**低步数加速后不要再叠加跳步、跳层或 BlockCache**……8 步本身已经很短，再继续跳过计算容易引入**画面崩坏或音频问题**」
- 【原文】**不推荐裁剪版模型**；多参考专用模型当时未适配

**②《BlockCache：音频感知加速、量化对比与低显存方案》**（作者本人，2026-08-05，浏览 4295）<https://bbs.monster/thread-4604-1-1.html>
- 【原文】「**缓存并非无损**。高速动作、小脸和复杂动态更容易因激进跳层损失细节；建议**降低阈值、推迟缓存开始位置、提前结束缓存或直接关闭加速**」
- 同场景计时（**非通用承诺**）：BF16 ≈255s、INT8 ≈121s、+SageAttention ≈84s、EasyCache+Sage ≈65s、**H3 BlockCache ≈55s**

**③《提示词增强节点》**（作者本人，2026-08-04）<https://bbs.monster/thread-4596-1-1.html>
- 【原文】「**缓存会跳过变化很小的采样步骤**……**高速运动、舞蹈或复杂动态可能更容易损失脸部和动作细节**，可提高步数、降低阈值或直接关闭跳步」
- 【原文】**「工作流 JSON 可能保存 API Key，分享前应清空」**（安全提醒，值得照做）
- 【原文】INT8 主要帮不支持 FP8 的老卡/低显存设备，**「并不代表质量更高」**；**「模型体积更小也未必更快」**

**④《10Eros Max Test4：加速LoRA与提示词增强器实测》**（作者本人，2026-08-11）<https://bbs.monster/thread-4663-1-1.html>
- 【原文】把加速 LoRA 接到别的模型报 **MAT1/MAT2 不兼容**（51 层、2688 维投影 vs LoRA 低维）→ **「这个 LoRA 是在原基础模型上训练的，并不是专为 Test4 重新训练，因此能用不等于最佳效果」**

## 5.2 ⚠️ 对我 P0 建议的重要修正：**不要同时接两套低显存节点**

- 【原文·T8 `docs/H3_MEMORY_NODES_EXP.md`】「**不要再同时接 KJ 的同名 LowVRAM、ChunkFFN 或 H3 Memory Efficient Sage 节点；它们会争用同一组模块 forward**，T8 节点会明确拒绝，不会静默覆盖」
- **含义**：KJNodes 的 `MiniMaxLowVRAMAttention` + `MiniMaxChunkFeedForward`（你已装 ✅）与 T8 v1.81 的 `MiniMaxH3LowVRAMAttentionT8Advanced` + `MiniMaxH3ChunkFeedForwardT8Advanced` 是**同一组 forward 的竞争者** → **二选一**，别都接。

## 5.3 ⚠️ 缓存类节点对「音频/口型」是净负面（两条独立证据）

- 【原文·ComfyUI issue #15326（open）】H3 + **EasyCache** 默认 `reuse_threshold=0.2`：**视频几乎无损（SSIM 0.95–0.96）但音频明显劣化** —— 独奏钢琴低频变少、发闷、**幅度只剩一半**、谱心 9.6→10.6；逐条数据 `music: skipped 6/20, SSIM 0.956, log-mel L1 0.690, RMS ratio 0.503`。根因：EasyCache **只看视频流决定跳步，却把缓存 residual 也套到音频**，而 H3 音频不共享同一 schedule。<https://github.com/Comfy-Org/ComfyUI/issues/15326>
- 【原文·T8 自己的 VERIFICATION_REPORT】Block Cache OFF vs ON **非 bit-exact**：SSIM **0.8432/0.7577**、uint8 MAE 10.37、audio corr **0.9207**、audio SNR **7.99 dB**；提速 23.98% 全流程 / 27.99% 采样；**默认命中 0/4**，被作者**否决为默认 OOM 处理**；39 帧被降级为 `context_39_high_risk_experimental`。
- **结论**：你在追口型和音频质量，**`MiniMaxH3Cache` 应先关掉做基准**（这也是作者对"低步数 + 跳步"的明确警告）。

## 5.4 作者自己把「口型同步」列为**未验证**

- 【原文·`docs/SPEECH_VALIDATION_REPORT.md`】Denied claims 清单里明确包含 **"ADR phoneme alignment and visual lip synchronization"（音素对齐与**视觉口型同步**）未验证**
- 【原文·同文件】「**Raw ASR contained approximately 4.3s of unrelated lead-in**, followed by the complete target. Therefore **a bare Ref2VA completion cannot be assumed to contain only the requested line**」（即 issue #17 的书面承认：Ref2VA 可能在目标语音前多出 ~4.3 秒无关音频）
- 【原文·`docs/README_ComfyUI.md`】SyncNet 实测候选偏移 **-3/-4 帧**（25fps），400ms 延迟负对照 +9/+10 帧，但「**Confidence is low, and the one-frame mechanical offset gate fails**」；「This is **not** evidence of universal lip-sync stability…」
- 【原文】**16GB 现实**：整机峰值 **16,262–16,315 MiB / 总量 16,379.5 MiB** →「observed whole-device peak **headroom was only about 64–118 MiB**」；「**The pre-registered 512MiB safety gate fails**, so this configuration must not be labelled `memory_safe`」；「**`keep_loaded` is therefore not a safe 16GiB default.**」
- **含义**：① 口型在这套生态里本身就是「未验证」状态，别指望开箱即对；② 16GB 卡跑 H3 的余量只有几十 MiB —— 你之前的整机冻结/掉线，与"贴着显存上限跑"高度一致。

## 5.5 本机 LoRA 全量核对（我做的确定性验证，覆盖 B站实名报错场景）

B站评论区有用户实名报错：**`diffusion_model.blocks.20.adaln_proj.linear.weight shape '[96768, 8]' is invalid for input of size 260112384`**（即把**完整模型**训练的 LoRA 套到 **pruned** 底模上）。我把你 `models/loras/` 里全部 6 个 H3 LoRA 逐个与 `minimax_h3_ref2va_pruned_int8_convrot` 的键/shape 对了一遍：

| LoRA | 体积 | 目标数 | 含 adaln | 对 pruned 底模 |
|---|---:|---:|---:|---|
| `SexGod-NaughtyTimes-lora-MINIMAXH3` | 2364 MB | 258 | **50** | **匹配 258 / 缺 0 / 不符 0** ✅ |
| `minimax_h3_fl2v_turbo_4step_v0.1_comfyui_alpha8` | 1866 MB | 208 | 0 | 208/0/0 ✅ |
| `minimax_h3_fl2v_turbo_4step_v1.0_768p_comfyui_bf16` | 1866 MB | 208 | 0 | 208/0/0 ✅ |
| `minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16` | 1866 MB | 208 | 0 | 208/0/0 ✅ |
| `minimax_h3_ref2v_turbo_4step_v0.1_comfyui_bf16` | 1866 MB | 208 | 0 | 208/0/0 ✅ |
| `minimax_h3_turbo_4步加速_DasiwaREF2VAHybridV1_curveproj1025_compat_v001-T8` | 758 MB | 259 | **51** | **匹配 259 / 缺 0 / 不符 0** ✅ |

**结论：你手上 6 个 LoRA 全部与 pruned 底模 100% 兼容**——连带 adaln 的两个（SexGod、Dasiwa-T8）的 adaln 目标推出来的输入维也是 **8**，说明它们本就是**针对 pruned 投影**的。
⚠️ 所以 B站那个报错的成因（拿完整模型 LoRA 套 pruned 底模）**不适用于你现在的 LoRA**；但**风险真实存在**——你以后若从网上拿新 LoRA，先按这个方法核一遍再用。
⚠️ 另一层区分：作者论坛帖里**不推荐裁剪版模型**是**质量/训练匹配**层面的建议，与上面的**形状兼容**是两件事，两者不矛盾。

## 5.6 其他值得记的（来自 64 条 issue 全量）

| 项 | 结论 |
|---|---|
| **Manager 装不到新版** | Registry 里 v1.80.0 状态 `NodeVersionStatusFlagged`/`pending`，公开 latest 回退 **1.47.0**；作者已提 `Comfy-Org/registry-backend#233`，并加固发布门禁。**用 git clone，别用 Manager** |
| **Prompt Relay tokenizer** | #13（0.33.4）→ v1.52.3 修；**#20（ComfyUI 0.35.0）复发、0 回复、open** |
| 加速器误报 | 「GPU/加速器不受支持」是**前端名称归一化 bug**（Registry 返回 `GPU :: NVIDIA CUDA` vs 本机 `CUDA`），作者坚持不改合法 classifier；上游 `ComfyUI_frontend#15364` / `#17428` 仍 open |
| FLOW_AV 变更 | #2 `'MiniMaxH3FlowSampling' object has no attribute 'audio_scale'` → **1.3.1 修复**（`1c8040b`，区分新旧协议）—— 正是我们关注的那次核心变更的实例 |
| sm120 硬崩 | #16：`FLASH_ATTENTION` 在 sm120 无 kernel → 静默走 **mem-efficient cutlass** → 长序列**进程级 abort（无 Python traceback）**；作者 **v1.75.0** 修复（capability major 12 时只用 `CUDNN_ATTENTION/FLASH_ATTENTION`，**永不 mem-efficient fallback**） |
| SageAttention 判定失败 | #3：抛错点在 **KJNodes**（`ltxv_nodes.py`），非 T8 代码；作者提供**只读环境审计**（包导入/core 符号/wheel sm 架构），按外部依赖关闭 |
| **SageAttention sm_120 噪声** | ComfyUI #15263（open，15 评论）：FP8 PV kernel 在 sm_120 约 **167k token 以上出噪声**（142–154k 干净）；报告者后来自我更正 **"This works now on ComfyUI 0.31.1"**，并作废 `sageattn_qk_int8_pv_fp16_cuda`（sm_120 上首调 abort）——**该架构只有 `auto` 能跑** |
| **KJNodes#729** | `MiniMaxH3MemoryEfficientSageAttentionPatch` 在 sm90 长提示词下 **C++ 断言 abort 整个进程**（`value.size(3) >= div_ceil(kv_len, CTA_K) * CTA_K`；sm90 要求 128 对齐而 per_channel_fp8 只 pad 到 64）→ 已修。**与 AGENTS.md「掉总线元凶」同族**（长序列 + 该 patch → 进程级崩溃） |
| 第三方依赖缺口 | `comfyui-vrgamedevgirl` 的 Ref-to-Video 2-Pass 46/46 场景全失败，就因为**没声明依赖 `MiniMaxH3AVLatentSeparateT8`**；已由 PR #174 补进安装器 |
| B站评论区实名问题 | ① LoRA adaln shape 报错（见 5.5，**不适用于你**）；② **10 步下人物结构崩坏**：「使用10步的情况下…人物转身的时候，直接**头和身体反了**」，且**同一 seed 不用 LoRA 就不错** → 值得在 **8 步**下做一次同 seed A/B；③ 5090D 32G 卡住 vs 4070 12G 顺跑（**互相矛盾，无日志**） |
| HF Discussions | t8star 的 4 个 H3 模型仓库共 **5 条讨论，全部 open、作者 0 回复**（含"裁剪版跑不了高分辨率"、模型页无工作流、`Minimax-H3-Super-Acceleration-Comfy` 被质疑"文件其实是 LTX2.5"） |
| 作者响应风格 | 修得快、写明根因+提交号+测试数；**会自我推翻**（#10 主动重开承认回归测试遗漏）；对上游缺陷不绕过（#12/#19）；但**最新 open 的 #20 零回复**、HF 讨论零回复、B站评论多不答 |