Eval bug: GLM-5.3-Flash decode stalls on Metal because fused Lightning Indexer falls back to CPU

快速结论：在 Apple Metal 上运行 GLM-5.3-Flash 解码时，若出现 “Eval bug: GLM-5.3-Flash decode stalls on Metal because fused Lightning Indexer falls back to CPU”，通常发生在启用 fused Lightning Indexer、但 Metal 后端未对该配置走 GPU 路径的场景。优先排查 fused LID 的 GPU/CPU 执行情况，并更新到已包含修复的 master 构建。

适用环境：llama.cpp（Issue 中版本为 0.5.0-dev，build 11349，commit fb4b2737，另复现于 build b11347 / commit 5fc4f3c）；macOS（Darwin arm64，AppleClang 21.0.0.21000334）；Metal 后端；Apple M5；模型为 GLM-5.3-Flash（unsloth UD-IQ3_XXS，应用 shard rewrite）；运行参数为 -ngl 999 -fa on -c 65536。

最快修复方案：更新到包含 #29825 修复的当前 master 构建。Issue 中报告者在 master 上复测后确认卡顿消失，低上下文约 31 t/s、高上下文约 25 t/s，且无需手动修改开关或打补丁。

注意事项：该修复消除了每 token 长时间卡顿，但评论指出 GLM-5.3 在超过约 2048 tokens 后仍会出现每 256 tokens 一次的 graph reallocation，这一点尚未在该 Issue 中解决。Issue 中的临时方案（将 cparams.auto_flid 改为 true 从源码构建）仅为本地变通，不应替代正式修复。

问题场景

用户在 Apple M5 的 macOS 上使用 llama.cpp 的 Metal 后端加载 GLM-5.3-Flash（glm5-next，UD-IQ3_XXS），以 -ngl 999 -fa on -c 65536 进行解码。正常解码速度约 31 t/s，但在生成几十个 token 后，每个 token 会出现 1–9 秒的间歇性卡顿，平均速度降到 0.5–10 t/s。用户通过试错发现，禁用 fused Lightning Indexer（LID）后卡顿消失。该问题在 build b11347（5fc4f3c）上复现。

报错原文

Eval bug: GLM-5.3-Flash decode stalls on Metal because fused Lightning Indexer falls back to CPU

原因分析

Issue 正文提出了一种可能原因：fused_lid 被硬编码启用，同时 auto_flid 为 false，导致电源索引器的探测逻辑没有执行，从而无法在检测到 CPU 回退时自动关闭 fused op。用户还指出 Metal lightning indexer kernel 可能只支持特定 head 数（正文称仅支持 64 个 indexer heads），而 GLM-5.3-Flash 为 32 个 indexer heads，因而 fused op 回退到 CPU 并引发卡顿。

不过，维护者反馈无法复现该卡顿，并指出 Metal 已支持 lightning indexer，且认为只有一种 head size（DK = 128），所有模型都使用该尺寸。随后维护者更正称，该卡顿问题已由 #29825（@ServeurpersoCom）修复，应在 master 上消失。因此上述 head 数量与 CPU 回退的解释属于 Issue 中提出但未被最终确认的判断，真正修复来自 #29825 的改动。

环境排查

确认 llama.cpp 构建版本和 commit：Issue 中复现版本为 build b11347 / 5fc4f3c，另一次运行报告为 build 11349 / fb4b2737。
确认构建是否包含 #29825 的修复，建议直接用当前 master 重新构建。
确认 Metal 后端已启用（Issue 使用 -DGGML_METAL=ON，并启用 -DGGML_METAL_EMBED_LIBRARY=ON）。
确认运行参数与复现时一致：-ngl 999 -fa on -c 65536。
确认模型为 GLM-5.3-Flash，且 GGUF shard 已按 unsloth 说明完成 shard rewrite。
若仍使用旧版或自行修改过源码（例如是否将 cparams.auto_flid 改为 true），先恢复为原始构建以排除本地补丁影响。

解决步骤

将 llama.cpp 更新到包含 #29825 修复的 master 版本。
按 Issue 中的方式重新构建，确保 Metal 后端开启：-DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON -DGGML_METAL_EMBED_LIBRARY=ON -DGGML_NATIVE=ON -DBUILD_SHARED_LIBS=OFF。
使用与复现时相同的模型和参数运行 GLM-5.3-Flash：-ngl 999 -fa on -c 65536。
如果暂时无法升级，可优先尝试 Issue 中提到的本地变通：从源码构建时将 src/llama-context.cpp 第 238 行的 cparams.auto_flid = false; 改为 cparams.auto_flid = true;，使探测逻辑得以执行。该方法仅为个别用户本地验证，并非官方确认的一步修复方案。
若在旧版本上仍想手动关闭 fused LID，Issue 提到 #27754 曾经暴露 LLAMA_FUSED_LID_DISABLE 环境变量，但当前版本未提供该开关，需自行修改源码。

验证方法

在修复后的 master 构建上运行相同模型和参数，观察解码速度是否稳定在约 31 t/s（低上下文）和约 25 t/s（高上下文），且不再出现每个 token 1–9 秒的卡顿。Issue 中报告者按此方式复测后确认“works flawlessly”，不再需要手动开关。另外可留意高上下文（超过约 2048 tokens）时是否仍每 256 tokens 出现 graph reallocation，该现象属于另一个尚未在本 Issue 中解决的问题。