•
華為昇騰推理對決：開源vLLM vs 官方MindIE，資料說話「Qwen與DeepSeek推理實測」
在昇騰 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 進行，在保證復現性和易用性的前提下，快速完成部署與測試。
GPUStack https://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寒武紀)