|------|------------------------------------------|
| 报告编号 | RPT-910A-20260531-002 |
| 测试日期 | 2026年5月30日-31日 |
| | |
| 服务器 | bms-ytcs910a-260529 (鲲鹏CPU + 8卡910A NPU) |
| 报告版本 | V2.0 (综合版) |

一、测试概述

本次测试历时约12小时，系统性地验证了在华为昇腾910A NPU服务器上部署大语言模型推理服务的可行性。

测试先后尝试了三种主流推理框架：

vLLM + vLLM-Ascend：基于PyTorch生态的高性能推理框架，支持连续批处理和PagedAttention。最终因910A硬件算子库缺失（SwiGlu等关键算子不支持）而失败。
llama.cpp + CANN后端：纯C++实现的轻量级推理框架。因CANN 9.1.0-beta.1与llama.cpp最新代码头文件不兼容（aclnn_fused_infer_attention_score_v2.h缺失），且GCC 7.3.0不支持ARM NEON x2/x4 intrinsics而编译失败。
PyTorch Native + torch_npu + transformers：最终成功方案。基于华为原生PyTorch NPU后端，通过transformers的device_map="auto"实现多卡模型并行，成功部署Qwen3-32B Dense模型。

二、测试环境

2.1 硬件环境

|-------|----------------------|
| 项目 | 配置 |
| 服务器型号 | 鲲鹏CPU + 8卡910A NPU |
| CPU架构 | ARM aarch64 |
| NPU型号 | 昇腾910PremiumA × 8卡 |
| NPU显存 | 单卡32GB HBM2（总量256GB） |
| NPU驱动 | 25.5.0（升级后） |

2.2 软件环境（最终成功方案）

|--------------|----------------------------------|----|
| 组件 | 版本 | 状态 |
| 操作系统 | EulerOS 2.0 (SP8) / Ubuntu 22.04 | ✅ |
| CANN | 8.5.0（容器内） | ✅ |
| Python | 3.11.6（容器内） | ✅ |
| PyTorch | 2.1.0+cpu | ✅ |
| torch_npu | 2.1.0.post18.dev20251112 | ✅ |
| transformers | 4.51.0（最终稳定版） | ✅ |
| accelerate | 0.30.0 | ✅ |
| Flask | 最新版 | ✅ |

三、测试目标与模型矩阵

测试目标：在910A服务器上找到能够稳定运行、且参数规模尽可能大的开源大语言模型，并验证其多卡并行推理能力。

3.1 测试模型矩阵

|----------------------|-------|-----------|-----|---------------|---------------------------------------|
| 模型 | 架构 | 参数量 | 层数 | 模态 | 测试结果 |
| Qwen3.6-27B | Dense | 27B | 64层 | 多模态(文本+图像+视频) | ❌ transformers初始化卡住（vision模块） |
| Qwen3-30B-A3B | MoE | 30B总/3B激活 | 48层 | 纯文本 | ❌ 加载成功，推理卡住（MoE路由算子不支持） |
| Qwen3.5-35B-A3B | MoE | 35B总/3B激活 | 48层 | 纯文本 | ❌ transformers 4.51.0不支持qwen3_5_moe架构 |
| Qwen3.5-27B | Dense | 27B | 64层 | 纯文本 | ❌ transformers 4.51.0不支持qwen3_5架构 |
| Qwen2.5-14B-Instruct | Dense | 14B | 48层 | 纯文本 | ✅ 2卡/4卡/8卡均验证成功 |
| Qwen3-32B | Dense | 32B | 64层 | 纯文本 | ✅ 8卡验证成功（最终生产方案） |
| Qwen3-32B | Dense | 32B | 64层 | 纯文本 | ❌ 4卡OOM（910A连续内存限制） |

四、各方案详细测试过程

4.1 vLLM-Ascend方案（约10小时，最终失败）

vLLM-Ascend是华为与社区合作的高性能推理框架，官方明确标注910A"暂无计划"支持。但基于技术探索目的，仍进行了完整尝试。

