96GB顯存AI深度體驗，Intel Arc Pro B60專業顯卡攪局者

引言：跨越三十年的獨顯遠征

在半導體發展的長河中，英特爾對獨立顯卡的執念可以追溯到上世紀 90 年代。從最初本打算切入 RISC 市場的 i860 但是最終作爲圖形工作站加速器，從 1998 年曇花一現的 i740，再到後來試圖通過多核心通用架構重塑圖形領域的 Larrabee 項目，英特爾經歷了無數次的探索與蟄伏。

直到 2018 年，代號 Arctic Sound 的現代獨立 GPU 計劃正式啓動，才真正開啓了 Xe 架構的紀元。

經過第一代 Alchemist（代號 DG2/Xe1）的“破冰”嘗試，英特爾在視頻編解碼和基礎光柵化領域站穩了腳跟。而今天，我們迎來了代號爲 Battlemage（代號 Xe2）的第二代圖形架構。如果說 Xe1 是英特爾獨顯的“初試啼聲”，那麼 Arc Pro B60 所承載的 Xe2 架構，則是其在圖形效能、AI 推理和專業工作流領域真正走向成熟的標誌。

Xe2 (Battlemage) 微架構深度剖析——精算的藝術

Xe2 架構並非簡單的規模擴大，而是從指令分發、矢量執行、光線追蹤到幾何剔除機制的全面重構。

XVE 矢量的革新：從 SIMD8 到原生 SIMD16

在 Xe1 架構中，英特爾的矢量引擎（XVE）主要基於 SIMD8 構建。雖然支持 co-issue（並行發射），但在處理高負載渲染任務時，硬件利用率仍有提升空間。 Xe2 架構實現了底層執行邏輯的飛躍：它將計算資源重新劃分爲原生的 SIMD16 指令寬度。這意味着單個指令可以同時處理 16 個數據元素，不僅提高了硬件的吞吐能力，更改進了工作分發（Work Distribution）的均衡性。

Xe2 的 “3 路並行發射”（3-way co-issue）機制讓內核能在一個時鐘週期內同時處理：

• 1 路浮點指令（FP）

• 1 路整數或擴展數學指令（INT/EM）

• 1 路 XMX AI 矩陣指令

這種設計讓 Xe2 在處理現代混合渲染負載（即同時涉及數學模擬、光柵化和 AI 增強）時，單核 IP 效能相較 Xe1 提升了 1.2x 至 12.5x 之多。

指揮權的移交：硬件原生 Execute Indirect

這是 Xe2 架構最具前瞻性的改進。在傳統 D3D11 或早期 D3D12 環境中，每一個繪製調用（Draw Call）或者說繪製任務都必須由 CPU 循環發出。如果場景中有成千上萬個物體，CPU 就會遇到極高的 CPU Overhead（遞交開銷）。

Xe2 架構通過硬件原生支持 Execute Indirect（間接執行）徹底改變了這一點。

間接執行實現原理並不複雜，它允許 GPU 從名爲 IAB（Indirect Argument Buffer）的顯存緩衝區中直接讀取繪製或分發參數，無需 CPU 事無鉅細地參與指令生成。

異步 GPU 剔除 (Asynch Culling)：配合異步計算，GPU 可以在正式繪製前自行判斷哪些三角形是不可見的（視錐體外、背面或被遮擋），並生成精簡後的索引緩衝區。

帶來的好處：這種“工作負載延遲決定（Defer the Workload）”的模式，對於擁有 100 到 200 個動態角色的複雜場景，能節省大量的冗餘計算，將每一份算力都精準花在最終的屏幕像素上。

光線追蹤單元 (RTU) “線程排序”

光線追蹤最大的敵人是“不確定性”——當光線撞擊不同物體反彈後，計算任務會變得極度碎片化，導致 GPU 的 SIMD 利用率直線下降。

Xe2 架構在第二代 RTU（光線追蹤單元）中引入了線程排序單元（TSU），能達到類似 NVIDIA SER 的效果。

TSU 能夠自動對發散的光線線程進行重新排列，將命中相似材質、執行相似代碼的線程湊在一起重新發射。配合每週期兩次三角形求交和 18 次包圍盒求交的高性能，Xe2 在專業可視化應用中的光線追蹤效率得到了質的提升。

Xe2 RTU 的 BVH Cache 也提升到了 16KiB，是上一代的兩倍。

