vLLM Ascend完全指南：昇腾NPU大模型推理部署从入门到企业级实战

本文系统拆解 vLLM Ascend 的完整技术栈，从硬件软件栈、三种安装路径、PagedAttention 核心原理，到 PD 分离部署、上下文并行、性能调优，配合完整命令与面试题，帮你在华为昇腾 NPU 上从零搭建高性能大模型推理服务。
参考：https://docs.vllm.ai/projects/vllm-ascend-cn/zh-cn/latest/getting_started/overview.html

---

写在前面

随着国产算力的普及，越来越多的团队开始在华为昇腾 NPU 上部署大模型推理。但很多人第一次接触时会遇到各种问题：CANN 版本和 PyTorch 版本不兼容、Docker 容器里识别不到 NPU、模型跑起来了但吞吐量上不去、长序列推理直接 OOM。

vLLM 作为目前最流行的开源推理引擎，通过 vLLM Ascend 插件正式支持了昇腾 NPU。它让你可以用和 NVIDIA GPU 上几乎一样的方式，在昇腾硬件上部署大模型推理。本文将带你从零开始，把 vLLM Ascend 彻底讲透。

---

痛点场景：昇腾 NPU 部署大模型的那些坑

场景一：版本不兼容，装了一天还没跑起来

你拿到一台昇腾 910B 服务器，想部署一个 Qwen 模型。你按照网上的教程装了 CANN 8.0，然后 pip 安装 vllm-ascend，结果 import 的时候报错：torch_npu 版本不兼容。你升级了 torch-npu，又报 CANN 版本太低。你再升级 CANN，驱动又不匹配了。

折腾了一整天，最后发现：vLLM Ascend 的每个版本都有严格的兼容性矩阵，CANN、PyTorch、TorchNPU、Triton、vLLM 五个组件的版本必须严格对应，混用任何一个版本都会出问题。

场景二：Docker 容器里识别不到 NPU

你用了预构建镜像，docker run 启动容器，进去之后跑 npu-smi info，结果报错：command not found。或者 torch.npu.is_available() 返回 False。

你检查了半天，发现是启动容器时没有挂载 NPU 设备节点和驱动库。昇腾 NPU 的 Docker 透传比 NVIDIA GPU 复杂得多，需要挂载 /dev/davinci0、/dev/davinci_manager、/dev/devmm_svm、/dev/hisi_hdc 四个设备，还要挂载 dcmi、npu-smi、驱动库、版本信息等多个目录和文件。少挂一个都不行。

场景三：模型能跑，但吞吐量极低

你终于把模型跑起来了，单用户测试延迟还可以。但一上并发，吞吐量惨不忍睹，比 GPU 上差好几倍。你不知道该调什么参数：max_num_seqs 设多少？gpu_memory_utilization 设多少？张量并行用几张卡？

原因是你不了解 vLLM 的核心优化：PagedAttention 和连续批处理。这些机制决定了 vLLM 为什么比朴素的 HuggingFace 推理快 2 到 4 倍，但参数设置不当会让这些优化失效。

场景四：长序列推理直接 OOM

你需要部署一个支持 128K 上下文的 RAG 服务。单卡 910B 显存 64GB，模型权重占了 40GB，剩下的显存根本放不下 128K 的 KV Cache。你把 max_model_len 调小，业务不接受；调大，直接 OOM。

你不知道可以用上下文并行（Context Parallel）把长序列切分到多张 NPU 上，也不知道 PD 分离可以把预填充和解码放在不同配置的节点上独立优化。

场景五：生产环境不知道选哪个推理框架

团队要在昇腾 NPU 上做生产级推理部署，面对 vLLM Ascend、MindIE、SGLang 等多个选项，不知道该选哪个。vLLM 生态好但性能是不是不如华为官方的 MindIE？MindIE 性能好但模型支持是不是滞后？SGLang 代码清晰但昇腾支持成熟吗？

选型错误会导致后期大量返工，这个决策需要基于各框架的核心差异来做。

---

痛点的解决方案：vLLM Ascend 标准化部署流程

以上五个痛点，分别对应五个核心解决方案：

痛点	根源	解决方案
版本不兼容	组件版本无统一管理	使用官方预构建镜像，严格遵循兼容性矩阵
容器识别不到NPU	设备和驱动挂载不全	标准 Docker run 参数，挂载全部必要设备和库
吞吐量低	不了解核心优化和参数调优	理解 PagedAttention + 连续批处理，合理设置并发和显存参数
长序列OOM	单卡显存不足	上下文并行（PCP/DCP）切分序列，PD分离独立优化
选型困难	不了解各框架差异	掌握 vLLM Ascend / MindIE / SGLang 的核心区别和适用场景

接下来，我们从最基础的概念开始，一步步把这些方案讲清楚。

---

一、vLLM Ascend 是什么

专业解释

vLLM 是由加州大学伯克利分校发起的开源大语言模型推理引擎，核心创新是 PagedAttention 算法和连续批处理（Continuous Batching），能够将推理吞吐量提升到朴素 HuggingFace 实现的 2 到 4 倍。

vLLM Ascend 是 vLLM 的昇腾 NPU 插件（vllm-ascend），它的作用是将 vLLM 连接到昇腾软件栈，让 vLLM 能够在华为昇腾 NPU 上运行。它不是一个独立的推理引擎，而是 vLLM 的硬件后端插件。

vLLM Ascend 运行在一套分层的硬件和软件栈之上，从下到上分别是：

