[ROCm] Skip fresh Kimi-K3 KDA state copies

[LiuYinfeng01]

Purpose

Detect all-fresh Kimi-K3 prefill batches from existing CPU metadata, then let chunk KDA start from zero and write final recurrent states directly to indexed cache rows. This skips dense gather, zero-fill, final-state allocation, and scatter while retaining the existing path for mixed, resumed, padded, and non-ROCm batches.

Kimi-K3 has 69 KDA layers. On TP8, one recurrent state is 0.75 MiB per request per layer. At batch 128, the old path materialized a 96 MiB zero initial-state tensor and a 96 MiB final-state tensor per layer before scattering the latter into cache rows.

Test Plan

• python -m pytest -q tests/models/kimi_k3/test_kda_metadata.py
• python -m pytest -q tests/models/kimi_k3/test_kda.py -k test_chunk_kda_none_matches_zero_initial_state
• TP8 serving smoke and short benchmark on rocm/vllm-dev:gfx950_kimi_k3_20260727 with [GFX950] Relocate MLA Gluon kernel and unify decode dispatch ROCm/aiter#4450

Test Result

• Metadata: 18 passed, covering fresh, resumed, and zero-length-padded batches.
• Kernel at Kimi head dimension D=128: output and final state match explicit-zero initialization; non-contiguous indexed cache rows match; untouched sentinel rows remain unchanged.
• TP8 server boot and all-fresh serving smoke passed.
• ISL 8192 / OSL 512 / concurrency 4 / 8 requests: zero failures. Median TTFT was 1649.10 ms baseline and 1658.77 ms candidate, neutral within this small sample.
• GSM8K subset before the direct-store follow-up, 100 questions / 5-shot / greedy / seed 42: baseline 100/100, candidate 99/100, with zero invalid responses. The direct-store kernel is separately numerically matched to the candidate path.
• Python syntax and git diff --check passed. The fixed image does not include Ruff.

Tool assistance

Cursor assisted with implementation, tests, benchmarking, and drafting this description.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @LiuYinfeng01.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork