vllm-project/vllm · 标签视图

`vllm chat` 流式展示 reasoning，思考阶段不再静默

值得精读，但只需 5 分钟：重点看 `_print_chat_stream` 的状态机与 TTFT 打点两处设计决策，而不是 19 行的体量。 - 想理解 vLLM 前端如何处理 reasoning 字段差异的读者，可以关注 `getattr(delta, "reasoning", ...) or getattr(delta, "reasoning_content", ...)` 这种"双字段兼容 + 安全降级"的写法，这在对接多家 OpenAI 兼容后端时是低成本高收益的模式。 - 关注 CLI/前端体验的工程师应注意到"thinking 不进返回值"这一取舍：它保证多轮历史不被思考链污染，但也意味着需要 reasoning 回传的 interleaved thinking 场景不能靠这里兜底。 - 如果你维护下游脚本消费 `vllm chat` 输出，需要评估新增 `<think>` / `</think>` 标签对解析逻辑的冲击。

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 的部署形态下先行规避。

延迟导入 SageMaker 集成，恢复 vLLM 启动日志级别

值得精读，约 10-15 分钟。关注三点：一是「延迟导入 + try/finally 恢复」这一处理第三方 import 副作用的标准范式，它在 `attach_router`/`_attach_router` 拆分中体现得最清楚；二是 `sagemaker_standards_bootstrap` 里 bootstrap 仍在 finally 之前执行，docstring 声称的「导入后立即恢复」并未落地，建议要么把恢复提到 import 之后、要么修正注释，这是本 PR 唯一未闭环的技术点；三是测试缺口——把 PR body 的手工脚本改写成 CI 可运行的单元测试（用 stub 模块替换 `model_hosting_container_standards`，断言 handler level 不变），成本极低但能防止回归。对维护自定义日志配置、或在 SageMaker/私有云上排障「日志消失」的工程师，这是必读改动。

修复 parser 基类 reasoning 结束与回合边界的 token 扫描，GLM 声明边界 token

值得精读，尤其是 `ParserEngine.extract_content_ids` 从「反向取最后一个 marker」改为「先定位回合边界、再正向取首个结束符」这一段——它同时修正了内容丢弃与多轮误判两类 bug，是理解 vLLM declarative parser 状态机的关键切入点。建议重点关注三处设计决策：一是把多结束符语义集中到基类、模型侧仅声明 `turn_boundary_tokens`；二是用 `wait_for_reasoning`（并回退到 `initial_state`）作为「是否需要裁剪」的唯一判据，取代子类 override；三是 gaby 给出的「reasoning-end 优先、tool marker 兜底」优先级排序。落地后建议为 ling3 等 GLM 派生 parser 补充同类边界测试，并考虑增加一条真实 chat template 的端到端用例，降低基类改动带来的隐性回归风险。

MCP 会话清理回调仅注册一次，修复重复清理与关闭后调用

值得精读，尤其是 `AsyncExitStack` 回调注册时机与去重模式：将遍历全部会话的清理回调从循环内移到循环外、用布尔标志控制注册一次，是处理"多次初始化、单次清理"任务的简洁范例。配套测试的参数化矩阵（空/单/未使用/首/末/全部）与部分初始化失败用例也值得借鉴。对使用 Responses API + MCP 工具的团队，建议合入后关注 MCP 服务端日志中清理请求是否恢复正常频率。

prompt_embeds 不可解析载荷从 500 改判 400，错误理由截断到 200 字符

值得精读，尤其是要把「调用方输入错误 → HTTP 状态码」这条链路做对的工程师。关注三处设计决策：一是 `except Exception` 取代显式异常元组（作者本人主动标注为相对已批准版本的语义放宽，并用 OOM 前置 re-raise 控制半径），这是本次最值得记住的取舍；二是 `_truncated_reason()` 用「截断 + 省略计数」把反射放大压到常量级且不损失调试信息；三是测试通过 patch `torch.load` 注入已知长度理由，把断言从「torch 恰好给出长消息」解耦出来——这套写法可以直接搬到其它依赖第三方错误文本的校验代码上。阅读时可顺手确认你所在部署的 5xx 告警基线是否需要随 400 迁移而调整，并注意 `image_embeds` / `audio_embeds` 路径仍是 500 的不一致。

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 序列化测试。

Rust 前端新增 --hf-overrides 配置覆盖支持

该 PR 值得精读，尤其是 `Arc<TempPath>` 管理临时文件生命周期的设计，以及同一份 patch 在 CLI、frontend args-json、managed-engine 转发三条路径中的一致性保证。对于理解 Rust 前端如何与 Python 引擎共享配置语义也有帮助。