pull_style_cutedsl_megakernel

Updating the SM90 (Hopper) CuTeDSL MegaMoE kernel src

Provenance

This tree vendors the kernel team's SM90 FP8 MegaMoE drop — a fork of the same kernel repo that kernel_src/sm100/cutedsl_megamoe vendors (Bangyu's SM100 tree). The SM90 work (Vincent's hopper_megamoe branch) moved the shared runtime forward, so this tree duplicates common/, src/, and moe_nvfp4_swapab/ at its own revision instead of sharing the SM100 copies. The two trees are separate backends:

• top-level module names collide (common, src, moe_nvfp4_swapab), so only one tree can be active per process — shim/_paths.bootstrap_paths raises if the sibling tree's modules are already imported. A process runs on either Hopper or Blackwell, never both, so this is not a practical limit.
• drops are updated independently; never "sync" shared files across the trees.

Current drop: kernel repo commit c3e2c2a ("Add token-based launch heuristics for Hopper FP8 MegaMoE", 2026-08), minus commit 4f9c042. Preserve this exclusion when syncing future drops.

BF16 drop: moe_hopper_bf16/ from the kernel team's "Support Hopper MegaMoE BF16 FWD" drop (2026-09-20), copied verbatim except for the import adaptation below. The shared common/, src/ and moe_nvfp4_swapab/ were NOT re-synced from that drop: the vendored FP8-era copies are a functional superset of what the BF16 kernel uses. The drop's vLLM comparison scripts (benchmark_vllm_hopper_bf16_moe.py, run_vllm_hopper_bf16_sweep.{py,sh}, summarize_vllm_hopper_bf16_sweep.py) and benchmark_data/ are not copied, matching the FP8 vendoring.

Import adaptation (both kernels; re-apply on every resync): the drop's moe_hopper_fp8/kernel_fp8_glu_fc12.py and moe_hopper_bf16/kernel_bf16_glu_fc12.py import GluMxFp8Fc12SchedExtension from moe_mxfp8_glu.custom_ext, which is not vendored; the vendored copies import it from moe_nvfp4_swapab.custom_ext instead (one-line edit each).

Local extensions pending upstream (re-apply when syncing a drop that has not picked them up):