fix(hcu): restore hybrid KV cache block alignment

[lihenga]

Summary

• delegate backend block-size post-processing to vLLM's shared platform implementation
• restore Attention/Mamba cache-page alignment for hybrid models while preserving the HCU-selected block size

Problem

HCUPlatform.update_block_size_for_backend() was a no-op, which skipped vLLM's hybrid cache-page alignment.

For Qwen3.5-27B with TP=2 and max_model_len=262144, this caused the KV cache requirement to be overestimated at approximately 391 GiB, preventing large-context startup.

After restoring the shared alignment logic, the attention block size is adjusted to 784 tokens with 0.13% Mamba-page padding. The resulting KV cache capacity is 807,957 tokens, supporting 3.08 concurrent 262,144-token requests.

Validation

• python -m py_compile vllm_hcu/platforms/hcu.py
• git diff --check
• verified startup on BW1000/HCU with max_model_len=262144
• verified /health returns HTTP 200

[wics1224]

[P1] super().update_block_size_for_backend() 会覆盖 HCU 已经选好的 block size
文件：vllm_hcu/platforms/hcu.py:617-622
check_and_update_config() 当前会根据 HCU 的 FlashAttention 模式设置 block size：

• varlen：64
• cutlass：64
• classic：128
• VLLM_HCU_FLASH_ATTN_BLOCK_ALIGNMENT_SIZE：使用环境变量指定的值
• Triton：16
  这些赋值发生在 user_specified_block_size == False 的情况下，且只是直接修改 cache_config.block_size，不会把 user_specified_block_size 变成 True。这个字段只有在 CacheConfig 初始化时显式传入 block size 才会被标记为用户指定。HCU 配置逻辑、CacheConfig 的标记逻辑
  但这里调用的 vLLM 基类实现会在第一阶段重新执行：
  preferred = backend_cls.get_preferred_block_size(
  CacheConfig.DEFAULT_BLOCK_SIZE
  )
  cache_config.block_size = preferred
  只要 user_specified_block_size 为 False，它就会覆盖前面 HCU 设置的值。vLLM 基类实现
  对 HCU 的普通 FlashAttention 后端，除 custom 模式外，get_supported_kernel_block_sizes() 返回的是 MultipleOf(16)，而 CacheConfig.DEFAULT_BLOCK_SIZE 是 16，所以 get_preferred_block_size() 最终会返回 16。HCU FlashAttention 后端、vLLM 默认 block size
  因此这个 PR 合入后，以下场景会发生变化：
• 默认 varlen：64 -> 16
• classic：128 -> 16
• 通过 VLLM_HCU_FLASH_ATTN_BLOCK_ALIGNMENT_SIZE 设置的值也可能被覆盖为 16
• 非 hybrid 模型不会经过后续的 Mamba 对齐逻辑，因此会直接以 16 作为最终 KV cache block size
  这不一定会导致结果错误，因为 HCU FlashAttention 声明支持 16 的倍数，但会让 KV cache 的 block 数和 block table 元数据显著增加，并绕过 HCU 现有的 block size 选择策略，带来吞吐和调度开销回退。PR 描述中的 Qwen3.5 hybrid 场景能够得到 784，不能覆盖这个问题：后续 hybrid 对齐阶段可能把前面的覆盖掩盖掉，但普通模型和 Mamba 页需求较小的 hybrid 模型仍会受到影响。
  建议改为以下方案之一：

1. 保留 check_and_update_config() 已选出的 HCU block size，只执行 hybrid/heterogeneous page alignment；
2. 将 HCU 的 block size 策略迁移到对应 attention backend 的 get_preferred_block_size() 中，并让环境变量覆盖逻辑在该路径中生效；
3. 增加回归测试，至少覆盖 varlen=64、classic=128、环境变量指定值，以及执行 update_block_size_for_backend() 之后这些值仍然成立的情况。

[hygon-ai-ai-reviewer]

AI Review

🟢 未发现有明确证据的问题

在已提供并完成审查的 diff 范围内未形成可确认问题。

变更概览

本次变更主要包含：

• 将平台的 update_block_size_for_backend 从空实现改为调用父类实现，使 vLLM 共享的混合注意力/Mamba 缓存块大小对齐逻辑在该后端重新生效。

文件审查摘要

文件	变更	审查结果
vllm_hcu/platforms/hcu.py	修改 · +5/-3	—

审查信息

• 变更统计：1 个文件，+5/-3。
• 覆盖情况：共 1 个文件，已完整审查 1 个。
• 候选问题：0 项；证据复核过滤：0 项；发布前敏感信息保护：0 项。
• 本服务只审查 GitHub 提供的 PR diff，未执行代码或重跑测试；结论仍需维护者核验。

[hygon-ai-ai-reviewer]

AI CI 失败分析

工作流：HCU PR CI
状态：失败

总结

