Conversation
…AOT) Port sgl-kernel/csrc/moe/prepare_moe_input.cu to the lightweight JIT kernel system, matching the sgl_kernel call signatures. Replaces CUTLASS (cutlass::Array) and FlashInfer (flashinfer::vec_t) dependencies with self-contained lightweight equivalents: - cutlass::Array<T,N> → uint4 for 128-bit dtype-agnostic row copies - flashinfer::vec_t<t,N> → FloatVec<scalar_t,N> (float accumulator with cast_load/cast_store using CUDA intrinsics) Three exported functions: - prepare_moe_input: compute expert offsets, GEMM problem sizes, and token permutations (input_permutation, output_permutation); supports optional blockscale_offsets for FP8 MX block-scale workflows - shuffle_rows: dtype-agnostic 128-bit vectorized row gather (returns new tensor matching sgl_kernel.shuffle_rows API) - apply_shuffle_mul_sum: gather rows by permutation, scale by topk weights, and reduce over the topk dimension using float32 accumulators Files: - csrc/moe/prepare_moe_input.cuh: all kernels + tvm-ffi host launchers - prepare_moe_input.py: cache_once/load_jit wrappers, register_custom_op - tests/test_prepare_moe_input.py: 75 correctness tests vs PyTorch reference and optional cross-validation vs sgl_kernel AOT - benchmark/bench_prepare_moe_input.py: JIT vs AOT throughput comparison
Apply clang-format and black fixes from pre-commit hooks.
Summary of ChangesHello @Johnsonms, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a new set of JIT (Just-In-Time) kernels for Mixture-of-Experts (MoE) operations, porting existing functionality from a heavier Ahead-Of-Time (AOT) kernel system. The primary goal is to streamline the MoE pipeline by replacing complex external dependencies with optimized, self-contained CUDA implementations, thereby improving the efficiency and maintainability of MoE computations. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
The pull request successfully ports sgl-kernel AOT kernels to JIT kernels, specifically for MoE input preparation, row shuffling, and gather-scale-reduce operations. The changes include replacing heavyweight third-party dependencies with lightweight equivalents, which is a good design decision. The Python wrappers and benchmark scripts are well-structured, and the tests cover correctness against PyTorch references and AOT kernels. The overall code quality is good, and the implementation aligns with the stated motivation.
| dim3 grid(static_cast<unsigned>(m)); | ||
| dim3 block(block_threads > 0 ? block_threads : 1u); | ||
|
|
||
| apply_shuffle_mul_sum_kernel<scalar_t><<<grid, block, 0, stream>>>( |
There was a problem hiding this comment.
I would recommend LaunchKernel, which has extra error checking after kernel launch.
Replace hardcoded kThreadsPerExpert stride with blockDim.x in compute_problem_sizes_kernel and compute_arg_sorts_kernel loops, making the kernels robust to future changes in launch configuration.
Replace raw <<<>>> launch with LaunchKernel for apply_shuffle_mul_sum_kernel to get post-launch CUDA error checking via RuntimeDeviceCheck.
|
Thanks @Johnsonms! The target tree |
Motivation
This PR is part of tracking issue #17865, which migrates
sgl-kernelAOT kernels to the lightweightpython/sglang/jit_kernel/JIT system.Key Design Decisions
To reduce build complexity and improve portability, both dependencies are replaced with self-contained, lightweight equivalents:
cutlass::Array<T, N>uint4flashinfer::vec_t<T, N>FloatVec<scalar_t, N>cast_load/cast_storeusing CUDA intrinsics (__half2float,__float2half, etc.)These replacements preserve the original memory access patterns and numerical behavior without introducing additional dependencies.
Changes
python/sglang/jit_kernel/csrc/moe/prepare_moe_input.cuhExports three host-callable entry points via the TVM FFI interface:
prepare_moe_input— routing metadata constructioncompute_problem_sizes_kernelCounts tokens per expert and fills
problem_sizes1/problem_sizes2compute_expert_offsets_kernelPrefix sum to produce
expert_offsetscompute_expert_blockscale_offsets_kernelOptional FP8 blockscale offsets
compute_arg_sorts_kernelBuilds
input_permutationandoutput_permutationshuffle_rowsuint4for 128-bit vectorized loads/storesapply_shuffle_mul_sumFloatVec<scalar_t, N>fp16 / bf16 / fp32python/sglang/jit_kernel/prepare_moe_input.pysgl_kernel.prepare_moe_inputsgl_kernel.shuffle_rowssgl_kernel.apply_shuffle_mul_sumTests & Benchmark
Performance benchmark
Summary of Performance Findings
SASS comparison:
prepare_moe_inputkernels are instruction-identical between JIT and AOT, ruling out compiler codegen differences.Primary regression cause — CPU dispatch overhead (
prepare_moe_input):The JIT path incurs ~3 µs additional launch stall per call due to higher Python-side dispatch overhead (TVM FFI vs pybind11).
This affects small batch sizes only (3–32%) and fully disappears at large token counts where GPU compute dominates.