[GFX950] Relocate MLA Gluon kernel and unify decode dispatch

[LiuYinfeng01]

Summary

• Relocate the current gfx950 MLA Gluon kernel to aiter/ops/triton/_gluon_kernels/gfx950/attention/mla.py.
• Update sparse-prefill, benchmark, and test imports to the architecture-specific path.
• Connect the validated low-head BF16 configuration to the unified mla_decode_fwd entry while preserving the Triton fallback for all other configurations.

Scope

The split-scheduling performance optimization originally developed in this PR has already landed through #4555. This revision does not add a new split policy or further kernel performance tuning.

The moved kernel is byte-for-byte identical to the current file on main, so the relocation carries the implementation from #4555 and the subsequent NaN fix from #4711 without reimplementing either change.

Unified decode dispatch

The gfx950 Gluon path is selected only for the validated configuration:

• up to 16 query heads and one KV head
• BF16 query, KV cache, and output
• page size 1
• 512 latent dimensions + 64 RoPE dimensions
• contiguous, unshuffled tensors with no quantization scales

Unsupported configurations continue to use the existing Triton path.

Validation

• Added routing guard coverage, including fallback cases.
• Added gfx950 correctness coverage for 12/16 heads, single-token decode, MTP decode, and 100K context.
• Ruff check passes on all changed Python files.
• Python syntax compilation passes.
• gfx950 execution tests require a ROCm gfx950 environment and were not run on the local Windows host.

[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:triton-300x	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
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 4450 --add-label <label>

[JohnQinAMD]

This now overlaps #4405's caller-owned num_kv_splits override. #4450's
device-side runtime buckets are the more complete Kimi-K3 scheduling policy;
please preserve equivalent coverage for #4405's focused split-policy CI test
(test_mla_gluon_split_policy.py). If #4450 lands without that unit coverage,
I will rebase #4405 into a test-only follow-up rather than duplicate the
implementation.

[LiuYinfeng01]

@JohnQinAMD Thanks for pointing this out. I added equivalent split-policy and boundary coverage in commit dd521e2.

I confirmed that the #4450 measurements were collected on this machine, which has 8× AMD Instinct MI355X GPUs (gfx950). The end-to-end Kimi-K3 measurements used TP8, CUDA Graph enabled, and the 100K-input / 1K-output workload described in the PR.

The new coverage includes:

1. A shared _resolve_num_kv_splits() helper that preserves the automatic policy when the override is None and validates explicit caller-owned overrides.
2. test_mla_gluon_split_policy.py with 14 parameterized cases covering automatic-policy passthrough, explicit split values 1, 16, 32, and 256, out-of-range values, and invalid non-integer values.
3. A focused Kimi-K3 TP8 CI invocation covering contexts 1, 31, 32, 63, 64, 65, and 8192 with an explicit 32-split override.
4. The existing automatic runtime bucket behavior remains unchanged when no override is supplied.

Focused unit-test result:

14 passed in 5.73s

Explicit split-boundary command:

python op_tests/test_mla.py   --decode-only   -c 1 31 32 63 64 65 8192   -b 1 -n 12,1   -d bf16 -kvd bf16   -k 512 -qn 512 -qr 64 -vh 512 -blk 1   --varlen -splits 32

All seven boundary cases passed the PyTorch golden check with atol=0.01 and rtol=0.01, including cases where the explicit split count is greater than the sequence length.

I also reran the automatic graph-safe policy without an explicit override at contexts 4K, 100K, and 262K. Output and LSE checks passed at all three lengths, and the varlen batch=3, context=10000 case passed as well.

This should preserve #4405's focused split-policy and boundary coverage while keeping #4450 as the single runtime scheduling implementation.

[LiuYinfeng01]

The optimization from this PR has been incorporated into #4555, so I’m drafting this PR.