层级	组件	作用
硬件层	Ascend NPU	昇腾 AI 处理器（910B / 950DT / 310P 等）
驱动层	Ascend HDK	驱动和固件，是 CANN 的硬件基础
运行时层	CANN（Toolkit + Ops + NNAL）	昇腾用户态运行时，算子库，ATB 运行时
框架层	PyTorch + TorchNPU / Triton Ascend	张量框架，将 PyTorch 连接到昇腾运行时；Triton 提供内核加速
引擎层	vLLM + vLLM Ascend	模型推理引擎和昇腾硬件插件

当前已验证的版本组合（v0.23.0）：Python 3.12、Ascend HDK 26.0.RC1、CANN 9.1.0、PyTorch 2.10.0、TorchNPU 2.10.0.post4、Triton Ascend 3.2.2、vLLM 0.23.0。这些版本作为一个兼容性集合进行联合验证，不能随意混用。

大白话

你可以把 vLLM Ascend 想象成一个**“翻译官+加速器”**的组合。

• vLLM 是一个聪明的调度员，它知道怎么安排很多用户的请求同时处理，怎么高效利用显存（PagedAttention），怎么让推理速度最大化。
• 昇腾 NPU 是一个只会说"昇腾语"的工人，算力很强但听不懂 vLLM 的指令。
• vLLM Ascend 插件 就是翻译官，把 vLLM 的指令翻译成昇腾 NPU 能听懂的话，让两者能协作。
• CANN 是昇腾 NPU 的"工具库"，里面有各种现成的算子（矩阵乘法、注意力计算等），翻译官直接调用这些工具。
• TorchNPU 是 PyTorch 和 CANN 之间的桥梁，让 PyTorch 的张量操作能在 NPU 上执行。

没有 vLLM Ascend，vLLM 这个调度员就只能指挥 NVIDIA GPU 的工人，指挥不动昇腾的工人。有了这个插件，vLLM 就能同时调度 GPU 和 NPU 两种工人。

生活案例

再举一个生活中的例子：餐厅厨房。

• vLLM = 餐厅的大堂经理，负责安排订单、调度厨师、优化出餐顺序
• 昇腾 NPU = 厨房的灶台和厨师，实际做菜的地方
• CANN = 厨房的厨具和菜谱（炒锅、蒸锅、菜谱）
• TorchNPU = 把通用菜谱翻译成这个厨房能用的操作手册
• vLLM Ascend = 专门负责和这个厨房沟通的传菜员，把大堂经理的订单准确传达给厨师

如果这个餐厅原来只有粤菜厨房（NVIDIA GPU），大堂经理（vLLM）直接用粤语下单就行。现在加了川菜厨房（昇腾 NPU），就需要一个会川菜的传菜员（vLLM Ascend）来翻译和传达。

支持的硬件平台

vLLM Ascend 支持以下昇腾硬件系列：

系列	常见产品	芯片	特点
Atlas A2 系列	Atlas 800T A2、900 A2 PoD、300T A2	昇腾 910B	训练推理两用，最主流
Atlas A3 系列	Atlas 800T A3、900 A3 SuperPoD	昇腾 910C	新一代，双 DIE 设计
Atlas 推理系列	Atlas 300I DUO、200I Pro	昇腾 310P	纯推理，功耗低
Ascend 950DT 系列	950DT	昇腾 950	最新一代，mxFP8 低精度

注意：Triton Ascend 仅用于 A2、A3 和 950DT 系列，不用于 Atlas 300I DUO 和 200I Pro。

---

二、为什么要用 vLLM Ascend

直接用 HuggingFace 推理不行吗

很多人会问：我直接用 HuggingFace 的 model.generate() 在 NPU 上跑不行吗？为什么非要用 vLLM？

答案是：能跑，但性能差很多。朴素的 HuggingFace 推理有两个致命问题：

1. 静态批处理：必须等一个 batch 里所有请求都生成完，才能处理下一批。短请求要等长请求，GPU/NPU 利用率低。
2. KV Cache 显存浪费：每个请求的 KV Cache 必须分配连续的显存块。因为请求长度不确定，通常按最大长度预分配，导致大量内部碎片。实际显存利用率可能只有 20% 到 40%。

vLLM 用两个核心创新解决了这些问题。

PagedAttention：像操作系统管理内存一样管理 KV Cache

PagedAttention 的灵感来自操作系统的虚拟内存和分页机制。

传统方式：每个请求的 KV Cache 是一块连续的显存，按最大长度预分配，用不完的就浪费了。

PagedAttention：把 KV Cache 分成固定大小的 block（页），每个 block 可以存固定数量 token 的 KV。这些 block 在物理显存中可以不连续，通过一个 block 表记录逻辑顺序。需要多少就分配多少，用不完的 block 可以给其他请求用。

这就像操作系统的内存分页：进程的虚拟地址空间是连续的，但物理页可以分散在内存各处，通过页表映射。

结果：KV Cache 的显存利用率从 20%-40% 提升到接近 90%，同样的显存能服务更多并发请求。

连续批处理：不等了，谁先完成谁先走

传统静态批处理：一组请求组成一个 batch，必须等所有请求都生成完毕，才能处理下一组。如果一个请求要生成 1000 个 token，另一个只生成 10 个，短请求要干等长请求。

连续批处理：调度器持续监控每个请求的状态。某个请求生成完成，立即从 batch 中移除，同时把队列中的新请求加入。不需要等整个 batch 完成。

结果：硬件始终保持高利用率，吞吐量大幅提升。vLLM 官方数据显示，吞吐量比朴素 HuggingFace 高 2 到 4 倍。

