调研方式：两个后台 agent 只用
web_search/web_fetch（未 ssh、未改文件），全部结论带 URL； 「本机实测核对」一节是我在你 GPU 机（zywpc）上做的确定性验证。 引用约定：【原文】＝来源明确写的；【推测】＝推断；「未找到」＝确实没查到。
| 问题 | 社区给出的原因 | 解决办法 | 出处 |
|---|---|---|---|
| H3 换人后口型对不上原唱 | 【原文】「只在最终封装时把原声轨接回去，不足以保住说话/歌唱同步」 | 把 video_1 + audio_1 作为成对 video_audio 参考块送进 H3，同时把 audio_1 写进目标音频流并冻结为生成时钟，最终仍还原未改动的原波形（audio_mode = auto / preserve / preserve_reference） | LongMedia AUDIO_MODES_GUIDE |
| 想用全新配音/换歌驱动口型 | 此时 Audio1 不能谎称是 Video1 原声 | h3_mode = video_ref_edit + audio_mode = lip_sync（还需 image_1），Audio1 作独立权威时钟 | 同上 |
| H3 到底会不会对口型 | 【原文】T8mars：「H3 可以让视觉表演受音频条件约束，但不强制音素级口型」「这是音频条件化表演编排，不是音素级 lip solver」 | 最终口型/身份/演技必须全速人工复核 | T8 audio docs |
| 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、T8 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 |
| 提示词层面 | 不要猜歌词 | 【原文】「不推测歌词写进 <d>，而是让嘴去对 <Audio 1> 本身」；分离人声标 <Audio 1>: fully_copy 并关联歌唱的 <Subject 1> (S1) | animede |
| 唱跳时嘴被挡 | — | 歌唱区间强制正面或 3/4 向 medium close-up、嘴部全程可见 | 同上 |
| 分镜切在字上导致口型断 | — | 按声学特征（静音、人声音量谷、换气点、段落、拍、小节）动态规划切分，而不是等长切 | 同上 |
| 长链越唱越闷 | 【原文】每跳拿上一段自己的输出当条件，声音频段会塌：8 段链 bank_pinned=0 时 4–10 kHz 掉 84–92% | bank_pinned=1；continuity=cut + memory_frames=0 | joeygambino SETTINGS |
| 口型"僵" | 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、#3、PR #10 |
| 其他相关节点 | — | LongMedia（lip_sync）、LeonQ8 Audio Drive、T8 audio 节点、animede Web 应用 | LeonQ8 README |
| SyncNet 节点 | — | 未找到 H3 专用可安装 SyncNet 节点（社区当外部脚本用） | — |
| 问题 | 原因 | 办法 | 出处 |
|---|---|---|---|
| 进程无 traceback 直接死 | 【原文】内核 OOM-killer，由 ComfyUI 页锁定池触发；锁页不可换出/回收 | --disable-pinned-memory（之后再加大 swap 才有意义）；dmesg -T | grep -i oom-kill 确认 | tonyd2wild |
| 报 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 |
| 激活峰值 | 【原文】MLP 8192/4096/2048/1024 ≈ 1970/1228/858/672 MiB；RoPE ≈ 820/638/550/501 MiB；attention kernel OOM 分块救不了 | 先降 MLP | star7 |
| 预留反噬 15× | 【原文】预留把权重预算挤掉；实测 960×544：第1段整载 18.8 s/it，第2段差 399 MB → 283 s/it | 预留上限 ＝ free − weights − 384 MB；同链 36m54s→14m03s；预留默认 0 | joeygambino |
| 分辨率口径 | — | 【原文】短边 768、单边 ≤ ~1344；16:9 用 0.98 MP＝1344×768（不要 1.0 MP）；宽高 32 倍数；帧数 17k+5（124≈5s，验证 124–362） | ComfyUI 官方文档 |
| 345 帧悬崖 | 【原文】4090 上 7 次里 6 次慢 3–17×，不是 VRAM，是个别 step 卡住 | 328 帧稳定 | matsuo |
| 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 | |
--fast-disk H3 实测 | — | 未找到正面受控收益；只有一次负面 | #15488 comments |
| 问题 | 原因／证据 | 办法 | 出处 |
|---|---|---|---|
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 |
| 排除项（别再试） | 【原文】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、KJNodes 源码 |
| 关键缓解②功耗墙 | 【原文】#15480（5090+192GB+610.88）：「運行 minimax h3 文生影片，nvidia 顯卡的供耗上限如果大於 80%，驅動就會崩潰，整個帶崩 comfyui」 | 功耗上限 ≤80% | ComfyUI #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 论坛 | |
| 「总主机冻结」取证 | 【原文】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 论坛 |
| ComfyUI 侧"将死"信号 | 【原文】采样期间不要轮询 HTTP（会卡 18–43 s）；CUDA context 真死前会先劣化（同片慢 1.8×） | 一出现就重启；排查加 --debug-hang | matsuo |
| netconsole/panic 类 | — | 未找到 panic_on_lockup 原词的 H3 记录；社区用 hung_task_panic/softlockup_panic + netconsole，结果抓不到 | — |
| 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。 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、Larryvrh |
| 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+ 步有意义 |
| 问题 | 结论 |
|---|---|
| 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 |
| 官方支持口径 | 【原文】Current Features 只写「Optimized kernels for Ampere, Ada and Hopper」；Blackwell 只写 CUDA≥12.8；SA3（Blackwell FP4）是独立目录，且官方说「SA2 更准」→ SageAttention README |
| 量化注意力 → 掉总线 | 【原文】实名报告多条（双 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」 |
FLOW_AV / ModelSamplingAV）bdcb886a4 ＝ PR #15243（kijai，2026-08-06）：新增 ModelSamplingAV（带 audio_shift）、ModelType.FLOW_AV，删除 time_shift_slope，节点显示名改 ModelSamplingMiniMaxH3。hasattr(comfy.model_sampling, "ModelSamplingAV")，不要只看版本字符串。efd4e951a、2504e68d4、e308cc73b（Sol-Attn/top-k SLA/VSA 合并为原生 Block Sparse Attention，替换 H3 全部 DiT block → 与 Block Cache 互斥）、804eb5513。--disable-pinned-memory 是否有效：同一用户先肯定后更正，另两人否定。MAX_PINNED_MEMORY 是 ram*0.40 还是 ram*0.90（版本差异）。--fast-disk / --cache-lru 在 H3 上缺正面受控实测。| 检查项 | 结果 | 含义 |
|---|---|---|
| 注意力后端 | 日志 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 那个是现成的降内存选项 |
MiniMax H3 Low VRAM Attention + MiniMax H3 Chunk FeedForward 接进模型链（默认参数）——社区里 5060 Ti 级用户靠这两个把 H3 从「必崩」变成「能连跑 25 分钟」；你机器上已有。sudo nvidia-smi -pl 144，80%）：#15480 原文「供耗上限 >80% 驱动就崩」；这是最省事的一条。euler + simple（别用 res_multistep），步数先做 4 / 8 / 10 固定 seed 对照；记住「UI 步数 ≠ NFE」。LoraLoaderBypassModelOnly @1.0（你已有此节点）。lock_source 路线）或按 LongMedia 的 lip_sync 把 audio_1 冻结为生成时钟。minimax_h3_ref2va_pruned_w4a8_mixed（11.2 GB） 试内存占用与速度（注意它同样 pruned，需重验画质/音频）。panic_on_lockup 未必有用：社区那例「总主机冻结」在装了 hung_task_panic + softlockup_panic + 双向 netconsole 后依然什么都没抓到（连网络日志都没发出去）。所以那套是「尽力而为」，不是保险。来源：第二个调研 agent 全量拉取 4 个重点仓库共 64 条 issue/PR + 作者文档逐条检索 + 第三方仓库 issue + HF Discussions + B站/论坛。 说明：4 个仓库全部未启用 Discussions；Reddit（API/jina 均被封）、贴吧、X/Twitter、知乎（403）均未找到针对这些包的讨论。
MiniMaxH3Cache 跳步缓存，正好撞上作者明确警告的「低步数 + 跳步/BlockCache」组合 → 建议关掉它做 A/B。MiniMaxH3Cache）都会改变输出。你在追口型和音频质量时，应该先关缓存做基准，再决定要不要用它换时间。native MiniMax H3 tokenizer lacks the byte-token contract。Comfy-Org/registry-backend#233，至今未解决。git clone 直接拿 main，正确做法。Comfy-Org/ComfyUI#15263：SageAttention FP8 在 sm_120 上、>160k token 出纯噪声。KJNodes#729：MiniMaxH3MemoryEfficientSageAttentionPatch 在长提示词下 C++ 断言直接 abort 整个进程 —— 与我们 09-14 记录的「Studio 硬编码插入该节点 → 掉总线」方向一致，等于上游独立佐证。environment_audit 里就有 sage_sm120_high_token_output_corruption_risk 守卫。| 原建议 | 修订 |
|---|---|
| 「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 |
第二个 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 反馈"源头为空）。
①《4步加速LoRA适配ComfyUI：8步设置与爆音规避》（作者本人，2026-08-06，浏览 4195）https://bbs.monster/thread-4626-1-1.html
②《BlockCache：音频感知加速、量化对比与低显存方案》（作者本人，2026-08-05，浏览 4295）https://bbs.monster/thread-4604-1-1.html
③《提示词增强节点》（作者本人，2026-08-04）https://bbs.monster/thread-4596-1-1.html
④《10Eros Max Test4：加速LoRA与提示词增强器实测》（作者本人，2026-08-11）https://bbs.monster/thread-4663-1-1.html
docs/H3_MEMORY_NODES_EXP.md】「不要再同时接 KJ 的同名 LowVRAM、ChunkFFN 或 H3 Memory Efficient Sage 节点；它们会争用同一组模块 forward，T8 节点会明确拒绝，不会静默覆盖」MiniMaxLowVRAMAttention + MiniMaxChunkFeedForward（你已装 ✅）与 T8 v1.81 的 MiniMaxH3LowVRAMAttentionT8Advanced + MiniMaxH3ChunkFeedForwardT8Advanced 是同一组 forward 的竞争者 → 二选一，别都接。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/15326context_39_high_risk_experimental。MiniMaxH3Cache 应先关掉做基准（这也是作者对"低步数 + 跳步"的明确警告）。docs/SPEECH_VALIDATION_REPORT.md】Denied claims 清单里明确包含 "ADR phoneme alignment and visual lip synchronization"（音素对齐与视觉口型同步）未验证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…」memory_safe」；「keep_loaded is therefore not a safe 16GiB default.」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，先按这个方法核一遍再用。 ⚠️ 另一层区分：作者论坛帖里不推荐裁剪版模型是质量/训练匹配层面的建议，与上面的形状兼容是两件事，两者不矛盾。
| 项 | 结论 |
|---|---|
| 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站评论多不答 |