CANN安装：CANN 9.0.0安装因驱动兼容性检查失败；CANN 9.1.0-beta.1通过RPM包安装成功，但缺少ATB/NNAL加速库。
Python环境：宿主机Python 3.7.0太老，编译安装Python 3.10.13，创建虚拟环境vllm-910a-env。
torch_npu适配：经历2.1.0→2.4.0→2.5.1三个版本迭代，最终2.5.1配合升级后的驱动才能正常工作。
vLLM编译：vLLM 0.7.3源码安装，修改setup.py硬编码版本号绕过Git检测；设置VLLM_TARGET_DEVICE=empty。
vLLM-Ascend安装：pip install vllm-ascend==0.7.3，自动安装torch 2.5.1、torch-npu 2.5.1等依赖。
模型配置问题：Qwen3.6-27B的text_config为dict类型，vLLM的get_hf_text_config断言失败；打补丁兼容。
tokenizer问题：transformers 5.9.0移除了all_special_tokens_extended，vLLM 0.7.3还在使用；打补丁兼容。
ATB/NNAL缺失：libatb.so缺失，安装NNAL 9.1.0-beta.1失败；创建软链接、设置LD_PRELOAD等均未解决。
致命错误：SwiGlu算子：aclnnSwiGlu failed: socVersion $ascend910$ does not support opType $SwiGlu$ 。910A硬件CANN 9.1.0-beta.1算子库不支持SwiGlu，这是vLLM-Ascend依赖ATB算子加速库的固有缺陷，无法绕过。

结论：vLLM-Ascend 0.7.3官方要求CANN 8.1.RC1，与910A的CANN 9.1.0-beta.1不匹配，且910A算子库缺少SwiGlu等关键算子。

4.2 llama.cpp + CANN后端方案（编译失败）

CMake配置：CANN 9.1.0-beta.1识别正常，SOC_VERSION=Ascend910PremiumA，CANN后端已包含。
编译错误1：aclnn_fused_infer_attention_score_v2.h头文件缺失。llama.cpp最新代码(b9260)针对CANN 8.5.T63开发，CANN 9.1.0 beta的ACLNN API有变化。
编译错误2：GCC 7.3.0不支持ARM NEON x2/x4 intrinsics（vld1q_s16_x2等），需要GCC 9+。
降级尝试：尝试回退到b8547版本，但910A兼容性仍不明确。

结论：llama.cpp CANN后端在910A + CANN 9.1.0-beta.1 + GCC 7.3.0环境下编译失败，需要升级GCC或等待官方适配。

4.3 PyTorch Native + torch_npu + transformers方案（成功）

基于成都智算中心提供的mindie_910a:2.3.0 Docker镜像，内置CANN 8.5.0 + PyTorch 2.1.0 + torch_npu 2.1.0，与驱动25.5.0完美兼容。

镜像加载：docker load -i mindie_230_910a.tar → mindie_910a:2.3.0
容器启动：挂载NPU设备、驱动、日志目录，-v /data:/home映射模型目录
PyTorch升级：容器内PyTorch 2.1.0与transformers 5.2.0不兼容，降级transformers到4.41.2/4.51.0
accelerate问题：transformers 5.2.0的accelerate检测逻辑有bug，手动创建accelerate.py stub文件绕过
device_map分配：手动构建device_map字典，将64层均匀分配到各NPU，embed_tokens和lm_head必须在同一设备（共享权重）
910A关键限制：do_sample=False（greedy decoding）：910A的MultinomialWithReplacement AICPU算子有bug，必须禁用temperature/top_p/top_k采样
attention实现：attn_implementation="eager"：避免sliding window attention在sdpa下的兼容性问题

五、卡数配置尝试记录

针对Qwen3-32B Dense模型（64层，5120 hidden_size，FP16约64GB权重），系统性地测试了1卡/2卡/4卡/8卡配置：

|----|--------|-----------|-------|----------|--------------------------------------------------------|
| 卡数 | 每卡层数 | 每卡权重 | 总HBM | 结果 | 原因 |
| 1卡 | 64层 | ~64GB | 32GB | ❌ OOM | 权重远超单卡容量 |
| 2卡 | 32层 | ~32GB | 64GB | ❌ OOM | 每卡32GB > 实际可用连续内存 |
| 4卡 | 16层 | ~16GB | 128GB | ❌ OOM/碎片 | 910A PyTorch NPU分配器无法分配16GB连续块，max_split_size_mb参数无法解决 |
| 6卡 | 10-11层 | ~10-11GB | 192GB | ⏸ 未测试 | 理论可行，留2卡给其他任务 |
| 8卡 | 8层 | ~8GB | 256GB | ✅ 成功 | 每卡8GB权重，余量24GB用于KV Cache和并发 |

关键发现：910A单卡虽然标称32GB HBM，但PyTorch NPU后端实际可用的连续内存块约为15-16GB（受分配器限制）。因此4卡每卡16层（约16GB）的配置会触发OOM，而8卡每卡8层（约8GB）则完全在安全范围内。

六、关键问题踩坑记录

