sgl-project/sglang · 标签视图

DCP KL 测试切换 MLA 后端并回退 bf16 KV

值得精读，但重点不在代码（+2/-4 的测试参数切换，几分钟即可看完），而在 motivation 里的因果链：一次 attention backend 解析逻辑的改动（#35770 unwrap `HybridLinearAttnBackend.full_attn_backend`）如何让 Kimi Linear prefill 意外落入 FP8 量化钩子，并把 KL 从 0.003-0.006 抬到 0.007-0.013。建议关注三个设计决策：(1) 为什么选择换后端而不是放宽阈值——保持了测试的判别力，是正确的取舍；(2) 为什么 `cutedsl_mla` 更合适——它是 SM100 上的 DCP 原生 MLA 内核，且已被 Kimi Linear DCP 测试采用，避免为单个测试保留一条非主路径；(3) 遗留问题——是否应把“tokenspeed_mla + fp8 KV + DCP”组合的精度损失记录为已知限制，或单独加一个小规模的 FP8 KL 守护测试，并考虑把阈值从 0.01 收紧到约 0.008 以保留回归灵敏度。

验证路径复用解码融合准备，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 诊断，不能直接当作上线依据。

FlashMLA 升版接入 V4.1 内核并补 B300 原生编译

值得精读。本 PR 是外部内核 fork 依赖升级的典型样本，重点关注三处：一是 pin 升级伴随上游目录重构时的适配模式（路径改写 + 手工前向声明 + shim 编译单元）；二是 sm_103a 编译目标的量化取舍，commit message 里给出了完整的回归与收益数据；三是测试探针 prompt 设计的统计思维——先确认被测对象在 base 模型上有固定答案，再谈度量。对需要维护 sgl-kernel 或处理类似第三方程内核集成的工程师，这些决策记录比代码本身更有参考价值。

cookbook 新增 NVIDIA NVFP4 导出并修复 5090 启动参数

值得 cookbook / 文档系统维护者精读：① 用逐字节对比 config.json 证明两个 checkpoint 等价从而合法复用配方的验证方法；② 前缀测试 vs 显式枚举的教训——`String(quant).startsWith("nvfp4")` 在新增导出后静默出错；③ 文档配置中 stripPrefixes 与 flags 必须成对维护的设计约束。对普通用户，重点是确认新导出的可用性结论（202 cell 全量 GSM8K 实测，NVIDIA 导出在全部三张卡上是得分最高的 NVFP4 checkpoint）。

裁剪 DSV4 trtllm B200 CI：删重复测试文件、4 个 recipe 收敛为 2 个

值得一读，尤其是维护 DSV4 后端 CI 与测试基础设施的同学：这是一份罕见的把「删测试」写成完整覆盖映射的 PR。建议重点关注三点：(1) 被删文件独有能力与被保留类的映射是否真的完备，特别是「TP4、非投机、非 DP」组合是否需要补一个最小 e2e（可以从 BCG 类去掉 --dp / --enable-dp-attention 派生）；(2) test_long_prompt_chunked_prefill_recall 的跨 chunk needle 召回写法值得作为模板沉淀进 test kit；(3) est_time 与实测耗时的对齐方式（per-file、~460s → 500）以及合并前 CI 失败重跑的流程，是否需要在团队内形成统一约定。

为 DeepSeek-V4.1 cookbook 剩余 NVIDIA cell 补齐 DSpark decode CUDA graph 启动上限

值得精读的是「为什么」，不必精读「改了什么」——单文件、31 行新增、纯配置。建议关注三点：(1) `verified` 徽标的可信度机制靠人工实测表格而非 CI，可以思考是否要为 cookbook 关键 cell 增加最小启动冒烟测试；(2) DSpark 下 decode CUDA graph 捕获显存与 `--cuda-graph-max-bs-decode` 的耦合关系，以及 H200 为何必须额外压低 `--mem-fraction-static`，这直接影响自建部署的显存规划；(3) 若你要部署 DeepSeek-V4.1，请整段复制对应 cell 的 flags，不要把 Low-Latency 的 cap 与 High-Throughput 的 `--max-running-requests 256` 混搭——后者是刻意不加 cap 的。另外注意本 PR 的 CI 中 PR Test (Extra) 失败、AMD 未跑，人工实测结论是主要依据。

回滚 #38770，恢复 GB300 相关的 CI 与发布工作流任务

值得快速过一遍而非精读：变更本身是机械取消注释，逻辑直白，核心价值在于理解两点设计决策。第一，#38770 采用「整段注释 + 保留 run_suite.py 注册与 runner_configs.yml 条目 + 保留 rust-ext-build-aarch64 缓存」的临时禁用范式，使恢复成为零冲突 revert，这值得作为团队处理「runner 故障需临时摘除 CI 阶段」的标准做法。第二，本次回滚暴露了基础设施侧的未闭环问题：建议跟进 runner 自愈/健康检查（例如把 runner 安装到持久层、或在 label 无 runner 时让 stage 快速跳过而不是无限排队），并澄清同批 `4-gpu-b200` 上 `test_kda_prefill.py`、`test_numa_utils.py` 的失败是否与本改动相关。

修复 V4.1 Cookbook 推理示例并补 NVIDIA 启动内存配置

值得精读，但重点不在代码：本 PR 的价值集中在 PR body 对 reasoning 参数契约的分析与 OOM 排查数据上，任何要在 DeepSeek-V4.1 上接 reasoning 或 tool calling 的工程师都应读完 §3.1 相关段落，只看 diff 会误以为它只是加了一个 flag。三个值得关注的设计决策：（1）打开 thinking 走请求侧 reasoning_effort，而不是要求用户设置服务端环境变量，因为 normalize_reasoning_inputs 会自动同步 chat_template_kwargs.thinking；（2）OOM 修复首选收敛 --cuda-graph-max-bs-decode，只在 H200 上叠加降低 --mem-fraction-static；（3）文档里显式区分“能启动”与“已调优”，避免读者把 64 当性能参数。建议动作：复核合并后的 deepseek-v4_1.jsx，确认 H200 / B200 cell 是否确实带上了 cap 与 verified，必要时补一个后续 PR；并考虑把真机验证矩阵以更机器可读的形式落盘，减少人工表述与文件内容之间的漂移。