midagedev/bloomery 是一个在同一项目中同时处理混合 (MoE) 模型的 GPU 与 CPU 推理的库。它用 Rust 编写，连 CUDA 内核也是自己实现的，并宣称自己是可替代 llama-server 的即插即用 (drop-in) 服务器。2026 年 11 月 5 日的提交 1a7bba2 只改动了 tools/ref/depth-serve.sh 这一个文件。提交链接是 https://github.com/midagedev/bloomery/commit/1a7bba264cdbc1df2bc7819855f5b15f619ddcde 。新增 18 行、删除 6 行，内容是修正了一个等待条件。在启动下一个服务器之前的等待中，除了 '端口已空' 和 '没有进程占用计时卡' 之外，还增加了 '上一个服务器的进程不在进程表中'。以前只凭前两个条件就结束等待。
之所以需要这个条件，源于提交消息中所记录的失败形态。被 wrapper 的 KILL 终止的服务器在清理约 262 GB 的主机集 (host set) 期间，会在终止中的状态再停留几秒。在这段时间里端口已经关闭、卡片上下文也已消失，于是下一个服务器前面的 CPU 探测把该进程读成了同机占用者 (co-tenant)，结果行被判为无效，显示为 [cpu-busy] bloomery-serve 99.7 % over 6.5 s。同样的失败在连续的两次发布轮次 (release sitting) 中重演。因此脚本中新增了 ds_serve_procs()。它用 pgrep -x 把 comm 名称为 bloomery-serve 或 llama-server 的进程以 pid 和名称的形式收集到等待队列中。ds_prev_gone 会一并检查端口、计时卡和进程表，并以名称保留正在等待的对象；一旦超过 PORT_WAIT_S 秒，就以 'its process has not exited' 这一名称判定为失败。提交中记录的自检结果是 199 checks ok。
不过，本次改动仅限于仓库中的 depth-serve 脚本一处，并非推理引擎或 CUDA 内核。没有给出性能数值或吞吐量变化。所涉及的场景也仅限于一个等待条件：被 KILL 终止的服务器仍在清理中的情况。提交尾注中还留有 Claude Fable 5.1 的共同作者署名和会话链接。判断来看，这是想要原样复现该仓库发布测量的人所需要的修正，而对于直接使用 MoE 推理路径的人来说，本次提交没有改动任何东西。