执行摘要

• 一句话：启用gfx942 split sparse decode，解码性能提升40%
• 推荐动作：值得合并。性能提升明显，且风险极低。评审已经通过。建议后续关注是否有其他架构（如gfx940）也能受益，但需单独验证。

功能与动机

DeepSeek-V4稀疏MLA解码在gfx942上原本使用fallback monolithic kernel，即使split partial/reduce路径在gfx942上也能正确运行且性能更优。此PR将该路径的硬件守卫从仅gfx950扩展到gfx942，以提升gfx942上的解码性能。详见PR正文："The latest MI300X/gfx942 profiles show the sparse decode work itself drops by about 40% with the split path."

实现拆解

1. 扩展硬件守卫：在vllm/v1/attention/ops/rocm_aiter_mla_sparse.py中，将条件从if not _ON_GFX950改为if not (_ON_GFX942 or _ON_GFX950)，使gfx942也能走split decode路径，否则fallback到原monolithic kernel。
2. 更新测试辅助函数：在tests/kernels/attention/test_rocm_triton_attn_dsv4.py中，将原有的_on_gfx950()重命名为_on_split_decode_arch()，并同时检查_ON_GFX942和_ON_GFX950，使测试在gfx942和gfx950上都能运行。相应地将pytest skipif条件从requires_gfx950重命名为requires_split_decode_arch。
3. 重构测试中的量化缓存函数：将_pack_fp8_ds_mla_cache和_read_fp8_ds_mla_cache的参数从is_extra改为use_fnuz，并使用vllm.models.deepseek_v4.common.ops.cache_utils.quantize_and_insert_k_cache替换手动循环，使测试与生产代码的量化逻辑对齐。

关键文件：

• vllm/v1/attention/ops/rocm_aiter_mla_sparse.py（模块 注意力算子；类别 source；类型 core-logic；符号 _rocm_sparse_attn_decode_ragged_triton）: 核心变更：修改split decode路径的硬件守卫条件，使gfx942也能使用优化后的split partial/reduce kernel，而不再fallback到monolithic kernel。这是性能提升的直接原因。
• tests/kernels/attention/test_rocm_triton_attn_dsv4.py（模块 测试；类别 test；类型 test-coverage；符号 _on_split_decode_arch, requires_split_decode_arch, _pack_fp8_ds_mla_cache, _read_fp8_ds_mla_cache）: 测试覆盖更新：将硬件检测函数从仅gfx950扩展为gfx942/gfx950，并重构了量化缓存辅助函数以对齐生产代码。确保split decode路径在gfx942上被测试覆盖。

关键符号：_rocm_sparse_attn_decode_ragged_triton, _on_split_decode_arch, requires_split_decode_arch, _pack_fp8_ds_mla_cache, _read_fp8_ds_mla_cache

关键源码片段

vllm/v1/attention/ops/rocm_aiter_mla_sparse.py

核心变更：修改split decode路径的硬件守卫条件，使gfx942也能使用优化后的split partial/reduce kernel，而不再fallback到monolithic kernel。这是性能提升的直接原因。

# vllm/v1/attention/ops/rocm_aiter_mla_sparse.py
# 在函数 _rocm_sparse_attn_decode_ragged_triton 中，
# 决定使用哪个 kernel 的关键守卫条件：
​
if not (_ON_GFX942 or _ON_GFX950): # 修改前 : if not _ON_GFX950
    # Fallback path for un-tuned architectures.
    # 对于 gfx942/gfx950 之外的架构，使用 monolithic ragged kernel。
    block_k = 16 if head_dim >= 256 else 32
    _sparse_attn_decode_ragged_kernel[(num_queries, heads_blocks)](
        q, q_stride_q, q_stride_h, ...
    )
else:
    # Split partial + reduce path (tuned for gfx942/gfx950)
    _sparse_attn_decode_partial_kernel[(num_queries, heads_blocks)](...)
    _sparse_attn_decode_reduce_kernel[(num_queries, heads_blocks)](...)

tests/kernels/attention/test_rocm_triton_attn_dsv4.py

测试覆盖更新：将硬件检测函数从仅gfx950扩展为gfx942/gfx950，并重构了量化缓存辅助函数以对齐生产代码。确保split decode路径在gfx942上被测试覆盖。

# tests/kernels/attention/test_rocm_triton_attn_dsv4.py
# 硬件架构检测函数：从仅检查 gfx950 扩展为同时检查 gfx942 和 gfx950
​
def _on_split_decode_arch() -> bool: # 原函数名 _on_gfx950
    if not current_platform.is_rocm():
        return False
    try:
        from vllm.platforms.rocm import _ON_GFX942, _ON_GFX950
        return bool(_ON_GFX942 or _ON_GFX950) # 原返回值 : bool(_ON_GFX950)
    except Exception:
        return False
​
# 对应的 pytest skipif 标记
requires_split_decode_arch = pytest.mark.skipif( # 原名 requires_gfx950
    not _on_split_decode_arch(),
    reason="split-K decode kernel is only tuned for AMD gfx942/gfx950",
)
​
# 同时，量化缓存辅助函数从手动循环改为调用生产代码的量化插入函数，
# 参数从 is_extra 改为 use_fnuz，与生产代码保持一致。
def _pack_fp8_ds_mla_cache(
    kv: torch.Tensor, block_size: int, use_fnuz: bool # 原 : is_extra: bool = False
) -> torch.Tensor:
    ...
    from vllm.models.deepseek_v4.common.ops.cache_utils import (
        quantize_and_insert_k_cache,
    )
    slot_mapping = torch.arange(num_tokens, dtype=torch.int64, device=kv.device)
    quantize_and_insert_k_cache(
        kv, cache, slot_mapping,
        block_size=block_size, use_fnuz=use_fnuz,
    )
    return cache

评论区精华

评审人tjtanaa在Approval中表示："LGTM. Thanks for fixing the extra and fnuz semantics. It is clearer than the one introduced in https://github.com/vllm-project/vllm/pull/46080 。" 说明之前PR#46080中引入的语义不够清晰，此PR做了清理。

• 审批意见：感谢修复extra和fnuz语义 (other): 评审认可，认为语义比之前的PR更清晰。

风险与影响

• 风险：风险较低。核心变更仅一行条件判断的修改，且经过测试验证（41个测试通过）、正确性校验（deterministic smoke request返回42、GSM8K精度一致）和端到端benchmark对比（性能提升无退化）。需要注意的是：
  • 此优化仅适用于gfx942/gfx950，其他AMD架构仍使用fallback路径，不影响。
  • 如果将来有其他架构也能走split路径，需要更新守卫。
  • 测试中重构了量化缓存函数，但已通过正确性diff验证与生产逻辑一致。
  • 影响：对使用DeepSeek-V4模型在AMD gfx942上的用户：解码性能显著提升（kernel级别约40%，端到端decode-heavy TPOT降低4.5%，高吞吐TTFT降低13%），且无需任何配置变更。对其他用户无影响，因为守卫条件确保了只有gfx942/gfx950受影响。团队维护成本低，因为变更集中且简单。
  • 风险标记：GPU架构特定, 依赖ROCm平台, 测试覆盖关键路径

关联脉络

• PR #46080 [ROCm][DSV4] 之前引入的量化缓存语义不够清晰: 评审人提到此PR修复了PR#46080中引入的extra和fnuz语义问题，使其更清晰。相关文件同为测试文件中的量化缓存函数。