Repository navigation
[Perf] Retune gfx942 Qwen3.8-27B a8w8 blockscale decode rows for cold weights - #7752
phambinhfin wants to merge 1 commit into
Conversation
… weights Picks faster in-table CK instances for nine decode rows. Signed-off-by: Pham Binh <194774975+phambinhfin@users.noreply.github.com>
🏷️ CI GuideRuns automatically on every PR:
Extended tests (opt-in via labels):
One backend per PR: PR title tags & labels: Reviews: |
Summary
On gfx942, nine decode rows of
a8w8_blockscale_tuned_gemm_qwen38_27b.csv(Qwen3.8-27B-FP8, TP1, from #5585) pick aCK instance that is slower than another instance already in the table when the weights come from HBM, as they do in a
decode step. This switches those nine rows.
Claims
new rows are still 1.01-1.36x (MI325X) and 1.04-1.16x (MI300X) faster. Unchanged neighbouring M move < 1%.
has the same GEMM shapes). GSM8K stays within its standard error.
the compiled
module_gemm_a8w8_blockscale. gfx942 / 304 CUs only.Validation
MI325X:
vllm/vllm-openai-rocm:nightly-a2bcb565…(AITER 0.1.27). MI300X:nightly-cf5cea2da37d…(AITER 0.1.28.post1).In both, this CSV is byte-identical to
mainand "after" only bind-mounts this branch's file.Kernel
gemm_a8w8_blockscale(production lookup), HIP-graph replay, us per call, median of interleaved rounds; cold = weightsrotated over ≥ 512 MB (MI325X) / 2 GiB (MI300X), hot = one weight copy.
mainN = 5120 / K = 6144 is
o_proj/out_proj, 14336qkv, 16384in_proj_qkvz, 34816gate_up. Through thegetPaddedMwalk the new rows serveout_projM = 1/3/4,qkvM = 1-8,in_proj_qkvzM = 3-8 andgate_upM = 9-16.Relative L2 against an fp32 reference is unchanged or lower on every served M; where split-K is dropped it falls from
2.5e-3 to 1.7e-3, the bf16 output-rounding floor. CUDA-graph replay with the split-K memset inside matches eager.
Serving
Median ITL in ms, ISL 1024 / OSL 1024, fresh server per run; vLLM pads decode batches to capture sizes 1, 2, 4, 8, 16,
so the changed rows are hit (server log,
AITER_LOG_TUNED_CONFIG=1).GSM8K, 5-shot, 1319 questions. MI325X (Qwen3.8-27B-FP8,
lm_evalcompletions): flexible-extract 0.7225 ± 0.0123 →0.7195 ± 0.0124, strict-match 0.6929 ± 0.0127 → 0.6899 ± 0.0127. MI300X (Qwen3.6-27B-FP8, vLLM's
tests/evals/gsm8k/gsm8k_eval.py, chat API, thinking off): 0.9682 → 0.9689 (± 0.0048).Tests
test_config_shape_collisionandtest_csv_validation: 51 passed onmainand on this branch.Not run: Qwen3.8-27B-FP8 serving on MI300X (Qwen3.6-27B-FP8 used instead).
Details
The current rows were chosen by tuner timing that reads one resident weight copy; with weights streamed from HBM they
lose. Where a non-split instance is within 2% of the fastest it is used, so the
qkvM = 1-8 andin_proj_qkvzM = 4/8rows drop split-K, removing the output memset and the bf16 atomic accumulation.
usin the changed rows is the cold-weight kernel time (torch profiler, memset excluded), not the tuner-writtenusof the other rows. Dispatch reads only
kernelNameandsplitK.Not added: an M = 32 row for
qkv/in_proj_qkvz(256x64x64x256) was 1.13-1.17x faster cold but 0.91x hot andraised ITL 0.3-0.5% at concurrency 32, so M = 17-32 keep the default, as in #5585. #7043 (M = 4096 rows in this file)
and #7233 (the B-preshuffle file) touch other rows and merge cleanly.
AI assistance was used to find and validate this change.
Testing
Documentation
Nine tuned rows change kernel; the CSV is the only place they are described.
Dependencies
Breaking Changes
None. No row is added or removed, and every new instance is already compiled.
PR Self-Review
Reviewed revision
48041eaebaa584ff5eea54249f11362d4897a581Behavior and intent
On gfx942 / 304 CUs, nine Qwen3.8-27B TP1 a8w8 blockscale decode rows switch to the CK instance that is fastest with
weights streamed from HBM. Other rows, files and architectures are unchanged.
Validation and unverified scope
Kernel, serving and GSM8K results above on MI325X and MI300X. Not run: Qwen3.8-27B-FP8 itself on MI300X.
PR-specific question
Does changing a row move another M onto it? The
getPaddedMwalk is exact M, then the next power of two below 16 orthe next multiple of 16 up to 256, then the next power of two; the served M above follow from it and were confirmed in
the lookup log, and neighbouring M (2, 5, 8 of
out_proj; 9, 16 ofqkv/in_proj_qkvz; 8, 17 ofgate_up) keeptheir rows and timing.
Changed op tests
None.