单卡910B4（32G）Qwen模型测试报告

永远的菜鸟

1333人浏览 · 2026-05-19 04:30:34

永远的菜鸟 · 2026-05-19 04:30:34 发布

单卡910B4（32G）Qwen模型测试报告

测试日期：2026-05-18 ~ 2026-05-19
硬件环境：华为Atlas 800 A2服务器，单卡910B4（32GB HBM2e，实际可用29.49GB）
软件环境：CANN 8.3.RC1 / vLLM-Ascend 0.18.0 / Python 3.10 / Ubuntu 22.04
报告版本：V1.1（合并版）

一、测试背景与目标

1.1 背景

本次测试基于华为昇腾910B4 NPU（32GB标称显存，实际可用29.49GB），针对Qwen3.6系列多个版本及不同量化格式进行适配验证。核心目标包括：

验证vLLM-Ascend 0.18.0在910B4上的实际部署可行性
对比vLLM-Ascend与MindIE的易用性和性能表现
探索32GB显存下的最优模型配置方案
记录真实测试过程中的问题、错误和解决方案

1.2 测试目标

完成vLLM-Ascend环境搭建与基础功能验证
测试Qwen3.6系列多个版本（8B/14B/27B/35B-MoE）的加载与推理
验证W8A8、FP8、AWQ等量化格式在昇腾平台的实际兼容性
记录各配置下的显存占用、错误日志及稳定性表现

二、环境搭建过程

2.1 硬件确认

项目	规格
NPU型号	昇腾910B4
显存容量	32GB HBM2e（实际可用29.49GB）
算力	半精度376 TFLOPS
服务器	AMD 7642 X 2

2.2 软件栈安装

2.2.1 CANN安装

# 安装CANN Toolkit 8.3.RC1（实际使用版本）
./Ascend-cann-toolkit_8.3.RC1_linux-aarch64.run --install
source /usr/local/Ascend/ascend-toolkit/set_env.sh

# 验证安装
npu-smi info

实际输出：

+------------------------------------------------------------------------------------------------+
| npu-smi 23.0.3                           Version: 23.0.3                                         |
+-------------------+-----------------+----------------------------------------------------------+
| NPU     Name      | Health          | Power(W)     Temp(C)           Hugepages-Usage(page)     |
| Chip    Device    | Bus-Id          | AICore(%)    Memory-Usage(MB)                        |
+===================+=================+==========================================================+
| 0       910B4     | OK              | 88.8         48                0    / 0                 |
| 0       0         | 0000:C1:00.0    | 0            31793 / 30271                          |
+===================+=================+==========================================================+

2.2.2 vLLM-Ascend安装

# 创建虚拟环境
python3 -m venv /root/vllm-ascend-env
source /root/vllm-ascend-env/bin/activate

# 安装vLLM-Ascend 0.18.0
pip install vllm-ascend==0.18.0 -i https://mirrors.huaweicloud.com/ascend/repos/pypi

# 安装modelscope（用于下载模型）
pip install modelscope -i https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple

2.3 关键依赖问题与解决

问题1：libatb.so缺失（核心阻塞问题）

现象：

OSError: libatb.so: cannot open shared object file: No such file or directory

根因分析： - ATB (Ascend Transformer Boost) 加速库路径未加入LD_LIBRARY_PATH - vLLM-Ascend的EngineCore是子进程，不继承当前shell的环境变量 - 即使当前shell设置了LD_LIBRARY_PATH，子进程启动时仍找不到libatb.so

解决过程：

# 1. 查找libatb.so位置
find /usr/local/Ascend -name "libatb.so*" 2>/dev/null
# 输出：
# /usr/local/Ascend/nnal/atb/8.3.RC1/atb/cxx_abi_0/lib/libatb.so
# /usr/local/Ascend/nnal/atb/8.3.RC1/atb/cxx_abi_1/lib/libatb.so

# 2. 确认Python版本对应cxx_abi
python --version # Python 3.10 → 使用cxx_abi_0