Battlemage Arc Pro ：用盡顯存紅利！

Intel 在 2024 年 12 月 3 日正式發佈 Arc B 系列遊戲顯卡，型號包括 B580、B570，憑藉可以和 RTX 4060 一較高下的表現，產品成熟度已經獲得了不少好評，特別是光線追蹤性能較同級的 AMD 顯卡領先不少，成爲入門級性能顯卡的有力競爭者。

而 Arc Pro B 系列工作站顯卡則是 2025 年發佈，目前有兩款產品，分別是主要面向圖形工作站的 Arc Pro B50 和兼顧 AI 推理的 Arc Pro B60。

其中 Arc Pro B60 的 Intel 官方規格是單 GPU 版本，但是由於 Intel並不打算自己賣卡，所以大家看到的 Arc Pro B60 都是第三方廠家推出的，而且相對於單 GPU 版本，Intel 更鼓勵廠商推出雙 GPU 版本。

銘瑄 Arc Pro B60 DUAL 48 GB實測

我們這次借到的就是兩片雙 GPU 版本的銘瑄 Arc Pro B60 DUAL 48 GB，屬於目前 Battlemage 家族裏的最強檔，主要面向圖形、推理和邊緣工作站市場。

銘瑄這款 Arc Pro B60 DUAL 由兩個 B60 GPU 組成，每個 GPU 擁有 20 個 Xe2 內核（對應 NVIDIA SM）、160 個 XMX AI 引擎（對應 NVIDIA Tensor Core，Arc Pro B60 INT8 張量性能可達到 197 PFLOPS）、20 個光線追蹤單元（RTU），擁有 192-bit 內存總線（每個 GPU 有 24GB 顯存，合計 48GB 顯存），集成了兩個 MFX 視頻編解碼器，PCIE 規格爲 PCIE Gen5*8。

爲了便於在對流環境相對較差的多卡工作站裏安裝，銘瑄 Arc Pro B60 採用了雙槽散熱器+鼓風機主動散熱方式，卡體長度尺寸爲 300mm。

銘瑄標註的單卡（雙 GPU） TBP 值爲 400 瓦，雙卡（4 GPU）的話可以部署 Deepseek-R1 Llama 70B FP8 量化版模型，能支持超長上下文。

顯示輸出方面提供了兩個 DP 2.1 UHBR20 和兩個 HDMI 2.1a，可以滿足工作站顯示輸出需求，單根線纜就能提供 8K60Hz HDR 顯示輸出或者同時驅動三臺 4K60 HDR 顯示器。

如果只是作爲計算、渲染用途的話，銘瑄 Arc Pro B60 也支持無頭模式（不連接顯示器），可以在純文本啓動的 Linux 系統裏提供純粹的強大計算性能。

測試之前，有必要介紹一下測試平臺。這次下血本用上了旗艦配置的ThinkStation P7工作站，這套方案由聯想與阿斯頓馬丁聯合設計，工作站本身可以支持3張雙槽位渦輪風扇顯卡，因此裝下兩張銘瑄Intel Arc Pro B60 Dual毫無問題。只需要將末端的限位扣提起，裝入顯卡後再將限位扣壓緊，顯卡即可完成。

爲了釋放4個Intel Arc Pro B60 GPU全部性能，我們使用了一塊Intel Xeon W9-3495X搭配W790芯片組主板。

慣例先給大家數個框框。

得益於英特爾至強Sapphire Rapids CPU本身強大的擴展能力，我們將8個內存通道插滿，單條64GB DDR5-5600，8條共計512GB內存。再配合兩塊三星2TB SSD和一塊HDD，這套測試平臺時至今日已經悄咪咪的往20萬元的價格奔赴了。

來看看壯觀的內存條。

最後是在Windows 11環境下，安裝驅動後，4個Arc Pro B60 GPU被正確識別。有意思的是，雖然在BIOS中開啓了Resizable BAR，但是在Windows驅動中會有2個GPU的Resizable BAR被識別沒有被開啓，但在Ubuntu中沒有這個問題，因此不影響後續我們在Ubuntu中進行的測試。

流暢的開箱即用

軟件安裝

