[Config] configs: add tuned configs for Qwen3.8-27B MXFP4 (gfx950)

[vorapolsiloai]

Motivation

Add gfx950 tuning coverage for amd/Qwen3.8-27B-Quark-AWQ-MXFP4 at TP1/TP2/TP4/TP8 on MI355X.

The model is dense hybrid GDN (Qwen3.5-style), not MoE, so this PR ships A4W4 blockscale GEMM tables only. No fused-MoE CSV. No BF16 hipBLASLt GEMM rows (same exclusion as #3113, #3974, #4352, and the later #4554 follow-up).

Added tuning data

• qwen38_27b_a4w4_blockscale_tuned_gemm.csv: 907 A4W4 blockscale GEMM rows, all for gfx950 / 256 CUs. Overlapping (5120,5120) keys already in the global a4w4_blockscale_tuned_gemm.csv were omitted so merge stays unique.
• 32 distinct (N,K) across decode/prefill M buckets.

This update adds missing TP-sharded GEMM coverage that was not in the previous table:

• new (N,K): 4096x5120, 8192x5120, 16384x5120
• additional M buckets 288–480 on those TP-sharded shapes
• on overlapping (gfx, cu_num, M, N, K) keys, keep the lowest-us kernel

The earlier TP8 GDN linear_attn k-out GEMM (N=5120, K=256) rows remain. k_proj / v_proj / fused QKV stay omitted at TP8 because num_key_value_heads=4 does not divide by 8.

No raw request lengths (for example M=6/24). No hipBLASLt rows.

Data validation

• exact expected row counts — passed;
• no null or malformed rows — passed;
• gfx950 and 256-CU metadata on every row — passed;
• all observed errRatio values are 0.0 — passed;
• 0 hipBLASLt libtype/kernel rows (898 ASM f4gemm_*, 24 CK a4w4_blockscale_*) — passed;
• no duplicate runtime keys within the added files — passed.

End-to-end integration status

The previous SGLang TP1 uplift claims are withdrawn pending a corrected benchmark. They did not exercise this CSV:

• SGLang's Quark W4A4 dense-linear implementation in both tested images calls aiter.ops.triton.gemm_afp4wfp4.
• This PR's CSV is consumed by the separate aiter.ops.gemm_op_a4w4.gemm_a4w4 dispatcher.
• The tuned run successfully mounted and resolved all 754 CSV rows, but emitted no A4W4 tuned-selection lines. A controlled GPU probe then showed the Quark call still succeeds after gemm_op_a4w4.get_GEMM_config is disabled.
• The ROCm 10 image has no Qwen3.8 CSV and none of its 35 specialized GEMM-AFP4WFP4 JSON (N,K) pairs matches this PR's 29 pairs; both sweep sides therefore used the same generic Triton configurations.

Accordingly, the measured +0.06% mean / +0.05% geometric-mean output-throughput difference is only a same-path noise check, not evidence for or against this tuning table. A replacement e2e result using a verified CSV-consuming call path is in progress.

Notes

• Dense MLP, so FMoE tuner input is empty by construction.
• Vision N/K 1152/4304 is omitted: 4304 is not 128-aligned for a4w4 blockscale.
• Small-M (5120,256) ASM 256x256 tiles GPU-fault on this node; those candidates were skipped. Winners are 32x128 ASM with errRatio 0.0.

This PR was developed with AI assistance. The human author reviewed the tuning provenance and validation, and owns the submitted data.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:gfx1250-ffm-triton	Run the five-shard gfx1250 FFM Triton test suite
ci:triton-300x	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
multigpu	Aiter multi-GPU tests on the 8-GPU runner
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: GPT-OSS-120B, DeepSeek-R1-0528, Kimi-K2.5
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 5350 --add-label <label>

PR title tags & labels:
Component tags ([Triton/Gluon], [HIP], [CK], [ASM], ...) are added to the PR title and as PR labels automatically from the changed files and re-synced on every push — change-type tags like [fix]/[Perf], op tags like [MLA], and human labels (ci:*) are left untouched. Add the no-auto-title label to opt this PR out.

[vorapolsiloai]

Checked this table against the two GEMM-config review items from #4554 that apply here (BF16 hipBLASLt count and raw-M BF16 rows do not apply; this PR is A4W4-only).

1. hipBLASLt exclusion — pass. The a4w4 tuner has no hipBLASLt candidate and these files have no libtype column. 754/754 winners are ASM f4gemm_* (730) or CK a4w4_blockscale_* (24). Same production reason as #3113 / #3974 / #4352 / the #4554 follow-up: lazy hipBLASLt selection is fragile under HIP graph capture.

2. Runtime padded-M grid, matching untuned CSV — pass.

• Tuned and untuned M,N,K sets match (754/754), no duplicate runtime keys.
• M is only the canonical getPaddedM endpoints: gl=0 16-aligned buckets for M<=256, then gl=1 powers of two through 16384 (1,2,4,8,16,32,48,…,256,512,…,16384).
• 0 rows are raw request lengths (no M=6/24-style incidental traces).
• 29 (N,K) × 26 M buckets, including the TP8 GDN k-out (5120,256) fill.

Not in scope from that review: BF16 tuned CSV (this model ships A4W4 only) and the 6,977/7,212 non-canonical A4W4 count (that was the other ticket’s table).

[yifehuan]

LGTM