vllm-project/vllm

Qwen2.5/3-VL RoPE 缓存改实例级，修复 shutdown 显存驻留

值得精读，建议按以下视角阅读： 1. 重点学习“实例方法被类级 `lru_cache` 装饰导致缓存以 `self` 为键强引用实例”这一隐蔽生命周期陷阱的定位方法（PR body 中展示了 AI 辅助引用链分析的完整路径）。 2. 关注“bounded per-instance LRUCache 替代类级缓存”的通用范式：用容量上限防止无限增长，用实例属性保证随所有者释放，是 Python 缓存生命周期管理的标准解法，可迁移到其他模型的同类问题。 3. 参考 review 中“宁删不烂”的测试取舍：低价值测试（手动装配对象导致无法捕捉真实回归）不如删除，避免虚假的安全感。 阅读顺序建议先看 `qwen3_vl.py` 的 `rot_pos_ids` 改动理解模式，再看 `qwen2_5_vl.py` 的 `get_rope_by_thw` 确认落地细节。

ROCm MLA 投机解码实现 FULL cudagraph,吞吐提升约 3.8 倍

值得精读。这是 ROCm MLA 投机解码性能的关键一跃,且 review 质量高:okorzh-amd 的拆分并行度分析、tjtanaa 对 4-D 入口的提示都直接改变了最终方案。建议重点学习四个设计决策:builder 与 impl 的职责边界(同步必须离开捕获区)、组级而非层级的 CG 支持上报、用 kernel 原生 4-D MTP 替代手动 flatten、以及在修复性能时同步修正正确性隐患(min_kv_seq_len 污染、assert 剥离、padding 行溢出)。

解耦 cuBLAS router GEMM 门禁，修复 GB10 退化路径

值得精读。改动只有 21 行，但揭示了一个重要的分层设计教训：架构专属内核的门禁不应串联到架构无关的通用加速路径上。建议关注 `_router_gemm_cublas_capable` 的独立门禁模式，以及 review 中围绕门禁粒度、bias 支持延后、测试脆弱性展开的讨论；同时建议跟进 addmm-bias 的 follow-up 并为该 tier 补一个不依赖平台谓词的单元测试。

修复 Ray PG 拆除后资源等待不足导致的 CI flaky

值得快速浏览（10 分钟内即可读完）的 CI/测试修复 PR。核心学习点：Ray placement group 拆除是异步的，GCS 状态 `REMOVED` 与 raylet 实际归还资源之间存在时间差，等待逻辑必须基于真实资源；测试应复刻生产 teardown 路径，而不是自创一套等待机制；删除死代码前应确认无其他调用方。对维护 Ray executor 与 CI 稳定性的工程师尤其有参考价值，但不需要作为架构级 PR 精读。

分配器簿记替代设备级查询，修复 sleep 测试 flaky

值得快速精读，重点学习两点：一是对 `torch.accelerator.get_memory_info()` 语义的辨析——docstring 明说 free 值是"available across all processes and applications"，任何基于该值增量的时序断言都天然脆弱；二是 co-tenant A/B 实验设计，用受控噪声量化 flake 根因，而不是猜测。若团队要写类似的 allocator 测试，可先确认生产对象是否已暴露类似 `pointer_to_data` 的可观测簿记。无需精读生产代码，因为本 PR 不含任何生产逻辑变更。

草稿与目标 Gumbel 噪声流解耦，修复概率投机采样偏差

值得精读。核心价值不在代码量，而在三个可迁移的设计：用 Philox 偏移盐廉价地切分噪声流；用分布化检验（而非逐 token 比对）验证采样统计性质；把隐式 +1 约定上移为各调用方显式声明。测试里“宽词表测不出、窄词表高样本才能分辨偏差”的敏感性分析（chi2 12 vs 1500）是统计测试设计的好范例，适合作为投机解码采样正确性回归测试的模板。

批量聊天 echo 不再回显用户 prompt

值得精读。变更虽只有一行核心条件，但包含两点学习价值：一是"两处语义相同的代码因漏改产生行为漂移"的典型修复案例，可与 serving.py 对照阅读；二是测试设计巧妙——用 __new__ 绕过初始化、以 stub async generator 驱动真实生产方法，实现秒级且免 GPU 的回归，适合在 vLLM 前端测试中推广。

为 stop_token_ids 补词表校验，杜绝越界击穿引擎

值得精读。虽然代码改动只有单文件 46 行，但 review 过程质量很高：关于 len(tokenizer) 与 model_config.get_vocab_size() 差异的论证（多模态占位 token、模型侧新增 token、gap id 越界路径）、max 方案的过度修正与回退、以及逐字段审计“谁消费索引、张量尺寸由谁决定”的方法论，对理解 vLLM 的词表边界约定和前端参数校验架构都很有借鉴价值。关注点：无自动化测试的取舍是否符合团队长期预期，以及 bad_words 字段的边界问题是否会作为后续跟进。