执行摘要

• 一句话：禁用 FlashInfer 持久化缓存以规避文件缓存碰撞导致的运行错误
• 推荐动作：建议尽快合入以修复 CI 失败。代码逻辑清晰，并且设计了方便的恢复路径（修改布尔常量即可）；待上游 FlashInfer 修复后应移除该工作区并用回文件缓存。

功能与动机

PR body 指出 FlashInfer 自动调优的持久化文件缓存无法区分 use_8x4_sf_layout 等内核参数，造成缓存键冲突，最终选中无效策略，引发 Check failed: (config.mOptions.mSfLayoutB == mOptions.sfLayoutB) is false: Invalid sf layout in run 运行时错误。

实现拆解

1. 在 vllm/model_executor/warmup/kernel_warmup.py 中增加模块级常量 _FLASHINFER_USE_PERSISTENT_CACHE = False，并附 TODO 注释说明上游修复后可移除。
2. 修改 flashinfer_autotune 函数：当该常量为 False 时，所有 rank 各自执行 fi_utils.autotune()（不传入 cache 参数，即不落盘），调用 runner._dummy_run 进行预填和解码核的自动调优，完成后调用 get_world_group().barrier() 同步，确保所有 rank 调优完成后再执行后续流程。
3. 旧的分 master/worker 使用文件缓存的代码路径完整保留（if 块的 else 分支），便于后续上游修复后通过简单修改常量即可恢复。

关键文件：

• vllm/model_executor/warmup/kernel_warmup.py（模块 预热模块；类别 source；类型 data-contract；符号 _FLASHINFER_USE_PERSISTENT_CACHE, flashinfer_autotune）: 唯一修改的文件，包含 FlashInfer autotune 逻辑的变更：禁用持久化缓存并添加 barrier 同步。

关键符号：flashinfer_autotune

关键源码片段

vllm/model_executor/warmup/kernel_warmup.py

唯一修改的文件，包含 FlashInfer autotune 逻辑的变更：禁用持久化缓存并添加 barrier 同步。

# vllm/model_executor/warmup/kernel_warmup.py
​
# 临时开关：禁用 FlashInfer 持久化文件缓存
# TODO: 待上游 FlashInfer 修复缓存键碰撞问题（如 use_8x4_sf_layout 参数无法区分）后移除
_FLASHINFER_USE_PERSISTENT_CACHE = False
​
def flashinfer_autotune(runner: "GPUModelRunner") -> None:
    import vllm.utils.flashinfer as fi_utils
    from vllm.distributed.parallel_state import get_world_group
​
    if not _FLASHINFER_USE_PERSISTENT_CACHE:
        # 回退方案：每个 rank 独立运行 autotune，不落盘
        with torch.inference_mode(), fi_utils.autotune():
            runner._dummy_run(
                num_tokens=runner.scheduler_config.max_num_batched_tokens,
                skip_eplb=True,
                is_profile=True,
            )
        # 显式 barrier 确保所有 rank 调优完成后再继续，避免死锁
        get_world_group().barrier()
        return
​
    # 以下为原有基于文件缓存的逻辑（保留代码路径）
    world = get_world_group()
    is_leader = world.rank_in_group == 0
    cache_path = _resolve_flashinfer_autotune_file(runner)
    # ... 省略完整逻辑

评论区精华

gemini-code-assist[bot] 在 review 中指出了关键风险：所有 rank 同时进行 autotune 且没有 barrier 的情况下，调优耗时不一致可能导致死锁——先完成调优的 rank 进入后续 warmup 步骤触发集体通信操作，而其他 rank 仍在调优中。mgoin 批准了 PR。

• 分布式同步与死锁风险 (correctness): 作者在代码中新增了 get_world_group().barrier() 来规避死锁风险。

风险与影响

• 风险：分布式环境下（TP > 1），若 autotune 在不同 rank 上耗时差异大，仍有可能出现 barrier 前隐含的集体通信导致死锁（已通过显式 barrier 缓解）。另外，禁用持久缓存后多次启动会重新 autotune，可能增加启动时间，但在 CI 场景中影响可控。
• 影响：直接影响使用 FlashInfer 注意力后端的用户，特别是在多 GPU（TP > 1）场景下。回退到每 rank 独立 autotune 会增加启动开销，但消除了因使用失效缓存导致运行时崩溃的风险。影响范围限定在 vllm/model_executor/warmup/kernel_warmup.py 文件，仅修改一处代码。
• 风险标记：核心路径变更, 潜在死锁问题（已处理）

关联脉络

• 暂无明显关联 PR