为什么选 vLLM Ascend 而不是其他方案

在昇腾 NPU 上，vLLM Ascend 的核心优势：

1. 生态兼容：vLLM 是目前最主流的开源推理引擎，模型支持最全，新模型（DeepSeek、Qwen、GLM 等）通常第一时间支持。
2. API 兼容：提供 OpenAI 兼容的 API 接口，前端代码不需要修改。
3. 部署简单：预构建镜像一键启动，和 GPU 上的 vLLM 用法几乎一致。
4. 特性丰富：支持 PD 分离、上下文并行、前缀缓存、推测解码、量化、LoRA 等高级特性。
5. 开源活跃：社区活跃，版本迭代快，问题响应及时。

---

三、vLLM Ascend 是怎么演进过来的

理解演进历史，能帮你更好地理解当前的设计。

第一阶段：昇腾 NPU 推理的早期探索（2023年）

大模型爆发初期，昇腾 NPU 上的推理主要依赖华为官方的 MindIE 和原生 CANN 算子。第三方框架支持很少，开发者只能用华为提供的工具链，模型支持滞后，部署灵活度低。

第二阶段：vLLM 崛起与昇腾适配启动（2024年初）

vLLM 凭借 PagedAttention 在 GPU 上取得巨大成功，成为开源推理引擎的事实标准。社区开始尝试将 vLLM 移植到昇腾 NPU 上。早期版本需要手动打补丁、修改源码，兼容性差，只支持少数模型。

第三阶段：vllm-ascend 插件正式发布（2024年中）

华为与社区合作推出正式的 vllm-ascend 插件，作为 vLLM 的硬件后端。vLLM 主项目通过插件机制支持多种硬件，vllm-ascend 负责昇腾适配。CANN 8.x 版本配合 torch-npu，支持的模型逐渐增多。

第四阶段：成熟完善与企业级特性（2025年至今）

vLLM Ascend 进入成熟期：

• CANN 升级到 9.x，PyTorch 升级到 2.10，TorchNPU 不再需要开发版
• 支持 PD 分离（Prefill/Decode 分离部署）
• 支持上下文并行（PCP/DCP），解决长序列问题
• 支持前缀缓存、推测解码、量化、LoRA/Multi-LoRA
• 预构建镜像覆盖 A2/A3/310P/950DT 全系列硬件
• 支持 Ubuntu 和 openEuler 双操作系统

目前 vLLM Ascend 已经是昇腾 NPU 上开源推理的首选方案。

---

四、怎么用：从环境搭建到部署推理

4.1 第一步：确认硬件环境

无论用哪种安装方式，第一步都是确认昇腾 NPU 的驱动和固件已正确安装：

npu-smi info

如果输出显示 NPU 设备信息（型号、驱动版本、固件版本、使用率），说明硬件环境正常。如果命令不存在或报错，需要先安装 Ascend HDK（驱动和固件）。

4.2 三种安装路径

vLLM Ascend 提供三种安装路径，根据你的需求选择：

需求	推荐方法	目标用户
尽快获得可用环境	使用预构建镜像	首次使用或快速部署
在现有 CANN 环境中安装	在 CANN 环境中安装	已有 CANN 镜像或主机
手动管理完整软件栈	从基础环境安装	需要自定义、开发调试

路径一：预构建镜像（推荐，最省事）

宿主机只需要安装好 Ascend 驱动和固件，以及 Docker。镜像中包含完整的 CANN 用户态环境、PyTorch/TorchNPU、vLLM 和 vLLM Ascend。

第一步：拉取镜像

根据你的硬件选择对应镜像：

# A2 系列（910B），Ubuntu
export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0

# A2 系列，openEuler
# export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0-openeuler

# A3 系列（910C），Ubuntu
# export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0-a3

# 310P 推理卡
# export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0-310p

# 950DT 系列
# export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0-a5

docker pull "$IMAGE"

如果镜像下载慢，可以使用国内镜像加速：

# 方式一：daocloud 加速
docker pull m.daocloud.io/quay.io/ascend/vllm-ascend:v0.23.0

# 方式二：南京大学镜像
docker pull quay.nju.edu.cn/ascend/vllm-ascend:v0.23.0

注意：只替换镜像仓库前缀，保留完整标签（包括 -a3、-310p、-openeuler 等后缀）。

第二步：启动容器

A2/310P/950DT 系列（单设备节点）：

export DEVICE=/dev/davinci0
export MODEL_CACHE="${HOME}/.cache"
mkdir -p "$MODEL_CACHE"

docker run --rm \
    --name vllm-ascend \
    --shm-size=1g \
    --device "$DEVICE" \
    --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 "$MODEL_CACHE:/root/.cache" \
    -p 8000:8000 \
    -it "$IMAGE" bash

A3 系列（双 DIE 设计，需要两个设备节点）：

export DEVICE0=/dev/davinci0
export DEVICE1=/dev/davinci1
export MODEL_CACHE="${HOME}/.cache"
mkdir -p "$MODEL_CACHE"

docker run --rm \
    --name vllm-ascend \
    --shm-size=1g \
    --device "$DEVICE0" \
    --device "$DEVICE1" \
    --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 "$MODEL_CACHE:/root/.cache" \
    -p 8000:8000 \
    -it "$IMAGE" bash

Docker 参数详解：