在軟件支持方面，Intel 目前提供了 LLM-Scaler 和 LLM-Scaler Omni，LLM-Scaler是英特爾提供的vLLM Serfving鏡像版本，和開源的vLLM Serving是統一的，是Intel針對生成式AI推理的性能優化解決方案。LLM-Scaler Omni是支持多模態模型的推理框架，也是LLM-Scaler發佈的另一個Docker鏡像。

LLM-Scaler 可以用於文本生成、圖形生成、視頻生成等應用，支持包括 vLLM、ComfyUI、SGLang Diffusion、Xinference 等常見的開源推理框架項目，確保 Intel Arc Pro B60 跑上述應用的時候提供最佳性能。

對於大部分 Intel Arc Pro 用戶來說，最簡單的方式就是使用容器來跑 vLLM。

首先是從 Intel RDC 網站上下載離線安裝器：https://cdrdv2.intel.com/v1/dl/getContent/871223/871005?filename=multi-arc-bmg-offline-installer-25.45.5.4.tar.xz

然後解開安裝包，用 root 權限執行裏面的 installer.sh。

完成安裝，重啓，之後可以嘗試執行 scripts/evaluation/platform_basic_evaluation.sh 來做初步的評估，確認完成軟件安裝。

之後我們可以嘗試運行一下下面這條 xpu-smi 指令作進一步確認：

大家可以看到，這條 xpu-smi 指令測試出來的 Arc Pro B60 單 GPU FP32 性能是 12.1 TFLOPS、內存帶寬是 440 GB/s、4K H.265 解碼性能是 160 fps、PCIE 總線帶寬未 27.5 GB/s、壓力測試下的功耗值未 129 瓦。

vLLM輕鬆駕馭

接下來就是執行 docker pull intel/llm-scaler-vllm:1.2，用於下載 LLM-scaler 對應的 vllm 1.2 版容器。

然後用下面的命令啓動容器：

sudo docker run -td \

--privileged \

--net=host \

--device=/dev/dri \

--name=lsv-container \

-v /home/intel/LLM:/llm/models/ \

-e no_proxy=localhost,127.0.0.1 \

-e http_proxy=$http_proxy \

-e https_proxy=$https_proxy \

--shm-size="32g" \

--entrypoint /bin/bash \

intel/llm-scaler-vllm:1.2

容器啓動後，可以 exit 退出，之後再進入的話可以用下面的命令重新進入容器：

docker exec -it lsv-container bash

進入容器後，我們的所有操作其實都和使用 CUDA 做 LLM 推理沒什麼差別了。

例如用下面的指令啓動 vLLM 服務：

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \

VLLM_WORKER_MULTIPROC_METHOD=spawn \

vllm serve \

--model /llm/models/DeepSeek-R1-Distill-Qwen-7B \

--served-model-name DeepSeek-R1-Distill-Qwen-7B \

--dtype=float16 \

--enforce-eager \

--port 8000 \

--host 0.0.0.0 \

--trust-remote-code \

--disable-sliding-window \

--gpu-memory-util=0.9 \

--no-enable-prefix-caching \

--max-num-batched-tokens=8192 \

--disable-log-requests \

--max-model-len=8192 \

--block-size 64 \

--quantization fp8 \

-tp=1 \

2>&1 | tee /llm/vllm.log > /proc/1/fd/1 &

啓動 vLLM 服務後，我們可以用下面的指令來做一個初步的測試：

vllm bench serve \

--model /llm/models/DeepSeek-R1-Distill-Qwen-7B \

--dataset-name random \

--served-model-name DeepSeek-R1-Distill-Qwen-7B \

--random-input-len=1024 \

--random-output-len=512 \

--ignore-eos \

--num-prompt 10 \

--trust_remote_code \

--request-rate inf \

--backend vllm \

--port=8000

這段代碼的意思就是使用輸入 1024 token、輸出 512 token 等條件進行 Deepseek R1 蒸餾版 Qwen 7B 模型的推理性能測試。

當然，這個指令是比較粗糙未完全優化的，它只啓用了 1 個 GPU、10 個提示詞請求，我們可以通過添加 -tp 4、增大 num-prompt 到 100 以及設置 fp8 量化等參數進行 4 GPU 以及更大提示詞請求規模的測試。

vLLM 多 GPU 性能實測：DeepSeek-R1-Distill-Qwen-7B

我們使用上面的指令作爲模板，使用大量不同的參數、推理模型進行了測試，得出了銘瑄 Intel Arc Pro B60 DUAL 48GB 在單卡、雙卡、四卡時的性能。