# 3. 持久化到虚拟环境activate脚本（关键！）
cat >> /root/vllm-ascend-env/bin/activate << 'EOF'

# === vLLM-Ascend ATB lib path ===
export LD_LIBRARY_PATH=/usr/local/Ascend/nnal/atb/8.3.RC1/atb/cxx_abi_0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/Ascend/ascend-toolkit/latest/lib64:$LD_LIBRARY_PATH
EOF

# 4. 重新激活环境
deactivate 2>/dev/null; source /root/vllm-ascend-env/bin/activate

# 5. 验证
python -c "import ctypes; ctypes.CDLL('libatb.so'); print('✅ libatb.so 加载成功')"

问题2：triton版本不兼容（警告，非阻塞）

现象：

WARNING: Triton is installed, but `triton.backends` could not be imported. Disabling Triton.
ERROR: Failed to import Triton kernels. Error: cannot import name 'Language' from 'triton.backends.compiler'

根因：vLLM-Ascend 0.18.0与当前triton版本不兼容，但这是NPU后端，Triton主要用于GPU CUDA kernel生成，对NPU影响有限。

处理：可忽略，不影响核心功能。

问题3：setuptools降级后pkg_resources版本属性报错（非阻塞）

现象：

AttributeError: 'Version' object has no attribute 'major'

根因：降级setuptools后，pkg_resources的版本解析逻辑变化。

处理：不影响主流程，可忽略。

三、vLLM选择历程

3.1 选型对比

方案	优点	缺点	结论
vLLM-Ascend	开源生态、API兼容、PagedAttention完整支持、社区迭代快	CANN版本严格对齐、部分量化格式NPU不支持	最终选择
MindIE	华为官方深度优化、性能潜力大	配置复杂、文档封闭、社区支持弱	备选方案
llama.cpp	跨平台、GGUF支持好	昇腾支持不完善、性能损失大	不适用
TGI	HuggingFace生态	昇腾支持有限	不适用

3.2 选择vLLM-Ascend的核心原因

生态兼容性：与现有基于vLLM的API服务架构完全兼容，无需重构代码
PagedAttention：内存管理效率显著优于MindIE的静态分配
量化支持预期：官方文档声称支持FP8、AWQ等格式（实际NPU支持有限，见第四章）
社区活跃度：华为与vLLM社区联合维护，版本迭代快于MindIE

四、Qwen3.6模型测试详情

4.1 测试模型清单

模型名称	来源	参数量	量化格式	文件大小	显存需求(估算)	vLLM-Ascend支持
Qwen3.6-27B (Dense)	基座模型	27B	FP16/BF16	~54GB	~54GB	✅
Qwen3.6-27B-W8A8	Eco-Tech	27B	W8A8	~34GB	~29GB	✅ (ascend)
Qwen3.6-27B-FP8	MoYuit	27B	FP8	~27GB	~27GB	❌ NPU不支持
Qwen3.6-27B-AWQ	tclf90	27B	AWQ	~15GB	~15GB	❌ NPU不支持
Qwen3.6-35B-A3B (MoE)	官方	35B(激活3B)	BF16	~67GB	~40GB	✅
Qwen3-8B	官方	8B	FP16	~16GB	~16GB	✅
Qwen3-14B	官方	14B	FP16	~28GB	~28GB	✅

4.2 vLLM-Ascend量化支持真相

官方文档声称支持 vs 实际NPU测试验证：

量化方式	官方代码列表	NPU实际测试	错误信息	差距原因
ascend (W8A8)	✅	✅ 支持	无	华为自研，完全支持
fp8	✅	❌ 不支持	fp8 quantization is currently not supported in npu	NVIDIA GPU特性，NPU后端显式禁用
awq	✅	❌ 不支持	awq quantization is currently not supported in npu	NVIDIA GPU特性，NPU后端显式禁用
ptpc_fp8	✅	未测试	-	可能也不支持
fbgemm_fp8	✅	未测试	-	可能也不支持
gguf	✅	未测试	-	-

