执行摘要

• 一句话：移除跨模块的未使用 fake 实现，清理 torch.compile 适配代码。
• 推荐动作：此 PR 是一个典型的、大规模的代码清理（cleanup）工作。对于希望了解 vllm 如何管理自定义操作与 torch.compile 集成、或对代码库健康度感兴趣的工程师，值得快速浏览其变更模式。对于维护者，建议结合 CI 结果确认无回归后合并。其价值在于执行而非设计创新。

功能与动机

虽然 PR body 内容较为简略，但标题和变更模式明确指出了动机：移除代码库中不再使用的 fake 实现。这些 fake 实现是为 torch.compile 服务的占位符函数，在库的演进过程中，部分操作的 fake 实现可能已过时或被其他机制替代，保留它们只会增加代码噪音和维护成本。移除它们可以简化代码，减少潜在的错误点。

实现拆解

1. 变更入口：变更遍布多个核心模块文件，入口分散在 vllm/_aiter_ops.py（ROCm AITER 操作）、vllm/_custom_ops.py（通用自定义操作）、vllm/_xpu_ops.py（XPU 操作）以及 vllm/model_executor 和 vllm/models 下的多个模型/层实现文件中。
2. 核心逻辑改造：每个被修改的文件都执行相同的模式：a) 删除标记为 fake 的函数定义（例如 *_fake 函数）；b) 移除在 direct_register_custom_op 调用中传递给 fake_impl 参数的对应引用。例如，在 vllm/_aiter_ops.py 中，_rocm_aiter_topk_softmax_fake 等多个 fake 函数被整体删除，同时其在注册 rocm_aiter_topk_softmax 操作时的 fake_impl 参数也被移除。这样的改动意味着 PyTorch 编译器在追踪这些自定义操作时，将不再使用这些假实现来推断输出形状或类型，可能依赖于操作本身的元信息或其他机制。
3. 配套改动：本次变更没有包含测试、配置或部署文件的配套修改。这表明被删除的 fake 实现可能确实未被任何测试用例或编译路径所依赖，或者其功能已由其他方式保障。

关键文件：

• vllm/_aiter_ops.py（模块 AITER 内核；类别 source；类型 core-logic；符号 _rocm_aiter_topk_softmax_fake, _rocm_aiter_topk_sigmoid_fake, _rocm_aiter_biased_grouped_topk_fake, _rocm_aiter_grouped_topk_fake）: 删除了最多的 fake 实现（如 _rocm_aiter_topk_softmax_fake 等），涉及 ROCm 平台多种内核操作。
• vllm/_custom_ops.py（模块 自定义操作；类别 source；类型 core-logic；符号 _scaled_fp4_quant_out_fake, _moe_gptq_gemm_rdna3_fake, fp32_router_gemm_fake, _fake_fused_quantize_nv）: 删除了涉及 FP4 量化、MoE GPTQ、Router GEMM、NV 量化融合等多个通用自定义操作的 fake 实现。
• vllm/_xpu_ops.py（模块 XPU 内核；类别 source；类型 core-logic；符号 _gemma_rms_norm_fake, _fused_add_gemma_rms_norm_fake, _gdn_attention_core_xpu_fake, _xpu_deepseek_fused_indexer_q_rope_fp8_fake）: 删除了 Intel GPU/XPU 平台相关操作的 fake 实现，包括 Gemma RMS Norm、GDN 注意力、DeepSeek 索引器等。
• vllm/model_executor/layers/attention/attention.py（模块 注意力层；类别 source；类型 data-contract；符号 unified_attention_with_output_fake）: 删除了核心统一注意力操作（unified_attention_with_output）的 fake 实现，影响广泛。
• vllm/model_executor/offloader/prefetch_ops.py（模块 权重卸载；类别 source；类型 data-contract；符号 _wait_prefetch_fake, _start_prefetch_fake）: 删除了权重预取/等待操作的 fake 实现，这些操作对编译器的数据流分析至关重要。

关键符号：direct_register_custom_op

关键源码片段

vllm/_aiter_ops.py

删除了最多的 fake 实现（如 _rocm_aiter_topk_softmax_fake 等），涉及 ROCm 平台多种内核操作。

# 原始文件 vllm/_aiter_ops.py 在变更前包含大量如下的 fake 函数定义：
def _rocm_aiter_topk_softmax_fake(
    topk_weights: torch.Tensor,
    topk_indices: torch.Tensor,
    token_expert_indices: torch.Tensor,
    gating_output: torch.Tensor,
    renormalize: bool,
    num_shared_experts: int = 0,
    shared_expert_scoring_func: str = "",
) -> None:
    # 这是一个空的 fake 实现，用于 torch.compile 追踪。
    # 其作用是告知编译器该操作不产生输出张量（或输出已在参数中），
    # 且不修改除 mutates_args 声明外的其他输入。
    pass
