使用 vLLM 在 Intel Arc Pro B 系列 GPU 上快速且经济地部署 LLM 服务
英特尔® Arc™ Pro B 系列 GPU 产品家族 提供强大的 AI 功能，重点在于易用性和出色的性价比。其大容量内存和多 GPU 设置的可扩展性，使得在本地运行最新的大型高性能 AI 模型成为可能，从而让专业人士无需承担 AI 硬件通常的高昂成本，即可部署大语言模型（LLM）。
vLLM 是实现英特尔 Arc Pro B 系列 GPU 上快速且高性价比 LLM 服务的软件栈核心。在过去几个月中，英特尔开发人员一直与 vLLM 社区积极合作，启用并优化关键功能，确保在英特尔 Arc Pro B 系列 GPU 上通过多 GPU 扩展和 PCIe P2P 数据传输实现无缝性能表现。
英特尔® Arc™ Pro B 系列 GPU 为 vLLM 提供了关键功能和优化，包括：
- 为 DeepSeek 蒸馏 Llama/Qwen 模型提供稳健的推理性能
- 支持长上下文（>50K），且在批处理规模上具有良好的扩展性
- 支持 Embedding、Reranker 和 Pooling 模型
- 支持多模态模型
- 深度优化混合专家（MoE）模型（GPT-OSS、DeepSeek-v2-lite、Qwen3-30B-A3B 等）
- 逐层在线量化以减少所需的 GPU 内存
- 支持数据并行、张量并行和流水线并行
- 支持 Torch.compile 的 FP16 和 BF16 路径
- 支持 n-gram、EAGLE 和 EAGLE3 方法的投机采样（Speculative Decoding）
- 异步调度
- Prefill/Decode 分离
- 低秩自适应（LoRA）
- 推理输出（Reasoning output）
- 睡眠模式
- 结构化输出
- 工具调用（Tool calling）
- 混合精度支持，涵盖 BF16、FP16、INT4 和 FP8 vLLM 方案
针对 MoE 模型的深度优化
混合专家（MoE）是一种模型架构，它通过多个专门的专家网络协作来处理输入序列，并由门控机制进行引导。对于输入序列中的每个 token，门控网络会动态选择处理该 token 的专家子集。MoE 架构没有依赖于单个密集的反馈层，而是采用跨专家网络并行分布的多个 GEMM 操作来达到同等的计算功能。这种设计为模型引入了结构化稀疏性，因为对于任何给定的输入，只有一部分专家被激活，从而在保持模型容量的同时提高了计算效率。除了针对通用矩阵乘法（GEMM）和 Flash Attention 的常规优化外，这些 MoE 组件（专家和门控网络）是 MoE 类语言模型中关键的性能贡献者。
然而，简单的 MoE GEMM 操作实现可能会面临严重的效率瓶颈。传统的做法是在 for 循环的每次迭代中顺序启动各个 GEMM 内核，这会产生过多的内核启动开销并引入大量的调度延迟。此外，由于专家路由决策是由门控网络产生的，GEMM 操作必须等待门控计算完成后才能开始执行。这种数据依赖性会导致流水线停顿，从而干扰内核执行流并严重限制 GPU 并行度，阻碍了设备的最佳利用。
针对 MoE GEMM 的这些限制，我们设计了一种持久化的零间隙内核，在英特尔® Arc™ Pro B60 GPU 上实现了超过 80% 的硬件能力利用率。
优化 1. 在持久循环中启动单个内核
单内核设计消除了上述的启动和调度开销。此外，持久化循环消除了对依赖于专家路由网络结果的启动参数的需求，这有助于保持最大的设备并行度。
英特尔® Arc™ Pro B60 GPU 拥有 20 个 Xe 核心，每个核心拥有相同的资源，可以承载多个 SYCL 组。在我们的设计中，每个 Xe 核心启动两个组，以平衡计算和内存带宽需求。
优化 2. 计算组的动态负载均衡
一个观察结果是，由于专家路由的不平衡，每个组运行的工作量不同。如果一个组循环执行固定步长的工作，总会有一个组承担最大的工作量，而另一个承担最小的工作量。它们之间的差距将累计达到 MoE GEMM 总时间的 15%。更好的替代方案是让任何在一个循环中完成任务的组，在下一个循环中立即开始执行可用的任务。举个具体的例子，有 40 个组要处理 200 个 GEMM 块，静态步长会导致组 0 循环处理 0、40、80……，组 1 循环处理 1、41、81 等。一个需要注意的问题是，由于 MoE 的特性，每个 GEMM 块的计算强度可能不同。此外，随机的访问模式会让某些组比其他组更快地完成工作。这种方式限制了效率，因为那些总是较早完成工作的组无法帮助那些总是遇到繁重负载的组。
| 之前 | 之后 |
|---|---|
 |  |
