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

在半導(dǎo)體發(fā)展的長河中，英特爾對獨立顯卡的執(zhí)念可以追溯到上世紀 90 年代。從最初本打算切入 RISC 市場的 i860 但是最終作為圖形工作站加速器，從 1998 年曇花一現(xiàn)的 i740，再到后來試圖通過多核心通用架構(gòu)重塑圖形領(lǐng)域的 Larrabee 項目，英特爾經(jīng)歷了無數(shù)次的探索與蟄伏。

直到 2018 年，代號 Arctic Sound 的現(xiàn)代獨立 GPU 計劃正式啟動，才真正開啟了 Xe 架構(gòu)的紀元。

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

Xe2 (Battlemage) 微架構(gòu)深度剖析——精算的藝術(shù)

Xe2 架構(gòu)并非簡單的規(guī)模擴大，而是從指令分發(fā)、矢量執(zhí)行、光線追蹤到幾何剔除機制的全面重構(gòu)。

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

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

Xe2 的 “3 路并行發(fā)射”（3-way co-issue） 機制讓內(nèi)核能在一個時鐘周期內(nèi)同時處理：

? 1 路浮點指令（FP）

? 1 路整數(shù)或擴展數(shù)學(xué)指令（INT/EM）

? 1 路 XMX AI 矩陣指令

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

指揮權(quán)的移交：硬件原生 Execute Indirect

這是 Xe2 架構(gòu)最具前瞻性的改進。在傳統(tǒng) D3D11 或早期 D3D12 環(huán)境中，每一個繪制調(diào)用（Draw Call）或者說繪制任務(wù)都必須由 CPU 循環(huán)發(fā)出。如果場景中有成千上萬個物體，CPU 就會遇到極高的 CPU Overhead（遞交開銷）。

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

間接執(zhí)行實現(xiàn)原理并不復(fù)雜，它允許 GPU 從名為 IAB（Indirect Argument Buffer）的顯存緩沖區(qū)中直接讀取繪制或分發(fā)參數(shù)，無需 CPU 事無巨細地參與指令生成。

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

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

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

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

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

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

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

Battlemage Arc Pro ：用盡顯存紅利！

Intel 在 2024 年 12 月 3 日正式發(fā)布 Arc B 系列游戲顯卡，型號包括 B580、B570，憑借可以和 RTX 4060 一較高下的表現(xiàn)，產(chǎn)品成熟度已經(jīng)獲得了不少好評，特別是光線追蹤性能較同級的 AMD 顯卡領(lǐng)先不少，成為入門級性能顯卡的有力競爭者。

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

其中 Arc Pro B60 的 Intel 官方規(guī)格是單 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 內(nèi)核（對應(yīng) NVIDIA SM）、160 個 XMX AI 引擎（對應(yīng) NVIDIA Tensor Core，Arc Pro B60 INT8 張量性能可達到 197 PFLOPS）、20 個光線追蹤單元（RTU），擁有 192-bit 內(nèi)存總線（每個 GPU 有 24GB 顯存，合計 48GB 顯存），集成了兩個 MFX 視頻編解碼器，PCIE 規(guī)格為 PCIE Gen5*8。

為了便于在對流環(huán)境相對較差的多卡工作站里安裝，銘瑄 Arc Pro B60 采用了雙槽散熱器+鼓風(fēng)機主動散熱方式，卡體長度尺寸為 300mm。

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

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

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

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

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

慣例先給大家數(shù)個框框。

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

來看看壯觀的內(nèi)存條。

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

流暢的開箱即用

軟件安裝

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

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

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

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

然后解開安裝包，用 root 權(quán)限執(zhí)行里面的 installer.sh。

完成安裝，重啟，之后可以嘗試執(zhí)行 scripts/evaluation/platform_basic_evaluation.sh 來做初步的評估，確認完成軟件安裝。

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

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

vLLM輕松駕馭

接下來就是執(zhí)行 docker pull intel/llm-scaler-vllm:1.2，用于下載 LLM-scaler 對應(yīng)的 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 服務(wù)：

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 服務(wù)后，我們可以用下面的指令來做一個初步的測試：

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 模型的推理性能測試。

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

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

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

測試是啟用了 fp8 量化，不過因為 Battlemage 缺乏硬件 fp8 支持，因此我們在這里實際上是用 fp16 進行計算，fp8 量化此時的好處主要是節(jié)省內(nèi)存、帶寬上。

從測試結(jié)果來看，

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

batch size 8192：

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

batch size 4096：

吞吐量也隨 np 增長，但整體數(shù)值略低，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 越大，單位時間內(nèi)處理的數(shù)據(jù)越多，但也可能導(dǎo)致單次任務(wù)耗時更長。

根據(jù)測試結(jié)果，我們認為對于這臺系統(tǒng)來說，如果需要高吞吐環(huán)境的話，可以設(shè)置 batchsize=8192，TP=4，如果是希望更好的服務(wù)響應(yīng)，可以考慮設(shè)置為 batchsize=4096 和 TP=2。如果希望均衡性能，最好是 batchsize=4096 和 TP=4。

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

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

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

增加 number_prompt 后的吞吐性能在 80 個后開始下降，這意味著對于 4 GPU B60 來說，運行 gpt-oss-120b 合理 np 值應(yīng)該在 80 左右。

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

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

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