重要结论：vLLM-Ascend 0.18.0的NPU后端实际上只支持ascend（W8A8）量化，其他量化方式虽然在代码常量列表中存在，但运行时被显式拦截报错。

4.3 各模型详细测试记录

4.3.1 Qwen3.6-27B W8A8（Eco-Tech）—— 核心测试

下载：

modelscope download --model Eco-Tech/Qwen3.6-27B-w8a8 --local_dir /data/models/Qwen3.6-27B-w8a8

文件结构：

total 34G
-rw-r--r-- 1 root root 4.0G quant_model_weights-00001-of-00009.safetensors
...（共9个分片）
-rw-r--r-- 1 root root 122K quant_model_description.json

测试过程（多次调整参数，逐步降低显存需求）：

尝试1：默认参数

vllm serve /data/models/Qwen3.6-27B-w8a8 --quantization ascend --dtype bfloat16 --max-model-len 4096 --gpu-memory-utilization 0.92

结果：❌ OOM

RuntimeError: NPU out of memory. Tried to allocate 172.00 MiB
(NPU 0; 29.49 GiB total capacity; 28.79 GiB already allocated; 118.31 MiB free)

尝试2：降低max_model_len到2048

vllm serve /data/models/Qwen3.6-27B-w8a8 --quantization ascend --dtype bfloat16 --max-model-len 2048 --gpu-memory-utilization 0.92

结果：❌ OOM

RuntimeError: NPU out of memory. Tried to allocate 162.00 MiB
(NPU 0; 29.49 GiB total capacity; 28.76 GiB already allocated; 165.86 MiB free)

尝试3：降低max_model_len到1024，gpu_memory_utilization到0.85

vllm serve /data/models/Qwen3.6-27B-w8a8 --quantization ascend --dtype bfloat16 --max-model-len 1024 --gpu-memory-utilization 0.85

结果：❌ OOM

RuntimeError: NPU out of memory. Tried to allocate 162.00 MiB
(NPU 0; 29.49 GiB total capacity; 28.76 GiB already allocated; 150.36 MiB free)

尝试4：极限参数（max_model_len=512, gpu_memory_utilization=0.98）

export HCCL_OP_EXPANSION_MODE=AIV
vllm serve /data/models/Qwen3.6-27B-w8a8 --quantization ascend --dtype bfloat16 --max-model-len 512 --gpu-memory-utilization 0.98 --max-num-seqs 1 --max-num-batched-tokens 512

结果：❌ OOM

RuntimeError: NPU out of memory. Tried to allocate 62.00 MiB
(NPU 0; 29.49 GiB total capacity; 28.73 GiB already allocated; 62.00 MiB free)

根因分析： - W8A8量化后权重约29GB，已接近单卡极限29.5GB - vLLM运行时还需要分配：KV Cache（即使max_model_len=512也需要数百MB）、激活内存、图编译缓存、通信buffer等 - 权重加载阶段就已耗尽显存，模型在初始化RowParallelLinear（MLP down_proj层）时申请162MB失败 - 即使将gpu_memory_utilization调到0.98，max_model_len降到512，仍无法满足运行时内存需求

4.3.2 Qwen3.6-27B FP8（MoYuit）—— 量化格式不支持

下载：

modelscope download --model MoYuit/Qwen3.6-27B-FP8 --local_dir /data/models/Qwen3.6-27B-FP8

测试命令：

vllm serve /data/models/Qwen3.6-27B-FP8 --quantization fp8 --dtype float16 --max-model-len 2048 --gpu-memory-utilization 0.92

结果：❌ vLLM-Ascend不支持FP8

pydantic_core._pydantic_core.ValidationError: 1 validation error for ModelConfig
Value error, fp8 quantization is currently not supported in npu.

分析：FP8虽然在vLLM官方支持列表中，但在NPU后端被显式禁用。这是vLLM-Ascend 0.18.0的已知限制，与模型无关。

4.3.3 Qwen3.6-27B AWQ（tclf90）—— 量化格式不支持

