---
title: Atlas 800I A2 上部署 Qwen3.5-397B 模型时专家并行启动失败问题的定位与解决-官方技术文章-昇腾社区
description: 近期在使用 vLLM-ascend:v0.17.0rc1 镜像于 Atlas 800I A2 双机混部环境下部署 Qwen3.5-397B-A17B（w8a8）模型时，发现开启专家并行（Expert Parallelism）后服务启动失败。该问题直接影响了大规模 MoE 模型在多卡集群上的高效部署能力，需定位根本原
keywords: Atlas,上部署,Qwen,模型时专家并,行启动失败问,题的定位与解,官方技术文章,昇腾社区
url: https://www.hiascend.com/developer/techArticles/20260602-7
section: (其他)
---

# Atlas 800I A2 上部署 Qwen3.5-397B 模型时专家并行启动失败问题的定位与解决-官方技术文章-昇腾社区

URL: https://www.hiascend.com/developer/techArticles/20260602-7
描述: 近期在使用 vLLM-ascend:v0.17.0rc1 镜像于 Atlas 800I A2 双机混部环境下部署 Qwen3.5-397B-A17B（w8a8）模型时，发现开启专家并行（Expert Parallelism）后服务启动失败。该问题直接影响了大规模 MoE 模型在多卡集群上的高效部署能力，需定位根本原
关键词: Atlas,上部署,Qwen,模型时专家并,行启动失败问,题的定位与解,官方技术文章,昇腾社区

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

Atlas 800I A2 上部署 Qwen3.5-397B 模型时专家并行启动失败问题的定位与解决

Atlas 800I A2 上部署 Qwen3.5-397B 模型时专家并行启动失败问题的定位与解决

模型推理vLLMQwen3.5

发表于: 2026/06/02

42

0

## 背景概述

在基于 Ascend NPU 的大模型推理场景中，vLLM-ascend 作为推理框架，广泛支持主流 MoE架构模型的部署。近期在使用 vLLM-ascend:v0.17.0rc1 镜像于 Atlas 800I A2 双机混部环境下部署 Qwen3.5-397B-A17B（w8a8）模型时，发现开启专家并行后服务启动失败。该问题直接影响了大规模 MoE 模型在多卡集群上的高效部署能力，需定位根本原因并提供可落地的解决方案。

本文基于实际问题排查过程，系统梳理了故障现象、分析路径、修复方案及长期优化建议，为类似场景提供参考。

## 问题现象

在启动模型服务过程中，出现以下两类报错：

### 1.格式不一致警告

`failed to initialize unknown shape dtype and format. The input or output is input2.blockIDs.`同时伴随`Inconsistent format size [1] and data type size [2]`错误，触发函数`FUNC:InitUnknownFormatAndDtype`。

### 2.专家数量超限导致启动中断

`moeExpertNum is 32, in case of unlayered, it must no more than 24.`该错误直接导致服务初始化失败，成为阻塞性问题。

## 问题复现与分析

为精准定位问题，采用控制变量法进行验证：

| 测试项 | 配置 | 结果 |
| --- | --- | ---|
| 基准测试 | 移除--enable_expert_parallel参数 | 服务正常启动 |
| 故障复现 | 恢复原始配置并启用--enable_expert_parallel | 启动失败，报错与上述一致 |

结论：问题根源明确为专家并行配置与底层算子约束冲突。

进一步分析发现，Qwen3.5-397B 模型总专家数为 512，在 16 卡双机部署场景下，每卡需分摊 32 个专家。而当前 CANN 版本中 MC2 通信算子对单卡支持的专家数量存在硬性限制（上限为 24），导致在执行 MoE 通信时触发异常。

## 修复方案与验证

### 临时规避方案

参考社区修复方案PR #7364 [了解详情](https://github.com/vllm-project/vllm-ascend/pull/7364)，对`ascend_forward_context.py`文件中的通信逻辑进行增强：

- 新增单卡专家数量检测机制：当检测到单卡专家数超过 24 时，自动将 MoE 通信算法从 MC2 切换至 ALLGATHER。
- 动态切换策略：在不改变用户配置的前提下，实现算子兼容性自适应。

修改后，服务成功启动，后续压力测试未出现异常，验证修复有效。

### 长期解决方案

该修复逻辑已合并至 vLLM-ascend 主线分支。建议用户升级至包含该修复的稳定版本镜像，以获得更健壮的 MoE 模型部署能力。

✅ 推荐升级路径：vLLM-ascend ≥ v0.17.0（含修复补丁）

## 根因总结

1. 硬件算子约束：Atlas 800I A2 平台当前 CANN 版本中，MC2 算子为保障内存安全，对单卡专家数量设定了 24 的上限。
2. 负载分配不均：Qwen3.5-397B 模型共 512 个专家，16 卡部署下每卡需承载 32 个，超出算子安全阈值。
3. 通信策略未自适应：默认使用 MC2 算子进行专家通信，未根据实际负载动态降级，导致启动失败。

## 优化建议与补充说明

- CANN 9.0.0 及以上版本：已对 MC2 算子的专家数量限制进行泛化处理，理论上不再存在此类问题，建议在条件允许时升级 CANN 版本。
- 部署建议：对于超大规模 MoE 模型，建议结合`--enable_expert_parallel`与`--tensor-parallel-size`合理规划卡数与专家分布，避免单卡负载过高。
- 配置提示：在使用专家并行时，建议关注模型总专家数与卡数的比值，确保单卡分摊数在算子支持范围内。

点赞 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)