vllm-project/vllm · 标签视图

拆分 docstring 中斜杠合并参数，消除 griffe 文档警告

值得一读，但价值不在代码逻辑而在工具链约定：这是一个典型的“工具报错驱动的文档规范化”小改动，阅读时建议关注三点——(1) 斜杠合并写法为什么会让 griffe 同时漏掉两个真实参数，这是写 kernel docstring 时最容易踩的坑；(2) 拆分过程中对 `row_ks`/`row_ke`、`cu_seqlen_ks`/`cu_seqlen_ke` 补写 start/end 语义的做法，说明好的拆分应顺带澄清语义而非机械换行；(3) 是否值得在 CI 中把 griffe 警告提升为可见的检查项，以弥补 `ruff` 规则缺位导致的防回归空白。若只关心运行时行为，可以完全跳过本 PR。

DCP 有效注意力块大小贯通配置、握手与 gRPC

值得精读，尤其适合维护 KV cache 事件消费端、DCP 部署或 Rust 前端的工程师。重点关注三处设计决策：一是 `EngineCore._initialize_effective_attention_block_size()` 只在 full-attention 分组口径唯一时暴露值，体现了"不可靠就返回 None"的保守契约；二是 `_apply_ready_response` 把空 payload 也纳入一致性集合，这是一个容易忽略的边界；三是 Rust 侧把聚合从 gRPC service 上移到 `EngineCoreClient`，使"多引擎一致才可用"的语义集中在客户端。建议读完后一并确认 Elastic EP 缩容的遗留问题是否需要在 own 的部署形态下先行规避。

ROCm MLA RoPE 测试改为按 ULP 分级容差

值得精读，尤其是从事 ROCm 内核、数值测试或 CI 稳定性的工程师：这是“不要靠调 atol/rtol 掩盖数值差异”的一个正面范例，用 FMA 预舍入选择推导出 2 product-ULP 的物理上界，再用失败比例上限约束整体行为。阅读顺序建议：先看 PR body 中 Triton 3.7 vs 3.8 的 lowering 对比理解动机，再看 `assert_rope_close_rocm` 的 Tier 1/Tier 2 双段断言与 NeoX/交错两套乘积推导，最后看 `test_concat_and_cache_mla_rope_fused` 如何用 slot_mapping 把 KV cache 的 rope 区段收集回 token 顺序、并把 nope 区段保持严格比对。需要留意的设计决策是 bf16 的 `max_fail_fraction=1e-2` 取值依据（仅由 eps 更粗解释）以及 fp8 分支未被纳入统一模型；若后续要推广该断言，应先确认这两个边界。

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`。

DSpark KV 插入改走零查询头 KV-only 算子

值得精读，尤其是要改 KV cache 写入、融合内核或投机解码插入路径的工程师。 优先关注三处设计决策：一是用 `kNumHeadsQPadded == 0` 复用既有三条内核路径而不是新写 KV kernel，收益来自 RoPE 舍入与量化行为天然一致，代价是模板参数与网格逻辑要额外小心；二是把记录宽度从 Python 属性搬到 C++ 侧由 cache 张量形状推导，降低了与 attention 层属性命名的耦合；三是把输入校验从隐式约定改成 wrapper 里的 `STD_TORCH_CHECK`，让错误在算子入口立刻暴露。 阅读时要带着两个坑：网格选择在零查询头下的退化只在 >16k token 单次插入时显现，512/2048 token 的微基准会掩盖它；以及测试只对 dummy-query 基线做逐字节相等，不等于与模型参考实现数值等价。建议后续把与 #55654 重复的 uint8 API 收敛，并补一条 ≥ `NUM_TOKEN_CUTOFF` 的大 token 插入测试，以及 fp8 缺 scale、非法 dtype 的报错路径测试。

V4.1 索引器接入稀疏 MQA logits，长上下文提速

值得精读，尤其适合负责长上下文推理性能、KV cache 布局和内核接入的同学。重点关注四处设计决策：一是「一个独立的 `SparseMQAIndexer` 模块 + 独立 backend，而不是在 dense indexer 里加分支」，候选源层与消费者层的语义被清晰切开；二是「所有校验前移到引擎启动、路径上不留任何 PyTorch fallback」，这是评审反复推动的结果，也是这类新内核接入的可复用范式；三是「weights dtype 由融合 Q 核直接产出 bf16」，把 dtype 转换从热路径消灭掉；四是 KV 块的 `block_stride_alignment` 对齐方案，用 0.8% 显存换取 DeepGEMM 分页核的 512B 步长约束。阅读时建议配合 `tests/model_executor/layers/test_mla_short_prefill_indexer.py` 的参考实现一起看，并确认 `_INT32_BIG` 的模块级 `tl.constexpr` 是否已在合入版本修正。

修复 HiSparse 跨层 KV 覆盖，逐层计算绑定偏移

值得精读。修复本身只有 15 行，但揭示了共享分配（packed allocation）场景下 byte offset 计算的经典陷阱；PR 的调试与验证方法论（恢复单个函数到旧 commit 做负对照、curl 最小复现、全量 GSM8K + nightly 精度门槛）对处理类似缓存绑定类 bug 有直接借鉴意义。重点关注 `bind_hisparse_kv_caches` 的 `tensor_configs` 推导重构，以及 nightly 作业的 `source_file_dependencies` 设计。

ROCm Aiter MLA 支持非因果 draft 解码

值得精读，尤其是维护 ROCm/MLA 后端的同学。建议按三条线索阅读：(1) `AiterMLABackend.supports_non_causal()` 的「Python 签名 + per-arch manifest」双层判定——它说明了 AITER 的 Python 接口与 ASM kernel 表不同步这一结构性问题；(2) `AiterMLAMetadataBuilder` 把 `_decode_causal` 放在 per-ubatch 实例上、而不是扩展共享 `_build_decode` 契约的重构（commit `5d9817e6`），是避免为 AMD 专有需求改动 CUDA 也要实现的接口的好范例；(3) `has_fp8_non_causal_qlen2_kernel` 的白名单，是理解 AITER fp8 dispatch fold 规则的现成材料，也是本 PR 最脆弱的假设。跟进建议：确认 AITER 是否计划暴露能力 API；评估在 CI 中加入 gfx942 fallback 与长 qlen 非因果块的端到端用例。