下载：

modelscope download --model tclf90/Qwen3.6-27B-AWQ --local_dir /data/models/Qwen3.6-27B-AWQ

测试命令：

vllm serve /data/models/Qwen3.6-27B-AWQ --quantization awq --dtype float16 --max-model-len 4096 --gpu-memory-utilization 0.92

结果：❌ vLLM-Ascend不支持AWQ

pydantic_core._pydantic_core.ValidationError: 1 validation error for ModelConfig
Value error, awq quantization is currently not supported in npu.

分析：AWQ 4-bit显存需求仅~15GB，单卡完全够用，但vLLM-Ascend 0.18.0在NPU上不支持AWQ量化推理。这是本次测试中最遗憾的发现——理论上最可行的方案因框架限制无法实现。

4.3.4 Qwen3.6-35B-A3B MoE（官方）—— MoE全量加载OOM

下载：

modelscope download --model Qwen/Qwen3.6-35B-A3B --local_dir /data/models/Qwen3.6-35B-A3B

模型特点： - 总参数量35B，但每次只激活3B（8个专家） - 权重文件67GB（所有专家权重都需加载） - 架构：Qwen3_5MoeForConditionalGeneration - 层数：40层，num_experts_per_tok: 8

测试命令：

vllm serve /data/models/Qwen3.6-35B-A3B --trust-remote-code --dtype bfloat16 --max-model-len 2048 --gpu-memory-utilization 0.92

结果：❌ OOM（比Dense 27B更严重）

RuntimeError: NPU out of memory. Tried to allocate 1.00 GiB
(NPU 0; 29.49 GiB total capacity; 28.55 GiB already allocated; 499.03 MiB free)

错误位置：SharedFusedMoE初始化时，专家权重申请1GB失败。

根因分析： - MoE模型虽然激活参数量小（3B），但所有专家权重都需要加载到显存 - 67GB权重文件加载到29.5GB NPU，OOM是必然的 - vLLM的MoE实现目前不支持”按需加载专家”，而是全量加载后通过路由选择激活 - MoE的显存需求 = 总参数量 × 精度字节数，而非激活参数量

4.3.5 Qwen3-8B / Qwen3-14B（官方）—— 单卡可行（未实测，理论可行）

模型	FP16显存	单卡910B4可行性	备注
Qwen3-8B	~16GB	✅ 轻松	剩余13GB用于KV Cache，可支持长上下文
Qwen3-14B	~28GB	⚠️ 极限	剩余1.5GB，max_model_len需限制在2048以内

推荐启动命令（8B）：

modelscope download --model qwen/Qwen3-8B --local_dir /data/models/Qwen3-8B

vllm serve /data/models/Qwen3-8B --trust-remote-code --dtype bfloat16 --max-model-len 4096 --gpu-memory-utilization 0.92 --host 0.0.0.0 --port 8000 --served-model-name qwen3-8b

五、量化格式深度对比

5.1 理论显存效率 vs 实际可用性

量化格式	27B模型显存	910B4单卡可行性	vLLM-Ascend支持	实际测试结果
FP16	~54GB	❌ 不可能	✅	未测试（显存不足）
W8A8	~29GB	⚠️ 极限（实际OOM）	✅ ascend	❌ OOM
FP8	~27GB	✅ 理论上可跑	❌ NPU不支持	❌ 框架不支持
AWQ	~15GB	✅ 轻松	❌ NPU不支持	❌ 框架不支持

5.2 关键发现

W8A8是NPU上唯一可用的量化方式，但压缩比不足（2x），27B模型仍需要29GB，单卡无法运行
FP8和AWQ虽然显存需求更低，但vLLM-Ascend 0.18.0在NPU后端显式禁用
MoE模型不能按激活参数量估算显存，需按总参数量计算

六、关键问题与解决方案

6.1 问题记录

