S09 · Draft, Then Verify — 从推测解码走向 DSpark

草稿的价值取决于接受的 token 数与验证成本，而不是草稿长度本身。

01让廉价的草稿先往前走

逐 token 调用大模型有固定开销。推测解码先让草稿机制提出多个候选，再让目标模型验证，希望一次昂贵前向接纳多个 token。贪心场景可直观比较候选与目标 argmax，随机采样则需要正确的接受与修正规则，不能把简单匹配当成通用算法。草稿不被接受时，仍要保证最终选择服从目标规则。

s09_speculative_decode.py

# Framework pseudocode for draft-verification planning.
query_budget = confidence_policy.choose_budget(request_states)
plan = scheduler.plan_verification(request_states, query_budget)
main_output = model_runner.execute_main_model(plan)
sampler_output = model_runner.execute_sample(main_output, plan)

step_state = StepState(plan, sampler_output)
# Accepted lengths control committed token positions.
# Rejected positions must not remain visible as accepted state.
ready_outputs = post_process_when_ready(step_state)
publish(ready_outputs)

# Variable draft lengths can share one scheduling round.
# Inspect mtp_varlen.hpp for upstream allocation rules.

02拒绝之后，缓存也要回到正确位置

验证会处理尚未确定能留下的候选。拒绝发生后，未接受位置不能成为后续可见的上下文，草稿状态也需要同步修正。EOS、长度上限和接受长度共同决定可提交结果。框架需要把计划 query 数、实际接受数与状态回退分开维护，不能只按草稿长度前移请求位置。

03DeepInfer 还会按置信度分配验证预算

上游将 DSpark 与 confidence-scheduled verification 配合使用。mtp_varlen.hpp 根据候选接受率估计与执行成本模型选择总 query 预算，再分配到各请求，而不是给每条请求固定相同草稿长度。这里的教学伪代码标出预算、验证、采样和落账的边界，具体选择策略应回到上游核对。

04置信度决定验证机会，验证决定接受结果

官方生产设计：官方部署文章中的 DSpark 将候选置信度用于变长验证：同一轮预算内，不同请求可以得到不同数量的验证位置。置信度是候选被接受的估计；它可以影响哪些候选值得验证，却不能直接把未验证的草稿变成正式输出。最终提交仍取决于目标模型的验证与采样规则。 开源核对：MTPVarlen.schedule为总预算选择和逐请求长度分配维护不同的接受率队列与历史快照，并明确要求后面候选的置信度不能反向决定前面候选是否被验证。预算确定后，剩余验证位置按接受率排序分配。阅读时把置信度估计、query 长度、实际接受长度分开，才能理解变长验证与状态回退如何配合。

TRY IT YOURSELF

动手想一想

给两条请求各列出三个候选置信度，并限定只能验证三个草稿位置。比较平均分配与按预期接受数分配，标出不同接受结果需要修正哪些状态。