MiniMax H3 BlockCache：音频感知加速、量化对比与低显存方案

作者：@T8star-Aix

MiniMax H3 BlockCache：音频感知加速、量化对比与低显存方案

一句话导读：T8 开源了面向 ComfyUI 原生 MiniMax H3 的 BlockCache 节点，以音频和视频联合稳定性判断是否复用后续 Block，并结合量化、注意力加速、显存卸载和超分方案做了完整取舍说明。

核心内容：
1. 视频先比较 BF16、FP8 scaled、INT8 ConvRot 等精度路线。作者认为 INT8 ConvRot 通过旋转量化分散异常值，明显优于传统 INT8，但对其接近甚至超过 BF16 的说法保持谨慎，并用多组盲测强调实际质量和分辨率应优先于宣传数据。
2. 新的 MiniMax H3 Block Cache (T8) 每次先计算 Block 0，分别衡量目标音频与目标视频的 residual diff；只有两者都低于阈值时才复用缓存并跳过 Block 1–49。开源实现默认 residual_diff_threshold=0.12、start_percent=0.08、end_percent=0.95、max_consecutive_hits=2、metric_stride=8，且不能和 EasyCache/LazyCache 叠加。
3. 视频中的同场景计时用于展示相对取舍：BF16 约 255 秒，INT8 约 121 秒，叠加 SageAttention 后约 84 秒，EasyCache 加 SageAttention 约 65 秒，作者的 H3 BlockCache 测试约 55 秒。它们不是通用性能承诺，速度和质量会随硬件、模型格式、分辨率、帧数、步数及缓存阈值变化。
4. 缓存并非无损。高速动作、小脸和复杂动态更容易因激进跳层损失细节；作者建议降低阈值、推迟缓存开始位置、提前结束缓存或直接关闭加速。分辨率对脸部稳定性的影响尤其明显，条件允许时优先提高到模型较稳的分辨率，再谈加速。
5. 低显存路线需区分“能跑”和“跑得快”。ComfyUI 原生动态显存管理适合官方节点；UniBlockSwap 可手动把层卸载到 CPU、内存甚至虚拟内存，代价是频繁交换降低速度；16GB 以上还可用 ReservedVRAM 预留一部分显存，8GB 设备则不适合额外预留。
6. 在性价比优先的场景，可先生成较低分辨率视频，再用 RTX VSR 做快速基础高清化，或用 FlashVSR 换取更明显的修复效果。1080p 长视频的注意力、参考 latent 与 50 层计算开销会快速上升，宜先用 5 至 10 秒短片验证参数。
7. 节点仓库将其标为实验性近似缓存，只接受 ComfyUI 原生 MiniMaxH3Model，不修改核心文件或 Comfy Kitchen .pyd。音频或视频任一变化超过阈值都会回到完整 50 层计算，并限制连续缓存命中次数以降低持续跳层造成的质量风险。

适合人群：正在比较 MiniMax H3 量化格式、希望兼顾音画质量与生成速度，或需要在 8GB/16GB 等有限显存环境中规划 ComfyUI 加速与卸载方案的用户。

相关夸克网盘链接：
【模型及工作流：https://pan.quark.cn/s/a30a9a95a1bf】
【T8 comfyui整合包：https://pan.quark.cn/s/f07ebf88ff0d】
【无限画布整合包v2.6.8：https://pan.quark.cn/s/5871a0142ff3】
【贞贞整合包V4.8A：https://pan.quark.cn/s/ed4f5cc2db75】

补充说明：本文根据授权视频约 25 分钟完整音频转写、默认第一页评论、视频简介及作者公开节点源码整理。实际速度、显存占用与成片质量依硬件和参数而异；请遵守平台规则和适用法律。