[AMD] Support block FP8 MoE on gfx1250 - #3
Draft
yushengsu-thu wants to merge 4 commits into
Draft
Conversation
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
num_stages=1for gfx1250 block-FP8 MoE kernelsK=6144, TP4N=512, top-k 8)PYTHONPATHWhy
This is stacked on sgl-project#32754. That PR adds the corresponding gfx1250 workaround for dense block-FP8 GEMM, because native FP8
tl.dotfaults, multi-stage software pipelining can miscompile, and modulo-wrapped matrix offsets can become out-of-bounds on gfx1250. The generic fused-MoE block-FP8 kernel still used all three patterns, so MiMo-V2.5-Pro's 128x128 FP8 routed experts did not have the same correctness fallback.The pinned gfx1250 AITER grouped-MoE path does not support this checkpoint's per-128x128 format. The launcher therefore consistently disables AITER/CK and selects Triton for attention and MoE, avoiding AITER weight preshuffling for a Triton consumer.
SGLang's buffered multi-thread loader documents a peak of approximately
(workers + 2) * shard sizeper rank. This checkpoint has 34 roughly 30 GB shards; the default eight workers across four TP ranks can therefore create excessive host-memory pressure during bring-up. The launcher defaults toenable_multithread_load=falseuntil the node's capacity and stability are measured.Validation
python3 -m py_compile python/sglang/kernels/ops/moe/fused_moe_triton_kernels.py test/manual/quant/test_block_fp8.pyruff check --select F python/sglang/kernels/ops/moe/fused_moe_triton_kernels.pyshellcheck scripts/ci/amd/mi455_mimo_v25_pro.shbash -n scripts/ci/amd/mi455_mimo_v25_pro.shgit diff --checkMI455 runtime status
This remains a draft intentionally. The available MI455 host currently fails L2 neighbor resolution from the otherwise reachable AMD bastion (
No route to host), so the driver command and GPU numerical test cannot reach the node yet.Remaining gates:
amdgpuwithgpu_recovery=0TestW8A8BlockFP8FusedMoE.test_gfx1250_w8a8_block_fp8_fused_moeon gfx1250Dependency
Stacked on sgl-project#32754 (
akao-amd/sglang:amd_helios). It should be rebased ontosgl-project/sglang:mainafter that dependency lands.