• Selected hardware tests / integration-smoke-gfx938-p1of2：lora-switching 用例的 EngineCore 启动阶段崩溃，直接报错 RuntimeError: Paged KV cache block size must be divisible by 64 at gfx936 platform，调用路径经 flash_attn_varlen_func（本用例环境含 VLLM_HCU_USE_FLASH_ATTN_UNIFIED=1）；随后测试以 AssertionError rc=1 汇总该用例失败，rc=1 本身仅为汇总信号。；直接异常为 L934：flash_attn_cuda.varlen_fwd 抛 RuntimeError，要求 gfx936 平台 Paged KV cache block size 必须可被 64 整除；随后 L968 报 Engine core initialization failed，L970 断言失败，L976 汇总 1 failed。根因是运行时所用 block size 未满足该平台约束。

• Selected hardware tests / accuracy-gfx936：pytest 汇总 4 failed, 43 passed, 1 deselected（L2557）；可逐字核对的直接异常含 paged_attention 调用参数不兼容的 TypeError（定位 fa_utils.py:298），以及 test_hcu_kernel_accuracy.py:410 的显存峰值断言失败。exit code 1 为测试失败后的汇总退出信号，非根因本身。

• Selected hardware tests / qwen35-smoke：直接可见失败为测试封装抛出 AssertionError：vLLM integration case 'smoke' failed with rc=1（L660），命令为 python3.10 -m tests.integration.model_runtime smoke（L661）。本批嵌入的子进程输出仅到插件加载 INFO，rc=1 的底层原因未出现，无法确定根因。；日志直接证明：EngineCore 执行步进时经 flash_attn_cuda.varlen_fwd 抛出 RuntimeError: Paged KV cache block size must be divisible by 64 at gfx936 platform（L812），随后引擎致命错误（L738）并触发 MPClient shutdown，测试断言失败于 model_runtime.py:450（L845），1 failed、exit code 1。原始根因指向该平台 KV cache block size 与 flash_attn 64 整除约束冲突。

• Selected hardware tests / integration-smoke-gfx938-p2of2：graph-parity 用例进程返回 rc=1，测试包装层抛出 AssertionError（L677），命令为 tests.integration.model_runtime graph-parity（L678）。用例内部首个报错未出现在本批片段，深层根因无法确定。；flash_attn varlen_fwd 执行时抛出 RuntimeError: Paged KV cache block size must be divisible by 64 at gfx936 platform（L829），EngineCore 随后报 fatal error（L755），smoke 子进程 rc=1 导致 test_qwen35_9b_greedy_generation_smoke 断言失败（L973）。；EngineCore 执行时发生致命错误（L1051），直接异常位于已安装的 flash_attn 包的 varlen_fwd 调用：RuntimeError: Paged KV cache block size must be divisible by 64 at gfx936 platform（L1125）；随后 MPClient 关闭引擎，JUnit 汇总 tests=2、failures_or_errors=2（L1165）。

• ci-gate：尚未定位可核对的直接异常。

与本次改动的关系

无法确定：已定位的直接异常对本次改动的关联判断一致。

建议处理

1. 核对 gfx936/gfx938 平台下 paged KV cache block size 的配置来源与默认值，确保启用统一 flash attention 时取 64 的倍数；此为最小处理方向，需人工核验后实施。

2. 核对 gfx936 平台实际生效的 Paged KV cache block size 配置来源（引擎配置或平台条件分支），设置满足可被 64 整除约束的值；此为最小处理方向，需结合代码与配置人工核验，未实际修改。

3. 先在相同镜像与 gfx936 环境复跑该测试文件确认是否稳定复现；对照 paged_attention 扩展绑定的签名与调用方参数个数/顺序是否匹配，留意编译产物与当前源码是否同步；再核对 fa 显存断言公式的预期来源。以上为排查方向，均未执行。

4. 最小处理方向：核对日志中指向的制品 /hcu-ci-artifacts/integration/20260915_181224_Qwen3.5-9B_smoke.log 尾部首个报错，确定 rc=1 具体发生阶段后再决定是否需要改代码；本批证据不足以直接要求代码变更。

5. 核对 gfx936 平台上 paged KV cache block size 的实际取值及其设置来源（vllm 配置或插件侧），确认其不满足 flash_attn 的 64 整除要求；如需适配，考虑在该平台将 block size 设为 64 的倍数或选择 attention 后端前做约束校验。建议仅作方向，需人工核验后实施。

6. 结合其它批次与用例产物日志定位 graph-parity 返回 rc=1 前的首个错误；再核对本次 diff 是否涉及 graph parity 或 flash attention 相关路径，之后再决定是否需要改代码。

7. 最小处理方向：人工核对 paged KV cache block size 配置与平台约束（报错要求在 gfx936 平台可被 64 整除），并确认报错平台标识 gfx936 与任务硬件 gfx938 的一致性；结合其它批次确认约束来源组件后再决定是否改代码。

8. 最小方向：核对该平台上 flash_attn 对分页 KV cache 块大小的约束（错误信息要求可被 64 整除）与引擎实际 block_size 配置是否匹配；比对任务目标的平台标识与报错所写平台标识是否一致，并结合其它批次定位约束来源。