[ROCm] Bump AITER to v0.1.19.post2

[LucasWilkinson]

Purpose

Bump the ROCm base image's AITER pin from v0.1.19 to v0.1.19.post2 to pick up
ROCm/aiter#4312, which makes
fused_qk_norm_rope_cache_pts_quant_shuffle() stride-aware for block_size and heads.

Without it, the fused QK-norm+RoPE+KV-cache kernel hard-asserts and aborts the process
(SIGABRT, exit 134) on the packed KV-cache layout:

[AITER] csrc/kernels/fused_qk_norm_rope_cache_quant.cu:3278
        k_cache/v_cache must be contiguous within a block (dims >= 1)
Fatal Python error: Aborted

#44455 packed K/V into the content dim, (num_blocks, num_kv_heads, block_size, 2*head_size), and #49373 wired the AITER backends to read it via
transpose(1, 2).split(head_size, -1). Those views have a contiguous head dim but a head
stride of a whole block (e.g. (8192, 256, 4096, 1) for H=2, hs=128, N=16), which the
pre-#4312 kernel rejects.

This is the AITER half of the fix agreed in
#49590, where a vLLM-side
.contiguous() workaround was declined:

Duplicate of #49373, also this inserts a .contiguous which will break perf. The correct
fix is to bump AITER to include ROCm/aiter#4312, then land 49373.

The vLLM half (#49373) merged on 2026-08-07; the AITER pin was never moved, so the abort is
still live on the pinned version.

Version arithmetic

ref	contains #4312	guard
v0.1.19 (current pin)	no — 15 commits behind the merge	asserts at line 3278
v0.1.19.post1	yes (ahead 40)	—
v0.1.19.post2	yes (ahead 44)	assert removed

In .post2 the is_contiguous_from_dim1 guard is gone, replaced by explicit
k_stride_token / k_stride_head / k_stride_dim indexing.

Test Plan

MI300X (gfx942). Built v0.1.19.post2 from source and ran the fusion suite against
unmodified 640a09086d (no vLLM changes), so the pin is the only variable:

git clone --recursive --branch v0.1.19.post2 https://github.com/ROCm/aiter.git
PYTHONPATH=/path/to/aiter-post2 \
  pytest tests/compile/passes/test_rocm_aiter_qk_norm_rope_kvcache_fusion.py

Test Result

aiter	targeted subset (ROCM_AITER_FA and full-neox and auto)
0.1.16.post2 (pre-#4312, same guard as v0.1.19)	SIGABRT on the first case
v0.1.19.post2	18 passed, 18 skipped

The test asserts fusion_pass.matched_count == 1 and compares fused vs unfused q/k/v and
the KV cache, so these exercise the fused kernel and check it numerically on the packed
layout. Full-suite run in progress; will update.

Notes

• docker/Dockerfile.rocm_base_gfx1250 tracks AITER_BRANCH="main" and is unaffected.
• This does not unblock the patch_gating_output TODOs in
  aiter_mxfp4_w4a8_moe.py — those wait on
  ROCm/aiter#4530, which is still open.
• AI assistance was used for the investigation and testing above.

🤖 Generated with Claude Code

[AndreasKaratzas]

Hi @LucasWilkinson :) We are soon going to start the bumping process. I want one more PR to be cherry picked. Then we ll start the bumping process. @Rohan138 is the one putting up PRs for that. I expect that end of next week we ll have bumped it. Would it be OK to close this PR and let @Rohan138 handle the cadence?

[Rohan138]

@AndreasKaratzas I think we need to revert #49373 until the AITER bump lands, that PR is blocked by ROCm/aiter#4312 which isn't in the current AITER 0.1.19. Sorry for the confusion @LucasWilkinson!

[fxmarty-amd]

@AndreasKaratzas @Rohan138 is this PR up to date?

Next bump will be v0.1.19.post2?

[maeehart]

ROCm/aiter#4646 (FlyDSL a16wi4) merged on 2026-08-13. This pin is v0.1.19.post2, whose tip is 2026-08-05, so 4646 is not in it.

#51728 is still open, so including 4646 in this bump is still doable. That is the gfx942 MoE path used by Kimi-K3 and Qwen3.8 load-time INT4. Details are in #52803

If retargeting this PR is painful, a fast follow-up pin that contains 4646 also works. One bump that includes it is better.

[maeehart]

v0.1.20 is tagged at fc2e5d57fb5b (release/v0.1.20). It contains ROCm/aiter#4646. 4bbc57db (the 4646 merge) is an ancestor of that tag, 57 commits behind the tip.

Can this PR pin v0.1.20 instead of v0.1.19.post2? post2 is 2026-08-05 and does not have 4646. That kernel is the gfx942 FlyDSL a16wi4 path in #52803

If retargeting this PR is painful, a follow-up pin PR to v0.1.20 also works.

[AndreasKaratzas]

Hi @ChuanLi1101 we ve already established that this PR should probably be closed since, Rohan or Micah handle the version bumps, and since now we have .21 already there.

[mergify]

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

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