vllm-project/vllm · 标签视图

kpool 索引器迁入 glm5next 并拆分后端

值得精读，但重点不在 729 行的搬运量，而在三处设计决策：一是 `vllm/models/glm5next/sparse_indexer.py` 这个 22 行 dispatcher——它决定了所有平台行为，CodeRabbit 指出的「非 ROCm 即 NVIDIA」回落值得你判断是否要改成显式平台判定；二是 `CustomOp` 的 `forward_hip` / `forward_native` dispatch 契约，任何把实现按硬件拆文件的改动都要先确认被覆写的方法名与 `dispatch_forward()` 的绑定规则一致，否则就是 Codex 那条 P1；三是 helper 抽取边界——只抽纯索引/形状逻辑、把 kernel 调用留在后端文件，这个尺子本 PR 把握得比较准，可以照搬到其他模型。若你在 ROCm 上使用 `custom_ops=["all"]` 或 enforce-eager，建议先确认 `forward_hip` 是否已补上再升级；若你的代码直接 import 了 `vllm.model_executor.layers.sparse_attn_indexer_kpool`，需要同步迁移到 `vllm.models.glm5next.sparse_indexer`。

统一 h2d 异步复制工具，删除 async_copy_to_gpu

值得精读。重点关注 `async_tensor_h2d` 的 staged+pinned 设计（为什么 `pin_memory()` 返回新张量后还需要显式 stage 到连续 pinned 缓冲区）以及 `CpuGpuBuffer.copy_to_gpu` 对 FlashInfer 等后端的封装方式。对于后续做输入路径性能优化或接入新模型的工程师，建议直接统一使用 `async_tensor_h2d`，避免再次引入重复的拷贝工具。

清理 8 文件 1895 行死内核代码，覆盖 AMD 与量化算子路径

值得快速浏览，不必精读。它展示了 vLLM 中临时代码生命周期的管理实践：在 docstring 中写明删除条件（如 AITER 修复版本），到期后由维护者执行清理。对于内核与算子维护者，建议关注两个设计决策：一是 lamport.py 中基于 PDL 的死锁规避证明方法，这是跨 GPU 通信 kernel 的高价值设计文档，即使代码被删除也值得从 git 历史中学习；二是 triton_fp8_mqa_logits.py 中针对 gfx942 LDS 预算的 tile 大小自适应判断，展示了 Triton kernel 在特定硬件上做 occupancy 与硬件上限双重校验的思路。另外，本 PR 完全没有 review 讨论，阅读时建议自行核对删除边界，或在需要修改这些目录时通过 git blame 追溯删除决策。

重构结构化输出与投机解码的约束起点契约

值得精读，且建议按「契约 → 消费方 → 测试」的顺序读：先看 `vllm/v1/structured_output/__init__.py` 的 `_get_constraint_start()`，它是整个 PR 唯一的语义来源；再看 `scheduler.py` 三个调用点确认新契约的用法；最后看 `test_structured_output_manager.py` 的 `FlowCase` / `_run_real_flow()` 理解验证方式。重点关注四个设计决策：(1) 用 `len + 1` 哨兵而非 `None` 表达「本窗口无约束」，三个消费点的 `>=` / `>` / `<=` 各有语义，不要「顺手统一」；(2) 降序扫描把语义从「第一次边界」改成「最后一次边界」，这对交错思考模型更合理但改变了行为；(3) 断言降级为日志是刻意的（避免 engine core 被打挂），代价是失败请求要等 accept 阶段兜底；(4) 「reasoning parser 必须无状态」目前只是文档契约，落地前不建议在生产上把 stateful parser 与投机解码 + 结构化输出组合使用。

reasoning 结束判定统一由语法派生，删除多模型 override

值得精读，尤其推荐 parser / structured-output 方向的 owner 逐段读 `ParserEngine.is_reasoning_end` 的新实现与两条新测试。三个最值得关注的设计决策：一是把「无标记尾部」语义显式提为 config 字段而不是继续散落在模型分支里；二是用「从初始状态出发的 `THINK_START` 迁移是否进入 REASONING」来区分惰性 `<think>` 与真正打开 reasoning，这一条同时支撑了 thinking off 的行为修正；三是用 `turn_boundary_tokens` 而非更长的手写分支来限定回合。阅读时请一并记住作者自曝的三处未解决项（`extract_content_ids` 分歧、未声明边界的 latch、gemma4 惰性 `<|tool_response>`），若后续要动这些模型的 `continue_final_message` 或多轮工具调用，应优先补上边界声明与针对性用例。

删除 TPU 版 InputBatch 死代码与联合类型别名

值得快速精读一遍而不是逐行细看：核心收益在于识别“联合 TypeAlias 会让死代码看起来仍被使用”这一模式，以及 `lora_model_runner_mixin` 长期充当数据契约枢纽的分层倒置问题。建议关注三点：一是删除前如何用仓库内引用检查确认 `tpu_input_batch.py` 无使用者；二是 `mamba_utils.py`、`test_mamba_prefix_cache.py` 为何必须与源码注解同步改动；三是 `GPUInputBatch` / `TPUInputBatch` 这两个旧符号消失后，是否存在仓库外的依赖需要公告（例如在 release note 或迁移说明中提一句）。若后续做类似清理，建议在 PR body 中显式记录删除依据，避免“空 body 的纯删除 PR”只能靠维护者盲签。

MRV1 弃用前翻转 specdec 检查为黑名单并统一 ngram 分支

无需精读，快速浏览即可。值得关注的设计决策是“弃用过渡期把白名单倒置为黑名单”的思路：当旧运行时即将移除时，从维护“支持什么”转向维护“还不支持什么”，既减少维护成本，也让新特性默认流向新实现。对正在做类似运行时迁移的团队有参考价值。

统一多模态 LoRA token 计数钩子，20+ 模型迁移到新接口

值得精读，尤其是维护多模态模型接入和 LoRA 子系统的工程师。建议重点关注三处：`vllm/model_executor/models/interfaces.py` 的契约定义与弃用策略、`ultravox.py` 中“不再反解 chunk 数”的语义澄清（最容易被忽略的行为差异）、以及 `blip2.py` / `llava_next_video.py` 的整除与守卫改动。阅读时建议对照每个模型旧钩子的链式调用结果做一次等价性核对；同时把 Codex 的 P2 作为待办跟进——要么在已迁移模型上补 legacy 包装，要么明确公告旧 API 在本次发布中失效；并推动一个后续 PR 完成 legacy 钩子的最终移除与 `modality` / `mm_kwargs` 入参的实际落地验证。