在英特尔锐炫™ Pro B 系列 GPU 上借助 vLLM 实现经济高效的 LLM 推理服务
英特尔® 锐炫™ Pro B 系列 GPU 家族 提供强大的 AI 功能，并注重可及性和卓越的性价比。其大容量内存和多 GPU 设置的可扩展性，使得在本地运行最新、最大、功能最强的 AI 模型成为可能，让希望部署大语言模型 (LLM) 的专业人士无需承担通常与 AI 硬件相关的高昂成本，即可获得先进的 AI 推理能力。
vLLM 是在英特尔锐炫 Pro B 系列 GPU 上实现快速且经济高效的 LLM 推理服务的核心软件栈。在过去几个月中，英特尔的开发者一直与 vLLM 社区积极合作，以启用和优化关键功能，并确保在英特尔锐炫 Pro B 系列 GPU 上实现多 GPU 扩展和 PCIe P2P 数据传输的无缝性能。
英特尔® 锐炫™ Pro B 系列 GPU 为 vLLM 提供了关键功能和优化，包括：
- 为 DeepSeek 蒸馏的 Llama/Qwen 模型提供坚实的推理性能
- 长上下文长度（>50K），并能在批处理大小上实现良好扩展
- 支持嵌入、重排、池化模型
- 支持多模态模型
- 良好优化的混合专家 (MoE) 模型（GPT-OSS, DeepSeek-v2-lite, Qwen3-30B-A3B 等）
- 逐层在线量化以减少所需的 GPU 内存
- 支持数据并行、张量并行和流水线并行
- 为 Torch.compile 提供 FP16 和 BF16 路径支持
- 在 n-gram、EAGLE 和 EAGLE3 方法中支持推测解码
- 异步调度
- 预填充/解码分离
- 低秩适配器 (LoRA)
- 推理输出
- 睡眠模式
- 结构化输出
- 工具调用
- 为 BF16、FP16、INT4 和 FP8 vLLM 配方提供混合精度支持
针对 MoE 模型的高级优化
混合专家（MoE）是一种模型方法，其中多个专业化的专家网络在门控机制的引导下协同处理输入序列。对于输入序列中的每个标记（token），门控网络会动态选择应由哪个专家子集来处理该标记。MoE 架构不依赖于单个密集的前馈层，而是采用分布在专家网络中的多个并行 GEMM 操作来实现等效的计算功能。这种设计将结构化稀疏性引入模型中，因为对于任何给定的输入，只有一部分专家被激活，从而在保持模型容量的同时提高了计算效率。除了对通用矩阵乘法（GEMM）和 Flash Attention 的常规优化外，这些 MoE 组件（专家和门控网络）是基于 MoE 的语言模型中关键的性能贡献者。
然而，MoE GEMM 操作的朴素实现可能会遭遇严重的效率瓶颈。典型的方法是在 for 循环中为每次迭代顺序启动单个 GEMM 内核，这会产生过多的内核启动开销并引入大量的调度延迟。此外，由于专家的路由决策是由门控网络产生的，GEMM 操作必须等待门控计算完成后才能开始执行。这种数据依赖性会造成流水线停顿，中断内核执行流，并严重限制 GPU 的并行性，从而无法实现最佳的设备利用率。
针对 MoE GEMM 的这些限制，我们设计了一个持久化的零间隙内核，在英特尔® 锐炫™ Pro B60 GPU 上实现了超过 80% 的硬件容量效率。
优化 1. 在持久循环中启动单个内核
单内核设计将消除上述的启动和调度开销。此外，持久循环消除了对依赖于专家路由网络结果的启动参数的需求。这有助于保持设备的最大并行性。
在使用持久内核之前，我们可以看到设备因等待主机而处于空闲状态
启用持久化使设备保持繁忙
英特尔® 锐炫™ 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 算法，以提高内存加载效率
预打包（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 矩阵扩展（英特尔® XMX）AI 引擎，英特尔锐炫 Pro B 系列 GPU 为 vLLM 上的高频使用模型优化提供了良好的硬件能力。完整的支持模型列表可在 intel/ai-containers 找到。
从 8B 到 70B 大小的 DeepSeek 蒸馏模型经过优化，在配备八个英特尔® 锐炫™ Pro GPU 的系统上实现了良好的输出 token 吞吐量。
图 1：在配置了 8 张英特尔® 锐炫™ Pro B60 GPU 卡的系统上，FP8 模型在服务等级协议（SLA）下的最大并发输出 token 吞吐量。
系统在良好的并发负载下，下一 token 延迟维持在 100 毫秒以下。
图 2：在配置了 4 张英特尔® 锐炫™ Pro B60 GPU 卡的系统上，随着提示数量的增加，Qwen-32B 的下一 token 延迟。
模型推理在从 1K 到超过 40K token 的广泛输入序列长度范围内保持了一致的下一 token 延迟。这一性能得益于高度优化的 flash attention 内核，该内核在序列长度维度上并行化了操作。
图 3：在配置了 8 张英特尔® 锐炫™ Pro B60 GPU 卡的系统上，llama-70B 单批次长上下文输入（从 1K 到 40K 序列）的首 token 时间（TTFT）/每输出 token 时间（TPOT）。
GPT-OSS：英特尔® 锐炫™ Pro B60 GPU 在 OpenAI 最近发布的 GPT-OSS 模型上也表现出色，为开发者和企业提供了一个强大且经济高效的大规模 AI 推理解决方案，如下表所示。
| 模型 | 数据类型 | 张量并行数 | 输入/输出序列长度 | 并发数 | 首 token 时间 (秒) | 每输出 token 时间 (毫秒) | 输出 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：在配置了 8 张英特尔® 锐炫™ Pro B 系列 GPU 的系统上，使用 1-4 张 GPU 的 GPT-OSS vLLM 推理吞吐量。
MLPerf：英特尔锐炫 Pro B 系列 GPU 在最近发布的 MLPerf Inference v5.1 结果（链接）中表现出色。在 Llama 8B 测试中，英特尔® 锐炫™ Pro B60 GPU 展示了性价比优势。这些结果是使用 vLLM 作为推理服务框架实现的。
如何设置
支持英特尔 XPU 的 vllm Docker 镜像可以从 intel/vllm - Docker Image | Docker Hub 下载。自 vllm 0.10.2 Docker 版本起，支持 gpt-oss 等 MoE 模型。以下示例要求主机操作系统为 Ubuntu 25.04，KMD 驱动程序为 6.14.0，运行在配置了 4 张英特尔® 锐炫™ Pro B60 GPU 卡（插入 PCIe 插槽）的至强系统上。
使用以下命令获取发布的 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 张英特尔® 锐炫™ 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 获取更多详情。没有任何产品或组件是绝对安全的。英特尔技术可能需要启用相应的硬件、软件或服务。