DSpark 把投机解码的两条正交战线——"起草更快更准"和"验证更省"——合成一个
无损系统：半自回归起草 + 置信度调度验证，在 DeepSeek-V4 上以等吞吐口径把
每用户生成加速 57%–85%、外推吞吐-交互 Pareto 前沿
[dspark]。本篇把它放在两簇 peers 之间定位：一簇是
token 级投机解码 / 投机 serving（deepseek-v4、2603.03251、2605.08151、
2605.29639），另一簇是 agent / tool 级投机（2603.18897、2605.22154、
2605.13360）——后者共享"投机+验证"范式但攻击的是完全不同的瓶颈。
直接同层（token 级投机解码 · framework）
是 DSpark 在线实验的 production baseline，等吞吐加速比即相对 MTP-1 计量
[dspark]。DeepSeek-V4 本体是原生 1M 上下文的
hybrid CSA+HCA MoE，自带 MTP depth=1 的投机头
[deepseek-v4]，因此 DSpark 与其关系是"在既有 MTP
框架上换更强的 drafter + scheduler"，而非替换模型架构。V4 的异构 KV
cache / 变长压缩路由正是 DSpark 需要为 index-attention 与 compress 核
改造的底座 [dspark]。
最正面的对照。SSD 把 draft 部署到独立 GPU，在 verify 期间预计算多个
verification outcome 的 speculation cache，用 cache hit 消除 drafting
延迟 [2603.03251]。二者都攻击"drafting 占关键
路径"，但路线相反：SSD 靠额外硬件 + 时间重叠隐藏 draft，DSpark 靠
更强 drafter + 更省 verify 压缩每轮成本 [dspark]。
SPECTRE 用闭式吞吐阈值 $r^*$ 在 ordinary/parallel 两模式间按批级 rollback
比切换 [2605.08151]，DSpark 则用
$\Theta=\tau\cdot\text{SPS}(B)$ 在线选每请求验证长度
[dspark]——两者都把"是否/多长投机"归结为一个
运行时可测量的吞吐比较，是同一类"负载自适应投机调度"的两个实例。
C++ 组件（Propose/Score/Sample/Update），支持 Naive/MTP/Eagle/Prompt
Lookup [2605.29639]。它是 DSpark 这类算法可以被"插进去"
的工程容器，代表了 DSpark 生态位下游的 serving 系统形态。
远亲对照（agent / tool 级投机 · agent）——共享范式、不同层次：
"思考"时提前投机执行下一个 tool [2603.18897]。
Thompson 采样在 progressive/recovery 两策略间自适应
tool calling，把硬件投机执行（store buffer / commit point）搬到 agent
工具调用 [2605.13360]。
这三篇与 DSpark 的连接点是"投机+验证"的抽象共性，而非可直接对比的指标——
它们把 speculation 提升到 tool / plan 粒度，验证也从 rejection sampling 变成
"observation 到达后聚合 / commit"。放进来是为定位 DSpark 在整个投机谱系中的
坐标，而不是做数值 head-to-head。
vs SSD（2603.03251）— 隐藏 draft vs 消灭 draft 成本
SSD 的核心是"draft 不在关键路径上就等于免费"，但代价是强绑定：必须多一块
独立 GPU、必须有分布相近的小 draft model、且最佳效果只在 batch=1 greedy，
大 batch 下 cache hit 按 $p_{\text{hit}}^b$ 衰减
[2603.03251]。DSpark 的 delta 在于不新增硬件、
draft 与 target 同循环，并且明确把高并发当一等场景：置信调度器在目标容量
饱和时主动收缩验证预算、剪掉低置信尾 token 以保批容量
[dspark]。换言之，SSD 用"空间换时间"（idle GPU 换
draft 隐藏），DSpark 用"信息换算力"（置信度估计换验证浪费）。二者正交，
理论上可叠加（在独立 draft GPU 上跑 DSpark 的半自回归 drafter）。
vs SPECTRE（2605.08151）— 全局 vs 批级、无损 vs 有损精度
两者都做负载自适应投机调度，但决策粒度与保证不同。SPECTRE 的 $r^$ 是*批级
单一阈值**，对整批做 parallel/ordinary 二选一 [2605.08151]；
DSpark 的调度是每请求、按前缀存活概率 $a_{r,j}$ 降序贪心分配验证长度
[dspark]，粒度更细。更关键的是精度语义：SPECTRE 的
draft-side context compression（保留 10% prompt）是有损接受长度换延迟
[2605.08151]，而 DSpark 反复强调其调度严格无损
——局部 softmax 保住精确 per-token 概率、早停 / 异步两步前因果屏障保住
non-anticipating 属性 [dspark]。这是 DSpark
最独特的贡献：把"回顾式吞吐最大化搜索"与"无损"证明性地共存。
vs RTP-LLM（2605.29639）— 算法创新 vs 系统工程
RTP-LLM 的投机解码贡献是工程性的：C++ 直启消除 Python 开销带来对 vLLM
1.12× 吞吐，且实测 step size=1、~1.9 tokens/step 接受率
[2605.29639]。DSpark 恰好攻击这个"接受率天花板"：离线宏平均
接受长度超 Eagle3 26.7%–30.9%、超 DFlash 16.3%–18.4%
[dspark]。二者是互补的两层——DSpark 提供"每步接受更多 token"
的算法，RTP-LLM 提供"把算法低开销跑起来"的模块化容器。
vs deepseek-v4（MTP-1 baseline）— +60%–85% 的真实含义
DSpark 自己给出了最诚实的 delta 校准：120 TPS 下 +661%、50 TPS 下 +406% 的
巨大比值是 MTP-1 塌缩到极小 batch 的产物，应解读为"扩展了可行交互前沿"
而非代表性倍速 [dspark]。相对 V4 自带的 MTP depth=1
[deepseek-v4]，DSpark 的净增量是把静态 2-token 验证预算
替换成 4–6 token 的负载自适应预算。
vs agent 级投机（PASTE / IdleSpec / SI-Agents）— 粒度与验证语义
DSpark 的投机单位是 token / 草块，验证是 rejection sampling 的严格无损；
三篇 agent 论文的投机单位是 tool call / plan / action，验证是
"observation 到达后聚合或 commit"。PASTE 用 Pattern Tuple 解耦控制流与数据流、
符号推导参数 [2603.18897]，IdleSpec 用 Beta-Bernoulli
Thompson 采样覆盖 observation uncertainty [2605.22154]，
SI-Agents 用 safe/unsafe 分类 + commit-point 保正确性
[2605.13360]。三者都无法提供 DSpark 式的分布级无损保证——
因为 tool 执行有副作用、不可 rejection-resample，这正是 token 级与 agent 级
投机的根本分野。
1. "严格无损"的边界条件比宣称的窄。 DSpark 自证早停贪心全局最优当且仅当
$\Theta$ 单峰，隐含 $\text{SPS}$ 平滑衰减；但作者自己承认真实张量核容量呈阶梯状
jagged，此假设破裂 [dspark]。生产系统靠"异步两步前"因果屏障
去早停仍保无损，但这依赖"只评估两步前历史预测"——作者明说若在同步 / 单步内
去早停即刻破坏无损，此依赖极易被误实现 [dspark]。
可攻击点：无损性是实现条件性的，不是方法内禀的，复现者稍有偏差就得到
有偏分布（Appendix A 的 $(0.85,0.15)\ne(0.7,0.3)$ 反例）。
2. 固定草侧成本对低接受率 query 不可回收。 DSpark 承认即便调度剪掉验证
浪费，并行主干生成初始 $\gamma$ 块的算力对内在低接受率的复杂 query 不可回收
[dspark]。这恰是 SSD 的 batch-size-adaptive fallback 想
解决的问题——小 batch just-in-time、大 batch 随机 token
[2603.03251]。DSpark 缺一个对称的"草侧早退"机制
（作者仅列为未来工作），在难度混合流量下这是可被 SSD/SPECTRE 攻击的软肋。
3. 加速比口径的选择性呈现。 尽管作者罕见地自我警示 +661% 是 baseline
塌缩产物 [dspark]，但 TL;DR 与摘要仍主推 +60%–85% 的
"等吞吐"数字。SPECTRE 明确报告 PEARL 在 bs=128 退化到 0.36× AR、纯并行方案
会主动损害性能 [2605.08151]——DSpark 未在同等严苛的
高并发对照下报告其 drafter 是否也有类似退化区间，只给了"非退化"的定性结论。
4. drafter 质量迁移未验证。 离线主结果在 Qwen3-4B/8B/14B + Gemma4-12B 上
[dspark]，在线只在 DeepSeek-V4-Flash/Pro 上。序列头（Markov
/ RNN）注入的块内依赖是否随目标模型 vocab / 分布变化而稳定，跨家族迁移证据不足
——这与 SSD 被批"仅验证 Llama-3/Qwen-3 两家族"[2603.03251]
是同一类外部有效性质疑。
DSpark 处在投机解码算法层与生产 serving 系统层的接缝上，且明确站在
"高并发吞吐-交互 Pareto 前沿"这一 paradigm 上，而非传统投机解码追求的
单请求 batch=1 加速。
execution 的类比，本质是"用 idle 硬件做深度投机"，最佳生态位是延迟敏感的
batch=1 交互 [2603.03251]。DSpark 反其道，把生态位
定在高并发共享容量下——它的调度器价值恰恰在目标模型接近饱和时才最大化
显现 [dspark]。这使 DSpark 更贴近 SPECTRE/RTP-LLM 的
多租户 serving 世界，而非 SSD 的单用户低延迟世界。
检查点，并开放 DeepSpec 训练仓库（含 Eagle3/DFlash/DSpark）
[dspark]，但生产系统内部（HAI-LLM 通信优化、
异步调度器、index-attention/compress 核）未开源。对照 RTP-LLM 已完整开源
可替换引擎 [2605.29639] 与 SSD 的 MIT 开源
[2603.03251]，DSpark 属"算法与检查点开源、生产
调度闭源"的中间态——复现最难点正是那套无损调度的工程实现，而非算法本身。
PASTE/IdleSpec/SI-Agents 优化的是 agent 循环里 tool 等待的隐藏。二者在
agent serving 栈里是可叠加的正交层——DSpark 让每次 LLM 调用更快出 token，
agent 层投机让 tool 等待期不空转 [2603.18897]
[2605.22154]。DSpark 的生态位因此是"底层加速器"，为上层
agent 投机提供更低的每 token 延迟基座。
1. 难度感知的草侧早退（DSpark × SSD fallback）。 DSpark 已把验证端做成
负载自适应，但草侧仍是固定成本 [dspark]。借鉴 SSD 的
batch-size-adaptive fallback [2603.03251] 与 SPECTRE
的批级 rollback 阈值 [2605.08151]，可设计一个用置信头
早期信号预测"本 query 接受率低"→ 缩短甚至跳过起草的对称机制，让草侧成本也随
难度自适应。
2. 置信调度 × 混合模式切换（DSpark × SPECTRE 的统一）。 DSpark 的
$\Theta=\tau\cdot\text{SPS}(B)$ 与 SPECTRE 的 $r^*$ 阈值本质是同一吞吐权衡的两个
投影 [dspark][2605.08151]。一个统一
调度器可同时决定"每请求验证长度（DSpark）"与"ordinary/parallel 模式（SPECTRE）"，
在 TP 非对称 / 多租户部署下比任一单独机制更鲁棒——目前无人做这个二维联合调度。
3. 无损保证向 agent 层的迁移边界。 DSpark 证明了 token 级投机可严格无损
[dspark]，但 agent 级投机（PASTE/IdleSpec/
SI-Agents）因副作用只能靠 safe/unsafe 分类或 reference 聚合做"尽力无损"
[2605.13360][2605.22154]。未探索的是：
对只读 / 可回滚的 tool 子集，能否借用 DSpark 的 non-anticipating 因果屏障
思想，给出 agent 投机的分布级正确性保证？这是连接两簇的理论桥。
4. 半自回归 drafter 进 RTP-LLM 式模块化容器。 RTP-LLM 已把投机解码拆成
四个无状态组件但只跑到 ~1.9 tokens/step [2605.29639]。把
DSpark 的半自回归 drafter + 置信调度器实现为一组 ProposeExecutor/ScoreExecutor
插件，是把 DSpark 算法收益导入开源生产引擎的最直接路径，也能提供 SSD 未做的
continuous-batching / SLO-aware 集成验证 [2603.03251]。
5. SPS 查表的在线漂移与 jagged 容量建模。 DSpark 在初始化时 profile
$\text{SPS}(B)$ 成静态查表，其早停最优性依赖 $\text{SPS}$ 平滑
[dspark]，但真实张量核容量 jagged。未探索方向：把 SPS 建成
在线更新 + 显式阶梯感知的模型，让调度器直接在阶梯断点上做决策，而非靠异步
因果屏障绕过——这可能同时改善吞吐与无损实现的鲁棒性。