参数	作用
--device /dev/davinci0	挂载 NPU 计算设备
--device /dev/davinci_manager	挂载 NPU 管理设备
--device /dev/devmm_svm	挂载内存管理设备
--device /dev/hisi_hdc	挂载调试通道设备
-v /usr/local/dcmi	挂载 DCMI 管理接口库
-v /usr/local/bin/npu-smi	挂载 npu-smi 工具
-v /usr/local/Ascend/driver/lib64	挂载驱动库
-v /usr/local/Ascend/driver/version.info	挂载驱动版本信息
-v /etc/ascend_install.info	挂载安装信息
--shm-size=1g	设置共享内存大小（多卡通信需要）
-p 8000:8000	映射推理服务端口

第三步：验证环境

在容器中运行：

npu-smi info

python3 - <<'PY'
import torch
import vllm
import vllm_ascend

assert torch.npu.is_available(), "No available Ascend NPU detected in the container"
print("vLLM Ascend environment: OK")
PY

当输出包含 vLLM Ascend environment: OK 时，表示容器已准备就绪。

路径二：在已有 CANN 环境中安装

如果你已经有一个安装好 CANN 的镜像或主机，可以直接用 pip 安装：

# vLLM 和 vLLM Ascend 会自动安装匹配版本的 PyTorch 和 TorchNPU
pip install vllm vllm-ascend

# A2/A3/950DT 系列还需要安装 Triton Ascend
pip install triton-ascend

注意：PyTorch 和 TorchNPU 作为 vLLM 的依赖项自动安装，不需要单独安装。Triton Ascend 仅用于 A2、A3 和 950DT 系列。

路径三：从基础环境安装（高级用户）

需要从零开始安装完整软件栈：

# 1. 安装 CANN Toolkit + Ops + NNAL
# 从华为官网下载对应版本的 CANN 安装包
chmod +x Ascend-cann-toolkit_*.run
./Ascend-cann-toolkit_*.run --install
# 同样安装 Ops 和 NNAL 包

# 2. 安装 PyTorch 和 TorchNPU
pip install torch==2.10.0
pip install torch-npu==2.10.0.post4

# 3. 安装 vLLM 和 vLLM Ascend
pip install vllm==0.23.0 vllm-ascend==0.23.0

# 4. 安装 Triton Ascend（A2/A3/950DT）
pip install triton-ascend==3.2.2

# 5. 验证
source /usr/local/Ascend/ascend-toolkit/set_env.sh
python3 -c "import torch; print(torch.npu.is_available())"

4.3 部署第一个模型

环境就绪后，启动一个 OpenAI 兼容的推理服务：

# 启动 Qwen2.5-7B 推理服务（单卡）
vllm serve Qwen/Qwen2.5-7B-Instruct \
    --served-model-name qwen2.5-7b \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.9 \
    --max-num-seqs 256 \
    --port 8000

关键参数说明：

参数	作用	建议值
--served-model-name	服务模型名（API 调用时用的名字）	自定义
--max-model-len	最大上下文长度	根据模型和显存调整
--gpu-memory-utilization	NPU 显存利用率上限	0.85-0.95
--max-num-seqs	最大并发序列数	128-512
--tensor-parallel-size	张量并行卡数	多卡时设置
--port	服务端口	默认 8000

多卡部署（张量并行）：

# 4 卡张量并行部署 70B 模型
vllm serve Qwen/Qwen2.5-72B-Instruct \
    --served-model-name qwen2.5-72b \
    --tensor-parallel-size 4 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.9 \
    --max-num-seqs 128 \
    --port 8000

调用服务（OpenAI 兼容 API）：

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "qwen2.5-7b",
        "messages": [
            {"role": "user", "content": "你好，请介绍一下你自己"}
        ],
        "temperature": 0.7,
        "max_tokens": 512
    }'

Python 客户端调用：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed",  # vLLM 默认不需要 API Key
)

response = client.chat.completions.create(
    model="qwen2.5-7b",
    messages=[{"role": "user", "content": "你好，请介绍一下你自己"}],
    temperature=0.7,
    max_tokens=512,
)

print(response.choices[0].message.content)

4.4 vLLM 推理核心原理

理解了部署，再深入理解 vLLM 为什么快。

PagedAttention 的工作流程：

1. 每个请求到来时，不预分配完整的 KV Cache 空间
2. 随着 token 生成，按需分配固定大小的 block（通常每个 block 存 16 个 token 的 KV）
3. block 在物理显存中可以不连续，通过 block 表维护逻辑顺序
4. 请求结束后，block 被回收，可立即分配给新请求
5. 相同前缀的请求可以共享 block（前缀缓存），进一步节省显存

连续批处理的工作流程：

1. 调度器维护一个请求队列和一个正在运行的 batch
2. 每个解码步结束后，检查是否有请求完成
3. 完成的请求立即移出 batch，释放资源
4. 队列中的新请求立即加入 batch（如果有空闲资源）
5. 不需要等整个 batch 全部完成

这两个机制结合，让 vLLM 的吞吐量远高于朴素实现。

---

五、企业项目实战：高级特性与性能调优

5.1 PD 分离部署

大模型推理分为两个阶段：

• Prefill（预填充）：处理输入 prompt，计算所有输入 token 的 KV Cache。特点是计算密集型，输入越长计算量越大。
• Decode（解码）：逐 token 生成输出。特点是访存密集型，每次只生成一个 token，但需要读取全部 KV Cache。

这两个阶段的资源瓶颈完全不同：Prefill 受算力限制，Decode 受显存带宽限制。在同一组硬件上同时运行两者，会互相妥协，谁都跑不到最优。