我们通过让每个组通过原子编号竞争下一个任务来缓解这种影响。无论谁完成了一个 GEMM 块的计算，都会从原子编号中获得一个序列号，该编号决定了它将处理哪一个后续块。在这种情况下，我们消除了内核循环中的小间隙，并在各种专家路由场景下实现了完美的调度。
优化 3. 快速 MXFP4 转 BFLOAT16 算法，并配合预打包（Prepack）提升内存加载效率
众所周知，预打包（Prepacking）可以提高内存加载效率。在我们的案例中，对于 4 位内存加载，采用硬件友好的格式可以将效率提高多达 30%。此外，简单的 FP4 转 BF16 会产生过多的指令，因此需要更好的替代方案（借鉴 oneDNN，在单精度 E/M 位置上对 E2M1 编码进行位移，并乘以两种类型之间的比例差异）。
Bitcast-bf16 ((x << 12) >> 6 & 0x81c0) * 2^126
该解决方案最大限度地减少了将 fp4 转换为 bf16 所需的指令。
性能
凭借 24GB 高带宽 VRAM、456 GB/s 内存带宽和 160 个英特尔® Xe 矩阵扩展（Intel® XMX）AI 引擎，英特尔 Arc Pro B 系列 GPU 为 vLLM 上的高负荷模型优化提供了出色的硬件能力。完整的支持模型列表可在 intel/ai-containers 找到。
从 8B 到 70B 大小的 DeepSeek 蒸馏模型在配置了八块英特尔® Arc™ Pro GPU 的系统上进行了优化，可获得良好的输出 token 吞吐量。
图 1：在配置了 8 块英特尔® Arc™ Pro B60 GPU 卡的系统上，在 SLA 下具有最大并发度的 FP8 模型输出 token 吞吐量。
该系统在良好的并发负载下可维持低于 100 ms 的下一个 token 延迟。
图 2：在配置了 4 块英特尔® Arc™ Pro B60 GPU 卡的系统上，Qwen-32B 模型随着提示词数量增加的下一个 token 延迟。
该模型的推理在 1K 到超过 40K token 的广泛输入序列长度范围内，保持了一致的下一个 token 延迟。这种性能得益于高度优化的 Flash Attention 内核，它在序列长度维度上实现了操作并行化。
图 3：在配置了 8 块英特尔® Arc™ Pro B60 GPU 卡的系统上，llama-70B 单批次长上下文输入（1K 至 40K 序列）的 TTFT/TPOT 表现。
GPT-OSS：英特尔® Arc™ Pro B60 GPU 在 OpenAI 最近推出的 GPT-OSS 模型上也展现了卓越的性能，为开发人员和企业提供了一种强大的、高性价比的大规模 AI 推理解决方案，如下表所示。
| 模型 | 数据类型 | TP (张量并行) | 输入/输出序列长度 | 并发数 | TTFT (秒) | TPOT (毫秒) | 输出 Token 吞吐量 (toks/s) |
|---|---|---|---|---|---|---|---|
| GPT-OSS-20b | MXFP4 | 1 | 1024/1024 | 75 | 7.614 | 53.96 | 1210.74 |
| GPT-OSS-20b | MXFP4 | 1 | 2048/2048 | 38 | 7.823 | 42.35 | 818.92 |
| GPT-OSS-20b | MXFP4 | 1 | 5120/5120 | 15 | 8.36 | 34.27 | 416.94 |
| GPT-OSS-120b | MXFP4 | 4 | 1024/1024 | 100 | 8.04 | 58.78 | 1495.12 |
| GPT-OSS-120b | MXFP4 | 4 | 2048/2048 | 50 | 8.11 | 41.98 | 1085.58 |
| GPT-OSS-120b | MXFP4 | 4 | 5120/5120 | 20 | 8.60 | 30.60 | 619.10 |
表 1：在 x8 英特尔® Arc™ Pro B 系列系统上使用 1-4 块 GPU 进行 GPT-OSS vLLM 推理的吞吐量。
MLPerf：英特尔 Arc Pro B 系列 GPU 在最近发布的 MLPerf Inference v5.1 结果中表现出色（链接）。在 Llama 8B 测试中，英特尔® Arc™ Pro B60 GPU 展示了每美元性能优势。这些结果均使用 vLLM 作为服务框架实现。
如何设置
支持英特尔 XPU 的 vLLM Docker 镜像可从 intel/vllm - Docker 镜像 | Docker Hub 下载。自 vllm 0.10.2 Docker 版本起，支持像 gpt-oss 这样的 MoE 模型。以下示例要求：主机操作系统为 Ubuntu 25.04，KMD 驱动程序为 6.14.0，运行在配置了 4 块插在 PCIe 插槽上的英特尔® Arc™ Pro B60 GPU 卡的至强（Xeon）系统上。
使用以下命令获取发布的 Docker 镜像
docker pull intel/vllm:0.10.2-xpu使用以下命令实例化一个 Docker 容器
docker run -t -d --shm-size 10g --net=host --ipc=host --privileged -v /dev/dri/by-path:/dev/dri/by-path --name=vllm-test --device /dev/dri:/dev/dri --entrypoint= intel/vllm:0.10.2-xpu /bin/bash在 4 块英特尔® Arc™ Pro B60 卡上运行带有 gpt-oss-120b 的 vLLM 服务器
vllm serve openai/gpt-oss-120b --dtype=bfloat16 --enforce-eager --port 8000 --host 0.0.0.0 --trust-remote-code --gpu-memory-util=0.9 --no-enable-prefix-caching --max-num-batched-tokens=8192 --disable-log-requests --max-model-len=16384 --block-size 64 -tp 4启动另一个 shell 并运行基准测试
vllm bench serve --model openai/gpt-oss-120b --dataset-name sonnet --dataset-path="./benchmarks/sonnet.txt" --sonnet-input-len=1024 --sonnet-output-len=1024 --ignore-eos --num-prompt 1 --trust_remote_code --request-rate inf --backend vllm --port=8000 --host 0.0.0.0更多已验证的支持模型列表可在此处找到：支持的模型
展望未来
我们致力于加深我们的优化与 vLLM 核心项目之间的集成。我们的路线图包括：全面支持上游 vLLM 功能，为广泛的模型提供最先进的性能优化（特别关注英特尔硬件上的热门高性能 LLM），并积极将我们的增强功能回馈给 vLLM 上游社区。
致谢
我们要向整个 vLLM 团队表达我们诚挚的感谢。他们的开创性工作为 LLM 服务设定了新标准。他们的开放和支持使我们能够有效地做出贡献，我们非常感谢他们在这一努力中的合作伙伴关系。
通知与免责声明
性能因用途、配置和其他因素而异。详情请访问 www.Intel.com/PerformanceIndex。性能结果基于所示日期的测试配置，可能无法反映所有公开可用的更新。有关更多详细信息，请访问 MLCommons。没有任何产品或组件是绝对安全的。英特尔技术可能需要激活硬件、软件或服务。