aristo94/gsqhalo.cpp 是一个 llama.cpp 分支，旨在 AMD Strix Halo(gfx1151) 上运行 GSQ 量化后的 Qwen3.8-Flash-Next。2026 年 10 月 11 日的提交 16f0929 未改动任何代码，只涉及两份文档。docs/gsqhalo/README.md 中恢复了“restore oracle”一节，整理了从 SSD 读回的对话是否会与始终未离开槽位的对话一致地延续的条件与结果。
SSD KV 缓存是一项把模型先前的对话状态保存到磁盘上的功能，因此即使清空槽位也能继续对话。README 记录：29.7K token 的对话从磁盘读回仅需 2.5 秒，而从头重新预填充则需要 33.7 秒。新的预言机用于检查这种恢复是否产生与原始对话相同的结果。读回至自身槽位、读回至不同槽位、重启后读回，以及在另一槽位正在创建时读回——这四种情况都与基准运行（每个对话都在未单独离开槽位的情况下运行）逐位一致。槽位状态哈希在恢复之后以及每次提示布置时也都相同。
证据止步之处也很清楚。当两个对话同时生成时，其中一个对话的结果与单独生成时并不逐位一致。X 和 Y 在基准运行中分别从第 7 个 token 和第 32 个 token 起出现偏差，logprob 差异最大为 0.12。在概率超过 0.95 的 token 上，差异缩小到最大 0.004。由于批次形状不同导致了舍入偏差，而 QSA 与 MoE 路由器的 top-k 选择又放大了该差异。
启用 MTP 时，四种恢复都产生了与基准相同的 token，但 Y 的第二个 logprob 在第 28 个 token 处相差 0.08。这一差异源于 draft head 改变了验证批次。测量是在 7ece4bd 的代码上进行的，而该提交本身只增加了 45 行文档并删除了 2 行。此外仍保留着一项约束：槽位之间的状态哈希无法相互比较。因此，恢复一致性可被视为在“不启用 MTP 继续对话”的条件下得到确认的结果，但难以将其视为包含并发生成或 MTP 在内的完全一致。