Tencent / Tencent/hpc-ops

[RFC] Fused W8A8 MoE megakernel on H20

Open
#94 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
1.2k
Forks
142
Avg merge
23h 15m
Merged PRs (30d)
8

Description

Background

The current blockwise FP8 MoE path runs the local compute in several CUDA kernels:

  1. count and gather routed tokens
  2. gate/up GroupGEMM
  3. SiLU, gate multiplication and FP8 requantization
  4. down GroupGEMM
  5. top-k weighted reduction

There is no distributed communication involved here. The overhead comes from the kernel boundaries and from writing intermediate activations to global memory and reading them back in the next stage.

The roadmap already mentions Megakernel as a direction:

Fuse multiple consecutive operators into a single kernel to reduce inter-kernel launch overhead and intermediate memory traffic.

I have been experimenting with applying that idea to the W8A8 MoE path.

Design

The current prototype has two kernels:

  • a cooperative planner that builds the expert histogram, prefix sums and row-to-token mapping
  • a compute megakernel that performs the activation gather, both GEMMs, SiLU, amax/requantization and weighted output accumulation

The planner is separate because the histogram and prefix sums are grid-wide dependencies. Once the row mapping is available, the rest of the local MoE compute stays inside the megakernel and does not materialize the intermediate gate/up or down-GEMM outputs in global memory.

The implementation uses CuTe and SM90a primitives and currently targets H20.

Results so far

The measurements below were collected on H20. Both paths run back to back with the same normalized routing weights. The megakernel timing includes output zeroing, the planner and the compute kernel.

Workload Median megakernel/native Megakernel wins
Existing five model families 0.998 54/104
Three additional model configurations 0.965 13/21
DeepSeek-v3 TP8 0.871 19/20
DeepSeek-V2-Lite 0.967 5/7
Qwen3-30B-A3B 0.887 6/7
Mixtral-8x7B TP8/EP1 1.096 2/7

The megakernel is most useful for small-token workloads and TP-sharded MoE with a narrow local intermediate dimension. Native GroupGEMM is still better on some wide-intermediate or low-parallelism shapes, so I do not intend this as a universal replacement.

Question

Does the cooperative planner + compute megakernel split look like a reasonable implementation of the Megakernel direction for Fused MoE? If the structure makes sense, I can send the implementation and full benchmark details as a PR.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing blockwise FP8 MoE path and the roadmap's Megakernel direction; the issue names no files or tests. Evaluate the proposed cooperative planner and compute megakernel against the listed H20 workloads; done is an agreed design followed by a PR with full benchmark details.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
ai-infra-agents, hpc
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.