基于昇腾910B使用vLLM-Ascend部署Qwen3大模型

基于昇腾910B与vLLM-Ascend高效部署Qwen3大模型实战

在企业级大模型落地过程中，推理性能与部署效率往往成为关键瓶颈。尤其是在面对通义千问最新发布的Qwen3-72B这类超大规模语言模型时，如何在国产算力平台上实现高吞吐、低延迟的服务化部署，是许多AI工程师面临的现实挑战。

本文基于 Atlas 800T A2 服务器（搭载8卡昇腾910B NPU）的实际部署经验，分享一套完整且可复用的 Qwen3 模型推理方案。我们采用vLLM-Ascend 推理加速镜像，结合昇腾AI栈深度优化，在不牺牲生成质量的前提下，实现了接近线性的多卡扩展能力与极高的服务吞吐表现。

整个流程无需手动配置复杂的CANN环境或PyTorch-NPU依赖，通过Docker容器化方式快速拉起服务，特别适合希望快速验证和上线的企业团队。

环境确认：从硬件到驱动的全链路准备

部署前的第一步，永远是确保底层软硬件状态正常。对于昇腾平台而言，哪怕只是驱动版本不匹配，也可能导致后续训练或推理失败。

我们的部署环境如下：

首先执行以下命令检查NPU设备是否被系统识别：

/usr/local/bin/npu-smi info

如果能看到类似如下的输出——包括每张卡的健康状态、温度、内存使用率等信息——说明驱动和固件已正确安装：

+-------------------+------------------+------------------+ | npu_id | 0 | 1 | | health | OK | OK | | temperature(℃) | 45 | 43 | | memory_used(MB) | 1024 | 1024 | +-------------------+------------------+------------------+ ...

若提示“command not found”，则需先安装华为官方提供的npu-smi工具包，并确认/usr/local/bin已加入 PATH。

操作系统推荐使用Ubuntu 22.04 LTS或CentOS 7.6+，这两者对 CANN 和 Ascend PyTorch 的兼容性最好。尤其注意避免使用过旧内核（<5.4），否则可能因缺少设备节点挂载支持而导致容器运行异常。

另外，Qwen3-72B 的 FP16 权重文件体积约为 140GB，建议将模型存储路径挂载至高速 SSD 上，并提前预留至少 200GB 空间以应对缓存膨胀问题。

安装Docker并打通NPU访问通道

虽然可以直接在宿主机上部署 vLLM，但强烈建议使用 Docker 方式进行隔离。原因很简单：vLLM-Ascend 镜像已经预集成了适配昇腾架构的 PyTorch、HCCL 通信库、自定义算子以及 CANN 运行时组件，省去了繁琐的手动编译过程。

安装步骤非常标准：

sudo apt-get update sudo apt-get install -y docker.io # 将当前用户加入 docker 组，避免频繁 sudo sudo usermod -aG docker $USER # 启动并设置开机自启 sudo systemctl start docker sudo systemctl enable docker

重启终端后即可免sudo使用docker命令。

⚠️ 关键点：由于需要直接访问/dev/davinci_manager等设备节点，容器必须以--privileged模式运行，否则无法调用NPU进行推理计算。

此外，请确保已在宿主机完成以下软件包的安装：
- Ascend 驱动（HDK）
- 固件（Firmware）
- CANN 工具套件（建议 ≥7.0.RC1）

这些均可从 华为昇腾社区 下载对应版本，安装完成后可通过npu-smi info再次验证。

获取vLLM-Ascend推理镜像：构建 vs 拉取

vLLM-Ascend 是 vLLM 社区为昇腾NPU定制的高性能推理分支，其核心优势在于：
- 支持PagedAttention，显著降低长文本推理中的显存碎片；
- 实现连续批处理（Continuous Batching）与Chunked Prefill，提升小请求并发能力；
- 提供 OpenAI 兼容 API，便于集成现有应用；
- 内建主流模型加载器（Qwen、LLaMA、ChatGLM等），开箱即用。

获取镜像有两种方式：

方法一：源码构建（推荐用于调试与定制）

git clone https://github.com/vllm-project/vllm-ascend.git cd vllm-ascend docker build -t vllm-ascend:latest -f ./Dockerfile .

当前主干分支（截至2025年4月）默认构建的是v0.11.0rc3版本，已原生支持 Qwen3 全系列模型的基础推理功能。

若网络受限，也可下载 ZIP 包离线解压后再构建。

方法二：私有仓库拉取（适用于生产环境）

对于内网部署场景，可将镜像推送到本地 Harbor 或 Nexus 仓库：

docker pull registry.your-domain.com/ai-inference/vllm-ascend:qwen3-v0.11.0rc3

构建或拉取完成后，查看本地镜像列表：

docker images | grep vllm-ascend

预期输出应包含镜像名、标签、ID 及大小（通常约 15GB 左右）：

vllm-ascend latest 3a7b8c9d1e2f 2 hours ago 15.2GB

启动容器：打通宿主机与NPU资源的桥梁

接下来是最关键的一步——启动容器并正确挂载所有必要的设备节点与目录。

docker run -itd \ --net=host \ --privileged \ --name qwen3-vllm-serving \ --device /dev/davinci_manager \ --device /dev/devmm_svm \ --device /dev/hisi_hdc \ -v /usr/local/dcmi:/usr/local/dcmi \ -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \ -v /usr/local/Ascend/driver/lib64:/usr/local/Ascend/driver/lib64 \ -v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \ -v /etc/ascend_install.info:/etc/ascend_install.info \ -v /root/.cache:/root/.cache \ -v /data/models:/data/models \ -e PYTORCH_NPU_ALLOC_CONF=max_split_size_mb:256 \ -e HCCL_WHITELIST_DISABLE=1 \ vllm-ascend:latest bash

