Misc. bug: brutally bad SYCL performance on Battlemage

问题场景

用户在 Linux（Docker 容器、Proxmox VM 内）上用 llama.cpp 的 SYCL 后端运行 llama-bench 与 llama-server，加载 gemma-4-26B-A4B-it 的 UD-Q4_K_M GGUF（约 15.70 GiB）到 Intel Battlemage 显卡（B50/B70），并设置 -ngl 99 全部层卸载到 GPU。结果 SYCL 后端的 prefill 和 token 生成速度都接近 CPU 水平，而同一台机器上 Vulkan 后端明显更快。用户还提到 OpenVINO 与 vllm-xpu 表现同样差。

报错原文

Misc. bug: brutally bad SYCL performance on Battlemage

load_backend: loaded SYCL backend from /app/libggml-sycl.so
load_backend: loaded CPU backend from /app/libggml-cpu-haswell.so
| model                          |       size |     params | backend    | ngl |            test |                  t/s |
| gemma4 26B.A4B Q4_K - Medium   |  15.70 GiB |    25.23 B | SYCL       |  99 |           pp512 |        351.53 ± 9.93 |
| gemma4 26B.A4B Q4_K - Medium   |  15.70 GiB |    25.23 B | SYCL       |  99 |           tg128 |         13.33 ± 0.33 |

ggml_vulkan: 0 = Intel(R) Graphics (BMG G31) (Intel open-source Mesa driver) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 32 | shared memory: 49152 | int dot: 1 | matrix cores: none
load_backend: loaded Vulkan backend from /app/libggml-vulkan.so
| model                          |       size |     params | backend    | ngl |            test |                  t/s |
| gemma4 26B.A4B Q4_K - Medium   |  15.70 GiB |    25.23 B | Vulkan     |  99 |           pp512 |      1168.82 ± 12.78 |
| gemma4 26B.A4B Q4_K - Medium   |  15.70 GiB |    25.23 B | Vulkan     |  99 |           tg128 |         40.21 ± 0.17 |

原因分析

Issue 中没有给出确定的根因，以下为讨论中出现的方向，多为可能原因：

• 可能原因：优化被环境变量关闭。用户自述经常设置 GGML_SYCL_DISABLE_OPT=1（尤其是跑 MoE 模型不设就会崩溃），而维护者指出该变量会关闭所有 SYCL 优化，默认值应为 0，默认环境变量才是大多数 Intel GPU 的最佳性能配置。维护者据此推测“优化代码在你的场景里可能存在 bug”。
• 可能原因：虚拟化环境开销。用户的基准测试跑在 Proxmox 上的 VM 加 Docker 容器里，维护者建议裸机优先、Docker 其次，并说明 VM 对 CPU 性能有 5-10% 的折损，但对 GPU 的影响未知。
• 可能被排除：PCIe 3.0 / DDR4 带宽。维护者认为在单 GPU 且显存足够容纳模型的场景下，PCIe 版本和内存代数只影响模型加载速度，不影响推理运行速度；用户也在 PCIe 4.0 的 11400F 平台上复测未变快，与这一说法一致。
• 关于 Xe2 是否走未优化的 DMMV 路径：用户提出了这个疑问，但 Issue 中维护者回复“目前所有优化适用于所有 GPU，只有一个小的 PR 仅针对 Arc 770/750 + Q4_0”，没有确认或否认 Xe2 存在未优化路径。因此这一点仍是未确认的推测。

环境排查

• 确认 llama.cpp 构建版本（Issue 中为 f454bd7eb / 8935）与后端库是否加载正确（日志中应能看到 loaded SYCL backend）。
• 确认 SYCL / oneAPI 运行时版本与驱动：Issue 日志显示 oneAPI 组件包括 ccl 2021.17、mpi 2021.17、mkl 2025.3、umf 1.0 等，但未给出完整的运行时版本对比。
• 确认是否设置了 GGML_SYCL_DISABLE_OPT、GGML_SYCL_FORCE_MMQ、SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS 等环境变量；建议用新终端打印环境变量核对。
• 确认编译选项：Issue 中试过 GGML_SYCL_F16=ON、GGML_NATIVE=ON，并提到 FP32/FP16 切换需要清理后重新编译，在相同模型上分别测速对比。
• 确认运行位置：裸机、Docker、Proxmox VM 三层环境需要分开对比；VM 中需确认 ReBAR、Above 4G Decoding 与 BAR 大小（用户报告 32G BAR 可见）。
• 确认 GPU 是否被正确识别为目标型号（Issue 中 Vulkan 日志识别为 BMG G31），以及显存是否足以完整容纳模型并留出运行和缓存空间。

解决步骤

1. 打开一个全新的终端会话，不设置任何 GGML_SYCL_* 相关环境变量，尤其是不要设置 GGML_SYCL_DISABLE_OPT=1，让 SYCL 后端使用默认优化路径。
2. 用相同模型重跑 llama-bench，记录 pp512 与 tg128 数值，与 Issue 中设置变量时的结果对比，判断是否由关闭优化导致。
3. 如果默认配置下跑 MoE 模型出现崩溃，保留完整日志提供给维护者——维护者已表示希望看到完整日志以排查优化代码中的 bug。
4. 按维护者建议，优先在裸机上测试，其次是 Docker，最后才是 Proxmox VM；条件允许时用同一命令在裸机与 VM 上各测一次，量化虚拟化开销。
5. 如需切换 FP16/FP32 路径，先清理构建产物再重新编译（Issue 中明确 FP32 切 FP16 需要 clean 后 rebuild），然后重新测速。
6. 作为对照，用 Vulkan 后端在相同模型、相同参数下运行一次，确认差距来源确实是 SYCL 后端而非硬件或模型配置。

验证方法

用 ./llama-bench -m <模型> 在相同构建、相同模型、默认环境变量下比较 SYCL 后端的 pp512 与 tg128。Issue 中用户按建议清理环境变量后复测，SYCL 仍约为 pp512 367 t/s、tg128 13.74 t/s，与 Vulkan 的约 1168 t/s / 40 t/s 差距仍然巨大，因此该问题的验证标准应为：SYCL 吞吐明显向 Vulkan 邻近，而不仅是环境变量已被清空。若在裸机上差距明显缩小，则说明 VM 环境是重要影响项；若裸机仍复现，可附完整日志继续在 Issue 中上报。

参考来源

ggml-org/llama.cpp #22413

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。