PD 分离就是把 Prefill 和 Decode 放在不同配置的专用节点组上分别运行：

• Prefill 节点：高算力配置，处理长输入
• Decode 节点：高显存带宽配置，处理高并发生成
• 两组节点之间通过高速网络传输 KV Cache

PD 分离推荐用于具有并发多用户工作负载的生产部署，因为这类场景同时需要稳定的延迟和高吞吐量。

部署示例（DeepSeek-V4-Flash 多节点 PD 分离）：

# Prefill 节点启动
vllm serve deepseek-ai/DeepSeek-V4-Flash \
    --served-model-name deepseek-v4 \
    --node-role prefill \
    --pd-backend etcd \
    --etcd-endpoints http://<etcd-host>:2379 \
    --tensor-parallel-size 8 \
    --max-model-len 131072 \
    --port 8000

# Decode 节点启动
vllm serve deepseek-ai/DeepSeek-V4-Flash \
    --served-model-name deepseek-v4 \
    --node-role decode \
    --pd-backend etcd \
    --etcd-endpoints http://<etcd-host>:2379 \
    --tensor-parallel-size 8 \
    --max-model-len 131072 \
    --port 8001

注意事项：

• 使用 SFA（稀疏闪存注意力）的模型（DeepSeek-V3.2、GLM-5.1/5.2）做 PD 分离时，Prefill 和 Decode 节点必须同时启用或同时禁用 DCP，不对称配置可能导致精度问题
• Ascend 950 上 SFA 不支持上下文并行

5.2 上下文并行（Context Parallel）

当模型的上下文长度非常大（如 128K），单卡显存放不下 KV Cache 时，可以使用上下文并行。

上下文并行把长序列切分到多个 NPU 上，每个 NPU 只处理一部分 token 的注意力计算，然后通过集合通信（All-Reduce）合并结果。

分为两种模式：

• PCP（Prefill Context Parallel）：预填充阶段的上下文并行
• DCP（Decode Context Parallel）：解码阶段的上下文并行

启用方式：

vllm serve Qwen/Qwen2.5-72B-Instruct \
    --served-model-name qwen2.5-72b \
    --tensor-parallel-size 2 \
    --data-parallel-size 2 \
    --context-parallel-size 4 \
    --max-model-len 131072 \
    --port 8000

--context-parallel-size 设置上下文并行的度数，需要和张量并行、数据并行配合，总卡数 = TP × DP × CP。

上下文并行的作用：

• 降低单卡 KV Cache 显存占用
• 提高长序列推理速度
• 让超大上下文模型能在有限显存下运行

5.3 前缀缓存（Prefix Caching）

很多场景下，多个请求共享相同的前缀（如系统提示词、RAG 检索到的相同文档）。vLLM 支持自动前缀缓存，共享前缀的 KV Cache block 不需要重复计算。

vllm serve Qwen/Qwen2.5-7B-Instruct \
    --enable-prefix-caching \
    --max-model-len 32768 \
    --port 8000

前缀缓存在 RAG、多轮对话、固定系统提示词等场景下效果显著，可以大幅降低 Prefill 延迟。

5.4 量化支持

vLLM Ascend 支持多种量化方式，降低显存占用：

# AWQ 量化
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
    --quantization awq \
    --port 8000

# GPTQ 量化
vllm serve Qwen/Qwen2.5-7B-Instruct-GPTQ \
    --quantization gptq \
    --port 8000

# W4A8 量化（MoE 和 Dense 模型均支持）
vllm serve <model-path> \
    --quantization w4a8 \
    --port 8000

量化可以在精度损失很小的情况下，将显存占用降低一半甚至更多，让更大的模型能在有限显存上运行。

5.5 LoRA 和 Multi-LoRA 支持

vLLM Ascend 支持 LoRA 微调模型的推理，以及多 LoRA 动态服务：

# 单 LoRA
vllm serve base-model \
    --enable-lora \
    --lora-modules lora-a=./lora-a-checkpoint \
    --port 8000

# Multi-LoRA 动态服务
vllm serve base-model \
    --enable-lora \
    --lora-modules lora-a=./lora-a lora-b=./lora-b \
    --max-loras 4 \
    --max-lora-rank 64 \
    --port 8000

Multi-LoRA 允许多个微调模型共享同一个基础模型的权重，只加载各自的 LoRA 适配器，大幅节省显存。

5.6 性能调优 checklist

调优项	建议	说明
--max-num-seqs	128-512	并发数，太低压不满算力，太高调度开销大
--gpu-memory-utilization	0.85-0.95	显存利用率，留出安全余量
--max-model-len	按需设置	不要设太大，浪费 KV Cache 空间
--tensor-parallel-size	2/4/8	大模型必须多卡 TP，注意卡间互联
--enable-prefix-caching	RAG场景必开	共享前缀自动缓存
--enable-chunked-prefill	长输入场景开启	分块预填充，避免长请求阻塞短请求
量化	显存不足时使用	AWQ/GPTQ/W4A8
上下文并行	超长上下文使用	PCP/DCP 切分序列
PD 分离	高并发生产环境	Prefill/Decode 独立优化

---

六、主流推理框架对比

6.1 详细对比表

