DSV4 K 缓存位置读取移到 PDL 等待之后，避免写到陈旧槽位
值得精读，但读法要偏「知识点」而非「代码量」：diff 只有一行，真正的价值在 PR body 与两条评论串起的 PDL 契约推理。
重点关注：1）为什么 `out_loc` 必须晚读，而 `position` 与 `freqs_cis` 可以早读——这条「元数据就绪边界」的判断标准可以直接迁移到其它 fused kernel；2）DarkSharpness 提出的「等待点后置是为 prefetch overlap 服务」这一设计意图，以及作者如何用一行改动折中，这是性能与正确性权衡的典型样本；3）作者给出的验证方式（standalone GPU trials + CUDA-graph 微基准 + 明确的「非端到端」免责说明）值得作为 kernel 层修复的验证模板；4）遗留项：没有回归测试，建议后续补一个能构造「前置 kernel 刚产出 cache location」的最小用例，并顺带排查同目录其它 PDL kernel 是否存在同类提前读取。
gfx95 上把 prefill 计算预算按原始 token 计费，batch 精确填满 chunked-prefill-size
**值得精读，但重点不在 diff 的行数。** 建议按以下顺序看：
1. `PrefillAdder._update_prefill_budget` 新增的 `compute_charge` 参数——这是全 PR 的设计核心，理解“KV 预算按 page、计算预算按 token”的分工边界，以及为什么两个计算预算必须同时切换（否则先归零者会留下取整余量）。
2. `add_one_req` 的新 `elif self.exact_chunk_fill:` 分支——注意 `chunk_tokens_limit` 而非 `rem_chunk_tokens` 的选择、`truncation_align_size` 对齐、以及 `_check_prefill_tile_budget` 的插入位置，这三点决定了它和 SWA / tile budget 特性的边界。
3. 最后一个 merge commit 对上游 `raw_extend_input_len` 的处理，是“让本地改动贴合上游口径”的良好实践样本。
**改进建议**：为 `exact_chunk_fill` 补一个可直接断言的单元测试（例如 page_size=64、chunk=16384、prompt 混合，断言 `rem_chunk_tokens` 归零且 extend 总长恰为 16384），因为当前等价性与正确性完全依赖作者的一次性场景重放，无法防止后续回归。
验证路径复用解码融合准备，MLA 每层 preparation 由 5 次 launch 降为 1 次
推荐精读，尤其是正在做 MLA / speculative verify 性能优化或统一内存池相关改动的同学。值得关注的设计决策有三点：(1) 用 `fused_fp8_query` 单哨兵同时控制「跳过重复 KV 写入」和「跳过 query concat」，比在多处重复判断 gate 更难写错；(2) 复用 `forward_decode` 的守卫序列（`save_kv_cache` + 静态 gate + `_resolve_fused_write_loc`）而不是新建路径，使 decode 与 verify 的融合语义天然一致；(3) 明确把 dispatch 修复与 kernel 选择（CUDA vs Triton）切开，压缩了评审面。
阅读时建议同步确认两件事：一是 PR body 承诺的 `test/registered/kernel/attention/test_trtllm_mla_fp8_prepare.py` 是否已在其他 PR 落地，否则需补上 verify 路径的回归测试；二是真实权重（Kimi K3 + trtllm_mla + fp8 KV + MTP）的精度与吞吐结论是否已补齐，因为当前所有数字都来自 acceptance length=1.0 的 dummy 诊断，不能直接当作上线依据。