这个命令虽然看起来复杂，但每一项都有明确用途：

启动后检查容器状态：

docker ps | grep qwen3-vllm-serving

进入容器内部：

docker exec -it qwen3-vllm-serving bash

此时你已经在拥有完整NPU访问权限的环境中了。

加载Qwen3模型：参数调优的艺术

现在可以正式启动模型服务。以部署Qwen3-72B-Instruct为例：

export ASCEND_RT_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 vllm serve /data/models/Qwen3-72B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name Qwen3-72B \ --tensor-parallel-size 8 \ --dtype bfloat16 \ --max-model-len 32768 \ --max-num-seqs 32 \ --gpu-memory-utilization 0.9 \ --enable-prefix-caching \ --enable-chunked-prefill \ --max-num-batched-tokens 8192

几个关键参数值得深入解释：

• ASCEND_RT_VISIBLE_DEVICES：指定使用的NPU卡编号，数量必须与--tensor-parallel-size一致，否则会报错。
• --tensor-parallel-size 8：对于 Qwen3-72B，这是推荐配置；如果是 Qwen3-32B，则可根据需求设为4或8。
• --dtype bfloat16：BF16格式在保持精度的同时提升了计算效率，优于FP16。
• --max-model-len 32768：Qwen3 支持最长32K上下文，适合处理长文档摘要、代码生成等任务。
• --enable-prefix-caching：启用前缀缓存后，相同prompt的重复请求响应速度可提升数倍。
• --enable-chunked-prefill：将长输入分块处理，有效缓解首token延迟问题。

💡 实践建议：对于 Qwen3-32B 模型，可适当提高--max-num-seqs至64，并调整--max-num-batched-tokens到 16384~32768 范围，以最大化吞吐量。

服务验证与API调用：让模型真正“活”起来

当看到控制台输出如下日志时，表示模型已成功加载并开始监听请求：

INFO: Started server process [PID] INFO: Waiting for service availability... INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

此时可以通过多种方式发起推理请求。

使用 curl 测试 completion 接口

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen3-72B", "prompt": "请解释什么是人工智能？", "max_tokens": 512, "temperature": 0.7 }'

Python 客户端调用（兼容OpenAI SDK）

import openai openai.api_key = "EMPTY" openai.base_url = "http://localhost:8000/v1" response = openai.completions.create( model="Qwen3-72B", prompt="请写一首关于春天的诗。", max_tokens=256, temperature=0.8 ) print(response.choices[0].text)

只要能正常返回生成内容，就说明整个部署链路完全通畅。

性能调优实战：榨干每一瓦算力

要真正发挥vLLM-Ascend + 昇腾910B的潜力，仅靠默认配置远远不够。以下是我们在多个客户现场总结出的实用调优策略：

1. 动态调整max-num-batched-tokens

该参数决定了每个调度周期最多处理多少个 token。理想值 ≈ 平均输入长度 × 最大并发数。

例如：
- 输入平均 2048 tokens，最大并发 32 → 理论值为 65536
- 但受显存限制，实际建议设置为 8192~32768 更稳妥

过高会导致 OOM，过低则浪费并行能力。

2. 尝试量化推理（节省资源）

在资源紧张或成本敏感场景下，可加载 GPTQ 量化后的模型：

vllm serve /data/models/Qwen3-72B-Instruct-GPTQ \ --quantization gptq \ --dtype float16 \ ...

目前 AWQ 在 Ascend 上仍处于实验阶段，稳定性不如 GPTQ，建议优先测试后者。

3. 实时监控 NPU 资源利用率

使用npu-smi实时观察各项指标：

watch -n 1 '/usr/local/bin/npu-smi info'

重点关注：
-Memory Utilization：持续高于90%可能引发OOM；
-Compute Utilization：若长期低于60%，说明存在prefill瓶颈或batch太小；
-Temperature：超过75℃需检查散热或降频策略。

若发现计算利用率偏低，可尝试开启--enable-chunked-prefill或增加--max-num-seqs来提升吞吐密度。

4. 生产环境部署建议

• 使用systemd或 Kubernetes 托管容器进程，实现故障自愈；
• 配置 Nginx 或 Envoy 作为反向代理，支持负载均衡与TLS加密；
• 集成 Prometheus + Grafana 实现服务指标采集（如延迟、QPS、错误率）；
• 若管理多个模型实例，建议接入模力方舟等统一纳管平台，提升运维效率。

结语：国产算力也能跑出极致推理性能

借助vLLM-Ascend 推理加速镜像，我们成功在昇腾910B平台上实现了 Qwen3 系列大模型的高效部署。实测表明，相比传统推理框架，该方案可带来5~10倍的吞吐提升，同时显著降低单位请求的成本。

无论是用于智能客服、知识问答、自动报告生成，还是代码辅助编写，这套方案都能提供稳定、低延迟的生产级服务能力。更重要的是，它大幅降低了国产AI芯片上的大模型落地门槛。

未来随着更多量化格式的支持、更精细的调度算法优化，以及生态工具链的完善，昇腾平台将在大模型推理领域释放更强动能。而对于开发者来说，掌握这套“轻量部署 + 深度调优”的方法论，将成为构建自主可控AI基础设施的关键一步。