序号	问题描述	发生场景	解决方案	状态
1	libatb.so缺失，EngineCore子进程崩溃	任何模型启动	将LD_LIBRARY_PATH持久化到虚拟环境activate脚本	✅ 解决
2	vLLM-Ascend不支持FP8	Qwen3.6-27B-FP8测试	无（框架限制）	❌ 无法解决
3	vLLM-Ascend不支持AWQ	Qwen3.6-27B-AWQ测试	无（框架限制）	❌ 无法解决
4	W8A8单卡OOM	Qwen3.6-27B-W8A8多次测试	降低max_model_len至512，gpu_memory_utilization至0.98	❌ 仍OOM
5	MoE模型OOM	Qwen3.6-35B-A3B测试	无（67GB > 29.5GB）	❌ 硬件限制
6	triton版本不兼容警告	所有启动场景	可忽略（NPU不使用Triton）	⚠️ 非阻塞
7	setuptools降级后pkg_resources报错	pip安装后	可忽略	⚠️ 非阻塞

6.2 核心调试经验

环境变量持久化是关键：vLLM-Ascend的EngineCore子进程不继承shell环境变量，必须将LD_LIBRARY_PATH写入虚拟环境activate脚本
量化支持需实际测试验证：不能依赖官方文档的常量列表，NPU后端可能有额外限制
OOM时先看权重加载阶段：如果错误发生在模型初始化（如RowParallelLinear、SharedFusedMoE），说明权重本身已占满显存，调整max_model_len无效
MoE显存按总参数量估算：不能按激活参数量（3B）估算，需按总参数量（35B+）计算

七、可行方案与建议

7.1 方案一：多卡Tensor Parallel（推荐，需硬件支持）

如果有2×910B4（共59GB显存）：

export LD_LIBRARY_PATH=/usr/local/Ascend/nnal/atb/8.3.RC1/atb/cxx_abi_0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/Ascend/ascend-toolkit/latest/lib64:$LD_LIBRARY_PATH

vllm serve /data/models/Qwen3.6-27B-w8a8 --quantization ascend --tensor-parallel-size 2 --dtype bfloat16 --max-model-len 32768 --gpu-memory-utilization 0.88 --host 0.0.0.0 --port 8000 --served-model-name qwen3.6-27b-w8a8

预期：每张卡分配15GB权重，剩余14GB用于KV Cache，可支持较长上下文。

7.2 方案二：换小模型（单卡可行）

Qwen3-8B（单卡轻松，推荐）：

Qwen3-14B（单卡极限）：

vllm serve /data/models/Qwen3-14B --trust-remote-code --dtype bfloat16 --max-model-len 2048 --gpu-memory-utilization 0.92

7.3 方案三：等待vLLM-Ascend更新

关注以下功能： - FP8 NPU支持：https://github.com/vllm-project/vllm-ascend/issues - AWQ NPU支持：同上 - MoE专家按需加载：架构级优化

预计时间：不确定，需跟踪社区进展。

八、结论与建议

8.1 核心结论

单卡910B4（29.5GB可用显存）无法运行任何Qwen3.6-27B及以上规模的模型
- W8A8权重29GB + 运行时开销 > 29.5GB，即使极限参数仍OOM
- FP8和AWQ虽然显存需求更低，但vLLM-Ascend 0.18.0在NPU上不支持
- MoE模型全量加载专家权重，67GB >> 29.5GB
vLLM-Ascend 0.18.0在NPU上的量化支持严重受限
- 实际只支持ascend（W8A8）量化
- FP8、AWQ等虽然在代码常量列表中存在，但运行时被显式禁用
- 官方文档与实际能力存在差距
当前最优单卡方案是Qwen3-8B或Qwen3-14B
- 8B FP16单卡轻松，可支持长上下文
- 14B FP16单卡极限，需限制max_model_len

8.2 硬件配置建议

目标模型	最低硬件	推荐硬件	备注
Qwen3-8B	1×910B4	1×910B4	单卡富裕
Qwen3-14B	1×910B4	1×910B4	单卡极限，需限制上下文
Qwen3.6-27B W8A8	2×910B4	2×910B4	TP=2，每张卡~15GB
Qwen3.6-27B FP16	4×910B4	4×910B4	TP=4
Qwen3.6-35B MoE	2×910B4	4×910B4	全量加载专家

