在edge device 中，只能使用cpu推理吗

[dr3334]

❓ Questions and Help

I am trying to run SenseVoice GGUF inference through the llama.cpp/ggml Vulkan backend on an Android device with a Mali-G615 MC6 GPU.

The Vulkan loader can enumerate the physical GPU successfully, but the process crashes with SIGSEGV during Vulkan backend initialization or the first compute pipeline creation，exit code 139. CPU inference works correctly on the same device, model, audio files, and runtime.

Is Mali-G615 / Mali r44p1 currently supported by the ggml Vulkan backend? Are there known limitations or required build flags for Android Mali GPUs, especially for integrated GPUs using unified memory?

The failure occurs with both Android NDK r28b and r27c builds.

Code

The SenseVoice CLI is executed with:

./llama-funasr-sensevoice \
  --backend vulkan \
  -m ./models/sensevoice-small-q8.gguf \
  --vad ./models/fsmn-vad.gguf \
  -a ./audio/00_BAC009S0770W0259.wav

[LauraGPT]

感谢提供设备、驱动和 NDK 信息。这里需要把“当前支持范围”和“这次 SIGSEGV 的根因”分开：

1. SenseVoice GGUF 并非只能使用 CPU。FunASR v1.4.3 已提供 Linux/Windows x64 Vulkan 包；但该版本没有 Android 资产，Android/Mali 目前不是 FunASR 官方预编译或持续验证的发布目标。
2. 当前 FunASR main（8c60d278）的 find_gpu_backend_device() 只接受 GGML_BACKEND_DEVICE_TYPE_GPU。项目固定的 llama.cpp 803b7fca 会把 Vulkan integrated GPU 登记为 IGPU，所以按集显上报的 Mali 会先在 FunASR 的设备选择层被过滤。这个 selector 缺陷也影响 AMD 集显，已在 modelscope/FunASR#3479 跟踪。
3. 不过，当前 selector 找不到设备时会打印 no Vulkan GPU backend 并 exit(1)；它本身不能解释 SIGSEGV/139。上游也存在彼此不同的 Mali Vulkan 故障类型，例如驱动 fence/deadlock（ggml-org/llama.cpp#23359）和计算结果异常（ggml-org/llama.cpp#26921）。因此现有日志还不足以判断 139 发生在设备选择、backend 初始化还是第一条计算 pipeline，也不能据此判断 Mali-G615 普遍不支持。

请补充以下原始证据：

• FunASR 的 git rev-parse HEAD，以及构建目录中 _deps/llama-src 的 exact commit；
• 完整 CMake 配置命令与 flags、ABI、Android API level；
• 从 ggml_vulkan: Found ... 开始到崩溃为止的完整 stderr（包括 device type、UMA 和 driver 信息）；
• adb logcat -b crash 或 tombstone，以及使用同一套未剥离符号运行 ndk-stack 得到的 backtrace；
• 如果修改过 selector 或固定的 llama.cpp，请附最小 diff。

收到这些信息后，可以先确认你的二进制为什么越过了当前 main 应有的 IGPU 过滤/exit(1) 路径，再判断修复应落在 FunASR selector 还是上游 ggml Vulkan。你已经验证可用的 CPU 路径是目前可靠的回退方案。

[LiuMingqi2001]

#26921 mitigated several Qwen3.5 compatibility issues on Mali Vulkan, but the current changes are primarily workarounds rather than root-cause fixes.

[LauraGPT]

补充当前发布状态，并回应上面的 Mali 说明：上游 #26921 的 workaround 与 FunASR 设备选择层的问题是两件事，不能据此判断本 issue 的 SIGSEGV/139 已解决。

FunASR 侧的集显 selector 修复已经合并并发布：

• 修复 PR：fix(runtime): allow integrated GPU backends modelscope/FunASR#3531
• exact commit：c69e69a0b78fb9becc8b2be91db8ae57d2a41f3c
• release：https://github.com/modelscope/FunASR/releases/tag/runtime-llamacpp-v0.2.1

该修复会优先选择匹配的独显，并在没有匹配独显时接受匹配的 IGPU，因此源码层不再仅因 Mali/其他集显被登记为 GGML_BACKEND_DEVICE_TYPE_IGPU 就直接过滤掉它。但 v0.2.1 的九个平台资产仍然只覆盖桌面 Linux、macOS、Windows；Android/Mali 不是官方预编译或持续验证目标。这次桌面发布成功也不能证明 Mali-G615 初始化或计算 pipeline 可用，更不能解释或修复现有的 SIGSEGV/139。

因此这个 issue 继续保持打开。下一步仍需要前一条回复中要求的完整 stderr、adb logcat -b crash/tombstone，以及同一套未剥离符号经 ndk-stack 解析后的 backtrace。拿到栈后才能区分故障发生在 FunASR 调用层、ggml Vulkan backend 初始化，还是 Mali 驱动的首个 compute pipeline。