背景概述

在大模型推理场景中，多机多卡并行部署是提升吞吐与降低延迟的关键手段。Atlas 800I A2 作为华为自研的推理服务器，广泛应用于各类大模型服务化部署。vLLM-ascend 作为基于昇腾硬件优化的推理框架，支持多种主流模型的高效部署。在实际应用中，用户常需在双机背靠背组网环境下，基于 A2 服务器进行 16 卡混部部署，以满足高并发推理需求。

本文聚焦于在 Atlas 800I A2 双机背靠背组网下，部署 Kimi-K2.5 模型时出现的 aclnnMoeDistibuteDispatchV4 算子报错及 HCCL 建链失败问题，结合实际排查过程，提供可复现、可落地的解决方案。

问题现象

1在使用 vLLM-ascend 0.17.0RC1 版本，于 Atlas 800I A2 双机背靠背组网环境下部署 Kimi-K2.5 模型时，服务启动过程中报错如下：

Nnopbase fails to invoke the HcclAllocResourceByTiling function of the hcc1 module. ret = 4, comm = 0xfffe813c0800

同时，日志中频繁出现 aclnnMoeDistibuteDispatchV4 failed, error code is 561000 算子调用失败，伴随类似 HCCL 建链失败的异常信息。

该问题导致模型无法正常加载，推理服务无法启动。

模型与环境信息

• 模型名称：Kimi-K2.5
• 软件版本：vLLM-ascend 0.17.0RC1
• 硬件平台：Atlas 800I A2（双机背靠背组网，每机 16 卡）
• 部署模式：双机 16 卡混部，开启专家并行（Expert Parallelism）
• 通信方式：默认使用 MC2 通信协议

问题分析

1. 算子通信特性分析

aclnnMoeDistibuteDispatchV4 算子用于 MOE 模型中的专家分发与合并操作，其内部通信方式基于 AllToAllV。该通信模式在昇腾硬件中依赖 HCCL 全互联建链机制。

在双机背靠背组网架构下，由于网络拓扑限制，HCCL 的全互联通信路径无法建立，导致 HcclAllocResourceByTiling 调用失败，最终引发建链异常。

参考文档：  aclnnMoeDistibuteDispatchV4

2. 代码逻辑路径分析

在当前部署配置下（MOE 模型 + 专家并行 + A2 + 16 卡混部），框架逻辑会自动选择 MC2 通信方式。此时，combine 与 dispatch 算子将使用 HCCL 全互联建链机制。

由于双机背靠背组网不支持全互联通信，建链过程失败，进而导致整个推理流程中断。

问题根因

在 Atlas 800I A2 双机背靠背组网环境下，部署开启专家并行的 MOE 模型（如 Kimi-K2.5）时，框架默认采用 MC2 通信协议。该协议在 combine 与 dispatch 阶段使用 HCCL 全互联建链，而双机背靠背网络拓扑不支持该通信模式，导致建链失败，服务无法启动。

解决方案

为规避 HCCL 全互联建链在背靠背组网下的兼容性问题，可通过手动调整通信策略，将 combine/dispatch 算子的通信方式由 HCCL 全互联切换为 ALLGATHER 通信。

修改建议

在源码中定位至 _select_moe_comm_method 方法，在返回通信类型前，强制将 moe_comm_type 设置为 MoECommType.ALLGATHER，以避免使用 HCCL 全互联建链。

⚠️ 注意：该修改为临时方案，适用于背靠背组网场景。使用 ALLGATHER 通信方式将影响部分通信效率，建议在性能可接受范围内使用。

验证与建议

• 验证方式：修改后重新部署 Kimi-K2.5 模型，观察日志是否仍出现 HcclAllocResourceByTiling 失败或 aclnnMoeDistibuteDispatchV4 报错。
• 推荐配置：在双机背靠背组网下，优先使用 ALLGATHER 通信模式，确保建链成功。