​
# 在函数注册时，之前会传入该 fake：
direct_register_custom_op(
    op_name="rocm_aiter_topk_softmax",
    op_func=_rocm_aiter_topk_softmax_impl,
    mutates_args=["topk_weights", "topk_indices", "token_expert_indices"],
    fake_impl=_rocm_aiter_topk_softmax_fake, # 此参数被移除
    dispatch_key=current_platform.dispatch_key,
)
​
# 变更后，fake 函数定义被删除，注册调用中也不再包含 fake_impl 参数。
# 这要求 PyTorch 编译器能从其他来源（如操作本身的元信息）推断出正确的形状。

vllm/_custom_ops.py

删除了涉及 FP4 量化、MoE GPTQ、Router GEMM、NV 量化融合等多个通用自定义操作的 fake 实现。

# 原始文件 vllm/_custom_ops.py 中，部分 fake 实现被条件性地定义在 hasattr 检查内：
if hasattr(torch.ops, "_rocm_C") and hasattr(torch.ops._rocm_C, "moe_gptq_gemm_rdna3"):
    @register_fake("_rocm_C::moe_gptq_gemm_rdna3")
    def _moe_gptq_gemm_rdna3_fake(
        a: torch.Tensor,
        c: torch.Tensor,
        # ... 其他参数 ...
    ) -> None:
        # 同样是一个空的 fake 实现。
        return
​
# 变更后，整个 if 块（包括 fake 函数定义）被删除。
# 这意味着即使底层 C++ 操作存在，其对应的 fake 也不再注册。

vllm/_xpu_ops.py

删除了 Intel GPU/XPU 平台相关操作的 fake 实现，包括 Gemma RMS Norm、GDN 注意力、DeepSeek 索引器等。

# 原始文件 vllm/_xpu_ops.py 中，类似地移除了以下 fake：
def _gdn_attention_core_xpu_fake(
    core_attn_out: torch.Tensor,
    z: torch.Tensor,
    projected_states_qkvz: torch.Tensor,
    projected_states_ba: torch.Tensor,
    layer_name: str,
) -> None:
    return # 空实现
​
# 在注册处：
direct_register_custom_op(
    op_name="gdn_attention_core_xpu",
    op_func=eager_break_during_capture(_gdn_attention_core_xpu_impl),
    mutates_args=["core_attn_out", "z"],
    # fake_impl 参数被移除
)

评论区精华

Review 过程中几乎没有技术讨论。两位审阅者（aoshen02, gau-nernst）均直接批准（APPROVED），无评论。唯一的评论来自 claude[bot]，是配置说明，非技术讨论。这暗示此次清理可能经过事先确认，移除决策风险较低，或属于公认的维护任务。

• 未进行任何技术讨论 (other): 变更被两位审阅者直接批准，表明清理决策已达成共识或风险被认为极低。

风险与影响

• 风险：

  1. torch.compile 兼容性风险：移除 fake 实现后，若某些自定义操作在 torch.compile 的图捕获（graph capture）阶段仍依赖这些 fake 来确定输出元数据（如形状、类型），则可能导致编译失败或运行时错误。需要确认这些操作是否已在其他地方（如 PyTorch 操作库本身的元函数）提供了足够的元信息。
  2. 回归风险：尽管变更量很大（956 行删除），但模式单一且机械。主要风险在于可能遗漏了某些仍在间接使用的 fake 实现，导致特定模型或平台的推理路径出错。需要依赖全面的 CI 测试来验证。
  3. 平台特定风险：变更涉及多个硬件后端（NVIDIA、ROCm、Intel GPU/XPU）。移除某个平台的 fake 实现，理论上只会影响该平台的编译路径，但若代码共享，也可能交叉影响。
     - 影响：用户影响：对于终端用户，如果变更成功且未引入回归，将无直接感知。代码库更整洁，长期看有助于维护。
     系统影响：减少了代码体积和符号数量，可能略微加速模块导入和代码分析。影响范围是使用了 torch.compile 和相关自定义操作的推理流程。
     团队影响：降低了维护者的认知负担和未来修改时的困惑。清理了潜在的死代码，使自定义操作的注册模式更清晰。

• 风险标记：大规模删除代码, torch.compile 兼容性, 平台特定逻辑移除

关联脉络

• 暂无明显关联 PR