执行摘要

• 一句话：清空 FlashInfer BF16 置换索引缓存，修复 RL 权重更新损坏
• 推荐动作：值得精读的短小修复。虽然改动只有 5 行，但背后是 RL 权重热更新与 GPU 缓存生命周期的经典冲突。建议关注两点：一是“在周期开始时清空缓存、周期内继续复用”的权衡；二是向后续维护者提示同类缓存（如 MXFP8、NVFP4 之外的其他后端缓存）需要一并审计。对从事 RL 训练、权重热更新或 FlashInfer 后端的工程师尤其有参考价值，后续应跟进正式单测。

功能与动机

RL 权重更新流程中，rollout 模型在加载新权重前会 pause 并 offload。UnquantizedFusedMoEMethod 把 FlashInfer permutation-index 张量缓存在 GPU 上，模型 resume 后这些张量可能指向已释放内存，复用它们会把新加载的 BF16 expert 权重按陈旧索引乱序写入，导致推理结果损坏。PR body 明确说明 #28676 只修复了 MXFP8 缓存，而 BF16 专家走的是 UnquantizedFusedMoEMethod 的另一套 cache。关联 Issue #28676 描述的现象是 train_rollout_logprob_abs_diff 从约 0.06 跳到约 3.83，根因是缓存同 shape 命中但内容已失效。

实现拆解

1. 变更入口：python/sglang/srt/layers/quantization/unquant.py 中 UnquantizedFusedMoEMethod.process_weights_after_loading() 是权重加载后的统一后处理入口，本 PR 只修改其中 if self.use_flashinfer_trtllm_moe: 分支。
2. 核心逻辑：在该分支起始处新增 self._cache_permute_indices.clear()，将 FlashInfer BF16 permute 索引缓存的生命周期与权重后处理周期对齐。这些索引只依赖权重 shape，因此重建后同一周期内各 expert 仍通过 _maybe_get_cached_w3_w1_permute_indices 与 get_w2_permute_indices_with_cache 复用索引，既保证正确性又不引入重复计算。
3. 为何 NVFP4 不受影响：ModelOpt NVFP4 量化路径的 prepare_static_weights_for_trtllm_fp4_moe() 每次 post-load 调用都会在局部创建 permutation-index 字典，本身不存在跨 cycle 的 GPU 缓存，因此无需清理。
4. 验证与配套：PR 未新增仓库内测试文件，但作者提供了外部回归测试（连续两次 BF16 FlashInfer post-load 循环，1 项通过）以及两个 8× B200 上的 Miles E2E（DeepSeek V3.2 5 层 MXFP8、GLM-5.2 5 层 NVFP4），权重更新/恢复循环均成功。无配置、schema 或部署配套改动。

关键文件：

• python/sglang/srt/layers/quantization/unquant.py（模块 量化层；类别 source；类型 core-logic；符号 process_weights_after_loading, UnquantizedFusedMoEMethod）: 唯一变更文件：在 UnquantizedFusedMoEMethod.process_weights_after_loading() 的 FlashInfer TRT-LLM 分支起始处清空 _cache_permute_indices，防止 RL colocated 权重 offload/resume 后索引张量指向已释放内存，修复 BF16 MoE 权重被打乱的问题。

关键符号：process_weights_after_loading

关键源码片段

python/sglang/srt/layers/quantization/unquant.py

唯一变更文件：在 UnquantizedFusedMoEMethod.process_weights_after_loading() 的 FlashInfer TRT-LLM 分支起始处清空 _cache_permute_indices，防止 RL colocated 权重 offload/resume 后索引张量指向已释放内存，修复 BF16 MoE 权重被打乱的问题。

