2026-09-16
修复 unified cache C128 对齐与释放区间重叠
值得精读，但重点不在代码量而在两处契约：一是 `base.py` 中 `floor_cache_len` 的"min 之后再做对齐"语义，它决定了组件体系的长度协商分两个阶段，读者应理解为什么不能放在 `prepare_for_caching_req` 里；二是 `cache_finished_req` 中把两个相接区间合并为 `(free_from, len(kv_indices_full))` 的判据，这是典型的"边界共享一页"陷阱，建议对照 `free_kv_row` 的升序/不重叠约束一起读。
建议后续动作：为该修复补注册单测（覆盖 EAGLE 与非 EAGLE 下 `floor_cache_len` 的边界值、以及 `tail_free_start == len(kv_indices)` 时命中合并分支 / 不命中分支），并为 `floor_cache_len` 增加"结果不得低于 `cache_protected_len`"的显式约束或断言，避免多组件粒度不一致时出现隐性回退。
DSV4.1 新增索引器内核，重做 Top-K v2 分派
建议精读，重点关注三处：`topk.py` 的探测驱动 JIT 宏与 `plan_topk_v2` 默认值语义、`topk_impl.cuh` 的 NaN padding 与 `coarse_bin_lower_bound` 的 round-to-even 补偿、`topk_v2.cuh` 的 `PageTransform` 解耦与 cluster 8/16 分派。四个值得学习的设计决策：用 NaN 而非极小值填充以保护合法的 -inf；用 ULP 步进而非重算 fp16 bin 处理 round-to-nearest-even；用 `cudaOccupancyMaxActiveClusters` 而不是 SM 数除法定 pool 尺寸（GPC 约束）；把 page-table 变换从选择内核解耦成独立结构以便两种输出模式共用。若负责索引器或 Blackwell 性能，建议先补齐 BBuf 要求的边界 benchmark 再信任这些阈值，并为三个新内核补注册测试。
抽出 DSV4.1 独立内核与 Python 封装，作为 PR 栈首层合入
值得精读，尤其是准备接 #38798 / #39648 的工程师与负责 DSV4.1 内核维护的同学。
- 优先看三处设计决策：`small_gemm_bf16.py` 的 `MAX_M` 策略上限与 `can_use_*` 契约（调用方负责回退，内核只做「形状正确即最快」）；`mxfp8_epilogue.py` 的 UE8M0 舍入 + 128x4 swizzle 偏移 + padding 槽位裁剪策略（多 CTA 写集合不相交的隐含证明）；`q_rope_store.py` 的 prefill/decode 分支与 int64 偏移、PDL 开关。
- 阅读时把每个 `assert` 当成调用契约而非防御式编程：这些断言定义了调度层必须满足的形状、stride 与设备前提。
- 跟进项建议：(a) 按 BBuf 的意见把 `candidate_blocks.py` / `indexer_postprocess.py` 的独立覆盖补进本层或明确移交 #39648；(b) 为 `engram_gather` 补 owned / unowned ID 的用例；(c) 刷新 PR 描述中已过期的 byte-identical 声明与文件统计，避免后续审计引用失效结论；(d) 如计划支持非 Blackwell 平台，尽早确认 `can_use_*` 谓词在所有调用点的使用方式。
更新 AMD DSV4 配置：镜像 0914、PDI 20、cache-aware 路由
不需要精读，仅作为 DeepSeek-V4 部署配置演进的参考。值得留意的是：参数类文档变更若缺少基准数据，建议跟进一个附带 latency/throughput 验证的 PR；同时关注 0914 镜像与 cache_aware 策略在真实 MI355X 上的可用性。
修复 AMD 上 DSV4 MTP 崩溃，用 is_dspark 门控 D2H 优化
不值得精读，但值得记录。它展示了性能优化遭遇平台差异时的一种最小成本处理方式：不整体回滚，而是用 is_dspark 将优化限定在已知安全的平台。对 AMD 后端维护者而言，建议确认 is_dspark 覆盖了实际崩溃环境，并考虑补充自动化测试，防止回归。
为 DeepSeek-V4.1 补齐 Rust 侧图像预处理、KV 池名与 PD bootstrap 布局字段
值得精读，尤其适合关注多模态预处理实现和 PD 拆分启动期校验的工程师。
推荐关注的设计决策：
- `dsv41/mod.rs` 中"先做全量几何校验再计算"的防御式写法，以及用 256 项 bf16 LUT 替代逐像素浮点运算的性能取舍；`par::for_chunks_mut` 按 patch 分块并行是天然无数据竞争的分工方式，值得作为同类 preprocessing 的模板。
- `bootstrap.rs` 把一致性校验放进 `rcu` 闭包并让闭包在 mismatch 时"原样返回"，从而既不增加 `registered_count` 也不污染 `prefill_ranks`——这是一个值得学习的"校验失败不留副作用"写法，但要注意并发重跑闭包的语义细节。
- `PoolName` 的双向字符串映射分布在 `unified_tree_core.rs` 与 `python_bindings.rs` 两个文件，属于容易漏改的隐式契约，建议后续补充一个穷举 round trip 的 Rust 单测来锁死。
如果需要跟进，重点看后续 Python 侧 PR 是否与 `dsv41_spec_layout`、`deepseek_v4_c1/c2` 池名以及 `resize_patchify` 的签名严格对齐。
新增预填充图固定上下文参数，C4 索引器内存开销降 58%
值得精读。该 PR 展示了"固定上下文元数据 + 超限 eager 回落"的设计模式，以及如何把一个新的性能开关安全地嵌入 prefill CUDA graph 核心路径：能力标记（supports 属性）、启动期校验、守卫双保险（can_run_graph + 后端内 raise）。工程上也有借鉴意义：review 驱动的 getattr 禁令促使数据字段显式化，参数解析收敛到 server args 层而不是散落在 runner 中。关注后续 DSV4 系列演进（如 #39677）对这一契约的扩展。
修复工具调用序号、图填充计数契约、prefill 嵌入刷新等五项缺陷
值得精读。两个设计决策有学习价值：① 用"槽位存在性"表达数据契约——槽位不存在即契约无效，让 CUDA graph 静态批与 eager 批在两条路径上共享同一不变量，避免再次出现"graph 携带 stale 状态、eager 携带 None"的分叉；② replay 闭包处理输入槽位的模式——能从 kwargs、位置参数逐步回退到现场计算（get_input_embeddings），可复用于其他 graph runner 的输入刷新。建议合并前向作者确认非 EP 下其他 num_token_non_padded 读取点的审计情况。