測試是啓用了 fp8 量化，不過因爲 Battlemage 缺乏硬件 fp8 支持，因此我們在這裏實際上是用 fp16 進行計算，fp8 量化此時的好處主要是節省內存、帶寬上。

從測試結果來看，

1、吞吐量（throughput）隨 np 增長的趨勢如下：

batch size 8192：

吞吐量增長更快，尤其在 tp=4 時，np=100 達到 2363.62。

batch size 4096：

吞吐量也隨 np 增長，但整體數值略低，np=100 時爲 2421.69，但增長曲線在 tp=4 時趨於平緩。

2、平均完成時間（mean_ttf）隨 np 增長的趨勢

batch size 8192：

平均完成時間增長更快，np=100 時達到 4703.63（tp=4）。

batch size 4096：

平均完成時間也增長，但整體略低，np=100 時爲 4730.36（tp=4）。

這說明 batch size 越大，單位時間內處理的數據越多，但也可能導致單次任務耗時更長。

根據測試結果，我們認爲對於這臺系統來說，如果需要高吞吐環境的話，可以設置 batchsize=8192，TP=4，如果是希望更好的服務響應，可以考慮設置爲 batchsize=4096 和 TP=2。如果希望均衡性能，最好是 batchsize=4096 和 TP=4。

vLLM 多 GPU 性能實測：GPT-oss-120b

gpt-oss-120b 是 openai 最新的開源語言模型，官方提供的版本是使用了 mxfp4 量化的，我們在這裏也使用 mxfp4，不過同樣因爲 Battlemage 缺乏 fp4 硬件支持，因此這裏的計算也是 fp16 實現的，不過模型佔用的空間和帶寬都因爲 mxfp4 的緣故會比較低。

我們這裏選擇了 batchsize=512 和 batchsize=8192 來展示，可以看到即使是啓用了 8192 token 的最大長度，在 number_prompt=20 時（20 個併發請求）的性能和 512 token 的時候相當（平均每個請求能獲得 15 token 的吞吐），之後也有 50% 以上的性能，考慮到這臺系統的配置，這個性能也是很不錯了。

增加 number_prompt 後的吞吐性能在 80 個後開始下降，這意味着對於 4 GPU B60 來說，運行 gpt-oss-120b 合理 np 值應該在 80 左右。

火力全開：ComfyUI Wan 2.2 多 GPU 文生視頻

Intel 也爲 LLM-Scaler-Omni 提供了容器鏡像，使用下面的指令就能拖拽下載：

docker pull intel/llm-scaler-omni:0.1.0-b5

創建容器：

sudo docker run -itd \

--privileged \

--net=host \

--device=/dev/dri \

-e no_proxy=localhost,127.0.0.1 \

--name=comfyui \

-v $MODEL_DIR:/llm/models/ \

-v $COMFYUI_MODEL_DIR:/llm/ComfyUI/models \

--shm-size="64g" \

--entrypoint=/bin/bash \

intel/llm-scaler-omni:0.1.0-b5

之後進入容器就是：

docker exec -it comfyui bash

執行下面的命令就能啓動容器內的 ComfyUI：

cd /llm/ComfyUI

python main.py --listen 0.0.0.0 --port 8188

之後就能在本地瀏覽器裏執行 127.0.0.1:8188 啓動 ComfyUI，你也可以透過 SSH、SSH+FRP 等方式遠程訪問。

我們的系統裏安裝了兩片銘瑄 Arc Pro B60 DUAL，合共 4 個 B60 GPU 和 96GB 顯存，ComfyUI 默認並不支持多 GPU 任務任務分派，需要額外的節點來實現，例如 LLM-Scaler-Omni 容器內自帶 Wan 2.2 工作流節點裏的 Raylight，就能支持多 GPU 並行計算加速，在 4 GPU 的時候能提高大約 25% 的性能。

下圖就是使用 Raylight 節點時候多 GPU 同時啓用的狀態圖。

由於需要透過 PCIE 5.0 X8 總線的 32GB/s 帶寬交換數據，所以在雙 GPU 的時候效率較低，性能會不如單 GPU，但是因爲分佈式池化，所以能裝進的模型權重還是要比單卡大。

實測結果如下：

