按 prompt 哈希记忆化 SpecPrefill 的打分结果

稀疏预填充先用便宜的打分器估计哪些 prompt token 重要，只对选中的部分做完整预填充。生产日志里同一个两万多 token 的 prompt 在一分半内被重复打分四次，每次约 4.1 秒。这条现象是真的，这个 PR 想做的是按原始 token 的哈希把「选中了哪些」记下来，跳过重复的打分。

提交时我写的前提是「打分在输入固定时是确定的」。这个前提是错的。 维护者在评审中指出打分器带随机性：_lookahead_decode 以 temp=0.6, top_p=0.95 采样且未固定种子，所以「打分 → 选中」并不是我在模块注释里描述的纯函数。按哈希记忆化因此不是透明地缓存一个确定结果，而是把某一次采样得到的选择冻结下来给后续所有相同 prompt 复用。日志里那行 selected 11744/23444 也证明不了位置一致——keep_n = ceil(n_chunks * keep_pct) 已经把这个数目定死，无论最终选中的是哪些块。这两点我都接受。

维护者的另一半理由是命中条件太窄：多轮对话从 A-B-C-D 变成 A-B-C-D-E，哈希就变了，而已有的草稿 KV 缓存本来就复用共享前缀。这半我补了一处更正：SpecPrefill 的请求从不写入目标前缀缓存（scheduler.py:8891 丢弃 raw_cache，scheduler.py:5554 在边界存储回退路径上同样如此），所以字节相同的重试会带着完整 prompt 重新进来并重新打分，这正是那四次重复打分的成因。但这不动摇他的结论：重试本身并不常见。

截至 2026 年 8 月 1 日，这个 PR 仍开放且尚未合并，维护者已明确表示不建议合并。 留在这里的原因是它记录了一次判断错误，而不是因为它还有希望。下一步不是继续加固这个缓存，而是去拆那 4.1 秒本身：在草稿缓存已命中两万两千多 token 之后，剩下的成本是前瞻解码加上对整个 K cache 的 _compute_importance——这部分每个请求都要付，包括选择缓存永远帮不上的多轮路径。这个 PR 会被改写或关掉。实时状态以 GitHub 为准。