sgl-project/sglang · 标签视图

CPU 新增 FP8 per-tensor GEMM 内核，W8A16 量化加速

值得精读。核心亮点是把 per-tensor scale 作为 block-scale 的特例来复用现有 tinygemm 框架，避免重写一套 GEMM；has_bias 通过模板参数在编译期展开，配合 AT_DISPATCH_BOOL 避免运行时分支；测试参数化覆盖了 scale 张量维度、prepack 与 bias 组合。建议读者关注模板泛化对既有调用点的契约影响，以及 CPU AMX 前置条件在前端如何被强制校验。

让 fused_moe_triton 调优器支持 XPU，并新增 Arc Pro B60 的 DeepSeek-OCR-2 MoE 调优配置

值得精读，尤其是正在做多后端 Triton kernel 调优或维护 MoE 相关 benchmark 工具的工程师。三个值得关注的设计决策：一是用 `get_device_module` 一次性收敛同步、事件、图捕获与播种，避免在 kernel 里写 XPU 专用分支，这是「最小持续成本」路线的具体落地；二是 `clear_b_tma_desc_cache` 揭示的隐藏耦合——描述符缓存与图捕获内存争用，在长生命周期服务的语境下为什么是 no-op；三是把 topk_ids 层布局从硬编码改为从模型配置解析，代价是引入了对模型元数据字段的隐式依赖。阅读时建议同时对照 Intel Triton issue #7306 / #7691 与 PR body 中的 workload 结果表，并留意 `tuning_fused_moe_triton.py` 与 `_sep` 版本仍需保持行为一致，以及 review 中 airMeng 提出的下一步方向（KV cache store 等 memory-bound kernel）。

XPU 块状 FP8 线性改用 torch scaled_mm，并预排布 scale 存储

值得精读，但重点不在算子本身，而在三处工程决策：一是派发层级的选择（把平台分支放进 _dispatch_auto_backend 而非顶层，保证显式 backend 仍可覆盖），这是容易被写错且直接破坏用户配置的细节；二是用公开 API torch.nn.functional.scaled_mm + ScalingType 显式表达 activation 与 weight 两套 block scale 配方，替换私有 torch._scaled_mm 关键字参数写法，可读性与前向兼容性都更好；三是把 scale 的 transpose-contiguous 物化提前到 process_weights_after_loading_block_quant，属于典型的「热路径代价前移」优化。建议后续补充：XPU 上 Triton vs scaled_mm 的延迟对比数据、在派发处增加 torch 版本/能力兜底，以及确认除 w8a8_block_fp8_linear 之外没有其他读取 weight_scale_inv 的消费方依赖行连续布局。

为 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` 这类私有接口的使用显式化。

XPU kernel 依赖由 git 源码直装改用 0.2.0 发布 wheel

值得花 5 分钟速览，不建议深读：改动只有一行，但它是 XPU 安装链路的“唯一入口”，理解它与理解一个内核 PR 同等重要。关注三点决策：一是 glibc>=2.38 / cp310-abi3 的平台约束是否符合你们现有 XPU 镜像基线；二是「固定 URL 直链 vs git 源」的取舍是否要补 `#sha256=` 校验或用内部索引代理；三是升级流程——建议在提交里同时声明 wheel 的对应 commit 与发布脚本位置（如 sgl-project/whl 的 tag），否则半年后难以判断 0.2.0+xpu 与哪个源码版本对应。此外，若你们自建 XPU 镜像，请确认 Dockerfile 中不存在与本次 URL 不一致的第二处安装点。

XPU 平台新增 DFLASH 投机解码支持与端到端测试

值得精读，但重点不在代码量（源码仅 +36/-19），而在三处设计决策：一是 xpu_backend.py 把 non-causal 语义从 is_cross_attention 扩展到 ENCODER_ONLY / DECODER_BIDIRECTIONAL，这是 DFLASH draft 双向注意力能在 XPU 上工作的前提，也是本 PR 唯一改动通用注意力路径的地方，建议与 FlashAttentionBackend 逐行对照确认无遗漏分支；二是 dflash_utils.py 中 _DFLASH_VERIFY_SKIP_CUSTOM_MASK_BACKENDS 的语义（只在 decode graph capture 时生效）以及它与 topk==1 的关系，这决定了新增的 decode-graph 用例是否真能覆盖到新代码；三是 draft attention backend 的默认值选择尚未闭环，跟进 mingfeima 的结论可避免 XPU 用户长期停留在次优后端。测试文件的基类复用与 sys.path 处理技巧也值得借鉴。

Gemma3RMSNorm 新增 XPU forward，并补齐 2D/3D/4D 测试覆盖

推荐精读，但属于小范围平台补齐，可快速浏览。建议重点关注三点：(1) `forward_xpu` 中三种分支的取舍——为什么 3D/4D 只在 `residual is None` 时走 kernel，以及这如何与 CUDA 分支产生语义分叉；(2) `_run_gemma3_rms_norm_test` 的 `non_contiguous` 分支，它是理解 Gemma3 q_norm/k_norm 真实视图形状的最佳入口；(3) review 暴露的流程问题——设备相关测试放在 `test/manual` 无法形成 CI 门禁，若后续要复用这套用例，应参考 #32093 的做法迁入 XPU nightly。此外建议顺手清理已失效的 "other dim == 1" 注释，并明确 sgl-kernel-xpu 的最低版本约束。