創(chuàng)建容器：

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

執(zhí)行下面的命令就能啟動容器內(nèi)的 ComfyUI：

cd /llm/ComfyUI

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

之后就能在本地瀏覽器里執(zhí)行 127.0.0.1:8188 啟動 ComfyUI，你也可以透過 SSH、SSH+FRP 等方式遠程訪問。

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

下圖就是使用 Raylight 節(jié)點時候多 GPU 同時啟用的狀態(tài)圖。

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

實測結(jié)果如下：

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

SPECViewperf v15

Viewperf 是行業(yè)最重要的圖形工作站性能基準測試套件之一，包括 NVIDIA、AMD、Intel 等廠商都會在其官方文檔、發(fā)布會上應(yīng)用 SPECViewperf 測試成績，在企業(yè)采購中，該測試往往作為重要的決策依據(jù)。

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

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

底層測試：海量的Cache/內(nèi)存帶寬！

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

我在這里使用了 AD107（RTX 4060）作為對比。

從測試結(jié)果看，Battlemage-G21(Arc Pro B60) 的 L1 Cache/SLM（Intel Xe 微架構(gòu)里的術(shù)語，等效于 CUDA 里的 Shared Memory 或者 OpenCL 里的 Local Memory） 是在 256 KiB 處發(fā)生顯著躍升，符合其 L1 Cache 大小為 256 KiB 大小的公開規(guī)格。

L2 Cache 階段在 16 MiB 處發(fā)生明顯躍升，略早于官方規(guī)格里的 18MiB。

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

除了內(nèi)存帶寬遠高于 AD107 外，Battlemage-G21 實測 28 GB/s 的 PCIE 總線帶寬也遠高于 AD107 的 13.2 GiB/s，在涉及 PCIE 總線的數(shù)據(jù)交換時 Arc Pro B60 的表現(xiàn)會更出色。

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

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

寫在最后：攪局者

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

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

以下是我們對這款測試對象的深度復(fù)盤：

1. 最大優(yōu)勢：參數(shù)給得足夠“慷慨”

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

? PCIe 5.0 的超前部署：實測 28 GB/s 的 PCIe 總線帶寬遠超對手，這在頻繁進行多卡數(shù)據(jù)交換或大規(guī)模紋理加載時，優(yōu)勢極其明顯。

? 軟件生態(tài)的“拎包入住”：相比于 RoCM 依賴包的“散裝”現(xiàn)狀，Intel 提供的 LLM-Scaler 解決方案更加整體化。通過容器化部署 vLLM，開發(fā)者可以幾乎零成本地從 CUDA 遷移到 Xe 架構(gòu)上，實現(xiàn)了真正的“開箱即用”。

2. 現(xiàn)存不足：細節(jié)之處仍有遺憾

? 硬件級低精度計算缺失： Battlemage 架構(gòu)在指令集上非常先進，但它的 XMX內(nèi)核缺乏硬件級的 FP8 和 FP4 支持。雖然能通過 FP16 模擬實現(xiàn) DeepSeek-R1 或 GPT-oss-120b 的運行，但在追求極致算力的場景下，模擬計算依然難以完全發(fā)揮架構(gòu)潛力。

? 訪存時延開銷較高：底層測試顯示，B60 在進入顯存訪存階段后的時延明顯高于對手，這反映出其底層內(nèi)存控制器的調(diào)教仍有精進空間。

? 多卡互聯(lián)的物理瓶頸：由于 B60 不支持物理 Xe-Link 接口，多 GPU 協(xié)同只能依賴 PCIe 總線。在運行如 Raylight 這種分布式切分模型時，數(shù)據(jù)同步的開銷限制了多卡擴展的效率。

展望：Intel 獨顯的“成熟期”將至

Arc Pro B60 的表現(xiàn)證明了 Xe2 架構(gòu)在 SIMD16 原生指令寬度和“硬件原生間接執(zhí)行”等設(shè)計上的前瞻性。它不僅在 SPECViewperf 傳統(tǒng)的專業(yè)制圖測試中表現(xiàn)穩(wěn)健，更在 DeepSeek 等 AI 浪潮中找到了自己的生態(tài)位。

對于工作站用戶來說，B60 的出現(xiàn)最大的意義在于提供了一個成熟的選擇。 隨著未來驅(qū)動程序的進一步迭代，以及如果能在后續(xù)型號中補齊硬件級 FP8 加速，英特爾極有可能在專業(yè)計算市場實現(xiàn)真正的“跨越式遠征”。

隨著Arc Pro B60陸續(xù)登陸授權(quán)經(jīng)銷電商平臺，如果你需要一個大顯存、高帶寬且軟件支持直觀的 AI 推理或圖形渲染平臺，銘瑄、藍戟推出的這款 48GB “雙芯怪獸”無疑是目前市場上最值得關(guān)注的變數(shù)。

本文感謝原 PCPOP/顯卡之家主筆Edison Chen的鼎力支持，在平臺搭建和測試過程中，筆者受益匪淺，如有興趣，請訪問Edison Chen的知乎主頁：

https://www.zhihu.com/people/edison-chan-24