对比维度	vLLM Ascend	MindIE	SGLang Ascend	TensorRT-LLM	Transformers
开发方	开源社区+华为	华为官方	开源社区	NVIDIA	HuggingFace
硬件支持	昇腾全系列	昇腾全系列	昇腾 910B 等	仅 NVIDIA GPU	全硬件
核心优势	vLLM 生态兼容、新模型支持快、部署简单	极致性能、PD分离调度、K8S云原生、商用SLA	RadixAttention、多调用调度、代码清晰易二次开发	N卡极致性能、FP8量化	简单易用、模型最全
核心劣势	性能调优空间大、部分高级特性仍在完善	模型支持滞后、闭源、定制灵活度低	生态较新、部分模型不支持、昇腾适配不如vLLM成熟	不支持昇腾、配置复杂、编译耗时	性能最低、无批处理优化、不适合生产
PagedAttention	支持（核心）	类似机制	RadixAttention（更优）	类似机制	不支持
连续批处理	支持	支持	支持	支持	不支持
PD分离	支持	支持（调度引擎成熟）	支持	支持	不支持
上下文并行	支持（PCP/DCP）	支持	部分支持	支持	不支持
前缀缓存	支持	支持	支持（RadixAttention天然支持）	支持	不支持
推测解码	支持	部分支持	支持	支持	不支持
量化	AWQ/GPTQ/W4A8	支持	支持	支持（FP8最强）	部分支持
LoRA/Multi-LoRA	支持	支持	支持	支持	支持
OpenAI兼容API	支持	支持	支持	需额外封装	需自己实现
K8S部署	需自行封装	原生支持、一键拉起	需自行封装	需自行封装	需自行封装
开源	是	否（闭源商用）	是	部分开源	是
学习曲线	中等	中等	中等	陡峭	平缓
适用场景	开发者快速验证、科研、中小团队生产	企业级生产、极致性能、稳定业务流	高并发MoE、复杂多轮对话、需要二次开发	纯NVIDIA环境、极致吞吐	原型验证、小流量、学习研究

6.2 各方案特点分析

vLLM Ascend

优势：

• vLLM 是目前最主流的开源推理引擎，生态最成熟
• 新模型支持速度快，DeepSeek、Qwen、GLM 等通常第一时间适配
• 部署简单，预构建镜像一键启动，API 与 GPU 版一致
• 开源活跃，社区支持好，问题响应快
• 特性丰富，PD分离、上下文并行、前缀缓存、推测解码、量化、LoRA 全覆盖

劣势：

• 性能相比华为官方深度优化的 MindIE 还有差距
• 部分高级特性（如 K8S 原生调度）需要自行封装
• 昇腾适配版本迭代快，版本间兼容性需要注意

MindIE

优势：

• 华为官方出品，针对昇腾硬件深度优化，性能极致
• 内置服务化调度引擎，PD分离调度成熟，性能提升约40%
• K8S 云原生部署，一键拉起，支持弹性伸缩
• 商用级高可靠，PD 实例级故障隔离与恢复（自愈型故障60秒内、系统级故障7分钟内）
• 可对接 vLLM、SGLang 等第三方开源引擎

劣势：

• 闭源商用，定制灵活度低
• 新模型支持相对滞后
• 学习资料不如 vLLM 丰富

SGLang Ascend

优势：

• RadixAttention 比 PagedAttention 更先进，前缀缓存效率更高
• 多调用调度（Multi-call Scheduling），复杂多轮对话场景性能好
• 代码结构清晰，比 vLLM 更易二次开发
• 开源维护者积极，开发节奏快

劣势：

• 昇腾适配不如 vLLM Ascend 成熟
• 生态和模型支持广度不如 vLLM
• 部分高级特性仍在完善中

TensorRT-LLM

优势：

• NVIDIA 官方出品，在 N 卡上性能极致（比 vLLM 高 15%-30%）
• FP8 量化支持最成熟
• 编译优化充分，峰值吞吐最高

劣势：

• 完全不支持昇腾 NPU
• 配置复杂，每个模型需要单独编译
• 不适合快速迭代和多模型场景

6.3 选型建议

根据场景给出以下建议：

1. 开发者快速验证、科研、中小团队生产：选 vLLM Ascend，生态好、部署快、模型全
2. 企业级生产环境、极致性能要求、稳定业务流：选 MindIE，官方深度优化，商用 SLA 保障
3. 高并发 MoE 模型、复杂多轮对话、需要深度二次开发：考虑 SGLang Ascend
4. 纯 NVIDIA 环境、追求极致吞吐：选 TensorRT-LLM
5. 原型验证、学习研究、极小流量：用 Transformers 即可

实际项目中，也可以采用 MindIE 作为服务化调度层，底层对接 vLLM 或 SGLang 引擎的混合方案，兼顾性能和灵活性。

---

七、面试官高频面试题

面试题 1：vLLM 为什么比朴素 HuggingFace 推理快？核心优化是什么？

参考答案：

vLLM 的核心优化有两个：PagedAttention 和连续批处理（Continuous Batching）。

PagedAttention 借鉴操作系统的虚拟内存分页机制，把 KV Cache 分成固定大小的 block，物理上可以不连续，通过 block 表映射。按需分配，用多少分多少，消除了传统连续内存分配的内部碎片，KV Cache 显存利用率从 20%-40% 提升到接近 90%。

连续批处理打破了传统静态 batch 的限制：不需要等整个 batch 的请求都完成，某个请求生成完立即移出，新请求立即加入。硬件始终保持高利用率。

两者结合，vLLM 的吞吐量比朴素 HuggingFace 实现高 2 到 4 倍。

面试题 2：vLLM Ascend 的硬件和软件栈是怎样的？为什么版本不能混用？

参考答案：

