ByteDance-Seed / ByteDance-Seed/Triton-distributed
[Question] For gemm_rs kernel, does FUSE_SCATTER option achieve better performance or the non fused one?
- Dominant language
- Python
- Stars
- 1.5k
- Forks
- 172
- PR merge metrics
- No merged PRs in 30d
Description
Hello! quick question about performance. specifically for GEMM + ReduceScatter.
Notice in the kernel below,
https://github.com/ByteDance-Seed/Triton-distributed/blob/3edf7618f493c2c71d31ed3ed10bfb466a90ef82/python/triton_dist/kernels/nvidia/gemm_reduce_scatter.py#L210
the persistent gemm part has two branches, one with FUSE_SCATTER (seems like similar with the idea of FLUX), the other one is non fused scatter option and running separate `reduce_scatter` on the backend stream.
Curious which option in practice achieves better performance? And does this kernel utilize NVSHMEM?
Also, regarding the perf claimed in README.md, which implementation you guys chose to use?
One last question, for the flux performance here in this graph, assuming it is flux_triton version kernels? (or the CUTLASS ones)?
Thanks in advance!
Contributor guide
Research direction
Start with python/triton_dist/kernels/nvidia/gemm_reduce_scatter.py around line 210 and the repository README.md. Compare the FUSE_SCATTER and non-fused paths, check the referenced performance claims and implementation choices, and verify whether NVSHMEM is involved. Done means the README or issue has clear, supported answers to each performance and kernel-variant question.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- distributed-systems, performance
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100