vllm-project/vllm · 标签视图

对齐 Gemma4 parser 与模板的 enable_thinking 默认值

值得精读。虽然只有一行核心改动，但它清晰展示了“chat template、文档、parser 三方默认值必须一致”的设计原则，以及如何通过三态 parametrize 测试锁定行为边界。对维护 parser 或 reasoning 功能的开发者有参考价值。

结构化输出已激活时跳过 reasoner 构造，省去不必要解析开销

值得精读。该 PR 展示了一个简洁的通用优化模式：通过状态前置判断避免昂贵对象构造，并用测试锁定"不变量"。虽然改动量小，但触及 structured-output 热路径，且与已有 `#43388` 回归测试保持了良好的一致性。建议关注 `should_advance` 中短路顺序与 `reasoning_ended` 状态写入的时序关系，后续若统一 `openai_gptoss` 路径时可进一步删除遗留分支。

解析引擎支持 reasoning token 计数并输出到 usage 字段

值得精读。核心看点是 parser engine 管线的 token 计数设计：按字符摊分（`_char_token_counts`）+ 按切分回算（`_pop_token_count`）+ deferred 终端计数不丢失（scanner 侧前缀 / trailing 计数），是一套可复用的流式边界记账方法。另一个值得关注的设计决策是 ParserManager 对'同引擎合并、异引擎组合'的处理，以及围绕 DelegatingParser 语义保持的 review 讨论——这是理解 vLLM parser 子系统组合思想的关键材料。

DSV4 parser thinking 默认对齐 tokenizer，修复工具调用泄漏

值得精读。8 行核心改动配合参数化测试，展示了「与 tokenizer 默认行为对齐 + 保留显式 opt-out」的回归修复模式；trace_builder 的配套改动体现了测试不应隐式依赖默认值的原则。对从事 LLM serving 解析层与 structured output 的工程师有参考价值。需关注 thinking / enable_thinking 冲突时的 OR 语义，以及 reasoning_effort 字符串比较的耦合。

修复 lfm2 工具解析器丢弃含括号换行等参数的工具调用

值得精读，重点看 vllm/tool_parsers/utils.py 中 quote-aware 扫描器与候选 first-wins 设计，以及控制符转义限定在 lfm2 调用点的共享边界决策，对任何想加固 LLM 输出解析的团队都有参考价值。合并后建议观察 lfm2 用户对流式首 token 延迟和 tuple / set 参数输出形状的反馈。

修复 Inkling 无思考块开头工具调用泄漏为 content

值得精读。这是一个观察“两遍解析不对称性”如何引发流式边界 bug 的典型修复案例：配置层一行事件、引擎层一次顺序重排，配合精确的 blast radius 审计与双形态门测试。重点阅读 `StreamingParserEngine._on_terminal` 的控制流重组，以及如何在不破坏 #51391 记账逻辑的前提下完成组合；测试设计（正反两种表形态的引擎级门测试）也值得借鉴。

修复 Inkling 无思考块时文本后接工具调用解析失败

值得精读：变更虽小，但清楚展示了共享 parser engine 中 phase gating 的设计约束，以及 maintainer 如何通过 review 把 PR 收窄到单一 bug。关注 `inkling_config()` 的六条 transition 与 `test_visible_text_then_tool_streaming` 的断言方式。后续处理 #50528 或重构 DelegatingParser 时可复用此测试模式。

修复 Inkling 工具启用时块结束 token 泄漏进 content

值得精读。核心设计决策是：语义事件（`TOOL_CALL_START` / `TOOL_CALL_END`）不能作为词法工具区域的边界依据，应改由状态转移结构推导；同时 `transition is None` 分支也要同步清理转发状态。这对任何使用共享 parser engine 新增 grammar 的开发者都有直接借鉴意义，也建议后续为嵌套/多 wrapper 工具区域补充更细粒度的测试。