几个月前,我们评测了蓝戟 Arc Pro B70 显卡,这张显卡用的是满血版的 BMG-G31 核心,32 个 Xe2-core。然后 BMG-G31 其实还有另一个版本,20 个 Xe2-core 的,型号是 Arc Pro B65。你也许注意到了 Arc Pro B60 也是 20 个——别单看数字做决定。Arc Pro B60 用的是 Arc B580 同款的 BMG-G21。这导致了显存上的差别,Arc B70 和 B65 都是 32GB GDDR6 显存,而 B60 是 24GB。不过它们的显存速度都是 19Gbps,只有 Arc Pro B50 在各方面上都是个例外。哦对,正如标题所示,今天我们评测的是 Arc Pro B65,差点忘记说了。
这一次的 Arc Pro B65 仍然来自英特尔锐炫显卡首家核心伙伴——蓝戟,相信大家已经很熟悉了。还有一件事必须要在开头说的是,这次我们有两张 B65,加起来总共 64GB 显存,这太棒了。考虑到我们目前并没有 HEDT 平台在手,这就是极限了。
显卡规格参数
型号 | 蓝戟 Intel Arc Pro B65 TF 32GB 专业显卡 |
核心 | BMG-G31 |
Xe2-core 数量 | 20 |
光刻类型 | 台积电 N5 |
显卡时钟频率 | 2400MHz |
GPU 性能 | Int8: 197TOPS |
显存大小 | 32GB GDDR6 |
显存速度 | 19Gbps |
显存位宽 | 256 bit |
显存带宽 | 608GB/s |
显示 | 3 个 DP2.1+1 个 HDMI2.1 |
PCI Express | 5.0 |
OpenGL | 4.6 |
TBP | 200W |
电源接口 | 2*8PIN |
尺寸 | 268*111.1*40.1MM |
编码 / 解码 | AV1,H.265,H.264,VP9 |
操作系统 | Windows 10/Windows 11/Linux |
超 能 网 制 作
既然 Arc Pro B65 和 Arc Pro B70 采用了同一颗核心,显存配置也相同,再加上专业级显卡的定位,这些要素共同构成了一个点,那就是 Arc Pro B65 的外观和我们早些时候评测过的 Arc Pro B70 不会有什么太大的变化:低调的原色牛皮纸盒、涡轮散热设计和方方正正的黑色外壳,供电接口也是双 8-pin,就是这样。
这两张卡在外观上如此高的一致性让我觉得实在没有什么重复叙述的需要,虽然为了填充字数我大可以直接借用一下 Arc Pro B70 的评测(反正也是本人写的),但真要这样做的话也未免过于不负责任了,所以还是请大家看看照片吧。老实说除了侧边的 B65 字样,你就找不到其他和蓝戟 Arc Pro B70 不同的点了——单凭数字的变动可以撑起的鸿篇巨制大概只有周年贺词,评测是做不到的。
测 试 配 置 | |
CPU | AMD 锐龙 9 9950X |
主板 | 微星 MEG X870E GODLIKE |
内存 | 芝奇皇家戟 DDR5-7200 CL36(24GB x2 ) |
显卡 | 蓝戟 Intel Arc Pro B65 TF 32GB 专业显卡 x2 |
硬盘 | 三星 990 Pro 1TB 金士顿 NV2 2TB |
散热器 | 雅俊 GRATIFY AIO 5 |
电源 | 海韵 Vertex PX-1200 青龙 | 1200W |
软件配置 | |
Microsoft Windows 11 25H2 / Ubuntu 24.04.4 | |
本文为蓝戟委托的技术验证测试 / 联合体验推广内容,测试过程执行超能网标准测试流程。
测试平台有一点点变动,主要还是主板方面的:开头我已经说了我们没有 HEDT 平台,因此目标就变成了一块有着两条 PCIe x16 全长插槽的主板,我选的是微星 MEG X870E GODLIKE,速度规格上,它的第一根插槽最高是 PCIe 5.0 x16,第二根则是 PCIe 5.0 x8,都来自 CPU。两根插槽满上的话,就平分 x16,都变成 PCIe 5.0 x8。
比较重大的变化是系统环境。我分别在 Windows 11 和 Ubuntu 下都进行了测试。其实就 AI 负载来说,Linux 的优先级肯定是要比 Windows 高的。只不过完全忽视 Windows 也不太好,总有人是用 Windows 的,对吧?而且 UL Procyon 的这些测试也没有 Linux 版本。
Windows 11 环境主要测试的是单显卡设置。当然,由于一张 Arc Pro B65 也有 32GB 显存,能做的事情还是不少的。举个例子,Qwen 3.8 27B 的 Q4_K_M 量化 gguf 肯定放得下,还能开 192K 上下文。
先来看经典的 UL Procyon 测试,虽然里面所用的模型都比较旧,但是它们毕竟是作为基准测试存在的,模型更新太快的话就失去基准的意义了。不过在这里可以倒是可以看出英特尔专用的 OpenVINO 和通用的 ONNX DirectML 运行时之间的效率差距。
接下来是 ComfyUI,这里有一个比较值得说的一点就是蓝戟不仅做了卡,还做了份指南文档,并把带 Intel XPU 加速的 ComfyUI 打包好了上传到网盘,这对于用户,特别是国内用户来说是个好事。毕竟配置环境确实很烦,就算交给 agent 做也耗 token,能开箱即用自然是最好的。不过如果网络条件允许的话,我建议还是直接去 ComfyUI 官网下载 ComfyUI Portable,有支持英特尔显卡的版本,也能够一键启动,下面的测试我就是用这个版本,因为诸如 Qwen Image 2.1 这些新模型还是要新版 ComfyUI 才能开得起来。
以 ComfyUI 官方的 Minimax H3 工作流(带 8 步加速 Lora)为例,我们生成一个 640 x 640 的 5 秒视频。如果在写好提示词的情况下,仅更改种子进行抽卡的话,每次生成大约需要用时 2 分半。如果更改提示词的话,因为 text encoder 部分要重新加载到显存里,所以耗时也会相应增长。通过更换量化版模型,是可以有进一步优化空间的,比如说这个 int8 的 text encoder 实在大了点,可以换成 q4 gguf 的。
新出的 Qwen Image 2.1 是图像生成和编辑模型,对于显卡的压力是比较小的,我们这里用的也是 ComfyUI 官方的工作流,一张图的生成速度在 45-46 秒。
最后是 LLM 运行,在这里我们选的是 Unsloth Desktop,它的推理引擎也是用的 llama.cpp,和 LM Studio 这些应用一样。模型则是 local AI 这边最近非常火热的 Qwen 3.8 27B,因为是单卡运行,所以我们选的是 UD-Q4_K_M 量化,其中 UD 指的是 Unsloth Dynamic v3.0 量化方法。
通过截图可以看到,Qwen 3.8 27B UD-Q4_K_M 的生成速度在 20-22token/s 左右。不过说真的,llama.cpp 的 vulkan 后端在 Arc Pro 上表现得不是很稳定(Arc Pro B70 的时候就这样了),偶尔会报设备错误。因此还是让我们快进到双显卡环节吧。
双显卡自然是 Linux,我们安装的发行版是 Ubuntu 24.04.4。和 NVIDIA 或者是 AMD 一样,英特尔也提供了 docker 镜像,名为 LLM Scaler,其中 LLM Scaler vLLM 是给文本生成用的,而 LLM Scaler Omni 是用于图像生成的,这点看名字就知道。
LLM Scaler vLLM docker 给你包完了
作为英特尔 Arc Pro 显卡的配套解决方案,LLM Scaler 拥有非常多的优点,除了开箱即用的多显卡支持、多模态模型支持这些个优点外,个人觉得比较值得说的就是这个 INT4 和 FP8 在线量化推理服务,以及对 FP8 模型的支持——先说后者,熟悉 Battlemage 架构的各位应该知道,这一代的 XMX 引擎并不原生支持 FP8,而 LLM Scaler 在软件层面实现了转换,也就是说,显存里面可以放 FP8 模型节约空间,跑的时候就按 BF16 去算。
前者呢则是可以让你下载 BF16 的模型,但是加载时实现转换,变成 FP8 或者 INT4 模型从而降低显存占用,非常方便。我们会通过 gemma-4-26B-A4B-it 这一个模型去展现这点。
先来看最近非常火热的 Qwen3.8-27B-FP8,它是被测的三个模型里唯一的 dense 模型,权重大小约为 30GB,摊到两张卡上各约 15GB,显存毫无压力,因此上下文可以开得更长一些。单人用时,每生成一个 token 要 18.5 毫秒,合每秒 51 个 token。这个数字之所以低,是因为 dense 模型每生成一个字都必须把 27B 权重完整地从显存里读一遍,单条序列的访存请求根本填不满两张卡的带宽,硬件绝大部分时间在等数据。随着并发数的上升,输出速度和延迟也随之上升了,而 16 并发看起来是个不错的选择,每人 21.9 token/s,到 32 人就掉到 13 token/s 了。
因为 Qwen 还没有开源他们最新的 35B-A3B 模型,所以我们就只能用早前的版本,也就是 Qwen3.6-35B-A3B-FP8 来测试 Arc Pro B65 运行 MoE 模型的表现了。和 27B 勉强能用 BF16 权重不同,35B 的 BF16 版本体积来到了 72GB 左右,两张卡放不下。性能方面,因为是 MoE 模型,每 token 只激活约 3B,输出速度和每字延迟自然要比 dense 模型好上不少——单用户就能跑到 144 token/s,每字延迟在 6.09 毫秒。而且就算是 32 并发,每人还能分到 23 token/s,这速度对于 local AI 来说仍然是可以接受的,延迟也在 38.04 毫秒。
gemma-4-26B-A4B-it 的 BF16 权重大小约为 52GB,塞入这两张卡里面也勉勉强强。通过 llm-scaler 的在线量化,模型本身的体积可以压到 24GB。和 Qwen3.6-35B-A3B-FP8 一样,这个模型在两张 Arc Pro B65 上的速度也是比较快的,单人使用时 80 token/s、每字 12.09 毫秒;一路加到 32 并发,总速度来到 532 token/s,大概是每人 16.6 token/s,总的来说,16 并发及以下是舒适区,和 Qwen3.8-27B-FP8 有点像。至于说 BF16 转 FP8,FP8 又转 BF16 中间有多少性能损耗,这是个值得思考的问题,但是从易用性这个角度上去说的话,我觉得 llm-scaler 这套还是很值得用的,再说了,如果真要追求吞吐量和延迟,llm-scaler 还提供了 INT4 在线量化呢。
对于 Local AI 来说,显存有多重要估计是不用我多说了,在游戏看来相当够用的 16GB,对于 AI 来说还真不算什么——在本地部署这块,VRAM 越大越好总是没错的,毕竟就算 GPU 核心性能再强,显存放不下的话处理就是比较麻烦。而蓝戟 Arc Pro B65 同时具有两个很吸引人的特性:第一,它的单卡显存达到 32GB,而且是 19Gbps 的 GDDR6;第二,和显存规格接近的显卡相比,它在售价上非常有竞争力,电商平台上才 8999 元,对于多卡平台而言,可以说数量越多性价比越有。
当然,硬件是一回事,有没有配套的软件支持也是很重要的一点。在测试中,我能感受到英特尔的 llm-scaler 确实足够易用。之前我在 NVIDIA 平台怎么操作的 vLLM,现在在英特尔平台上就怎么操作,顶多改点参数,不用再大改些什么,这是不错的。对于 FP8 这些主流格式的支持也到位,直接扔进去就能跑,而不用关心它是怎么转换的,也是值得称赞的一点。
本次用到的测试脚本:https://github.com/1oogiraffe/lsv-b65-scripts
LLM Scaler 文档:https://github.com/intel/llm-scaler/blob/main/vllm/README.md
最后,我把本次用到的 docker 和 vllm 测试脚本放到 GitHub 了,有需要的各位可以自取,或者在此基础上让 agent 捏一个更好的 ...
本次测试结果仅对本次样品负责,无法保证其它市售商品都能达到完全一致的表现,产品在生命周期内可能会因供应链变动而调整元器件,不自动延展适用于该型号未来可能出现的改款或变动批次。
超能网公众号
扫码关注我们,浏览热门硬件评测
随时查看最新天梯榜


登录后才可以发布评论哦
打开小程序可以发布评论哦