半導體研究機構SemiAnalysis高度評價輝達在vLLM推理引擎上的性能最佳化，同時指出AMD在部分模型支援上仍有明顯差距。輝達憑藉二十年CUDA積累、主流框架優先適配及TensorRT等最佳化庫建構的軟體壁壘，在推理時代仍形成持久競爭優勢。 一、綜述：一次戲劇性的敘事反轉 7月13日，半導體研究機構SemiAnalysis在社交平台發佈推文，高度評價輝達在vLLM推理引擎上的性能最佳化成果，同時明確指出AMD在部分模型的vLLM支援上仍有較大追趕空間。 這一評價之所以值得關注，恰恰在於僅僅兩周前，同一機構剛剛指出輝達的"CUDA護城河正遭緩慢侵蝕"，認為超大規模雲廠商和AI模型公司採用自研ASIC的趨勢正在動搖輝達的統治地位。從"CUDA神話鬆動"到"點贊vLLM"，SemiAnalysis在短短兩周內完成了對輝達競爭力的重新評估。

在昇騰 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 對比 MindIE6 並行 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 對比 MindIE6 並行 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 對比 MindIE6 並行 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 對比 MindIE6 並行 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 對比 MindIE6 並行 MindIE 性能資料6 並行 vLLM Ascend 性能資料測試 Qwen3-32B（雙卡平行）在 試驗場-對話-多模型對比，分別選擇兩種後端運行的 Qwen3-32B 模型進行對比測試；切換到 6 模型對比，重複選擇 vLLM Ascend 運行的模型測試 6 並行請求；更換 MindIE 運行的模型測試 6 並行請求。以下為 Qwen3 32B 模型在雙卡昇騰 910B 上的推理性能資料對比：單並行 vLLM Ascend 對比 MindIE6 並行 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寒武紀)

僅用不到1200行程式碼，實現最小化且完全可讀的vLLM！DeepSeek研究員俞星凱搞了個開放原始碼專案引得大夥拍手叫絕。項目名為Nano-vLLM（奈米級-vLLM），有三大特點：快速離線推理：推理速度可與vLLM相媲美可讀性強的程式碼庫：基於不到1200行Python程式碼實現，簡潔乾淨最佳化套件：包含前綴快取、Torch compilation 、CUDA graph等下面是vLLM與Nano-vLLM在不同硬體和模型配置下的基準測試情況。在RTX 4070硬體、Qwen3-0.6B模型環境中，設定了256個序列的總請求數，輸入和輸出長度均在100-1024個 token間隨機採樣。測試結果be like：vLLM略微領先。二者輸出token量相同，vLLM耗時98.95秒、吞吐量為1353.86 tokens/s，Nano-vLLM耗時101.90秒、吞吐量1314.65tokens/s。接著在H800硬體、Qwen3-8B模型環境中，總請求數為1024個序列，輸入輸出長度同樣隨機採樣。此時Nano-vLLM甚至反超原框架。二者輸出token量依舊相同，vLLM耗時98.67秒、吞吐量5916.89 tokens/s ，Nano-vLLM耗時86.73秒、吞吐量 6731.42 tokens/s。這一成果來自於DeepSeek研究員俞星凱。他2021年獲得南京大學電腦科學與技術系學士學位，同年又被南京大學免試錄取為碩士研究生，在校他同時也是由周志華教授領導的LAMDA團隊的成員。vLLM是什麼？vLLM是一款專為LLM推理與部署最佳化的高性能框架，最初由加州大學伯克利分校的Sky Computing Lab開發，現已發展成為一個匯聚學界與業界貢獻的社區驅動項目。該項目在GitHub目前已累計49.5k+ Star。其核心技術靈感源自作業系統虛擬記憶體分頁機制。此前LLM服務系統因採用連續記憶體儲存KV快取，導致內部/外部碎片化嚴重，且無法有效共用記憶體，極大限制了批處理規模。針對這一問題，團隊提出PagedAttention演算法，允許將連續的鍵（key）值（value）對儲存在非連續記憶體空間中，通過將KV快取劃分為固定大小的塊（Block），利用塊表動態對應邏輯塊與物理塊地址。在注意力計算過程中，PagedAttention核心會分別識別和獲取不同的KV塊。下面是一個示例，鍵和值向量分佈在三個塊中，且這三個塊在實體記憶體中並不連續。基於PagedAttention演算法，團隊建構了vLLM服務系統，其架構下圖所示：vLLM採用集中式調度器來協調分佈式GPU工作節點的執行。借助PagedAttention，KV快取管理器以分頁方式有效管理KV快取。具體而言，KV快取管理器通過集中式調度器傳送的指令來管理GPU工作節點上的物理KV快取記憶體。vLLM實現了KV快取記憶體近乎零浪費，請求內及請求間KV快取的靈活共享進一步降低記憶體使用。評估顯示，與FasterTransformer和Orca等此前最先進系統相比，vLLM在相同延遲水平下將流行LLM的吞吐量提升2-4倍，且在更長序列、更大模型和更複雜解碼演算法場景中改進更為顯著。總結來說，vLLM靈活且易於使用，具備以下特點：與流行的Hugging Face模型無縫整合，包括類Transformer模型、混合專家模型、嵌入模型、多模態模型；支援通過各種解碼演算法實現高吞吐量服務，包括平行採樣、波束搜尋等；支援張量平行和pipeline平行，以實現分佈式推理；支援流式輸出；相容OpenAI的API伺服器；支援NVIDIA GPU、AMD CPU和GPU、Intel CPU和GPU、PowerPC CPU、TPU以及AWS Neuron；支援前綴快取；支援多LoRA。值得一提的是，在實現層面，vLLM前端基於FastAPI，後端是基於GPU的推理引擎。vLLM引擎由8500行Python程式碼和2000行C++/CUDA程式碼構成。而這次DeepSeek研究員僅用不到1200行程式碼就實現了輕量級vLLM，性能和原版相媲美。參考連結：[1]https://github.com/GeeeekExplorer/nano-vllm/tree/main[2]]https://www.lamda.nju.edu.cn/yuxk/[3]https://arxiv.org/pdf/2309.06180[4]https://github.com/vllm-project/vllm (量子位)