# 权重后处理（post-load）阶段的核心分支：为 FlashInfer TRT-LLM MoE 重排权重
if self.use_flashinfer_trtllm_moe:
    # 缓存的 permute 索引是 GPU 张量；colocated 权重 offload 在两次 reload
    # 之间会释放其底层内存，导致旧索引指向已释放区域。
    # 因此在每个 post-processing 周期开始时清空，强制重建；
    # 同一周期内各 expert 仍然复用这些索引，避免重复计算。
    self._cache_permute_indices.clear()
​
    from flashinfer.fused_moe.core import (
        _maybe_get_cached_w3_w1_permute_indices,
        convert_to_block_layout,
        get_w2_permute_indices_with_cache,
    )
​
    # w1 与 w3 已完成交换，这里只需要按 block layout 重排行顺序
    epilogue_tile_m = 128
    block_k = 128
    old_shape_w13 = layer.w13_weight.data[0].shape
    old_shape_w2 = layer.w2_weight.data[0].shape
    new_shape_w13 = None
    new_shape_w2 = None
    for i in range(layer.num_local_experts):
        # 从缓存获取（或首次计算）w3/w1 的 permute 索引
        permute_indices = _maybe_get_cached_w3_w1_permute_indices(
            self._cache_permute_indices,
            layer.w13_weight.data[i].view(torch.uint8),
            epilogue_tile_m,
            is_gated_act_gemm=layer.moe_runner_config.is_gated,
        )
        # 按索引重排权重，产出 kernel 所需的逐块连续内存布局
        tmp_weights1 = (
            layer.w13_weight.data[i]
            .clone()
            .view(torch.uint8)[permute_indices.to(layer.w13_weight.data.device)]
            .contiguous()
        )
        # 后续对 w2_weight 执行相同流程并写回，再处理下一 expert

评论区精华

本 PR 没有产生实质 review 评论线程，Fridge003 直接批准合并。最有价值的技术说明集中在 PR body 与关联 Issue #28676 中：

• 这类按 shape 记忆化的 GPU 索引缓存面临“同 shape 命中但内容已失效”的静默复用风险，是权重热更新场景的通用陷阱。

• 前一修复（#28676）只覆盖 MXFP8 的 _flashinfer_trtllm_shuffle_row_indices_cache_mxfp8，本 PR 补齐了 BF16 路径，说明同一问题可能在多个缓存点重复出现。

• 暂无高价值评论线程

风险与影响

• 风险：清空缓存带来的一次性重建开销只发生在权重后处理阶段（每个 cycle 一次），不在模型 forward 热路径上，性能风险可忽略。行为正确性上，若同一 cycle 内多次调用 process_weights_after_loading，首次调用后重建的索引仍有效并被后续调用复用，不会回归。主要风险是缺少仓库内单测：目前验证依赖外部回归测试和 E2E，建议后续补充覆盖“连续两次 post-load”的单元测试，防止类似缓存失效问题在 _cache_permute_indices 之外的其他 GPU 持久化缓存（如 shape 相关缓存）上再次出现。
• 影响：受益对象是使用 RL colocated（Miles）训练、且 MoE 走 flashinfer_trtllm_routed 路径的用户，尤其是混合精度 checkpoint（BF16 experts）如 DeepSeek V3.2。修复前权重更新后推理结果可能静默损坏（logprob 偏差从 0.06 量级跳到 3.83 量级），修复后 3/3 rollout、24/24 training step 均通过。对系统整体性能无感知影响；对团队而言，本 PR 提供了一个可复用的修复模式：GPU 持久化缓存需要与可暂停内存区域的释放周期同步失效。
• 风险标记：缺少仓库内单测, 权重后处理路径, GPU 缓存生命周期

关联脉络

• PR #28676 [RL] fix deepseek v4 MXFP8 flashinfer_trtllm_routed MoE weight update: 与本 PR 是同一问题的姊妹修复：28676 清除了 MXFP8 的 _flashinfer_trtllm_shuffle_row_indices_cache_mxfp8 缓存，本 PR 清除了 BF16 路径的 _cache_permute_indices，两者都源于 GPU 索引缓存与权重 offload 内存生命周期不同步。