问题1：transformers版本兼容性
transformers 5.2.0要求PyTorch ≥2.4，但容器内PyTorch 2.1.0与CANN 8.5.0绑定，升级PyTorch会破坏NPU兼容性。解决方案：降级transformers到4.51.0（支持PyTorch 2.1.0且支持Qwen3架构）。

问题2：accelerate模块缺失
transformers 5.2.0的device_map检测逻辑有bug，即使安装了accelerate 0.34.2也报错"requires accelerate"。解决方案：手动创建accelerate.py stub文件，注入is_accelerate_available=True和check_and_set_device_map函数。

问题3：tied parameters设备分配
lm_head.weight和model.embed_tokens.weight共享权重，device_map中必须分配到同一NPU设备，否则会报"Tied parameters are on different devices"错误。

问题4：bfloat16不支持
Qwen3系列模型config默认torch_dtype=bfloat16，910A硬件不支持bfloat16。解决方案：强制config.torch_dtype=torch.float16，并在加载后遍历参数转换残留bfloat16。

问题5：MultinomialWithReplacement AICPU算子bug
910A的CANN 8.5.0中MultinomialWithReplacement算子实现有缺陷，do_sample=True时触发ERR99999 UNKNOWN application exception。解决方案：强制do_sample=False（greedy decoding），禁用temperature/top_p/top_k。

问题6：Sliding Window Attention
Qwen3使用sliding window attention，transformers的sdpa实现不支持。解决方案：attn_implementation="eager"，使用纯PyTorch实现。

问题7：MoE模型路由算子不支持
Qwen3-30B-A3B（MoE）加载成功但推理卡住，910A不支持MoE的topk/gate路由算子。解决方案：放弃MoE模型，改用Dense模型。

问题8：多模态模型初始化卡住
Qwen3.6-27B含vision encoder，transformers初始化时构建图像处理模块耗时极长（30分钟+无输出）。解决方案：放弃多模态模型，改用纯文本模型。

问题9：Docker镜像文件损坏
mindie_230_910a.tar传输过程中损坏（unexpected EOF），重新下载完整镜像后解决。

问题10：驱动版本不匹配
初始驱动23.0.0与CANN 8.5.0不兼容，导致AICPU ops加载失败（507033/E39006）。解决方案：升级驱动到25.5.0。

七、最终成功方案：Qwen3-32B 8卡部署

7.1 部署架构

采用Flask + PyTorch Native + torch_npu + transformers架构，8卡模型并行（Model Parallelism），每卡承载8层Transformer。

|------|----------------------------|
| 推理框架 | PyTorch Native + torch_npu |
| API层 | Flask (threaded=True) |
| 并行策略 | 模型并行（Model Parallelism） |
| 卡数 | 8卡（NPU 0-7） |
| 每卡负载 | 8层 + 部分共享权重 |

7.2 关键配置参数

|-------------|----------------------------------|
| 模型路径 | /home/models/Qwen3-32B |
| 数据类型 | torch.float16（910A不支持bfloat16） |
| device_map | 手动分配，8卡各8层 |
| attention实现 | eager（避免sliding window不兼容） |
| 采样策略 | do_sample=False（greedy decoding） |
| 最大上下文 | 512-4096 tokens（受KV Cache显存限制） |
| API端口 | 8000 |

7.3 服务启动命令

export ASCEND_RT_VISIBLE_DEVICES=0,1,2,3,4,5,6,7
cd /home && python qwen_server_32b_8card.py

7.4 API测试示例

curl -H "Content-Type: application/json" -d '{
"model": "Qwen3-32B",
"messages": ${"role": "system", "content": "你是一个有帮助的助手"}, {"role": "user", "content": "请用一句话介绍自己"}$ ,
"max_tokens": 128
}' http://localhost:8000/v1/chat/completions

八、结论与建议

8.1 测试结论

|------------------|-------|------------------------------------------------------------|
| vLLM-Ascend方案 | ❌ 不可行 | 910A算子库缺少SwiGlu等关键算子，vLLM-Ascend官方明确不支持910A |
| llama.cpp方案 | ❌ 不可行 | CANN 9.1.0-beta.1与llama.cpp头文件不兼容，GCC 7.3.0不支持NEON x2/x4 |
| PyTorch Native方案 | ✅ 可行 | 基于transformers + torch_npu，8卡模型并行，成功部署Qwen3-32B |
| MoE模型 | ❌ 不支持 | 910A不支持MoE路由算子（topk/gate），Qwen3-30B-A3B/Qwen3.5-35B-A3B均失败 |
| 多模态模型 | ❌ 不支持 | Qwen3.6-27B含vision encoder，transformers初始化卡住 |
| Dense模型 | ✅ 支持 | Qwen2.5-14B和Qwen3-32B Dense架构验证成功 |
| | | |

