资源消耗减半的秘密MiniMax-H3-Comfy-NPU 只读权重底座与多 rank 热缓存机制详解【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPUMiniMax-H3-Comfy-NPU是让 MiniMax-H3 音视频生成模型在 ComfyUI 昇腾 NPU 上跑通的开源适配补丁。它的核心卖点一句话就能说清在效果基本不变的前提下把原基线8 卡 NPU、约 2400 秒生成 768P 15 秒视频的资源消耗砍掉一半——4 卡 NPU、约 500 秒即可出片。省下的卡和时间靠的正是本文要拆解的两套机制只读权重底座与多 rank 热缓存。上面这张机甲龙图片就是 MiniMax-H3 在 ComfyUI 工作流中生成的参考素材之一存放在仓库的示例素材目录 additional_files/input/minimax-h3/ 下。一、为什么原来那么烧资源MiniMax-H3 是一套文本/图片 → 视频 音频的联合生成模型支持 FL2VA首帧/首尾帧生视频和 Ref2VA参考图/视频生视频两类任务。它的底座权重非常重BF16 DiT 约 66.3 GBBF16 文本编码器约 51.5 GB多卡推理时如果每张 NPU 各自从共享存储读取、反序列化一遍权重不仅 IO 翻几倍内存占用也会成倍上涨。原基线用 8 张 NPU 硬扛就是这个原因。二、只读权重底座一份权重只读一次补丁的关键设计是safetensors 文件在整个进程生命周期里只读取一次在 CPU 侧形成一个共享的只读权重底座read-only base。之后所有卡上的模型副本都基于这份底座构建而不是各读各的。这套逻辑可以在补丁文件 comfy-ui-changes.patch 中找到README 中的补丁说明第 5 条README.md 第 43 行附近也有明确描述safetensors 只读取一次形成只读 CPU 权重底座多卡下各 rank 独立持有 NPU 热缓存offload/reload 不重新读取共享存储或反序列化权重。落到代码层面补丁给模型注册了cached_patcher_init_from_source这类来源工厂深拷贝多卡副本时日志会打印Reusing shared checkpoint source——意思就是我不再碰磁盘直接用共享底座。对普通用户意味着什么4 张卡共享同一份 66.3 GB 的权重内存而不是各占一份阶段切换文本编码器 → DiT → VAE时换入换出不再触发磁盘读取切换速度快得多。三、多 rank 热缓存各卡有自己的小仓库有了共享底座接下来解决换入换出慢的问题靠的是per-rank每张卡独立的NPU 热缓存首次运行从共享存储读取权重建立各 rank 的模型拓扑、CPU 热缓存和 NPU 驻留residency此时最慢之后的任务每张 NPU 独立持有自己的热缓存副本。当某个阶段被卸载offload后重新加载reload时直接从本机 CPU 热缓存取数据不重新读取 NFS 共享存储也不重新反序列化卸载有讲究补丁新增的model_stage_unload只会丢掉设备驻留明确注释为retaining a source-backed dynamic RAM cache保留有来源支撑的动态内存缓存——也就是说 NPU 显存腾出来了但 CPU 侧缓存完好无损随时可换回。补丁中的offload_components函数comfy-ui-changes.patch同样遵循这个原则卸载整族克隆副本、释放分配器预留但注释写得很直白——without destroying their CPU reload sources不破坏 CPU 重载源。这张城市屋顶的图片同样是工作流参考素材展示的是 Ref2VA参考图生视频任务常用的输入风格。四、多 NPU 分工谁干什么由一个节点统一管理这套机制由工作流里的Multi-NPU Parallel Config节点统一调度。补丁新增的MultiNPUParallelConfig节点位于 comfy-ui-changes.patch 中comfy_extras/nodes_multigpu.py部分按卡数自动分配角色卡数DiT文本编码器视频 VAE音频 VAE1同卡同卡同卡同卡2卡 0卡 0卡 0卡 14全部卡序列并行全部卡张量并行卡 0卡 3各模块的并行方式也各不相同互不浪费DiTpacked-token 序列并行切 token不切参数Qwen3-VL 文本编码器张量并行按 rank 切分见补丁中minimax_h3_tp_reload_model_options(world_size, rank)视频 VAE多设备时间分块解码各卡解自己的块再羽化合并。这里有个常见疑问四卡显存为什么还是高因为 DiT 是序列并行而非参数分片每张卡都需要完整模型的可换入权重地址空间——加速的是计算不是权重显存的除法。这也是为什么低显存场景推荐 pruned INT8 权重见下文。五、实测效果4 卡约 500 秒资源消耗减半核心场景统一为 4 NPU、1344x768768P、24 fps。节选自 README.md 第 8 章的性能数据场景权重输出端到端耗时Ref2VA Turbo 8 步BF16768P / 15 秒495.79 sRef2VA Turbo 8 步pruned INT8768P / 15 秒454.77 sFL2VA Turbo 8 步INT8768P / 5 秒113.51 sRef2VA res_multistep 21 步BF16768P / 15 秒944.96 sRef2VA Euler 50 步BF16768P / 15 秒2263.03 s对比原基线8 卡、约 2400 秒、效果相同4 卡 495.79 秒意味着卡数减半、耗时约降到 1/5。8 步 Turbo LoRA 是官方推荐的性能基线21/50 步工作流见 additional_files/workflows/minimax-h3/只作质量对照。如果手里只有 1 张 NPU 也别急单卡 INT8 权重 480P 是被验证过的低资源成功性方案FL2VA 480P/15 秒约 371 秒但单卡 BF16 768P 15 秒不在支持范围内。六、上手提醒三分钟看懂两个细节首次任务会慢需要读取约 66.3 GB 的 BF16 DiT 和 51.5 GB 文本编码器并建立各 rank 的拓扑与热缓存。别慌第二次开始就是热的了——这正是热缓存机制的价值所在。卡数要对上服务只暴露 1 或 2 张卡时必须把Multi-NPU Parallel Config节点的npu_count改成相同值可选 1/2/4否则运行前校验会失败。启动服务只需执行 additional_files/runtime/restart-v1.sh完整的环境依赖、容器创建与权重放置清单可参考 README.md 第 2~4 章和机器可读的来源记录 source_deps_info.json。小结MiniMax-H3-Comfy-NPU 用两个朴素却高效的机制改写了多卡推理的资源账本权重只读一次形成共享的只读底座每张 NPU 独立持有热缓存换入换出永不碰盘。再配合按卡数分配角色的多 NPU 调度最终实现 8 卡 → 4 卡、2400 秒 → 约 500 秒的消耗减半。对于想在昇腾平台上跑 MiniMax-H3 音视频生成的新手这套机制开箱即用你只需要关心工作流和素材了。【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
资源消耗减半的秘密：MiniMax-H3-Comfy-NPU 只读权重底座与多 rank 热缓存机制详解
资源消耗减半的秘密MiniMax-H3-Comfy-NPU 只读权重底座与多 rank 热缓存机制详解【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPUMiniMax-H3-Comfy-NPU是让 MiniMax-H3 音视频生成模型在 ComfyUI 昇腾 NPU 上跑通的开源适配补丁。它的核心卖点一句话就能说清在效果基本不变的前提下把原基线8 卡 NPU、约 2400 秒生成 768P 15 秒视频的资源消耗砍掉一半——4 卡 NPU、约 500 秒即可出片。省下的卡和时间靠的正是本文要拆解的两套机制只读权重底座与多 rank 热缓存。上面这张机甲龙图片就是 MiniMax-H3 在 ComfyUI 工作流中生成的参考素材之一存放在仓库的示例素材目录 additional_files/input/minimax-h3/ 下。一、为什么原来那么烧资源MiniMax-H3 是一套文本/图片 → 视频 音频的联合生成模型支持 FL2VA首帧/首尾帧生视频和 Ref2VA参考图/视频生视频两类任务。它的底座权重非常重BF16 DiT 约 66.3 GBBF16 文本编码器约 51.5 GB多卡推理时如果每张 NPU 各自从共享存储读取、反序列化一遍权重不仅 IO 翻几倍内存占用也会成倍上涨。原基线用 8 张 NPU 硬扛就是这个原因。二、只读权重底座一份权重只读一次补丁的关键设计是safetensors 文件在整个进程生命周期里只读取一次在 CPU 侧形成一个共享的只读权重底座read-only base。之后所有卡上的模型副本都基于这份底座构建而不是各读各的。这套逻辑可以在补丁文件 comfy-ui-changes.patch 中找到README 中的补丁说明第 5 条README.md 第 43 行附近也有明确描述safetensors 只读取一次形成只读 CPU 权重底座多卡下各 rank 独立持有 NPU 热缓存offload/reload 不重新读取共享存储或反序列化权重。落到代码层面补丁给模型注册了cached_patcher_init_from_source这类来源工厂深拷贝多卡副本时日志会打印Reusing shared checkpoint source——意思就是我不再碰磁盘直接用共享底座。对普通用户意味着什么4 张卡共享同一份 66.3 GB 的权重内存而不是各占一份阶段切换文本编码器 → DiT → VAE时换入换出不再触发磁盘读取切换速度快得多。三、多 rank 热缓存各卡有自己的小仓库有了共享底座接下来解决换入换出慢的问题靠的是per-rank每张卡独立的NPU 热缓存首次运行从共享存储读取权重建立各 rank 的模型拓扑、CPU 热缓存和 NPU 驻留residency此时最慢之后的任务每张 NPU 独立持有自己的热缓存副本。当某个阶段被卸载offload后重新加载reload时直接从本机 CPU 热缓存取数据不重新读取 NFS 共享存储也不重新反序列化卸载有讲究补丁新增的model_stage_unload只会丢掉设备驻留明确注释为retaining a source-backed dynamic RAM cache保留有来源支撑的动态内存缓存——也就是说 NPU 显存腾出来了但 CPU 侧缓存完好无损随时可换回。补丁中的offload_components函数comfy-ui-changes.patch同样遵循这个原则卸载整族克隆副本、释放分配器预留但注释写得很直白——without destroying their CPU reload sources不破坏 CPU 重载源。这张城市屋顶的图片同样是工作流参考素材展示的是 Ref2VA参考图生视频任务常用的输入风格。四、多 NPU 分工谁干什么由一个节点统一管理这套机制由工作流里的Multi-NPU Parallel Config节点统一调度。补丁新增的MultiNPUParallelConfig节点位于 comfy-ui-changes.patch 中comfy_extras/nodes_multigpu.py部分按卡数自动分配角色卡数DiT文本编码器视频 VAE音频 VAE1同卡同卡同卡同卡2卡 0卡 0卡 0卡 14全部卡序列并行全部卡张量并行卡 0卡 3各模块的并行方式也各不相同互不浪费DiTpacked-token 序列并行切 token不切参数Qwen3-VL 文本编码器张量并行按 rank 切分见补丁中minimax_h3_tp_reload_model_options(world_size, rank)视频 VAE多设备时间分块解码各卡解自己的块再羽化合并。这里有个常见疑问四卡显存为什么还是高因为 DiT 是序列并行而非参数分片每张卡都需要完整模型的可换入权重地址空间——加速的是计算不是权重显存的除法。这也是为什么低显存场景推荐 pruned INT8 权重见下文。五、实测效果4 卡约 500 秒资源消耗减半核心场景统一为 4 NPU、1344x768768P、24 fps。节选自 README.md 第 8 章的性能数据场景权重输出端到端耗时Ref2VA Turbo 8 步BF16768P / 15 秒495.79 sRef2VA Turbo 8 步pruned INT8768P / 15 秒454.77 sFL2VA Turbo 8 步INT8768P / 5 秒113.51 sRef2VA res_multistep 21 步BF16768P / 15 秒944.96 sRef2VA Euler 50 步BF16768P / 15 秒2263.03 s对比原基线8 卡、约 2400 秒、效果相同4 卡 495.79 秒意味着卡数减半、耗时约降到 1/5。8 步 Turbo LoRA 是官方推荐的性能基线21/50 步工作流见 additional_files/workflows/minimax-h3/只作质量对照。如果手里只有 1 张 NPU 也别急单卡 INT8 权重 480P 是被验证过的低资源成功性方案FL2VA 480P/15 秒约 371 秒但单卡 BF16 768P 15 秒不在支持范围内。六、上手提醒三分钟看懂两个细节首次任务会慢需要读取约 66.3 GB 的 BF16 DiT 和 51.5 GB 文本编码器并建立各 rank 的拓扑与热缓存。别慌第二次开始就是热的了——这正是热缓存机制的价值所在。卡数要对上服务只暴露 1 或 2 张卡时必须把Multi-NPU Parallel Config节点的npu_count改成相同值可选 1/2/4否则运行前校验会失败。启动服务只需执行 additional_files/runtime/restart-v1.sh完整的环境依赖、容器创建与权重放置清单可参考 README.md 第 2~4 章和机器可读的来源记录 source_deps_info.json。小结MiniMax-H3-Comfy-NPU 用两个朴素却高效的机制改写了多卡推理的资源账本权重只读一次形成共享的只读底座每张 NPU 独立持有热缓存换入换出永不碰盘。再配合按卡数分配角色的多 NPU 调度最终实现 8 卡 → 4 卡、2400 秒 → 约 500 秒的消耗减半。对于想在昇腾平台上跑 MiniMax-H3 音视频生成的新手这套机制开箱即用你只需要关心工作流和素材了。【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
