MiniMax-H3-Comfy-NPU 常见问题排查手册OOM 恢复、权重加载慢、四卡显存谜题逐一破解【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPU在Ascend NPU上跑MiniMax-H3 视频生成模型时新手最常遇到的三类问题任务 OOM 后服务假死、权重加载慢到怀疑卡死、以及四卡显存为什么没有除以四。本手册基于 MiniMax-H3-Comfy-NPU 交付仓库把这三个谜题和几条常见启动警告逐一拆解帮你快速定位并恢复服务不再盲目重启。一、项目速览30 秒了解它解决什么问题这个项目为MiniMax-H3在ComfyUI上做了Ascend 多 NPU 推理适配核心能力包括能力说明多卡调度通用MultiNPUParallelConfig统一管理 1 / 2 / 4 卡的 DiT、文本编码器、视频与音频 VAE序列并行DiT 采用 packed-token 序列并行文本编码器走张量并行视频 VAE 多设备时间分块解码低卡量化支持INT8、pruned 格式权重推理单卡也能跑 480P快速出片支持 Euler 50 步、res_multistep 21 步、Turbo LoRA 4~8 步降噪需要 clone 仓库时执行git clone https://gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPU完整安装与环境要求CANN 9.0.1、torch-npu 2.10.0.post2 等已验证版本组合见 README.md 第 2 章。二、OOM 恢复任务失败后不要直接重复提交这是新手最容易踩的坑显存溢出OOM之后直接重跑同一任务往往再次失败。为什么不能直接重跑OOM 发生时进程级 allocator 可能残留脏状态碎片化显存、未释放的热缓存。此时服务看起来活着但下一次任务大概率继续 OOM。正确的恢复步骤先读日志查看runtime/*.log中的第一条异常确认真实错误而不是最后一条报错。确认队列为空页面 Queue 里不要再有待执行任务。用官方重启脚本清理状态bash ${COMFYUI_RUNTIME_ROOT}/restart-v1.shrestart-v1.sh 会安全停止同一 PID 的旧进程、等待端口 8189 释放再拉起新服务并通过健康检查全程无需手动kill。配套脚本还有 stop_comfyui-4npu.sh停止前会校验进程命令行防止误杀和 start_comfyui-4npu.sh。如何降低 OOM 概率手段效果BF16 换成INT8 / pruned INT8权重显存大幅下降且实测更快INT8 FL2VA 8 步 5 秒113.51s比 BF16 的 212.33s 快近一倍768P 降为 480P单卡低显存场景的推荐分辨率Turbo LoRA 6~8 步比 4 步更稳同时避免过多步数带来的峰值压力三、权重加载慢首次启动为什么像卡死首次任务很慢不是故障而是它真的在搬 100 GB 的权重。三个真实原因原因说明权重大首次任务需从 NFS 读取约66.3 GB 的 BF16 DiT 约51.5 GB 文本编码器建拓扑各 rank 需要建立模型拓扑、CPU 热缓存和 NPU residency只读一次safetensors 只读取一次形成只读 CPU 权重底座多卡下各 rank 独立持有 NPU 热缓存如何让它更快后续任务不重读磁盘offload/reload 不会重新读取共享存储或反序列化权重所以慢只发生在服务重启后的第一个任务。换 INT8 权重量化后文件体积大幅缩小首载时间同步下降。用共享路径扫描权重把权重放在共享存储通过 extra_model_paths.yaml 配置base_path重启后在启动日志里看到Adding extra search path即生效。 经验值768P、15 秒属于高负载场景第一个任务的端到端耗时包含模型切换、conditioning、采样、VAE 解码和保存请给足耐心。四、四卡显存谜题为什么显存没有除以四这是最反直觉的一点上了 4 张卡每张卡的权重显存并不会变成 1/4。关键原理序列并行 ≠ 参数分片当前 DiT 采用的是序列并行把 token / attention 的计算切给四张卡并行算所以速度接近提升。但权重本身不分片每张卡都需要完整模型的可换入权重地址空间用于在 NPU 热缓存与 CPU 底座之间换入换出。一句话总结四卡加速的是算不是装。所以四卡的单卡显存占用依然接近完整模型这是设计使然不是配置错误。显存不够时的正确姿势优先换pruned INT8的 DiT INT8 文本编码器单卡场景必须降分辨率到 480PREADME 明确单卡 BF16 768P 15 秒不作为支持基线卡数与服务要一致服务只暴露 1 或 2 张卡时必须把Multi-NPU Parallel Config节点的npu_count改成相同数量可用值仅1/2/4否则运行前校验会失败。五、采样步数怎么选为什么推荐 8 步 Turbo采样耗时近似随步数线性增长这不是玄学看同一组 BF16、768P、15 秒输入下的实测数据工作流采样耗时定位Euler 50 步约 35.00 分钟质量对照日常别用res_multistep 21 步约 14.98 分钟质量对照Turbo 8 步约 5.79 分钟✅推荐性能基线Turbo LoRA 建议使用 4~8 步区间6~8 步观感明显优于 4 步strength保持1.0调度器用simple。归档工作流开箱即用快速出片fl2va_8steps_lora.json、ref2va_8steps_lora.json质量对照fl2va_21steps.json、ref2va_50steps.json工作流不打包输入图片首次运行前记得在LoadImage节点重新选择素材。六、启动日志常见警告速查表看到下面的警告先别慌它们大概率不代表 MiniMax-H3 运行失败警告原因需要处理吗ModuleNotFoundError: No module named skimage可选的姿态节点comfyui_controlnet_aux缺 scikit-image当前工作流不依赖❌ 可忽略xFormers not availablexFormers 是 NVIDIA CUDA 专用加速Ascend NPU 属预期提示❌ 可忽略其它自定义节点依赖缺失共享代码目录里还挂着与本交付无关的节点❌ 可忽略判断服务是否正常导入的标准以MultiNPUParallelConfig和 MiniMax Turbo 节点是否成功导入为准。核心多卡改动都在 comfy-ui-changes.patch 里含comfy/multidevice.py、comfy/multinpu.py公共通信层与 INT8 走npu_quant_matmul的量化路径依赖来源可在 source_deps_info.json 中核对。七、故障自查清单3 分钟走一遍☑️ 服务活着吗curl http://127.0.0.1:8189/system_stats有响应即可☑️ OOM 失败→ 读runtime/*.log第一条异常 → 清空队列 → 跑restart-v1.sh☑️ 首次任务慢→ 正常现象首载约 118 GB 权重后续任务会快☑️ 单卡显存爆→ 换 INT8/pruned 权重 480P并检查npu_count与服务卡数一致☑️ 出片太慢→ 换 8 步 Turbo 工作流别用 50 步☑️ 权重下拉框是空的→ 检查extra_model_paths.yaml并重启看Adding extra search path日志 安全提醒ComfyUI 默认无认证--listen 0.0.0.0仅用于可信内网对外暴露必须经由网关加认证与 TLS。参考文档README.md完整安装、权重下载清单与性能基线· install_deps_minimax_h3.sh依赖版本校验与文件导入· restart-v1.shOOM 恢复入口【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考