根据PR body，SM120 fp8 blockwise GEMM kernel使用KernelScheduleAuto作为schedule，在SM120上只选择cooperative kernel，导致小M时性能不佳。pingpong schedule相比cooperative对于小M快约2倍，因此需要优化以利用这一性能机会。
建议技术管理者关注此PR，因为它展示了性能优化的实际收益和硬件特定调优。工程师值得精读代码，学习基于运行时条件的schedule选择策略和CUTLASS集成最佳实践。
review过程中无实质性技术讨论，仅由BBuf批准。作者在issue评论中提供了NCU性能报告，进一步验证了性能改进，如pingpong schedule相比cooperative schedule性能提升约一倍。
修改位于sgl-kernel/csrc/gemm/fp8_blockwise_gemm_kernel.cu的launch_sm120_fp8_blockwise_scaled_mm函数。关键改动包括：添加kCanUsePingpong检查；根据M大小（M≤64）选择pingpong路径使用KernelTmaWarpSpecializedBlockwisePingpongSm120，否则使用cooperative路径；重构kernel setup以提高代码清晰度。
| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
sgl-kernel/csrc/gemm/fp8_blockwise_gemm_kernel.cu |
sgl-kernel/gemm | modified | 9.0 |
分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。
作者 b8zhong 在 issue 评论中分享了 NCU 报告，显示 pingpong schedule 相比 cooperative schedule 在 SM120 上性能提升约一倍。
结论：性能数据支持 PR 变更的有效性。 · 已解决
BBuf 评论 '/tag-and-rerun-ci again'，指示重新运行 CI 测试以确保变更稳定性。
结论：CI 通过，PR 被批准合并。 · 已解决
风险点包括：对于M>64使用cooperative路径以避免CUTLASS库问题，但可能存在未解决的准确性隐患；新添加的pingpong路径可能引入回归或兼容性问题，尤其是在不同硬件或配置下；代码变更集中在核心GEMM内核，缺乏充分的单元测试覆盖。
对用户影响：在SM120 GPU上运行小M形状的FP8 GEMM时，推理速度显著提升，如基准测试显示速度从34.14 token/s提升至52.11 token/s。系统层面，优化了内核调度，可能减少延迟和提高吞吐量。团队需关注CUTLASS依赖的潜在问题。
当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。
本PR优化了SM120 GPU上的FP8块状GEMM内核，通过引入pingpong schedule并基于M大小动态选择，显著提升了小M场景下的性能，推理速度提升约53%，同时保持了准确性。
原SM120 fp8 blockwise GEMM kernel使用KernelScheduleAuto，在SM120上仅选择cooperative schedule，导致小M时性能不足。pingpong schedule相比cooperative对于小M快约2倍，因此本PR旨在利用这一性能机会，提升整体效率。
关键改动集中在sgl-kernel/csrc/gemm/fp8_blockwise_gemm_kernel.cu文件的launch_sm120_fp8_blockwise_scaled_mm函数：
kCanUsePingpong常量检查。KernelTmaWarpSpecializedBlockwisePingpongSm120，否则使用cooperative路径。代码示例：
constexpr bool kCanUsePingpong = (64 % ScaleGranularityM == 0);
int m = a.size(0);
// ... 基于m选择schedule
review过程中无实质性技术讨论，仅由BBuf批准。作者在issue评论中提供了NCU性能报告，进一步验证了变更的有效性，例如pingpong schedule相比cooperative schedule性能提升约一倍。
风险：
影响：
本PR性能测试中与FlashInfer比较，关联到PR #20214（添加FlashInfer集成），表明团队在持续优化性能并集成第三方库。此外，无直接关联Issue，但体现了对硬件特定调优的关注。
参与讨论