在昇腾 NPU 上进行大模型推理，长期以来都是国内开发者面临的一项挑战。虽然华为官方提供了性能表现良好的 MindIE 推理引擎，并原生支持 Atlas 800 A2 系列和 Atlas 300i Duo（昇腾 910B 和 310P），但其使用门槛较高，环境配置复杂，限制了非官方团队在实际项目中部署和调试的效率。
开源社区也在积极推进对昇腾 NPU 的支持。尤其值得关注的是，近段时间昇腾联合 vLLM 社区推出了 vLLM Ascend 插件，实现了对 Atlas 800 A2 系列的支持（预计在 2025 年 Q3 支持 Atlas 300i Duo）。其开源生态活跃，发展势头迅猛，逐步成为昇腾推理生态中不可忽视的一股力量。
为了系统地评估 vLLM Ascend 与 MindIE 在实际推理场景中的性能差异，本文将从单卡推理、多卡并行、多并发处理等维度展开对比测试。实验基于开源模型服务平台 GPUStack 进行，在保证复现性和易用性的前提下，快速完成部署与测试。
GPUStackhttps://github.com/gpustack/gpustack 是目前对昇腾 NPU 支持最完善的开源模型服务平台。 它开箱即用地集成了 MindIE、vLLM（vLLM Ascend）、llama-box（llama.cpp）等多个后端，避免了用户在部署过程中反复踩坑和冗长的环境配置流程。平台原生支持昇腾上的多种模型类型，包括大语言模型、多模态模型、文本嵌入模型、重排序模型和图像生成模型等，同时也兼容昇腾的多机多卡推理场景，其中 vLLM 和 llama-box 已实现多机分布式推理支持，MindIE 分布式功能也在开发计划中。
以下是 GPUStack 官方的特性介绍：
• 广泛的 GPU 兼容性：无缝支持 Apple Mac、Windows PC 和 Linux 服务器上各种供应商（NVIDIA、AMD、Apple、昇腾、海光、摩尔线程、天数智芯）的 GPU。
• 广泛的模型支持：支持各种模型，包括大语言模型 LLM、多模态 VLM、图像模型、语音模型、文本嵌入模型和重排序模型。
• 灵活的推理后端：支持与 llama-box（llama.cpp 和 stable-diffusion.cpp）、vox-box、vLLM 和 Ascend MindIE 等多种推理后端的灵活集成。
• 多版本后端支持：同时运行推理后端的多个版本，以满足不同模型的不同运行依赖。
• 分布式推理：支持单机和多机多卡并行推理，包括跨供应商和运行环境的异构 GPU。
• 可扩展的 GPU 架构：通过向基础设施添加更多 GPU 或节点轻松进行扩展。
• 强大的模型稳定性：通过自动故障恢复、多实例冗余和推理请求的负载平衡确保高可用性。
• 智能部署评估：自动评估模型资源需求、后端和架构兼容性、操作系统兼容性以及其他与部署相关的因素。
• 自动调度：根据可用资源动态分配模型。
• 轻量级 Python 包：最小依赖性和低操作开销。
• OpenAI 兼容 API：完全兼容 OpenAI 的 API 规范，实现无缝迁移和快速适配。
• 用户和 API 密钥管理：简化用户和 API 密钥的管理。
• 实时 GPU 监控：实时跟踪 GPU 性能和利用率。
• 令牌和速率指标：监控 Token 使用情况和 API 请求速率。
调试昇腾设备在实际操作中远比 NVIDIA 环境复杂，尤其在依赖项编译、推理引擎集成等方面常常阻碍开发流程。GPUStack 的意义在于有效屏蔽部署过程中的环境复杂性，为开发者提供一个统一、稳定的推理平台，大幅降低了在昇腾设备上开展模型部署和推理的门槛。
此外，GPUStack 还内置了模型对比功能，支持在统一的测试环境下直观对比 MindIE 和 vLLM Ascend 的推理表现，为后续选型和优化提供直接的数据支持。因此，我们将在 GPUStack 上系统测试两种推理后端的性能表现。
快速安装 GPUStack
首先，参考 GPUStack 官方文档完成安装（https://docs.gpustack.ai/latest/installation/ascend-cann/online-installation/）。本文采用容器化部署方式，在昇腾 910B 服务器上，根据文档要求完成对应版本的 NPU 驱动和 Docker 运行时的安装后，通过 Docker 启动 GPUStack 服务。
在本次实验中，我们挂载了 /dev/davinci0 至 /dev/davinci3 共四张 NPU 卡，具体挂载方式可根据实际设备资源灵活调整。在运行时通过 --port 9090 指定管理界面的访问端口（使用 Atlas 300i Duo 的用户，可以参照安装文档选择对应的 310P 镜像，vLLM Ascend 暂不支持 310P）：
docker run -d --name gpustack \
--restart=unless-stopped \
--device /dev/davinci0 \
--device /dev/davinci1 \
--device /dev/davinci2 \
--device /dev/davinci3 \
--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 \
--network=host \
--ipc=host \
-v gpustack-data:/var/lib/gpustack \
crpi-thyzhdzt86bexebt.cn-hangzhou.personal.cr.aliyuncs.com/gpustack_ai/gpustack:v0.6.2-npu \
--port 9090
查看容器日志确认 GPUStack 是否正常运行（需要注意的是，昇腾 NPU 默认不支持设备在多个容器间共享使用，如果已有其他容器占用 NPU 设备（已挂载 /dev/davinci*），将导致 GPUStack 无法正常使用 NPU。在此情况下，需先停止占用 NPU 的其他容器，释放设备资源）：
docker logs -f gpustack
若容器日志显示服务启动正常，使用以下命令获取 GPUStack 控制台的初始登录密码：
docker exec -it gpustack cat /var/lib/gpustack/initial_admin_password
在浏览器中通过服务器 IP 和自定义的 9090 端口访问 GPUStack 控制台（http://YOUR_HOST_IP:9090），使用默认用户名 admin 和上一步获取的初始密码登录。登录 GPUStack 后，在资源菜单即可查看识别到的 NPU 资源：
GPUStack 也支持添加更多 Worker 节点构建异构推理集群。由于本文聚焦单机性能对比，相关集群部署内容不作展开，感兴趣的读者可参考前文提到的官方安装文档获取详细说明。
部署模型
GPUStack 支持从 Hugging Face、ModelScope 和本地路径部署模型，国内网络推荐从 ModelScope 部署。在 GPUStack UI，选择 模型 – 部署模型 – ModelScope 部署模型。
从 ModelScope 分别部署以下模型，并分别选择 MindIE 和 vLLM 后端，部署不同后端的模型服务。由于 MindIE 和 vLLM 后端默认的独占显存参数设置，当前资源不足以运行所有模型，本文将根据需要灵活停止和启动不同的模型进行测试。
GPUStack 提供了智能计算模型资源需求和分配资源的自动化调度功能，对于 7B 模型和 14B 模型，默认仅会分配单卡。如果想强制分配更多的卡数量：
• 对于 vLLM 后端，可以设置 --tensor-parallel-size=2 或手动选择 2 卡来分配 2 块 NPU
• 对于 MindIE 后端，可以手动选择 2 卡来分配 2 块 NPU
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
完成后，模型运行如下所示（注：根据所需，停止和启动不同模型进行测试）：
测试 DeepSeek-R1-Distill-Qwen-7B（单卡）
1. 在 试验场-对话-多模型对比，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-7B 模型进行对比测试；
2. 切换到 6 模型对比，重复选择 vLLM Ascend 运行的模型测试 6 并发请求；
3. 更换 MindIE 运行的模型测试 6 并发请求。
本文基于 GPUStack 的能力进行性能对比测试，更深入的性能测试可以使用 EvalScope 等工具进行。
以下为 DeepSeek R1 Distill Qwen 7B 模型在昇腾 910B 上的推理性能数据对比：
单并发 vLLM Ascend 对比 MindIE
6 并发 MindIE 性能数据
6 并发 vLLM Ascend 性能数据
测试 DeepSeek-R1-Distill-Qwen-7B（双卡并行）
1. 在 模型，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-7B 模型，修改配置分配 2 卡并重建生效；
2. 在 试验场-对话-多模型对比，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-7B 模型进行对比测试；
3. 切换到 6 模型对比，重复选择 vLLM Ascend 运行的模型测试 6 并发请求；
4. 更换 MindIE 运行的模型测试 6 并发请求。
以下为 DeepSeek R1 Distill Qwen 7B 模型在双卡昇腾 910B 上的推理性能数据对比：
单并发 vLLM Ascend 对比 MindIE
6 并发 MindIE 性能数据
6 并发 vLLM Ascend 性能数据
测试 Qwen3-14B（单卡）
1. 在 试验场-对话-多模型对比，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-14B 模型进行对比测试；
2. 切换到 6 模型对比，重复选择 vLLM Ascend 运行的模型测试 6 并发请求；
3. 更换 MindIE 运行的模型测试 6 并发请求。
以下为 DeepSeek R1 Distill Qwen 14B 模型在单卡昇腾 910B 上的推理性能数据对比：
单并发 vLLM Ascend 对比 MindIE
6 并发 MindIE 性能数据
6 并发 vLLM Ascend 性能数据
测试 Qwen3-14B（双卡并行）
1. 在 模型，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-14B 模型，修改配置分配 2 卡并重建生效；
2. 在 试验场-对话-多模型对比，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-14B 模型进行对比测试；
3. 切换到 6 模型对比，重复选择 vLLM Ascend 运行的模型测试 6 并发请求；
4. 更换 MindIE 运行的模型测试 6 并发请求。
以下为 DeepSeek R1 Distill Qwen 14B 模型在双卡昇腾 910B 上的推理性能数据对比：
点击图片可查看完整电子表格
单并发 vLLM Ascend 对比 MindIE
6 并发 MindIE 性能数据
6 并发 vLLM Ascend 性能数据
测试 DeepSeek-R1-Distill-Qwen-32B（双卡并行）
1. 在 试验场-对话-多模型对比，分别选择两种后端运行的 DeepSeek-R1-Distill-Qwen-32B 模型进行对比测试；
2. 切换到 6 模型对比，重复选择 vLLM Ascend 运行的模型测试 6 并发请求；
3. 更换 MindIE 运行的模型测试 6 并发请求。
以下为 DeepSeek R1 Distill Qwen 32B 模型在双卡昇腾 910B 上的推理性能数据对比：
单并发 vLLM Ascend 对比 MindIE
6 并发 MindIE 性能数据
6 并发 vLLM Ascend 性能数据
测试 Qwen3-32B（双卡并行）
1. 在 试验场-对话-多模型对比，分别选择两种后端运行的 Qwen3-32B 模型进行对比测试；
2. 切换到 6 模型对比，重复选择 vLLM Ascend 运行的模型测试 6 并发请求；
3. 更换 MindIE 运行的模型测试 6 并发请求。
以下为 Qwen3 32B 模型在双卡昇腾 910B 上的推理性能数据对比：
单并发 vLLM Ascend 对比 MindIE
6 并发 MindIE 性能数据
6 并发 vLLM Ascend 性能数据
数据汇总分析
将以上测试数据进行汇总得出下表：
根据以上性能数据分析，可以得出以下结论：
1. 中小模型单卡部署场景下，vLLM 在延迟和吞吐方面表现更优
以单卡部署的 DeepSeek R1 7B 和 Qwen3 14B 为例，vLLM 在 TTFT（首 token 延迟）方面普遍低于 MindIE，部分模型在吞吐上也略有提升，显示出其在延迟敏感型应用中具有一定优势。
2. 高并发场景下，vLLM 展现出良好的扩展性
在多并发测试中，vLLM 能够在保持较低延迟的同时实现与 MindIE 相当甚至略高的吞吐表现，说明其在并发请求调度和资源利用方面具备一定优势。
3. 多卡部署场景中，MindIE 在性能上更具优势
在双卡部署的多种模型测试中，MindIE 在吞吐率方面显著优于 vLLM，TPOT 延迟也表现更优。这一差距主要源于 MindIE 对图模式和融合算子的优化支持，而当前 vLLM Ascend 仍处于单算子模式，尚未充分释放多卡性能。随着社区计划发布 vLLM Ascend 0.9，该瓶颈有望得到改善。
4. 总体来看，两者在不同部署场景下各有优势
vLLM 目前更适用于单卡可运行的小型模型、延迟敏感和交互式应用场景；而 MindIE 更适合追求吞吐效率的大模型多卡部署。实际选型应结合业务需求、资源条件和生态支持情况综合判断。
总结
从本文的实验结果来看，当前 vLLM Ascend 的推理性能已初具规模，尽管在多卡并行等场景下仍存在一定差距，但其作为开源项目的发展潜力不可忽视。伴随社区与厂商的持续协作，性能的进一步突破值得期待。
值得强调的是，推理性能只是衡量生态成熟度的一个维度。易用性、可维护性、社区活跃度，以及对新的模型、新的加速技术的支持能力，都是构建国产 AI 推理生态不可或缺的要素。vLLM Ascend 正是这样一个探索的开端，也为更多开发者提供了参与昇腾生态建设的可能。
在本次测试过程中，为了更高效地在昇腾硬件上部署 vLLM Ascend 和 MindIE 推理服务，作者采用了开源模型服务平台 GPUStack。该平台已适配昇腾、海光等多种国产 GPU 架构，有效简化了 vLLM Ascend 和 MindIE 的部署和配置流程，显著减少了环境配置的时间成本，使测试工作得以专注于模型本身的表现与分析。
作为一个面向异构 GPU 生态的开源 MaaS 平台，GPUStack 的定位在于为模型推理、微调等场景和硬件适配之间提供稳定中间层。目前已有摩尔线程、天数智芯、寒武纪等厂商基于该平台进行了适配。未来，期待有更多国产 GPU 厂商加入，共同推动更统一、更高效的开源 AI 基础设施。如果你也关注国产 AI 基础设施平台的发展，不妨为该项目 https://github.com/gpustack/gpustack 点一个 star，关注后续适配进展，或参与生态共建。
国产 AI 算力生态的成长不应仅依赖封闭的官方路径，更需要开放、共享、协作的开发模式。从 MindIE 到 vLLM，从底层驱动到模型服务平台，每一个环节的开源努力，都是对自主可控技术路线的真实推动。
未来，我们期待更多项目以开放的姿态汇聚在一起，共同构建真正具备竞争力的国产 AI 基础设施体系。
公众号回复“进群”入群讨论。
（文：AI工程化）