8.2 关键限制

采样限制：必须禁用do_sample（temperature/top_p/top_k无效），只能使用greedy decoding
精度限制：仅支持float16，不支持bfloat16/FP8/INT8量化
并发限制：Flask threaded模式，真实并发能力约1-2 req/s（NPU算力瓶颈）
上下文限制：max_tokens建议≤4096，更大上下文可能触发OOM
模型限制：仅支持纯文本Dense模型，不支持MoE/多模态

8.3 后续优化建议

性能优化：使用gunicorn替代Flask开发服务器，或改用异步框架（如FastAPI + uvicorn）提升并发能力
显存优化：探索910A原生INT8量化（通过华为CloudMatrix-Infer或NPU-INT8库），可将模型压缩至1/4，支持更大上下文
模型升级：跟踪transformers 4.57.1+对Qwen3.5系列的支持，但升级需谨慎验证PyTorch兼容性
多卡优化：测试6卡配置（留2卡给其他任务），验证Qwen3-32B在6卡上的稳定性
生产部署：创建systemd服务文件，实现开机自启；配置Nginx反向代理，增加API限流和认证
异构集群：考虑使用GPUStack等中间层统一管理910A（PyTorch Native）与5090/4090（vLLM）异构集群

九、附录

9.1 关键命令记录

启动容器

docker run -it --ipc=host --name=mindie --shm-size=80G --net=host --privileged=true \
--device=/dev/davinci_manager \
--device=/dev/devmm_svm \
--device=/dev/hisi_hdc \
-v /usr/local/Ascend/driver:/usr/local/Ascend/driver \
-v /usr/local/Ascend/add-ons/:/usr/local/Ascend/add-ons/ \
-v /usr/local/sbin/npu-smi:/usr/local/sbin/npu-smi \
-v /var/log/npu/slog/:/var/log/npu/slog \
-v /data:/home \
mindie_910a:2.3.0 /bin/bash

验证NPU

npu-smi info

验证PyTorch NPU

python -c "import torch; import torch_npu; print(torch.randn(2,2).npu())"

启动服务

export ASCEND_RT_VISIBLE_DEVICES=0,1,2,3,4,5,6,7
cd /home && python qwen_server_32b_8card.py

测试API

curl -H "Content-Type: application/json" -d '{
"model": "Qwen3-32B",
"messages": ${"role":"user","content":"你好"}$ ,
"max_tokens": 128
}' http://localhost:8000/v1/chat/completions

9.2 版本兼容性矩阵

|--------------|--------------|--------------|------------------|----------------|
| 组件 | vLLM方案 | llama.cpp方案 | PyTorch Native方案 | 备注 |
| CANN | 9.1.0-beta.1 | 9.1.0-beta.1 | 8.5.0（容器内） | 910A需CANN 8.5+ |
| PyTorch | 2.5.1 | N/A | 2.1.0 | 容器内2.1.0稳定 |
| transformers | 5.9.0 | N/A | 4.51.0 | 4.51.0支持Qwen3 |
| 模型格式 | HuggingFace | GGUF | HuggingFace | Native方案最灵活 |

9.3 参考文档

vLLM-Ascend官方文档：https://vllm-ascend.readthedocs.io/
llama.cpp CANN后端文档：https://github.com/ggml-org/llama.cpp/blob/master/docs/backend/CANN.md
华为CANN文档：https://www.hiascend.com/software/cann
Qwen模型文档：https://qwen.readthedocs.io/

鲲鹏CPU + 8卡910A NPU服务器大语言模型推理部署测试报告

一、测试概述

二、测试环境

2.1 硬件环境

2.2 软件环境（最终成功方案）

三、测试目标与模型矩阵

3.1 测试模型矩阵

四、各方案详细测试过程

4.1 vLLM-Ascend方案（约10小时，最终失败）

4.2 llama.cpp + CANN后端方案（编译失败）

4.3 PyTorch Native + torch_npu + transformers方案（成功）

五、卡数配置尝试记录

六、关键问题踩坑记录

七、最终成功方案：Qwen3-32B 8卡部署

7.1 部署架构

7.2 关键配置参数

7.3 服务启动命令

7.4 API测试示例

八、结论与建议

8.1 测试结论

8.2 关键限制

8.3 后续优化建议

九、附录

9.1 关键命令记录

启动容器

验证NPU

验证PyTorch NPU

启动服务

测试API

9.2 版本兼容性矩阵

9.3 参考文档