Prhub

#34478 [Spec] Support output logprobs with DSpark

原始 PR 作者 zhisbug 合并时间 2026-08-18 05:23 文件变更 0 提交数 3 评论 2 代码增减 +0 / -0

speculative-decoding deepseek feature test run-ci

执行摘要

DSpark 路径启用 output logprobs，复用共享投机处理器

PR 正文的三点目标明确了动机：允许 output-logprob 请求与 DSpark 共存、用共享 speculative v2 处理器计算 accepted-token logprobs、并重新开启既有的 DSpark grammar/logprob 集成覆盖。交易路径的模型会产出并丢弃多余 token，若 accepted-token 的 logprob 不能正确投影回最终序列，依赖 return_logprob 的客户端将无法在 DSpark 上使用。该 PR 没有关联 Issue。

若您的业务在 DeepSeek-V4 DSpark 上依赖 logprobs 输出，本 PR 值得精读；值得关注的设计决策是"复用共享投机 v2 处理器而非复制实现"，这与仓库内 specv2 统一化的方向一致。由于本次分析未获得 diff，建议以完整 patch 复核两点：accepted-token 的 logprob 到底取自 draft 分布还是 target 分布，以及放开限制后是否影响 DSpark 与其他投机后端共存的调度分支。

讨论亮点

该 PR 没有任何代码 review 评论（review_comments_count 为 0），也没有技术讨论线程。两条 Issue 评论均为维护者发起的 /tag-and-rerun-ci 命令，属于 CI 重跑操作。唯一值得记录的协作信号是提交历史中 merrymercy 补了一次 Fix DSpark worker import ordering 提交，说明合入前曾有一轮 lint/导入顺序修整。

实现拆解

根据提交消息与仓库结构的推断（本次未提取到 diff），实现可拆解为以下几步：

  1. 放开 DSpark 对 output-logprob 请求的限制：在 DSpark 的投机 worker（推断为 python/sglang/srt/speculative/dspark_worker.py）中，移除对 return_logprob 请求的拒绝逻辑；该处是 DSpark 与调度器交互的入口，放行后请求才能进入投机流水线。
  2. 复用投机 v2 处理器计算 accepted-token logprobs：将 DSpark 已接受 token 的 logprob 计算接到共享的 speculative v2 处理器上，而不是在 DSpark 内复制一份逻辑。这样 DSpark 与 EAGLE 等其他 specv2 后端共用同一套 logprob 语义与返回格式，避免两套实现漂移。
  3. 修复 import 顺序：merrymercy 的提交 Fix DSpark worker import ordering 调整了 DSpark worker 的导入顺序，以满足 Ruff 检查并通过 CI。
  4. 恢复集成覆盖：重新启用既有的 DSpark grammar/logprob 集成测试，让 DSpark 路径的语法约束和 logprob 行为进入 CI 回归视野；CI 记录显示 Extra test 一次运行失败，推测与本次重新开启的模型级集成覆盖相关。
  5. 测试配套：PR 正文提到执行了 Python 语法编译、Ruff 导入/错误检查，并启用了 model-backed DSpark 集成覆盖；具体测试文件路径未在提取上下文中出现。
文件 模块 状态 重要度
python/sglang/srt/speculative/dspark_worker.py 投机解码 modified 6.0
python/sglang/srt/models/deepseek_v4_dspark.py 模型层 modified 5.0
test/（推断的 DSpark 集成测试，具体路径未提取） 集成测试 modified 3.0

分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。

评论区精华

没有提炼出高价值讨论线程

当前评论区没有形成足够清晰的争议点或结论，后续有更多讨论时会体现在这里。

风险与影响

风险点主要集中在三处，且由于本次没有 diff，部分无法直接核验：

  • logprobs 正确性回归：投机解码路径的 logprobs 必须与最终返回 token 序列严格对齐；accepted-token 的 logprob 应来自 draft 分布还是 target 分布需要在接入投机 v2 处理器时保持一致。若 DSpark 的 accepted 语义与处理器假设不一致，可能出现 token 与 logprob 错位，静默返回错误数据。
  • CI 稳定性：Extra test 在最新一次运行中失败（Run #32060676187），而基础测试通过；重新启用的 model-backed DSpark 集成覆盖可能受环境或模型状态影响，若失败与本次变更有关，需要后续跟进。
  • 兼容性与性能：影响面限定在 DSpark/DSV4 投机路径，普通 prefill/decode 与其它后端不受影响；logprobs 计算带来少量显存/带宽开销，但复用处理器不会新增大的数据搬运。

对用户：使用 DeepSeek-V4 DSpark 的客户端现在可以请求 return_logprob/logprobs，解锁基于 token 级 logprob 的评估、搜索与可视化工具；对非 DSpark 用户的 API 行为无变化。对系统：DSpark 与其它 specv2 后端在 logprobs 语义上趋于统一，后续维护只需维护投机 v2 处理器一处逻辑。对团队：重新开启的集成覆盖让 DSpark 的语法/logprob 回归进入 CI 视野，降低后续劣化风险。整体影响面狭窄，属于 DSpark 功能线内部的收尾性补齐。

投机路径 logprobs 对齐风险 复用 specv2 处理器 CI 集成覆盖重新启用 diff 证据缺失

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。

完整报告

Markdown PDF

参与讨论