vllm-project/vllm · 标签视图

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

值得精读，且建议按「契约 → 消费方 → 测试」的顺序读：先看 `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 与投机解码 + 结构化输出组合使用。

xgrammar 后端放行简单 patternProperties/propertyNames，并守卫会静默错编译的组合

值得精读，尤其是 `vllm/v1/structured_output/backend_xgrammar.py` 中守卫逻辑的分支条件，和 `tests/v1/structured_output/test_utils.py` 的测试范式升级（`grammar_accepts` + 独立 fixture）。建议重点追问四件事：一是布尔形式的 `propertyNames` / `additionalProperties` 是否也应纳入守卫；二是运行环境的 xgrammar 版本下限是否已在镜像或依赖中锁定到 0.2.1；三是 `patternProperties` 与 `properties` 共存时的拒绝是否应配合更友好的错误提示（当前用户只能看到 VLLMValidationError）；四是上游 #749/#826 修复后由谁负责回访放宽守卫。若线上开启了结构化输出，建议用真实的 MCP schema 集合回归一遍，而不是只依赖单测。

hf 模式禁用 mistral-common 回退

值得精读，尤其是负责 tokenizer、结构化输出与 Mistral 模型的同学。关注三个设计决策：(1) 为什么选择“在注册层强制 `mistral_format=False`”而不是继续在 processor 层包装 tokenizer（对比被 supersede 的 #50752）；(2) 对老版本 transformers 采用“显式报错”而非“静默降级”，以及反对“让用户卸载 mistral-common”的理由（mistral 工具解析器与 hf 分词器是合法组合）；(3) 删除兼容层时同步收缩了哪些隐式契约（`CachedTokenizer` 不再覆写解码函数、语法后端不再接受 MCommon）。阅读时建议同时看 `tests/tokenizers_/test_registry.py` 的 8 组参数矩阵，理解闸门的触发条件；并在升级 transformers 到 5.15+ 后确认那个 TODO 能否删除。

修复投机解码 -1 填充 token 导致结构化输出引擎崩溃的关键安全问题。

这是一个重要的安全修复，值得精读。核心设计决策——将填充剥离逻辑从单一后端移至调度器共享路径——是正确且具有远见的，它确保了修复的全面性和持久性。评审过程（@arpera 的深入分析和测试要求）显著提升了修复的质量和覆盖范围。建议关注以下方面：`strip_speculative_padding` 的实现细节及其在调度器两个不同入口点的应用方式；新增测试如何模拟崩溃场景（通过 `_RecordingGrammar` 和 `_Matcher` mock）；以及修复如何同时解决了功能性问题（崩溃）和用户体验问题（xgrammar 的嘈杂警告）。

消除结构化输出推理结束扫描的全历史回溯，将每步开销从 O(history) 降至 O(delta)。

这是一个高质量的性能优化 PR，值得精读。它通过精心设计的接口抽象（`ParserEngineReasoningAdapter` 和 `find_reasoning_end_offset`）实现了从 O(n) 到 O(1) 的渐进式优化，同时保持了完整的向后兼容性和清晰的回退路径。评审中关于接口语义和文档的讨论有深度，展现了良好的设计审查过程。建议关注：1) 引擎派生 `reasoning_end_token_ids` 的安全性条件；2) `_find_reasoning_end_index` 中对已接受 token 与草稿的不同处理逻辑；3) 与 PR #48200 的潜在协同。

为已移除引导解码字段添加警告，修复静默忽略问题。

该 PR 值得精读。虽然代码变更很小，但它解决了一个影响用户生产环境的实际问题，其设计决策（仅警告、使用 `warning_once`、复用基类验证器）简洁且有效。推荐关注的重点是：`warning_once` 如何与 Pydantic 验证器协作以避免日志洪泛，以及维护者关于测试必要性的判断逻辑。

修复投机解码推理结束后 FSM 误报错误

建议精读此 PR，因为它展示了如何在投机解码与结构化输出场景下正确处理推理结束后的 draft token，特别是 `validate_tokens` 与 `accept_tokens` 的区分使用，具有一定的借鉴价值。

拒绝 pattern/format 与长度约束混用 schema

值得精读：这是一个 fail-closed 守卫与上游协作的典型样本，展示了如何在依赖库存在静默语义错误时，以最小代价在服务边界兜底。值得关注的设计决策：坚持宁可 400 也不静默出错；把长期修复责任明确移交上游 issue；在对其他后端（outlines、llguidance）做行为核对后再决定是否推广。若后续要扩展结构化输出支持面，abmfy 提出的 schema 位置感知遍历（只跟随 schema 承载字段、跳过 const/enum 数据）值得纳入重构。