vLLM Ascend 运行在分层软件栈上，从下到上：Ascend NPU（硬件）→ Ascend HDK（驱动固件）→ CANN（Toolkit+Ops+NNAL 运行时）→ PyTorch+TorchNPU / Triton Ascend（框架层）→ vLLM + vLLM Ascend（引擎层）。

版本不能混用的原因：每一层都有严格的接口依赖。TorchNPU 依赖特定版本的 CANN，vLLM Ascend 依赖特定版本的 TorchNPU 和 vLLM，Triton Ascend 依赖特定版本的 CANN 和内核接口。这些组件作为一个兼容性集合进行联合验证，任何一个版本不匹配都可能导致算子编译失败、运行时崩溃或精度问题。

已验证的版本组合（v0.23.0）：CANN 9.1.0、PyTorch 2.10.0、TorchNPU 2.10.0.post4、Triton Ascend 3.2.2、Python 3.12、HDK 26.0.RC1。

面试题 3：Docker 容器中运行 vLLM Ascend 需要挂载哪些设备和目录？

参考答案：

需要挂载以下内容：

设备节点（4个）：

• /dev/davinci0（或对应卡号）：NPU 计算设备
• /dev/davinci_manager：NPU 管理设备
• /dev/devmm_svm：内存管理设备
• /dev/hisi_hdc：调试通道设备

目录和文件（5个）：

• /usr/local/dcmi：DCMI 管理接口库
• /usr/local/bin/npu-smi：npu-smi 监控工具
• /usr/local/Ascend/driver/lib64/：驱动库
• /usr/local/Ascend/driver/version.info：驱动版本信息
• /etc/ascend_install.info：安装信息

另外还需要 --shm-size=1g（多卡通信共享内存）和端口映射。A3 系列因为双 DIE 设计，需要挂载两个 davinci 设备节点。

面试题 4：什么是 PD 分离？为什么要做 PD 分离？

参考答案：

PD 分离（Prefill/Decode Disaggregation）是把大模型推理的两个阶段放在不同硬件节点上分别运行的部署架构。

• Prefill（预填充）：处理输入 prompt，计算 KV Cache，是计算密集型
• Decode（解码）：逐 token 生成输出，是访存密集型

为什么要分离：两个阶段的资源瓶颈不同，在同一组硬件上运行会互相妥协。Prefill 需要高算力，Decode 需要高显存带宽和大 KV Cache。分离后可以为各自配置最优硬件，Prefill 节点专注处理长输入，Decode 节点专注高并发生成，同时满足低延迟和高吞吐。

PD 分离通过调度器将新请求路由到 Prefill 节点，Prefill 完成后将 KV Cache 传输到 Decode 节点继续生成。适用于并发多用户的生产环境。

面试题 5：什么是上下文并行？PCP 和 DCP 有什么区别？

参考答案：

上下文并行（Context Parallel）是将长序列的注意力计算切分到多个 NPU 上的并行策略。每个 NPU 只处理一部分 token，然后通过集合通信（All-Reduce）合并结果，降低单卡显存占用，提高长序列推理速度。

• PCP（Prefill Context Parallel）：预填充阶段的上下文并行，针对长输入的注意力计算
• DCP（Decode Context Parallel）：解码阶段的上下文并行，针对生成阶段的 KV Cache 分布

两者的区别在于作用阶段和计算特征不同：Prefill 阶段计算量大，PCP 主要解决算力和显存问题；Decode 阶段每次只生成一个 token，DCP 主要解决 KV Cache 显存分布问题。

使用时通过 --context-parallel-size 参数设置，总卡数 = 张量并行 × 数据并行 × 上下文并行。

面试题 6：PagedAttention 的 block 是什么？前缀缓存是怎么实现的？

参考答案：

PagedAttention 将 KV Cache 分成固定大小的 block（页），每个 block 通常存储 16 个 token 的 Key 和 Value。这些 block 在物理显存中可以不连续，通过一个 block 表（类似页表）维护逻辑顺序。

前缀缓存的实现：当多个请求共享相同的前缀（如系统提示词、相同的 RAG 文档）时，PagedAttention 可以让这些请求共享相同前缀的 block。因为 block 是按 token 范围组织的，相同前缀对应的 block 内容完全一致，可以直接引用而不需要重新计算和分配。

vLLM 通过 --enable-prefix-caching 开启自动前缀缓存。在 RAG、多轮对话、固定系统提示词等场景下，能大幅降低 Prefill 延迟和算力消耗。

面试题 7：vLLM Ascend 和 MindIE 怎么选？

参考答案：

维度	vLLM Ascend	MindIE
定位	开源通用推理引擎	华为官方商用推理服务
性能	良好，持续优化	极致，深度硬件优化
模型支持	快，紧跟社区	相对滞后
部署灵活度	高，可深度定制	中，闭源商用
云原生	需自行封装	原生 K8S 支持
商用 SLA	社区支持	官方 SLA 保障
开源	是	否

选型建议：

• 开发者、科研、快速验证、中小团队生产 → vLLM Ascend
• 企业级生产、极致性能、稳定业务流、需要官方支持 → MindIE
• 也可以混合：MindIE 做服务化调度层，底层对接 vLLM 引擎

面试题 8：vLLM 的 --gpu-memory-utilization 和 --max-num-seqs 怎么调？

参考答案：

--gpu-memory-utilization：设置 vLLM 可以使用的 NPU 显存比例上限，默认 0.9。建议设 0.85-0.95，留出安全余量避免 OOM。设太低浪费显存，设太高可能在运行中 OOM。

