HCCL AllGatherV 实战解析:MiniMax-H3-Comfy-NPU 中 DiT 序列并行与 peer-copy 双后端机制 HCCL AllGatherV 实战解析MiniMax-H3-Comfy-NPU 中 DiT 序列并行与 peer-copy 双后端机制【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPUMiniMax-H3-Comfy-NPU 是一个面向 Ascend 多 NPU 的 ComfyUI 推理补丁核心是通过 HCCL AllGatherV 集合通信实现 DiT 序列并行让 4 张 NPU 卡把 768P、15 秒音视频生成从 2400 秒压缩到 500 秒左右资源消耗同时下降一半。本文带你从零看懂这套双通信后端是怎么工作的。一分钟了解这个项目在原生 ComfyUI 里多 GPU 只能把不同阶段文本编码、DiT、VAE拆到不同卡上串行执行计算利用率很低。这个项目的做法完全不同DiT 走 packed-token 序列并行把音视频 token 序列切成 N 份4 张卡各自只算自己那份注意力阶段再通过集合通信交换 K/V通信层抽出公共模块comfy/multidevice.py与comfy/multinpu.py统一封装 HCCL AllGatherV、peer-copy 和张量并行 reduce 三种原语自动降级容错HCCL 初始化失败时自动回退到 peer-copy业务无感知支持 euler 50 步、res_multistep 21 步、Turbo LoRA 4~8 步降噪以及 INT8 量化权重所有改动集中在一个补丁文件 comfy-ui-changes.patch 中配合 install_deps_minimax_h3.sh 一键安装。机制一DiT 序列并行每张卡只算 1/4 的 tokenMiniMax-H3 的 DiT 模型在 comfy-ui-changes.patch 中被改造后声明了supports_sequence_parallel True对应comfy/ldm/minimax/model.py部分。其工作方式可以类比为四道工序接力切分前向传播开始时按rank把整条序列h切成seq_len * rank // world_size到seq_len * (rank1) // world_size的区间RoPE 频率表和调制分段也同步切好本地计算每张卡用自己的完整模型副本只处理属于自己的 token 分片FFN 等逐 token 运算天然可切注意力交换Self-Attention 中 Q 用本地分片K/V 必须是完整序列——这里调用协调器的exchange()把各卡的 K/V 汇集成全量张量后再算注意力收尾合并50 层 block 全部算完后再对输出h做一次序列维度的 exchange拼回完整结果交给 VAE 解码这个设计的直接收益是attention 计算量随卡数近似线性分摊所以 4 卡 Ref2VA 生成 768P 15 秒视频端到端只需495.79sBF16 Turbo 8 步而同场景原生 vllm-omni 基线要 2400 秒。机制二序列交换的双通信后端序列交换是整个系统的咽喉。comfy/multidevice.py中的SequenceParallelCoordinator提供统一接口exchange(rank, tensors, cat_dims)底层则有两个可选后端后端 AHCCL AllGatherV推荐快路径comfy/multinpu.py通过 ctypes 直接调用libhccl.so用HcclCommInitAll在多卡间建立通信域。这里选 AllGatherVVariable而不是普通 AllGather 的原因很关键各 rank 的 token 分片长度可能不等长序列长度不是卡数的整数倍时普通 AllGather 要求所有段等长而 AllGatherV 接受每组counts元素个数displacements目标偏移量硬件直接完成变长汇聚。调用时的细节也值得新手留意各 rank 先发布本地张量线程屏障Barrier对齐后才发起集合通信避免死锁通信在 NPU 当前 stream 上异步执行完成后统一synchronize()结果先落到一维 flat buffer再按各 rank 的形状narrowview还原后 concat后端 Bpeer-copy保底路径如果 HCCL 初始化失败或环境变量强制peer模式协调器自动降级为peer_copy_cat所有 rank 把分片放到共享槽位 → 屏障同步 → 逐个把其它 rank 的张量.to(local_device)后torch.cat拼接。这条路径走的是设备间直接拷贝无需 HCCL 通信库性能略低但保证任何 NPU 环境都能跑通。如何选择后端通过环境变量COMFYUI_MULTI_DEVICE_BACKEND控制取值有三个取值行为auto默认NPU 环境优先建 HCCL 通信域失败则自动回退 peer-copy 并记录日志hccl强制 HCCL初始化失败直接报错便于排查通信问题peer强制 peer-copy不加载 HCCL 库另外补丁还内置了配套单测tests/test_multidevice_coordinators.py用 FakeFunction 模拟HcclAllGatherV验证协调器逻辑新手如果想深入阅读可以从这份测试入手。一站式配置MultiNPUParallelConfig 节点对使用者来说上述所有并行机制都收敛到 ComfyUI 画布上的一个节点——Multi-NPU Parallel Config定义在comfy_extras/nodes_minimax_h3.py补丁段中它接受 model、clip、video_vae、audio_vae 四条输入输出配置好的同款对象只需设置npu_count可选1、2、44 卡DiT 序列并行 Qwen3-VL 文本编码器张量并行all_reduce_sum/all_reduce_max归约 视频 VAE 多设备时间分块解码1/2 卡自动收缩为单/双卡调度2 卡时音频 VAE 单独占卡节点会校验可见设备数与 NPU 类型数量不符时直接给出明确报错实测性能4 卡如何把 15 秒视频压进 500 秒以下数据统一使用 4 NPU、1344x768768P、24fps 基准完整列表见 README.md 第 8 章场景权重输出端到端耗时Ref2VA Turbo 8 步BF16768P / 15 秒495.79sRef2VA Turbo 8 步pruned INT8768P / 15 秒454.77sFL2VA Turbo 8 步INT8768P / 15 秒389.37sRef2VA Euler 50 步BF16768P / 15 秒2263.03s采样耗时近似随步数线性增长相同 BF16、768P、15 秒输入下50 / 21 / 8 步的采样阶段分别约35.00、14.98、5.79分钟——所以日常创作推荐 Turbo LoRA 8 步工作流如 ref2va_8steps_lora.json 与 fl2va_8steps_lora.json21/50 步仅用于质量对照。新手避坑指南显存为何没除以 4序列并行切的是计算量不是参数。每张卡仍持有完整模型的可换入权重地址空间4 卡加速的是 token/attention 计算不会把单卡权重显存除以 4权重加载为何慢首次任务需从 NFS 读取约 66.3 GB DiT 权重补丁让 safetensors 只反序列化一次形成只读 CPU 底座offload/reload 不再重复读盘任务失败后先读 additional_files/runtime/restart-v1.sh 生成的runtime/*.log第一条异常OOM 后务必用restart-v1.sh清理 allocator 状态再重试1/2 卡环境打开工作流后必须把npu_count改为实际卡数否则设备创建会失败启动日志警告xFormers not available在 Ascend NPU 上属于预期提示以MultiNPUParallelConfig与 MiniMax Turbo 节点导入成功为准相关资料速查资料路径完整补丁含双后端实现comfy-ui-changes.patch部署与性能文档README.md依赖安装脚本install_deps_minimax_h3.sh代码版本来源记录source_deps_info.json权重扫描路径示例additional_files/extra_model_paths.yaml6 套官方工作流additional_files/workflows/minimax-h3/启停脚本additional_files/runtime/一句话总结HCCL AllGatherV 负责跑得快peer-copy 负责跑得通两者配合 DiT 序列并行让消费级创作流 ComfyUI 在 Ascend 4 卡上逼近原生推理框架的吞吐这就是本项目最值得借鉴的设计。【免费下载链接】MiniMax-H3-Comfy-NPU项目地址: https://ai.gitcode.com/Ascend-SACT/MiniMax-H3-Comfy-NPU创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考