文档
重要性 4.56
洞察度 3.00
更新 AMD DSV4 配置：镜像 0914、PDI 20、cache-aware 路由
不需要精读，仅作为 DeepSeek-V4 部署配置演进的参考。值得留意的是：参数类文档变更若缺少基准数据，建议跟进一个附带 latency/throughput 验证的 PR；同时关注 0914 镜像与 cache_aware 策略在真实 MI355X 上的可用性。
sgl-project/sglang · 标签视图
标签列表
聚合结果
documentation 相关 PR
2026-09-16
重构
重要性 9.00
洞察度 5.00
清理 SRT 大量死代码与废弃测试，净删 3159 行
值得精读，尤其适合作为“大规模死代码清理”的范例：PR body 给出了每类删除的可验证论证（调用方扫描、import 检查、动态查找、测试矩阵隔离对比），并量化了删除的测试收益与保留项。值得关注的设计决策包括：缓存键简化为 UUID 列表、用 main/PR 测试计数差精确对齐删除的测试用例、以及删除 scanner 测试但保留行为测试的“迁移后退役守卫”模式。对编译、模型加载与 HiCache 模块维护者，建议留意编译缓存键变化与三个守卫测试退役后的长期影响。
文档
重要性 3.67
洞察度 2.00
Qwen3.5 MI355X HiCache 文档改回 kernel 与 page_first 后端
该 PR 本身不值得精读：6 行改动、无讨论、无测试。但值得关注两点：一是 cookbook 命令生成器与真实部署命令的一致性维护机制（recipe-link MAJOR-arg 检查），二是它与 #39358 的一来一回可作为 AMD HiCache 后端选型（`kernel` vs `direct`）演进的观察线索；若后续镜像版本再次调整 flag，应同步检查这份文档。
2026-09-15
文档
重要性 3.51
洞察度 1.00
NPU 文档移除 4 个不受支持模型条目
不需要精读。建议只做两件事：一是 NPU 相关使用者快速扫一眼删除清单，确认自己在用的模型是否被从矩阵中摘掉，避免继续按旧版本文档尝试部署；二是关注该文档线后续是否会补充「为什么移除」的依据，或引入更可追溯的支持状态标记（例如区分「已验证 / 社区贡献 / 不支持」），否则纯粹的整行删除会让支持矩阵的维护历史难以回溯。设计决策层面没有值得借鉴的工程技巧，价值主要在于领会「支持矩阵类文档需要可追溯的删改理由」。
文档
重要性 5.43
洞察度 3.00
NPU 文档统一改用 Ascend A2/A3 系列产品名
作为纯文档重命名 PR，不需要精读全部 diff；但维护文档 Playground 或 NPU 配方文档的同学值得关注两点：一是 _deployment.jsx 与各 Deployment 组件里 label/targetTabName 和 MDX Tab 的跨文件一致性契约，二是本文确立的 "A3 Series" 与 "Ascend A3 Series Products" 命名分层。后续 NPU 文档改动应以此 PR 为命名基线，避免再次引入 Atlas 800I/910B/910C 等旧名。
文档
重要性 6.12
洞察度 6.00
为 RTX 5090 新增独立 H3 部署配方与实测提示
值得精读。该 PR 虽然只是文档，但展示了三个可迁移的工程模式：一是为文档化配置建立可验证的定量模型（磁盘吞吐公式），二是用 hard-cap 模拟与物理实测交叉验证的基准方法论，三是"单卡/多卡分流"的部署矩阵判定函数 `consumerSingleCard`。对部署 H3 的 RTX 5090 用户，重点读 cookbook 新增的 "RTX 5090 single card, physical desktop" 一节与磁盘吞吐提示；对引擎开发者，PR body 中关于 pin budget、O_DIRECT courier 与 compute wall 的分析是理解 diffusion offload 路径的关键背景。
2026-09-14
#39406 [AMD] GLM-5.2 MI355X MXFP4: bump image to 20260913, enable TOPK_V2
原始 PR · 作者 ChangLiu0709 · 合并时间 2026-09-14 21:50
文档
重要性 4.05
洞察度 4.00
GLM-5.2 MI355X MXFP4 配方升级镜像并启用 TOPK_V2
**是否值得精读**：源码层面不值得精读——没有任何逻辑实现，全文 14 行 diff，属于典型的文档/配置同步，3-5 分钟即可看完。 **值得关注的设计决策**：一是镜像 tag 与 env flag 的耦合关系，建议在 `docs/src/snippets/configs/zai-org/glm-5.2.jsx` 的 `dockerImages` 条目旁就地加注释，或在 MDX 里补一句「TOPK_V2 需要 20260913 及以上镜像」，把隐含前提显式化；二是用 Revert 收敛范围的取舍，如果确实需要解释 HiCache arm，应把说明放在 InferenceX 侧，而不是回流到 cookbook。 **给后续维护者的动作建议**：(1) 若计划对外发布该配方，补一次 MI355X 实机精度/性能快照，别只依赖 reviewer 的经验判断；(2) 在 InferenceX#3081 合并后回头核对镜像 tag 与并发点集是否仍一致，避免短期漂移；(3) 排查 PR body 中 “PR Test (Extra)” 失败的原因，确认它与本次文档改动无关。
#39396 [docs] DeepSeek-V4: MI355X PD disaggregation recipes for all three strategies
原始 PR · 作者 ichbinblau · 合并时间 2026-09-14 17:11
文档
重要性 7.87
洞察度 6.00
DeepSeek-V4 MI355X 补齐三档 PD 配方及 Playground 生成器支持
值得精读，但读者要分层看。维护 cookbook 或 Playground 的人应重点读 `_playground.jsx` 的四组扩展点（`roleOverrides`、`forceOff`、`notes`、`resolveRouter`）及其隐含契约——它们实际上把"哪些 flag 属于哪个 operating point"这类业务约束编码进了展示层，是这套配置引擎的重要演进方向；只关心 MI355X 部署的人读 `DeepSeek-V4.mdx` 的 §3.8 与 `deepseek-v4.jsx` 的三档 role 配置即可。建议关注两个设计决策：一是用 `forceOff` 而非让用户自行判断 DP 开关（因为命令里两个 flag 不变、后果却不同），二是用 `roleOverrides` 而非在下拉里堆重复项来表达同一 role 的多档 sizing。后续最值得补的是生成命令的快照测试：当前改动会改变其他 cell 的输出，却完全依赖人工浏览器比对。