标签列表
聚合结果
原始 PR · 作者 xinguozhu-2026 · 合并时间 2026-09-16 12:31
CPU 新增 FP8 per-tensor GEMM 内核，W8A16 量化加速
值得精读。核心亮点是把 per-tensor scale 作为 block-scale 的特例来复用现有 tinygemm 框架，避免重写一套 GEMM；has_bias 通过模板参数在编译期展开，配合 AT_DISPATCH_BOOL 避免运行时分支；测试参数化覆盖了 scale 张量维度、prepack 与 bias 组合。建议读者关注模板泛化对既有调用点的契约影响，以及 CPU AMX 前置条件在前端如何被强制校验。
原始 PR · 作者 Yuxingwang-intel · 合并时间 2026-09-16 10:01
为 CPU 扩散模型新增三个融合 norm / scale-shift 内核
值得精读，尤其是要在非 CUDA 平台写融合内核的工程师。重点关注四个设计决策：一是用 `DiffusionNormMode` 编译期 tag + `DiffusionNormTraits` 让 RMSNorm/LayerNorm 共享一套 row kernel，避免复制两遍几乎相同的向量循环；二是把广播语义全部推给 Python 的 `expand_scale_shift_cpu_param`，让 C++ 只面对 `stride_c ∈ {0, 1}`，这是把「组合爆炸」挡在语言边界之外的好例子；三是用「两个 gate 指针」而不是 `gate_t` 模板派发来兼容 Hunyuan（activation dtype）与 Wan（FP32）两种 gate，代价是函数多一个参数、收益是少一层 dispatch；四是刻意复刻 CUDA 的 activation-dtype 边界以保证跨设备数值一致，读代码时要留意那两处 `convert_from_float_ext` / `static_cast<scalar_t>` 往返并非冗余。读法与风险相关：`normd.cpp` 前半（dispatch 与 helper）与 `layernorm.py` 的两处 `forward_cpu` 是主干，`torch_extension_cpu.cpp` 只是样板注册可略读；建议同时留意 `custom_op.py` 中 `forward_cpu` 默认回退的语义翻转，以及测试未覆盖的非连续输入与 4D 广播分支。
新增 CPU 融合 QK-Norm/RoPE 内核并接入共享路径
值得精读，尤其是 CPU 后端、Kernel 与模型接入方向的同学；如果只关心 CUDA 性能可以略读，但 `apply_qk_norm` 的改动属于共享路径，仍建议确认自己维护的模型是否受影响。重点看三处设计决策：一是 CPU 版为何选择「消费预计算 cos_sin_cache」而非像 CUDA 版重算 YaRN 参数，这既是性能取舍也是能力边界；二是 `can_use_fused_qk_norm_cpu` 的门控条件集合（eps 相等、stride(-1)==1、head_dim 整除）如何界定原地写回的合法输入；三是 `apply_qk_norm_rope` 被重构为单一 use_fused 分支后，`_used_fused_qk_norm_rope_last_call`、`fused_set_kv_buffer` 等既有语义是否在 CPU 路径下仍然成立。后续若要扩展，优先补 partial rotary_dim 与 YaRN 场景测试，并把 `_match_cos_sin_cache_dtype` 这类私有接口的使用显式化。
修复 HiCache 启动时 ImportError 崩溃
值得精读，但属于中等篇幅即可读完的 PR（3 文件、+83/-5）。重点看三处：(1) `_resolve_device_accessible_ptr_fn` 的双重存在性检查（import + `torch.ops`）与 `lru_cache(maxsize=1)` 的收敛设计，这是跨仓库发布顺序错配时的通用处置模式；(2) HIP 上 fail-fast、CUDA 上 fail-soft 的平台分工，背后的依据是 UVA 下 host/device 地址别名关系；(3) 测试如何用 `alloc_with_host_register` + monkeypatch resolver 直接验证回退等价性，以及为什么在缺 op 时选择 skip 而不是 fail。阅读时请额外确认夹带的 `unified_radix_cache.py` 选择器改动（`req_id` → `request.rid`）在本仓库当前签名下确实必要，这行改动没有配套测试。若你是部署/CI 维护者，可作为「AOT op 与调用方必须分两个 PR 落地」的案例收藏。
原始 PR · 作者 sglang-bot · 合并时间 2026-09-14 11:49
sglang-kernel 依赖升至 0.4.7，同步三处引用
不值得精读，属于机械的依赖升版 PR。值得关注的不是代码本身，而是版本管理流程：aot 侧 pyproject.toml 作为版本定义源头，bot 自动同步主仓库三方引用。合入前需重点确认 CI Extra 车道的失败是否与 0.4.7 相关。
原始 PR · 作者 sglang-bot · 合并时间 2026-09-14 06:48
sgl-kernel 版本统一升至 0.4.7，覆盖四大平台构建配置
不值得精读，属于机械的版本号同步。建议重点做两件事：确认上游 sgl-kernel 0.4.7 wheel 已成功发布，以及排查 PR 中三个 CI 失败的具体原因。该 PR 的价值在于维持多平台版本契约的一致性。
FlashMLA 升版接入 V4.1 内核并补 B300 原生编译
值得精读。本 PR 是外部内核 fork 依赖升级的典型样本，重点关注三处：一是 pin 升级伴随上游目录重构时的适配模式（路径改写 + 手工前向声明 + shim 编译单元）；二是 sm_103a 编译目标的量化取舍，commit message 里给出了完整的回归与收益数据；三是测试探针 prompt 设计的统计思维——先确认被测对象在 base 模型上有固定答案，再谈度量。对需要维护 sgl-kernel 或处理类似第三方程内核集成的工程师，这些决策记录比代码本身更有参考价值。
退役 CUDA 12 构建发布通道，为 PyTorch 2.14 铺路
值得精读，尤其对负责发布流水线、镜像与依赖管理的工程师：这是一次「删除为主」的 PR，真正的决策密度集中在少数几处。建议重点关注三点：一是 `scripts/update_kernel_whl_index.py` 把 CUDA 版本白名单替换为 `+cuNNN` 正则匹配——这是 fail-closed 的稳健性提升，杜绝了未来新 CUDA 版本的 wheel 误入 cu130 索引，值得作为同类脚本的范式；二是 `_docker-build-and-publish.yml` 中 manifest 固定使用 cu130 digest 后 `tag_config.cuda` 字段被静默忽略，建议合并后排查所有调用方并显式拒绝（或警告）非 cu130 的 `cuda` 取值；三是给 `check_wheel_cuda_version` 补一组针对 `+cu129` / `+cu130` / 无标记 / `+rocm720` 的单测。对 CUDA 12 用户，应在 release notes 中明确「v0.5.19 为最后一个 CUDA 12 版本」以及升级到 CUDA 13 的路径，避免他们从新的报错提示里得不到有效指引。