vllm-project/vllm

新增 DSv4.1 自动打标规则，并用负向断言收紧 DSv4

若你是维护者或 CI 负责人，值得精读 PR body 中“两个打标器如何保持互斥”的推理段落，尤其是用负向先行断言做版本边界、以及“Flash/Pro 不可按文件条件区分所以不拆标签”的取舍；普通工程师只需知道这是标签配置变更，无需逐行看 YAML。建议跟进三件事：一是合并后立刻确认 DSv4.1 标签存在并完成回填与 #56228 纠正；二是把作者验证过的 25 条标题案例固化成测试（作者已明确愿意提交），补上 check-label-rules 不覆盖的标题正则盲区；三是把 `(?![._]?1)` 这种一次性 lookahead 抽象成更通用的版本号边界策略，否则 V4.2 出现时会重演同一问题。

新增 @arpera 为结构化输出 code owner

该 PR 不包含需要精读的实现逻辑，工程师无需逐行阅读。值得关注的设计性决策只有两点：一是采用“追加而非替换”的方式扩充 owner，保证原审查链路不中断；二是实现目录与测试目录的 owner 集合保持同步，避免审查责任出现结构性缺口。对管理者的建议是，把它当作团队维护分工变化的记录即可；真正值得关注的是随之而来的结构化输出演进方向（可结合同目录近期的 frontend structured-output 校验类改动一起观察）。

修复 CuTeDSL Q 迁移后测试入口与 FP8 ABI

值得快速浏览，无需精读。值得关注的决策点有两个：一是大迁移 PR 合并后如何第一时间捡起受影响测试（入口改名导致测试失效）；二是 wrapper 对外暴露 `float8_e4m3fn` 视图、对内保持 `uint8` 字节 ABI 的接口设计，后续迁移其它 CuTeDSL 内核时可复用这套约定。

Rust 前端在请求边界拒绝空的结构化输出约束

**值得精读，但不必逐行通读**。建议重点关注设计决策而非代码体量：(1) 校验为何放在 `validate()` 而不是可失败的构造函数——这是 `WIRE → 领域对象` 转换中「保持构造函数可用、把可失败性集中在边界」的典型取舍；(2) 同一份校验如何被 Serde、OpenAI `response_format`、gRPC 三条路径复用，以及两次漏检是如何被发现的，这对任何多入口的服务端都具备借鉴价值；(3) 描述与注释中「engine abort」被更正为「per-request 失败」的过程，揭示了 vLLM 中语法编译错误实际经由 scheduler 逐请求返回的错误传播链。如果只关心结论，读「关键源码片段」中的 `validate()` 与 gRPC 调用点即可。

Elastic EP 重配置复用 CUDA graph，停机时间降 95%+

值得精读。这是 Elastic EP 从「能扩缩容」走向「扩缩容不打断服务」的关键一步，建议重点看三处设计决策：一是 `can_reuse_fused_moe_kernel` 这种「后端能力开关」如何把不确定性收敛到一个返回布尔值的函数，从而让 commit 路径免于分支扩散；二是 `all2all.py` 中 `stage_ep_size` / `commit_ep_size` / `mask_remote_ranks` 构成的两阶段状态机，配合 `torch.accelerator.synchronize()` 处理 mask 可见性；三是 `eplb_state.py` 里用「最大容量 buffer + 视图」把「CUDA graph 复用」这一性能诉求转化为显存布局约束的做法，以及 `_commit_eplb_maps` 由换 tensor 改为换视图的细节。同时建议对照 PR body 的容量-吞吐对照表评估自己使用的专家内核是否需要调参，并留意 `VLLM_NIXL_EP_MAX_NUM_RANKS` 移除与 nixl 版本升级对运维脚本的影响。

DSV4.1 输入元数据改用 Triton 内核，decode TPOT 降约 15%

值得精读，尤其是正在做 vLLM 元数据路径优化或 CUDA-graph 兼容改造的工程师：`_token_request` 的“设备端二分 + lane 级收敛”与 `_indexer_decode_metadata_kernel` 的单内核多产物（seq_lens / block table / indices / per-request lens / padding 清零）是非常典型的“用内核替代 PyTorch 链”的设计范式，grid 公式 `max(num_decodes, num_decode_tokens + cdiv(capacity - num_decode_tokens, 256))` 同时承担“逐请求写入”和“容量尾部清零”两个职责，值得重点关注。阅读时建议重点核对三处：(a) `num_mapped_tokens` 依旧来自 CPU 的假设边界；(b) varlen 下 `decode_lens_buffer` 由逐请求变逐 token 后所有消费者的适配；(c) `requires_padding = False` 的传播范围。后续建议补两件事：把作者移出 PR 的元数据 benchmark 以 CI 形态回归（至少覆盖 batch-16 decode 与 DSpark 自适应路径），以及请维护者对 `vllm/v1/attention/ops/metadata.py` 的三个内核做一次独立逐行复核，因为当前 PR 只有机器人在场、无人工评审记录。

非 ROCm 平台跳过 ROCm 专属测试，修复 CI 失败

可作为「平台专属测试门控」的最小范例快速浏览，不值得深度精读。值得关注的设计决策是：用统一的 current_platform.is_rocm() 抽象做平台判定，而非散落的平台名判断；新增平台专属测试时应沿用 skipif 门控模式，避免跨平台 CI 被无关用例污染。

RDNA3 MoE 迁入 oracle 结构并修复加载崩溃

值得精读，尤其是正在做 MoE 后端接入、oracle 迁移或 ROCm 量化内核工作的工程师——它是一份完整的「把私有量化后端迁到 oracle/experts 模式」的参照实现，也直观展示了这种架构如何把平台门禁、量化兼容性判定、权重预处理三件事收拢到统一契约。阅读时建议重点看三处设计决策：(1) `workspace_shapes()` 的内存声明，它是替换旧 `layer.rdna3_*_buf` 预分配缓冲后的新契约；(2) `finalize_weight_and_reduce_impl()` 返回 `TopKWeightAndReduceNoOP()` 所依赖的内核 `output_topk` 语义；(3) `_backend_incompatibility_reason()` 中的四条拒绝条件，它直接决定了哪些 checkpoint 会静默回退 Triton。如果你维护 gfx1100 回归，建议把非对称、channel-wise、LoRA 三种回退场景补进手动回归清单，并顺手处理 coderabbit 指出的三个空跑用例；若你负责 MoE 加载路径，`routed_experts.py` 的类名白名单值得单独排期改造，否则同类 KeyError 会再次出现。