[Bug] dsv4 a8w8_blockscale_bpreshuffle tuned CSV uses cu_num=80, never matches gfx942 nodes reporting cu_num=304 -> "This GEMM is not supported"; fixing the row surfaces a second bug in opus kernel-baking

[abhishekkumar-sing]

Environment

• GPU: 8x AMD Instinct MI300X (gfx942), get_gfx()=gfx942, get_cu_num()=304
• ROCm: 7.1.1
• aiter: reproduced on both v0.1.19 and main @ 17f24ec6e (2026-08-07)
• vLLM: commit 4719a9b8f, VLLM_ROCM_USE_AITER=1
• Model: deepseek-ai/DeepSeek-V4-Flash-0731, shape M=8192 N=1536 K=4096, dtype=bfloat16

Bug 1: cu_num mismatch hides the entire tuned file on this hardware

aiter/configs/model_configs/dsv4_a8w8_blockscale_bpreshuffle_tuned_gemm.csv has ~30 gfx942 rows for N=1536,K=4096, all with cu_num=80. get_CKGEMM_config() keys on (gfx, cu_num, M, N, K) using runtime get_cu_num() = 304 here, so no row in this file ever matches on this node, for any shape -- not just M=8192. Every shape silently falls through to "not found tuned config ... will use default config!"; for M=8192 the default has no valid kernel:

gemm_a8w8_blockscale_bpreshuffle failed for shape M=8192, N=1536, K=4096, dtype=torch.bfloat16, config=None: This GEMM is not supported!

Call path: vllm/models/deepseek_v4/amd/rocm.py:_bpre_attn_gemm (invoked from _fused_wqa_wkv_gemm during profile_run).

The file is otherwise dense here (M=...,3840,7296,7680,[gap],15360) -- M=8192 sits in a gap between two shapes that both already use the same kernel (opus_gemm_gfx942_a8w8_bs_bpreshuf_sb_tailm_v16_512x128x128x128_4x2_16x16x32_1x128x128, kernelId=11000).

Bug 2: opus backend fails to bake a referenced-but-untuned kernelId

Adding a corrected row (gfx942,304,8192,1536,4096,opus,11000,..., same kernel as neighbors) makes get_CKGEMM_config find it and module_deepgemm_opus JIT-builds -- but then:

[opus gen_instances] baked 0 tuned entries from 16 CSV file(s) into opus_gemm_lookup.h
...
TypeError: opus_gemm_a8w8_blockscale_bpreshuffle_tune(): incompatible function arguments.
Invoked with: <...aiter_tensor_t...> x5, 11000

"baked 0 tuned entries" -- the on-demand opus kernel-generation path doesn't register/bind kernelId=11000 for a shape absent from its tune set at build time, even though that ID is used by name in neighboring CSV rows for the same N,K.

Workaround

Neither fix alone is sufficient; currently routing this call around AITER entirely (forcing vLLM's _fused_wqa_wkv_gemm to use the generic MergedColumnParallelLinear path instead of _bpre_attn_gemm).