--max-num-seqs：最大并发序列数，决定同时处理的请求数。调优原则：

• 太小：硬件利用率低，吞吐上不去
• 太大：每个请求分到的 KV Cache 变少，max_model_len 受限，调度开销增大
• 建议从 128 开始，根据实际负载逐步调整到 256 或 512
• 短文本多、并发高的场景可以设大；长文本多的场景适当设小

实际调优需要结合监控（NPU 利用率、显存使用率、吞吐量、延迟）来找到最优平衡点。

面试题 9：昇腾 NPU 和 NVIDIA GPU 在推理部署上有什么区别？

参考答案：

维度	昇腾 NPU	NVIDIA GPU
软件栈	CANN + TorchNPU	CUDA + PyTorch
容器透传	需挂载4个设备+5个目录，较复杂	--gpus all 简单
推理引擎	vLLM Ascend / MindIE / SGLang	vLLM / TensorRT-LLM / SGLang
量化	W4A8 / AWQ / GPTQ	FP8 / AWQ / GPTQ / INT4
互联	HCCS / RoCE	NVLink / InfiniBand
生态	快速发展中	成熟完善
驱动	Ascend HDK	NVIDIA Driver

核心区别在于软件栈：NPU 使用 CANN 作为计算架构，通过 TorchNPU 连接 PyTorch；GPU 使用 CUDA。容器透传 NPU 比 GPU 复杂，需要挂载更多设备和库。但在 vLLM Ascend 等框架的适配下，上层 API 使用方式已经基本一致。

面试题 10：如果让你设计一个昇腾 NPU 上的大模型推理服务，你会怎么架构？

参考答案：

我会按以下层次设计：

硬件层：

• 根据模型大小选择昇腾 910B/950DT 集群
• 配置高速互联（HCCS 卡间、RoCE 节点间）

引擎层：

• 中小模型、快速迭代：vLLM Ascend 单节点张量并行
• 超大模型、高并发生产：PD 分离 + 多节点部署
• 企业级稳定服务：MindIE 服务化调度 + vLLM 引擎

服务层：

• OpenAI 兼容 API，前端无感知
• 负载均衡（多实例）
• 限流、鉴权、监控
• K8S 容器化部署，弹性伸缩

优化层：

• 前缀缓存（RAG 场景必开）
• 量化（显存不足时）
• 上下文并行（超长上下文）
• 推测解码（降低延迟）
• Multi-LoRA（多租户微调模型）

运维层：

• npu-smi 监控（利用率、显存、温度）
• 日志收集（请求量、延迟、错误率）
• 灰度发布和回滚
• 定期性能基准测试

关键原则：先跑通再优化，根据实际负载数据调参，不要过早过度设计。

---

八、总结与最佳实践

核心要点回顾

1. vLLM Ascend 是插件不是独立引擎：它让 vLLM 能在昇腾 NPU 上运行，上层 API 与 GPU 版一致
2. 五层软件栈：NPU → HDK → CANN → PyTorch/TorchNPU/Triton → vLLM/vllm-ascend，版本必须严格匹配
3. 预构建镜像是首选：避免版本兼容问题，一条 docker run 启动完整环境
4. Docker 透传是关键：4个设备节点 + 5个目录文件，少一个都识别不到 NPU
5. PagedAttention + 连续批处理是性能核心：显存利用率从 40% 提升到 90%，吞吐提升 2-4 倍
6. PD 分离解决生产并发：Prefill 和 Decode 分离部署，同时满足低延迟和高吞吐
7. 上下文并行解决长序列：PCP/DCP 把长序列切到多卡，突破单卡显存限制
8. 选型看场景：vLLM Ascend 适合开发和中小生产，MindIE 适合企业级极致性能

最佳实践清单

• 优先使用官方预构建镜像，不要手动混用版本
• 启动容器前先 npu-smi info 确认驱动固件正常
• Docker run 必须挂载全部 4 个设备和 5 个目录/文件
• A3 系列挂载两个 davinci 设备节点
• --gpu-memory-utilization 设 0.85-0.95，留安全余量
• --max-num-seqs 从 128 开始，根据监控调整
• RAG 场景必开 --enable-prefix-caching
• 显存不足时考虑量化（AWQ/W4A8）
• 超长上下文使用 --context-parallel-size
• 高并发生产环境考虑 PD 分离部署
• 多卡部署注意卡间互联（HCCS），同节点卡做 TP
• 模型缓存挂载到宿主机，避免容器重启重新下载
• 生产环境配置健康检查和监控告警
• 定期做性能基准测试，跟踪版本升级带来的变化

写在最后

vLLM Ascend 的出现，让昇腾 NPU 上的大模型推理部署变得和 NVIDIA GPU 上一样简单。它的价值不在于重新发明了一个推理引擎，而在于把 vLLM 这个成熟生态无缝带到了昇腾硬件上。

对于开发者来说，这意味着你不需要为了国产硬件重新学习一套完全不同的工具链。vLLM 的命令、参数、API 在昇腾上几乎一模一样。你只需要关注硬件环境的搭建（驱动、CANN、Docker 透传），剩下的就是你熟悉的 vLLM。

国产算力的生态正在快速成熟，vLLM Ascend 是其中的重要一环。掌握它，你就能在昇腾 NPU 上搭建出高性能、可扩展的大模型推理服务。

希望这篇文章能帮你从零开始，在昇腾 NPU 上顺利部署你的第一个大模型推理服务。

---

转载声明：本文为原创文章，如需转载，请联系作者获得授权，并注明出处。