sgl-project/sglang

JIT 内核统一迁入 namespace sglang

值得精读，尤其是 compile.py 中 _make_sources 的设计思路，以及如何在宏大重构中通过全量测试发现隐藏 bug（B200 特有分支、nvcc 延迟查找）。该 PR 展示了大规模全局重构的规范性执行方式，可以借鉴其任务拆分、测试验证和文档同步的方法。

单 CTA Triton align 内核，让宽专家 MoE 解码每层少一次 launch

值得精读，尤其是对 Triton 内核优化和 kernel 测试感兴趣的工程师。核心看三处：pair 轴 vs expert 轴的推导与实测结论（为什么 pair 轴是唯一赢的方案）、两处有意语义偏差的契约论证（桶内稳定序、尾部不写）、以及 gate 四条件的取舍（为什么 64 桶以下留给 CUDA）。测试文件里的纯 torch oracle 与 blockwise 双重校验写法可以直接借鉴到其他 kernel 测试。

Sana 融合 adaLN 内核，BCG 下去噪提速 4.8%

值得精读，尤其是三点： 1. `_sana_ln_modulate` 的"按执行上下文条件融合"设计——把 Python 发射开销与 GPU kernel 时间分开度量，只在回放零成本时启用融合，是 CPU-launch-bound 场景下很实用的取舍； 2. 位精验证 + 白名单 + 永久禁用三层兜底，让加速路径在无法保证数值一致的环境里自动让位，可作为高风险优化的默认策略； 3. tail chunk 掩码对 aten 串行 Welford 顺序的复刻细节，连同 #34008 一起构成现成的"任意 hidden 都能位精融合 LN+modulate"的基础设施。 建议后续 FLUX.1（#34004）接线时复用本 PR 的 raw 变体与验证框架。

多节点 MNNVL 自动启用 CUDA VMM 多模态传输

值得精读。重点看三个设计决策：一是 `server_args._handle_multimodal_feature_transport` 的分层自动选择策略（单节点 cuda_ipc / 多节点 MNNVL cuda_vmm / cpu 兜底），是"安全默认值自动选择"的范例；二是模型类属性 `supports_cuda_vmm_feature_transport` 作为 opt-in 契约的模式，扩展成本极低；三是 `_resolve_transport_consumer_count` 的钳制逻辑，解决了 DP 注意力下全 TP 确认的错误释放问题。建议阅读时结合 #33899 的传输实现，并关注后续多节点实测 PR。

trtllm_mla 禁用 piecewise prefill 图，修复 TTFT 回归

值得精读。PR 虽小，但展示了"默认值升级 + 后端例外 + 显式覆盖"的三层优先级设计，是分析 CUDA graph 与 MLA 注意力后端兼容性规则的好入口。建议结合 #30889（回归源头）和 #32288（同区域正交修复）一起阅读，能快速理解 sglang 中 prefill CUDA graph backend 选择的演进逻辑。

Inkling MoE 激活内核迁移纯 Triton，移除 helion 依赖

值得精读。三个看点：一是 bitwise 级内核移植方法论（复刻运算顺序、仅 store 一次 cast、用独立 harness 做 88/88 逐位对比）；二是性能工程细节（BLOCK_M==1 时 mask 省略、evict_last/evict_first 缓存提示、N-fastest 光栅化、tile/warp 扫描直至编译后 PTX 指令混合与 helion 一致、63 寄存器 0 spill）；三是用两个静态 mask 内核加小 launch 启发式替代整套 AOT autotune 配置表体系的设计决策，是消除第三方运行时 codegen 依赖的典型范例。同时注意其仅 sm_100 实测的验证边界，若团队在非 Blackwell 架构上运行 Inkling，建议补充一次基准对比。

恢复 /generate 的 data_parallel_rank 别名，修复 dp 路由静默失效

值得精读。代码改动极小（41 行），但 PR body 呈现了教科书式的“静默失败根因分析 + 兼容矩阵 + 选项空间”论证，适合在跨组件契约维护中借鉴。可重点关注两点：一是 normalize_batch_and_arguments() 作为归一化喉点的选择理由（覆盖所有构造路径、与 #19268 原始映射一致）；二是作者关于 gateway 在弃用窗口内双发字段的建议是否已作为 follow-up 落实。

Docker 镜像改用 sgl-deep-ep 发布 wheel，删除 DeepEP 源码编译阶段

值得快速浏览，作为「从源码编译迁移到发布 wheel」的 Docker 依赖治理范例。关注三点：一是 CUDA 12 用 cu129 wheel + PEP 440 local version 满足公开版本约束的技巧；二是从 pyproject 单一来源读取版本避免双重 pin 的实践；三是确认原 configs.cuh 超时定制是否已内置于发布 wheel，这决定是否存在潜在的通信超时行为变化。