NVIDIA Grace Blackwell 與 vLLM 推理效能探討

雖然不少網上測試認為PGX Spark可支援每秒300 Tokens速度，我們使用兩部ASUS Ascent GX10桌上型AI超級電腦進行測試。這平台與NVIDIA DGX Spark完全一致，同樣使用NVIDIA的GB10 Grace Blackwell晶片。

首先，若以PGX Spark作推理用途，採用Ollama推理框架會出現速度慢、性能大打折扣的問題。Ollama雖然使用相容OpenAI的API，但有不少限制，例如工具調用等方面。

Grace Blackwell晶片是NVIDIA工業級晶片。利用Mac Studio跑Ollama其實沒有參考價值，而Ollama（或依靠llama.cpp的推理工具）也難以負載超大型LLM，例如支援MoE、達1200億參數的gpt-oss-120。只有工業級vLLM配合PageAttention優化，才能在Grace Blackwell晶片上極致發揮推理速度。

問題是vLLM在管理記憶體上必須非常審慎。即使是經量化的模型，如果屬於SOTA級別，同機也只能支援一個，否則只能縮小Context window來減低記憶體消耗。

不少評論吹捧Grace Blackwell速度，但以單機安裝而言，頂多只能體驗單一模型每秒輸出的Tokens量。單機Grace Blackwell晶片可用記憶體只有119GB，只能安裝gpt-oss-120b。如果再加上其他LLM，Context必須下降。我們在單機上安裝vLLM，同時安裝gpt-oss-120和Qwen2.5-coder-32b時，Context必須降至32K和16K，速度和性能大為下降。上述兩個LLM已佔用103.5GB，而32K和16K的Context也難以應付主要工作。

現時Context windows（上下文視窗）對推動工作極為重要。16K長度只能算是「非常勉強」——即使Qwen2.5-coder-32b支援最大120kContext，編程時遇上大文件也是左支右絀。

GX Spark支援RDMA（Remote Direct Memory Access），因此兩部電腦的GPU可合二為一。使用RDMA over Converged Ethernet（RoCE），兩部電腦可通過高速線纜連接GPU。底層使用NVIDIA GPU的計算框架CUDA，通過NCCL（NVIDIA Collective Communications Library）分散式通信庫，專門處理GPU之間（單機多卡/跨節點多卡）的高速資料傳輸。支援NCCL的CUDA意味著CUDA能調用NCCL的優化能力，GPU間的通信效率極大提升。對於建立GPU集群（張量並行/分散式訓練），支援NCCL的CUDA在推理和訓練都跑得更快，而且一加一大於二，速度比單一台更快。

我們採用華碩Ascent GX10，內置NVIDIA ConnectX-7（CX-7）網絡介面。華碩借出QSFP112接線，連接兩部Ascent GX10，才能以全速執行推理工作。

vLLM在兩個節點上執行，必須使用Ray Cluster（Ray framework）。Ray不是由NVIDIA開發，而是由加州大學柏克萊分校的RISE Lab開發的開源框架，但與NVIDIA關係密切。在跨節點（多機）場景下，Ray是vLLM實現張量並行（Tensor Parallelism, TP）多節點的標準原生方式。vLLM的「原生PyTorch TP」（僅tensor-parallel-size）只適用於單節點內的多GPU。Ray是vLLM官方為多節點分散式場景設計的核心依賴，負責跨節點資源管理、GPU調度、節點間通信橋接，以及管理節點之間的NCCL通信。

Ray Cluster的核心是支援Tensor Parallelism（TP）。如果有兩個節點，Ollama的Cluster不支持TP——因此無法將一個LLM切分到兩個GPU上運行，只能每個節點跑完整模型。換句話說，同一應用每次只能用一個GPU，採用Round Robin方式，速度完全沒有改善。

NVIDIA網站上有介紹如何安裝vLLM，但Spark整合了ARM處理器，相容性已有不少問題。尤其vLLM在網絡配置方面，部分模型需要配置自己的Tokenizer。例如gpt-oss-120就必須到OpenAI的OpenLab下載Tiktoken。gpt-oss-120開放了權重，但Spark只處理分散式資料集（如DataFrame、RDD），而非內置LLM權重的管理邏輯。ASUS Ascent GX10 Spark使用gpt-oss-120，需要通過PySpark調用PyTorch/TensorFlow等深度學習框架載入模型。gpt-oss-120支援不同精度權重（FP16/INT8/INT4），模型開發者會將權重拆分為多個分片檔（按層拆分的shard-00001.safetensors、shard-00002.safetensors），需經過檔定義讓Spark正確拼接、載入完整權重。

NVIDIA在推理性能的Token輸出量有很大分別。據官方解釋，根據LLM量化方式而有不同。GB10執行AWQ 4-bit比NVFP4/MXFP4更佳。部分報告更指在MXFP4精度下，vLLM比另一種推理框架SGLang慢。不過vLLM可支援多節點的分佈式部署，通過Ray在多節點上部署Tensor parallelism，因此我們只安裝vLLM。

gpt-oss-120在vLLM也有其他問題，例如經lm_head輸出成文字之前，LLM使用MXFP4格式時，會先轉換成FP32格式。模型最後一步的輸出層被強制換成高精度計算，拖慢整體速度。所以vLLM在優化後，性能應是兩上層樓。

我們在此向ASUS團隊在推理測試過程中的協助，我們ASUS Ascent GX10會用在訓練用途，但是我們相信不少Spark仍是以推理為主，即使是兩部ASUS Ascent GX10，以成本和用電，加上保護私隱考慮，相信還是物有所值。