vllm-project/vllm

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 的报错路径测试。

为 Nemotron VL 启用语言模型侧 LoRA，绕开编码器内 token 的索引映射缺失

值得精读，重点看两处：一是为什么 VL 包装类必须把 `is_non_gated_moe` / `packed_modules_mapping` / `embedding_modules` / `lora_skip_prefixes` 从 `NemotronHForCausalLM` 抄一遍（LoRA 目标模块解析对元数据完整性的依赖）；二是 `_create_final_video_embeddings` 里 encoder 内部生成 token 与 per-token 适配器索引映射的不匹配，以及用 `base_layer` 兜底的取舍——这是多模态 + LoRA 场景中值得沉淀的通用模式。阅读时请把 linitra24 的提问和 danisereb 的回复对照看：功能虽然打开了，但 embedding LoRA 场景的正确性缺口是被“实际适配器不带 embedding 权重”这一经验事实掩盖的，如果要把它纳入线上能力，建议补一个检测到 embedding LoRA 时的告警或明确文档说明，并加一条多模态 + LoRA 的自动化回归用例。

KV Offload 新增按请求的 max_load_tokens 加载上限

值得精读，尤其面向 KV offload / 调度方向的同学。建议关注三个设计决策：一是 `__post_init__` 的解析约定（`type(raw) is int` 排除 bool、非法值 warning + 忽略而非报错）；二是 cap 在 `_lookup_complete_chunks` 中的两个插入点（先按 GPU 前缀偏移取 min，再按 group chunk 粒度下取整），理解为什么 `0` 会自然退化为“直接返回 0”；三是测试设计——在 hybrid KV cache helper 上同时覆盖 sync/async scheduling，并用 `expected_stored` 断言 store 路径不受影响。若要投产，建议先补齐多级部署验证，并考虑在服务入口对字符串数字等易错输入给出更显式的告警或校验。

修复 XPU worker 忽略 device_ids 的设备放置

值得精读，尤其适合关注平台差异收敛、多后端设备绑定与 CI 依赖治理的工程师。 阅读建议： - 先看 `vllm/v1/worker/xpu_worker.py` 的 `init_device`，重点是「映射存在 / 不存在」两条分支与 `logical_device_id_to_visible_device_id()` 的引入，这是理解 vLLM 里 logical rank 与 visible ordinal 两套编号体系的好样本。 - 再看 `vllm/v1/engine/core.py` 的 `_set_visible_devices` 与 `_set_assigned_physical_gpu_ids`，理解 device_ids 是如何从 CLI 一路解析并写回 `VllmConfig` 的（这条链路也直接决定 Ray 部署下 DP rank 的设备分配）。 - 特别关注 review 中 jikunshang 对 dpctl 的质疑与作者的复现数据，这是「依赖一个非直觉的外部库副作用来修正确性」的典型案例。 可跟进的改进（若团队在 XPU + Ray 生产部署）：补一个覆盖 `assigned_physical_gpu_ids` 非 None 的单元测试（mock `torch.xpu.get_device_properties` 与 `logical_device_id_to_visible_device_id` 即可低成覆盖断言分支）；把 dpctl 依赖写入文档或环境检查；评估是否把映射发布挪到断言之后以消除全局状态污染。

Rust 前端容忍 NaN 致 rank 0 logprobs，消除服务级故障

值得精读。一是根因链路完整（NaN 比较语义 → rank 0 → frame-scoped 解码失败 → sticky health error），是典型的“边界校验把合法引擎状态误判为损坏数据”的案例，对理解 batched 协议解码的故障放大效应很有帮助；二是 BugenZhao 的 review 体现了分层设计原则：解码层保留原始语义，展示层做格式转换。阅读时重点关注 `PositionLogprobs::from_decoded_row` 的校验边界与 OpenAI 转换层 `-9999.0` 约定，并留意后续是否需要对 completions 等路径补充 NaN 序列化测试。

XPU 启用融合内核，decode 提速 55%

值得快速浏览：它展示了在 Triton 内核跨平台可用时，通过放宽平台门控即可获得大幅性能收益的轻量做法。关注点是此类一行改动通常缺少独立数值测试，团队可参考其 CI 覆盖方式决定是否补测。

修复 worker 内存快照测试的 XPU 兼容性

不值得精读——这是单一测试文件的平台适配。但有两个小决策可供 XPU 移植类测试参考：一是用 `current_platform.is_xpu()` 做运行时分支而非复制整个测试文件；二是把 NCCL 专属标签改为后端无关的 `dist_all_reduce`，保持测试语义中立。若后续维护，建议顺手确认 `xpu_worker.init_worker_distributed_environment` 与 GPU 版本是否为同一实现，消除 original 函数引用错配的隐患。

退役 Buf schema 发布，统一到 crates.io 分发

值得花 10 分钟快速阅读，重点看三点设计决策： 1. **先立后破的渠道迁移模式**：先在 #56365 建立 crates.io 发布并让 Rust 前端消费同一 crate，再在本 PR 退役 BSR，避免出现无发布渠道的空窗期。 2. **保留 buf build/lint 而非整体删除 workflow**：发布路径可以退，但 schema 质量门禁不能退，且移除 owner 限定后 fork 也能校验。 3. **文档对消费契约的明示**：README 直接写明 "no longer published" 并给出替代路径，比在 release note 里提一句更可靠。 该 PR 逻辑直白，不需要深挖源码，适合作为“发布基础设施收口”的参考案例。