[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$feu8p4pjbh5ul":3},{"slug":4,"category":5,"publishedAt":6,"titleZh":7,"titleEn":8,"summaryZh":9,"summaryEn":10,"models":11,"hardwares":12,"bodyZh":13,"bodyEn":14,"sourceName":15,"sourceUrl":16,"updatedAt":17},"llamacpp-b11933-vulkan-cpu-fallback-2026-10-28","RUNTIME","2026-10-27T23:26:52.752Z","llama.cpp 修复一类 Vulkan CPU 回退：先查算子落点，再判断显卡速度","llama.cpp fixes a Vulkan CPU fallback: inspect placement before judging GPU speed","b11933 修复 MUL_MAT 第四维广播的支持判断。它解释了特定多流场景为何回退 CPU，但不是全模型加速承诺；目前仅有提交者测试，本站未独立复现。","Build b11933 fixes support detection for dimension-3 broadcasting in MUL_MAT. This addresses a specific CPU fallback, not a universal speedup. AraoAI has not independently reproduced the change.",[],[],"【站方新闻 · AI 辅助整理】\n\n显卡跑得慢，不一定是带宽不够，也可能是某个算子根本没有留在显卡上。北京时间10月27日晚，llama.cpp 合并 PR #31239；窗口内发布的 b11933 已包含这项 Vulkan 修复。本文依据上游 PR 与发布说明整理，不是本站真机复现，也没有可承诺的速度增幅。\n\n问题出在 MUL_MAT 的支持判断：当输入张量第四维 ne3 不一致时，旧判断会拒绝该运算，但若干 Vulkan 计算路径原本已经支持这一维广播。结果是本可在 Vulkan 执行的矩阵乘法回退到 CPU，并携带权重副本。提交者描述，在非统一 KV cache 的 glm5-next 场景里，ubatch 流数变化会改变执行落点，使计算图在不同节点数量间切换，并触发调度器重新预留资源。\n\n修复不是把所有检查放开。它保留 MUL_MAT_ID 的严格限制，并让广播情况避开要求 ne3 相等的 mul_mat_vec_nc 路径。这属于特定算子支持和调度行为修正，不能据此推导出某张卡、某个量化档普遍快了多少。\n\n提交者报告，在 RTX PRO 6000 容器环境、软件 Vulkan 和 NVIDIA Vulkan 驱动上进行了检查，相关广播测试开始得到支持，软件 Vulkan 的上下文测试也通过。这些是上游贡献者的验证陈述，不是跨机器社区复现，更不是本地模型的吞吐榜单。\n\n对部署者有用的动作是：先固定权重、量化、上下文、batch 和引擎版本，记录旧构建的后端分配与运行日志，再与包含修复的新构建对照。只见 GPU 被识别，不能证明每个关键算子都在 GPU 执行；也不要把它与另一类 CPU 层小算子卸载问题混为同一个缺陷。\n\n判断边界很清楚：这次修复证明一种回退路径确实存在，不证明你遇到的慢速一定由它导致。\n\n来源：\n- https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F31239\n- https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb11933","[AraoAI editorial · AI-assisted]\n\nA slow GPU result can reflect operator placement rather than insufficient bandwidth. llama.cpp merged PR #31239 on October 27, and build b11933, released within this reporting window, includes the Vulkan fix. This article reports upstream documentation; AraoAI has not independently reproduced the change and makes no throughput claim.\n\nThe support check rejected MUL_MAT whenever the inputs differed in dimension 3, even though several Vulkan paths already supported broadcasting along that dimension. An affected multiplication therefore fell back to the CPU with a weight copy. In the contributor's glm5-next case with a non-unified KV cache, changing the number of streams in an ubatch changed placement, altering the graph and causing scheduler re-reservation.\n\nThe patch does not remove every restriction. It retains the strict check for MUL_MAT_ID and routes broadcasting away from mul_mat_vec_nc, a path that requires matching ne3. This is a specific correctness and scheduling fix, not evidence that every GPU, quantization or model runs faster.\n\nThe contributor describes checks in an RTX PRO 6000 container, software Vulkan and the NVIDIA Vulkan driver. Those are contributor-reported checks, not independent cross-machine reproductions or an inference leaderboard.\n\nFor a meaningful A\u002FB test, pin the weights, quantization, context, batching and engine version. Save backend placement and runtime logs from the old build before comparing a build containing the fix. Device detection alone does not prove that important operators execute on that device. Also distinguish this issue from small-operation offloading in CPU-resident layers, which is a separate report.\n\nThe conclusion is narrow: this fallback existed. It does not establish the cause of any particular reader's slowdown.\n\nSources:\n- https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F31239\n- https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb11933","llama.cpp upstream PR and release","https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F31239","2026-10-27T23:26:52.753Z"]