8.3 后续建议

短期（本周）： 1. 确认服务器实际卡数（npu-smi info） 2. 如果有2×910B4，立即测试TP=2跑W8A8 3. 如果单卡，部署Qwen3-8B作为生产方案

中期（本月）： 1. 跟踪vLLM-Ascend版本更新，关注FP8/AWQ NPU支持进展 2. 测试Qwen3-14B在单卡上的实际性能和稳定性 3. 评估是否需要采购更大显存卡（如910B 64GB）

长期（本季度）： 1. 建立完整的昇腾推理基准测试体系 2. 对比MindIE在相同模型上的性能差异 3. 探索昇腾+Diffusers的文生图/视频生成

附录

A. 完整环境配置脚本

#!/bin/bash
# setup_vllm_ascend.sh

# CANN环境
source /usr/local/Ascend/ascend-toolkit/set_env.sh

# Python虚拟环境
source /root/vllm-ascend-env/bin/activate

# 关键：ATB库路径（必须持久化到activate脚本中）
export LD_LIBRARY_PATH=/usr/local/Ascend/nnal/atb/8.3.RC1/atb/cxx_abi_0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/Ascend/ascend-toolkit/latest/lib64:$LD_LIBRARY_PATH

# 可选优化
export HCCL_OP_EXPANSION_MODE=AIV
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True

B. 模型下载命令汇总

# W8A8量化版（Eco-Tech）- vLLM-Ascend支持，但单卡OOM
modelscope download --model Eco-Tech/Qwen3.6-27B-w8a8 --local_dir /data/models/Qwen3.6-27B-w8a8

# FP8量化版（MoYuit）- vLLM-Ascend不支持
modelscope download --model MoYuit/Qwen3.6-27B-FP8 --local_dir /data/models/Qwen3.6-27B-FP8

# AWQ量化版（tclf90）- vLLM-Ascend不支持
modelscope download --model tclf90/Qwen3.6-27B-AWQ --local_dir /data/models/Qwen3.6-27B-AWQ

# MoE版（官方）- 单卡OOM
modelscope download --model Qwen/Qwen3.6-35B-A3B --local_dir /data/models/Qwen3.6-35B-A3B

# 小模型（官方）- 单卡可行
modelscope download --model qwen/Qwen3-8B --local_dir /data/models/Qwen3-8B
modelscope download --model qwen/Qwen3-14B --local_dir /data/models/Qwen3-14B

C. 测试脚本汇总

# W8A8单卡极限测试
vllm serve /data/models/Qwen3.6-27B-w8a8   --quantization ascend   --dtype bfloat16   --max-model-len 512   --gpu-memory-utilization 0.98   --host 0.0.0.0   --port 8000   --served-model-name qwen3.6-27b-w8a8

# W8A8双卡TP=2（推荐）
vllm serve /data/models/Qwen3.6-27B-w8a8   --quantization ascend   --tensor-parallel-size 2   --dtype bfloat16   --max-model-len 32768   --gpu-memory-utilization 0.88   --host 0.0.0.0   --port 8000   --served-model-name qwen3.6-27b-w8a8

# 8B小模型（单卡轻松）
vllm serve /data/models/Qwen3-8B   --trust-remote-code   --dtype bfloat16   --max-model-len 4096   --gpu-memory-utilization 0.92   --host 0.0.0.0   --port 8000   --served-model-name qwen3-8b

D. NPU显存清理脚本

#!/bin/bash
# clean_npu.sh

echo "=== 强制终止所有占用NPU的进程 ==="
killall -9 python3 2>/dev/null
killall -9 python 2>/dev/null
pkill -9 -f "EngineCore" 2>/dev/null
pkill -9 -f "vllm" 2>/dev/null
sleep 2

echo "=== NPU显存状态 ==="
npu-smi info