網易首頁 > 網易號 > 正文申請入駐

華為昇騰推理對決：開源vLLM vs 官方MindIE，數據說話「Qwen與DeepSeek推理實測」

2025-06-17 07:08:17　來源: AI寒武紀

江蘇舉報

分享至

在昇騰 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（單卡）

在試驗場-對話-多模型對比，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-7B 模型進行對比測試；
切換到 6 模型對比，重復選擇 vLLM Ascend 運行的模型測試 6 并發請求；
更換 MindIE 運行的模型測試 6 并發請求。

本文基于 GPUStack 的能力進行性能對比測試，更深入的性能測試可以使用 EvalScope 等工具進行。

以下為 DeepSeek R1 Distill Qwen 7B 模型在昇騰 910B 上的推理性能數據對比：

單并發 vLLM Ascend 對比 MindIE

6 并發 MindIE 性能數據

6 并發 vLLM Ascend 性能數據

測試 DeepSeek-R1-Distill-Qwen-7B（雙卡并行）

在模型，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-7B 模型，修改配置分配 2 卡并重建生效；
在試驗場-對話-多模型對比，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-7B 模型進行對比測試；
切換到 6 模型對比，重復選擇 vLLM Ascend 運行的模型測試 6 并發請求；
更換 MindIE 運行的模型測試 6 并發請求。

以下為 DeepSeek R1 Distill Qwen 7B 模型在雙卡昇騰 910B 上的推理性能數據對比：

單并發 vLLM Ascend 對比 MindIE

6 并發 MindIE 性能數據

6 并發 vLLM Ascend 性能數據

測試 Qwen3-14B（單卡）

在試驗場-對話-多模型對比，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-14B 模型進行對比測試；
切換到 6 模型對比，重復選擇 vLLM Ascend 運行的模型測試 6 并發請求；
更換 MindIE 運行的模型測試 6 并發請求。

以下為 DeepSeek R1 Distill Qwen 14B 模型在單卡昇騰 910B 上的推理性能數據對比：

單并發 vLLM Ascend 對比 MindIE

6 并發 MindIE 性能數據

6 并發 vLLM Ascend 性能數據

測試 Qwen3-14B（雙卡并行）

在模型，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-14B 模型，修改配置分配 2 卡并重建生效；
在試驗場-對話-多模型對比，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-14B 模型進行對比測試；
切換到 6 模型對比，重復選擇 vLLM Ascend 運行的模型測試 6 并發請求；
更換 MindIE 運行的模型測試 6 并發請求。

以下為 DeepSeek R1 Distill Qwen 14B 模型在雙卡昇騰 910B 上的推理性能數據對比：

單并發 vLLM Ascend 對比 MindIE

6 并發 MindIE 性能數據

6 并發 vLLM Ascend 性能數據

測試 DeepSeek-R1-Distill-Qwen-32B（雙卡并行）

在試驗場-對話-多模型對比，分別選擇兩種后端運行的 DeepSeek-R1-Distill-Qwen-32B 模型進行對比測試；
切換到 6 模型對比，重復選擇 vLLM Ascend 運行的模型測試 6 并發請求；
更換 MindIE 運行的模型測試 6 并發請求。

以下為 DeepSeek R1 Distill Qwen 32B 模型在雙卡昇騰 910B 上的推理性能數據對比：

單并發 vLLM Ascend 對比 MindIE

6 并發 MindIE 性能數據

6 并發 vLLM Ascend 性能數據

測試 Qwen3-32B（雙卡并行）

在試驗場-對話-多模型對比，分別選擇兩種后端運行的 Qwen3-32B 模型進行對比測試；
切換到 6 模型對比，重復選擇 vLLM Ascend 運行的模型測試 6 并發請求；
更換 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寒武紀，好內容不錯過?

用你的贊和在看告訴我～

求贊

特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.