llama.cpp 修复一类 Vulkan CPU 回退：先查算子落点，再判断显卡速度
b11933 修复 MUL_MAT 第四维广播的支持判断。它解释了特定多流场景为何回退 CPU，但不是全模型加速承诺；目前仅有提交者测试，本站未独立复现。
【站方新闻 · AI 辅助整理】
显卡跑得慢，不一定是带宽不够，也可能是某个算子根本没有留在显卡上。北京时间10月27日晚，llama.cpp 合并 PR #31239；窗口内发布的 b11933 已包含这项 Vulkan 修复。本文依据上游 PR 与发布说明整理，不是本站真机复现，也没有可承诺的速度增幅。
问题出在 MUL_MAT 的支持判断：当输入张量第四维 ne3 不一致时，旧判断会拒绝该运算，但若干 Vulkan 计算路径原本已经支持这一维广播。结果是本可在 Vulkan 执行的矩阵乘法回退到 CPU，并携带权重副本。提交者描述，在非统一 KV cache 的 glm5-next 场景里，ubatch 流数变化会改变执行落点，使计算图在不同节点数量间切换，并触发调度器重新预留资源。
修复不是把所有检查放开。它保留 MUL_MAT_ID 的严格限制，并让广播情况避开要求 ne3 相等的 mul_mat_vec_nc 路径。这属于特定算子支持和调度行为修正，不能据此推导出某张卡、某个量化档普遍快了多少。
提交者报告，在 RTX PRO 6000 容器环境、软件 Vulkan 和 NVIDIA Vulkan 驱动上进行了检查，相关广播测试开始得到支持，软件 Vulkan 的上下文测试也通过。这些是上游贡献者的验证陈述，不是跨机器社区复现，更不是本地模型的吞吐榜单。
对部署者有用的动作是：先固定权重、量化、上下文、batch 和引擎版本，记录旧构建的后端分配与运行日志，再与包含修复的新构建对照。只见 GPU 被识别，不能证明每个关键算子都在 GPU 执行；也不要把它与另一类 CPU 层小算子卸载问题混为同一个缺陷。
判断边界很清楚：这次修复证明一种回退路径确实存在，不证明你遇到的慢速一定由它导致。
来源：
- https://github.com/ggml-org/llama.cpp/pull/31239
- https://github.com/ggml-org/llama.cpp/releases/tag/b11933