---
title: Atlas 800I A2 双机部署 Kimi-K2.5 时 HCCL建链失败问题分析与解决方案-官方技术文章-昇腾社区
description: 本文聚焦于在 Atlas 800I A2 双机背靠背组网下，部署 Kimi-K2.5 模型时出现的 `aclnnMoeDistibuteDispatchV4` 算子报错及 HCCL 建链失败问题，结合实际排查过程，提供可复现、可落地的解决方案。
keywords: Atlas,双机部署,Kimi,时,HCCL,建链失败问题,分析与解决方,官方技术文章
url: https://www.hiascend.com/developer/techArticles/20260602-9
section: (其他)
---

# Atlas 800I A2 双机部署 Kimi-K2.5 时 HCCL建链失败问题分析与解决方案-官方技术文章-昇腾社区

URL: https://www.hiascend.com/developer/techArticles/20260602-9
描述: 本文聚焦于在 Atlas 800I A2 双机背靠背组网下，部署 Kimi-K2.5 模型时出现的 `aclnnMoeDistibuteDispatchV4` 算子报错及 HCCL 建链失败问题，结合实际排查过程，提供可复现、可落地的解决方案。
关键词: Atlas,双机部署,Kimi,时,HCCL,建链失败问题,分析与解决方,官方技术文章

官方技术文章 [了解详情](https://www.hiascend.com/zh/developer/techArticles)

Atlas 800I A2 双机部署 Kimi-K2.5 时 HCCL建链失败问题分析与解决方案

Atlas 800I A2 双机部署 Kimi-K2.5 时 HCCL建链失败问题分析与解决方案

vLLM昇腾部署

发表于: 2026/06/03

69

0

## 背景概述

在大模型推理场景中，多机多卡并行部署是提升吞吐与降低延迟的关键手段。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 [了解详情](https://www.hiascend.com/document/detail/zh/canncommercial/850/API/aolapi/context/ops-transformer/aclnnMoeDistributeDispatchV4.md)

### 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`通信模式，确保建链成功。

点赞 0

本页内容

背景概述 [了解详情](https://www.hiascend.com/#id-1)

问题现象 [了解详情](https://www.hiascend.com/#id-2)

模型与环境信息 [了解详情](https://www.hiascend.com/#id-3)

问题分析 [了解详情](https://www.hiascend.com/#id-4)

问题根因 [了解详情](https://www.hiascend.com/#id-5)

解决方案 [了解详情](https://www.hiascend.com/#id-6)

验证与建议 [了解详情](https://www.hiascend.com/#id-7)