tildaslashalef/nuclis 是一个用 Zig 编写、附带 Metal 后端的本地 LLM 推理引擎。2026-11-01 的提交（177daa1c，https://github.com/tildaslashalef/nuclis/commit/177daa1cd71b1fd3c4e3271bf360839a5b101df7）一并处理了单个客户端 Muon 报告的三个问题。Muon 写道，三者他都在 `0.12.0-dev+990ba6c` 上确认了。第一是提示词全部被缓存的请求以 `500 model_failed EmptyPrompt` 失败的问题。在 Gemma 4 中，以工具结果结尾的渲染没有生成提示词，缓存结束标记覆盖了整个请求，而再次发送同一请求时已没有可填充的 token。现在 `Completer` 会保存标记之前的那个 token，把会话回退一格，然后重新放入该 token 以取得 logits。在无法回退的情况下（drafter 已加载且不知道前面的 token），则重置会话并重新预填充整个提示词。
第二是 `nemotron-asr-0.6b` 在 lookahead 3 下于最终转写末尾重复十次 'plus' 的问题。原因是 RNN-T 的 greedy 循环在同一个编码器行中不断产出相同的词首片段。现在，如果一个行中词首片段连续出现两次，就结束该行。该规则只作用于片段以 U+2581 开头的词首 token，允许单词内部的片段重复。它同时进入了 CPU 的 `Decoder.decodeRow` 和 Metal 的 `Stream.decode`。`scripts/api-check.py` 中新增了 `check_again`，用于发送同一请求三次，并分别检查以用户消息和工具消息结尾的情况。
第三，新增了 `reasoning_effort: "minimal"`。它的渲染方式与 `low` 相同，但在思考预算的一半处关闭，即以默认思考预算 1,024 token 计算，在 512 token 处结束。提交所附的测量来自 Muon 真实的 `tasks_add` 请求：在 `gemma-4-26b-a4b` 上，对四种提示词各加四个种子，紧接在 `none` 请求之后发送。`low` 在 32 次中有 31 次以工具调用或反问回应，中位时间为 14–20 秒。`minimal` 在 512 token 时为 28/32 和 10 秒，在 256 token 时为 20/32 和 5.5 秒。由于在 256 时三分之一的工具调用消失，预算被定为 512。
提交中同时还写明了剩余的限制。`minimal` 仍会在 32 次中漏掉 4 次，约八分之一的工具调用。Muon 在这种情况下退回 `low`，而紧接在 `none` 请求之后的第一个 `low` 因系统块不同，一个缓存 token 也无法复用。这项成本只是被记录下来，尚未修复。检查结果显示 `make verify-auto` 通过，但 `make verify` 只通过了 71 个中的 56 个，其余 15 个因本机没有相应模型（Muse、Bonsai、Saluki）而被跳过。ASR 方面，60 个片段的转写在 lookahead 0·3·6·13 下没有变化，Metal WER 维持在 6.52·6.11·6.44·6.36%。CPU WER 门槛为 8.13%，在 11% 的上限之内。由于这是针对单个客户端实际使用报告的窄范围修复，剩下的质量差距只能另行等待。