执行摘要

此PR针对ROCm平台，默认禁用RoPE自定义操作符以修复MI355 GPU上的性能退化，并调整rope+kvcache融合条件，将优化级别从O1提升至O2。变更影响编译配置和文档，旨在平衡性能与稳定性。

功能与动机

动机源于测试发现vLLM RoPE自定义操作符在MI355上导致高达5%的性能回归（PR body引用：'vLLM RoPE custom op also regresses MI355 perf by up to 5%'）。因此，临时禁用它直到更多微基准数据，同时更新fuse_rope_kvcache融合的启用条件，作为#35601的后续改进。

实现拆解

实现按模块拆解：

• 平台配置模块（vllm/platforms/rocm.py）：移除默认启用rotary_embedding自定义操作符的代码段，直接避免性能退化。
• 配置模块（vllm/config/vllm.py）：修改enable_rope_kvcache_fusion函数，添加条件cfg.compilation_config.use_inductor_graph_partition or not cfg.compilation_config.splitting_ops_contain_kv_cache_update()，并默认将fuse_rope_kvcache设为False。
• 编译配置模块（vllm/config/compilation.py）：新增def splitting_ops_contain_kv_cache_update(self) -> bool:函数，处理kv cache操作符检查；在set_splitting_ops_for_v1中添加警告逻辑，在特定条件下禁用融合。
• 文档模块：更新docs/design/fusions.md和optimization_levels.md，将fuse_rope_kvcache移至O2并补充性能收益2-4%。

评论区精华

Review讨论中最有价值的交锋：

1. typo修复：gemini-code-assist[bot]指出：'There\'s a typo in the operator names... This will cause splitting_ops_contain_kv_cache_update to always return False'，Rohan138回应'good catch, fixed'，快速修复关键bug。
2. 逻辑设计权衡：ProExpertProg质疑：'If self.splitting_ops is None, then kvcache ops might get added, no? So this check if called before splitting ops is set might be deceiving?'，Rohan138添加早期返回条件并评论：'I added the early return True condition. I do think it\'s a bit unclean as it stands IMO, until https://github.com/vllm-project/vllm/issues/33267 is resolved.'，体现对复杂性的认知和临时解决方案。

风险与影响

• 技术风险：新函数splitting_ops_contain_kv_cache_update逻辑可能在高并发或边缘配置下出错；禁用RoPE自定义操作符可能在其他硬件上引入性能损失；文档更新若不准确可能误导用户。
• 影响分析：主要影响ROCm平台用户，避免MI355性能退化但牺牲优化灵活性；融合条件调整需用户重新评估编译设置；文档变更提升透明度，帮助用户更好理解优化层级。

关联脉络

• 历史PR关联：此PR直接关联#35601（PR body提及），属于同一功能线的性能优化迭代。近期仓库PR中，如#37529（ROCm MoE修复）和#38505（ROCm CI调整）显示ROCm平台持续改进趋势，但本PR更专注于rope和kv cache融合的微调。
• 演进方向：讨论中提及未来可能通过模式匹配或vLLM IR迁移来进一步优化RoPE处理，揭示了架构演进方向：逐步将复杂优化逻辑标准化，以减少平台特定hack。