sgl-project/sglang · 标签视图

benchmark 启动改 spawn，修复 XPU/CUDA fork 崩溃

值得精读，但重点不在修复本身（核心只有一行），而在配套测试的设计：如何用 stub 掉设备探测、如何选择 patch 粒度（`BaseProcess` 而非 `get_context`）、如何断言进程类型来固定 spawn 语义。这是为"进程启动方式"类缺陷补回归测试的范例，对 `benchmark` 工具链及其他 spawn/fork 敏感代码的后续维护有参考价值。

让 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 的消费方依赖行连续布局。

Qwen-VL 快路径兼容 `<image>` 哨兵并加回退兜底

值得精读。这是一个典型的「性能快路径引入新不变量、破坏旧输入形态」的回归修复，代码量小但信息密度高：1）推荐重点看 `_normalize_prompt_for_fast_path` 如何用一次 `subn` 同时完成替换与计数、并在 chat template 场景下退化为 no-op 以保住 LRU 缓存与 H100 收益；2）看 `compose_image_artifacts` 把它自己从“必须成功”改造成“可以失败”的 `Optional` 契约，以及调用方 `process_mm_data_async` 的三段式兜底——这套模式可以直接复用到其他多模态处理器的 artifact 快路径。 阅读时建议带着三个待办：确认 CUDA 侧 `<image>` 回归测试是否已经补上（PR 未做）；评估字面 `<image>` 文本被误判为图像槽位的边界（当前无讨论、无测试）；以及把 `"prompt placeholders"` 这类基于错误文案的异常判定改为更稳的判别方式（例如专用异常类型）。若你是多模态链路的 owner，也值得顺手核对其他 `generates_input_ids_from_raw_prompt = True` 的处理器是否有同类不变量假设。

新增 Mamba-1/2 纯 SSM 模型推理支持

值得精读，尤其是 Mamba-1 如何在不新增 state cache 实现的前提下复用 Mamba2 后端。建议按以下顺序阅读：先看 `configs/mamba.py` 与 `configs/mamba_utils.py` 的 `Mamba2StateShape.create_full_rank`（理解 `num_heads = intermediate_size`、`head_dim = 1` 的状态布局映射），再看 `layers/attention/mamba/mamba1.py` 的 `_ssm_params`/`forward`（理解三元返回契约与 radix/投机断言的由来），然后是 `models/falcon_mamba.py` 的 `use_bc_dt_rms` 参数化与统一 `load_weights`（review 驱动的复用设计），最后看 `configs/model_config.py` 的 SSM 分支与 `utils/hf_transformers/config.py` 的 `_try_load_raw_mamba_config`。生产落地前建议确认两点：一是长上下文场景是否接受当前 Mamba-1 prefill 吞吐（等待 Triton scan kernel），二是运维侧能否接受 `--disable-radix-cache` 这一约束；此外可在非 XPU 设备上补一条 runtime 冒烟测试以扩大覆盖。

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 的最低版本约束。