在單 GPU 模式下，銘瑄 Arc Pro B60 DUAL 48GB 的耗時是 50.9 秒，雙 GPU 模式下是 57.4 秒，增加了大約 13%，在四 GPU 模式下時間縮短到了 41.1 秒，縮短了大約 19%。

SPECViewperf v15

Viewperf 是行業最重要的圖形工作站性能基準測試套件之一，包括 NVIDIA、AMD、Intel 等廠商都會在其官方文檔、發佈會上應用 SPECViewperf 測試成績，在企業採購中，該測試往往作爲重要的決策依據。

Viewperf v15 是 SPEC.org 2015 年發佈的最新版工作站圖形基準測試套件，包含了 Vulkan、D3D12、OpenGL 等多種 API 的工作站圖形負載軌跡，新增了多個項目，例如 Blender、Unreal 遊戲引擎、Enscape 建築可視化實時光線追蹤，傳統的 3ds Max、CATIA、Creo、Maya、SolidWorks 等工作站應用圖形軌跡也得到了更新。

測試使用的視口分辨率是 1920x1080，測試結果如上，數值就是各個項目的幾何平均幀率，測試過程非常流暢、穩定，未看到明顯的渲染瑕疵。

底層測試：海量的Cache/內存帶寬！

我用 Neme 的 Vulkan 底層測試工具進行了一些測試，包括時延、吞吐等，首先看看訪存時延：

我在這裏使用了 AD107（RTX 4060）作爲對比。

從測試結果看，Battlemage-G21(Arc Pro B60) 的 L1 Cache/SLM（Intel Xe 微架構裏的術語，等效於 CUDA 裏的 Shared Memory 或者 OpenCL 裏的 Local Memory）是在 256 KiB 處發生顯著躍升，符合其 L1 Cache 大小爲 256 KiB 大小的公開規格。

L2 Cache 階段在 16 MiB 處發生明顯躍升，略早於官方規格里的 18MiB。

AD107 在 L1 Cache 階段擁有更快的時延，但是在 L2 Cache 階段則更慢，而且 L2 Cache 發生躍升的位置（20 MiB）也只是在宣稱（48 MiB）的 L2 Cache 一半不到，在進入訪存階段後，B60 的訪存時延開銷要比對手高很多。

除了內存帶寬遠高於 AD107 外，Battlemage-G21 實測 28 GB/s 的 PCIE 總線帶寬也遠高於 AD107 的 13.2 GiB/s，在涉及 PCIE 總線的數據交換時 Arc Pro B60 的表現會更出色。

Arc Pro B60 擁有高很多的Cache/內存帶寬，這得益於它擁有 192-bit 內存總線，實測單 GPU 模式下內存帶寬達到了 422 GB/s，而對手 RTX 4060（GPU 內核代號 AD107，NVIDIA 採用 AD107 的專業卡爲 RTX 2000 Ada Generation）只有 128-bit 內存總線，實測內存帶寬是 248GB/s。

在浮點性能方面，Arc Pro B60 在 Vullan 下實測 fp32 fma 指令性能爲 12.3 TFLOPS，FP64 是 757.7 GFLOPS，作爲對比 RTX 4060 是 15.8 TFLOPS 和 265 GFLOPS，Arc Pro B60 因爲具備更強的內存帶寬，在性能平衡上一般會更好。

寫在最後：攪局者

回看這幾天的深度測試，Arc Pro B60 給我最深的感觸是：Intel 獨立顯卡已經脫離了“跑分好看”的初期階段，真正開始在專業工作流和 AI 大模型領域展現出**“攪局者”**的硬實力。

基於 Battlemage (Xe2) 架構的銘瑄 Arc Pro B60 DUAL，在 48GB 海量顯存和全新底層邏輯的加持下，爲開發者和專業用戶提供了一個極具性價比的“非綠”選項。

以下是我們對這款測試對象的深度覆盤：

1. 最大優勢：參數給得足夠“慷慨”

• 同級別配置下顯存帶寬與位寬的降維打擊。在同級別定位中，對手（例如 RTX 2000 Ada Generation）往往在顯存位寬上顯得吝嗇，而 B60 憑藉 192-bit 內存總線，實測內存帶寬高達 422 GB/s，幾乎是競品 AD107（RTX 4060）的兩倍。這種大帶寬在處理大模型推理和高分辨率渲染時，能夠提供更穩健的性能下限。