mirror of
https://github.com/deepseek-ai/DeepGEMM.git
synced 2026-11-05 00:47:26 +00:00
[PR #435] [CLOSED] Improve SM100 MX MQA logits clean-output performance #443
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/DeepGEMM#443
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/deepseek-ai/DeepGEMM/pull/435
Author: @OutWhite
Created: 9/10/2026
Status: ❌ Closed
Base:
main← Head:codex/sm100-mx-mqa-clean-performance📝 Commits (2)
0185f6bImprove SM100 MX MQA logits clean-output performance197189eDocument SM100 MQA cleanup scheduling choices📊 Changes
1 file changed (+34 additions, -16 deletions)
View changed files
📝
deep_gemm/include/deep_gemm/impls/sm100_mqa_logits.cuh(+34 -16)📄 Description
On GB200 with NVCC 13.3.33, placing MXFP8/MXFP4 MQA-logits cleanup after the CTA's main computation improves
clean_logits=Trueperformance by about 1.6–2.3x for the H64/D128 cases below, with identical complete outputs. This PR proposes that scheduling change for the SM100 MX paths.Move the MX cleaner after the CTA's producer/consumer work and TMEM release. Reuse the existing cleaner through a local lambda, and synchronize with a separate named barrier (ID 1) so it cannot overlap the math-only barrier (ID 0). The grid-stride cleanup ranges, in-coverage masks, metadata layout, and public API are unchanged. FP8 retains concurrent cleanup; moving FP8 cleanup as well caused a 5–8% slowdown in some exploratory cases. The lambda's
kCleanLogitsguard also avoids instantiating contiguous-only cleaner methods for paged schedulers.Performance
Baseline:
66081d4c9c7d7c44f13fea402e5b622aa0f409c2. Same GB200 GPU (152 SMs), NVCC 13.3.33, default DeepGEMM JIT flags targetingsm_100f, driver 580.167.08, PyTorch 2.13.0+cu130; PDL disabled.H=64, D=128, FP32 weights/output, uncompressed logits. Q/K/weights are all zero, MX scales are one, and each row uses
[0, KV-Q+row). These are CUDA Graph GPU timings of the completeclean_logits=Truecall, including all cleaning. Metadata is precomputed outside timing. Five calls per graph with distinct retained output buffers; 40 samples, rotating/reversing variant order, immediate warmup before each timed replay; median per-call latency. The timing runs use normal GPU clocks. Separate Nsight captures below use controlled base clocks.The
clean_logits=Falsecontrol stays within 0.2% between builds for these eight points. A further 18-shape screen (both metadata modes) includes H=8/32/64, Q=KV=8192, CP windows, and BF16 weights/output: MX latencies improve in every screened case; FP8 is within 0.2% of baseline. The improvement also appears with random inputs. The table uses an all-zero workload to reduce input-dependent power effects.Timing data, including p10/p90 (microseconds)
Investigation notes
A few local ablations helped distinguish cleanup bandwidth costs from sensitivity to code placement. These use H64/D128, Q=2048, KV=32768:
clean_logits=False. The cleaner-loop unrolling and inline-PTX store variants showed similar timings to baseline.With the final patch, a controlled-clock Nsight Compute 2026.2 comparison for MXFP8, Q=2048, KV=32768, no metadata shows:
per_issue_activeratio)Exploratory PC samples place much of the additional wait around the math-side TMEM-result barrier check. Together, these results suggest that cleaner placement affects main-loop execution; memory traffic and resource allocation are largely unchanged, and neither binary has register spills. The precise low-level dependency remains to be investigated. The proposed change avoids this sensitivity on the tested configuration while retaining the existing output semantics.
Validation
test_mqa_logits: 32 sampled configurations pass (including its 20-repeat bitwise checks, scheduled-path equality, full mask checks, and reference comparisons).test_paged_mqa_logits: 4 sampled configurations pass, exercising the shared core with paged schedulers.No permanent test-matrix or benchmark-file additions. Existing upstream tests can be run from a built checkout with:
Standalone performance reproducer (writes every timing sample to JSON)
Save as
pr-reproduce.pyand run it once with each built revision, using the same GPU and NVCC. Both builds and all JIT compilations must finish before timed sampling; the script warms every specialization before capture. It verifies the zero output and complete negative-infinity mask before timing.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.