mohammadhaishemkhawaja/hashyy 是一个面向 llama.cpp 的 expert streaming 项目，声称在单张 12 GB GPU 上以 11.5 tok/s 的速度处理未经剪枝的 177B MoE 模型。其说明中写道，同时还收录了测量工具链以及一路走来的失败。2026-10-03 的提交 6189bf3 是不涉及代码、仅改动 README.md 这一个文件的文档变更，全部内容就是新增 17 行、删除 1 行。改动对象是测量表中的一行，该提交说明这是解释这一行究竟在测量什么的变更。
README 把原有的表述 'as inherited' 改为 'baseline'，并强调该 baseline 并不是 stock llama.cpp。它说明在 README 所讲述的这次变更之前，这个项目里就已经有了两轮工作，并将其列表列为：PR #25294 的 fork、重写的 Windows 读取路径、保存下来的 heat map，以及 --poll 0。测量条件也一并写明：在同一个二进制文件上，用 LLAMA_MOE_STREAM_ONE_HANDLE=1 恢复过去的单一共享文件句柄、9 个 I/O 线程、不带 --poll 0、没有 hot file、使用 -c 4096，将 before 与 after 两条分支交替运行。它指出仅受操作系统页面缓存影响，结果就会有 3-5% 的波动，并得出结论：与来自其他构建或其他日期的数字相比并没有特别的意义。
在这份文档中，8.14 tok/s 是此前针对该项目被引用过的数值，但 README 澄清说那是更宽松的旧协议下的 warm 测量值，而表中的 5.85 – 7.07 是用 bench/sweep.py --cold 测得的 cold 测量值。它明确说明，在这个文件里被引用的比较只有 cold-to-cold。表中其余的数值是：交替使用不同提示词时为 11.43 – 11.58，相同条件下的 cold start 为 11.55 – 11.57，把新对话按轮次延续下去时为 9.1 → 13.4（中位数 10.30），表下方的总结是 ~7.0 → 11.6 tok/s、+65%。
不过，这次变更只是说明而已。没有性能改进，也没有代码修正，因此不能读作该仓库变快了。表中的数字和 +65% 的总结全都是仓库自行整理出来的值，并不是独立验证的结果。在“仅受页面缓存影响就会波动 3-5%”这一记录之下，把 warm 的 8.14 tok/s 和 cold 的 5.85 – 7.07 并列摆出来时，条件其实是不同的，这一点需要一并记住。与其把数字原样搬用，不如先读清楚每个值是在什么条件下得出的。