有些工作负载像闪电战，有些则像持久的围城。大模型推理，尤其是面向海量并发请求的在线服务，显然属于后者。在这场围城中，算力是有限的城墙，延迟是不断飞来的箭矢。传统的自回归解码，一个token一个token地往外蹦，在压力下显得笨重而昂贵。推测解码，这个被寄予厚望的“工兵”，试图用一种“先起草、后核准”的策略来打开缺口。但想法虽好，落地时往往遇到新麻烦：草稿打不准怎么办？验证过程本身又成了新的算力黑洞？最近，LMSYS团队（Chatbot Arena背后的那群人）把DSpark算法塞进了SGLang这个开源推理引擎里，他们要解决的，恰恰就是这最后一公里的工程难题。
高并发的痛点：验证成本吃掉了红利
推测解码的基本逻辑不难理解：用一个轻量、快速的小模型（或特殊草稿器）先一口气猜出好几个token，然后让大模型一次性把这些候选token并行验证一遍，看哪些猜对了。猜对越多，大模型一次性“吞”下的token就越多，吞吐量自然提升。这很像考试时的“排除法”，快速写下几个答案，再集中精力去检查。理论上，速度提升显著。
然而，现实很骨感。在服务器挤满请求的高峰期，这套“考试策略”会失灵。问题出在验证环节。传统推测解码通常采用固定长度的验证：无论草稿质量如何，大模型都必须花费固定的计算资源去验证一整条长长的候选序列。当草稿质量差、大部分猜测都是错的时候，这些验证计算就全打了水漂，变成了纯粹的、昂贵的浪费。在高负载下，这种无效验证会迅速堆积，反而可能让系统比老实解码更慢。推测解码带来的红利，被验证环节的低效悄悄吞掉了。
DSpark的核心：让验证变得聪明而节俭
DSpark算法的出发点很明确：别再做傻傻的固定长度验证了。它引入了几个关键机制，让整个推测和验证流程变得可伸缩、自适应。
块生成与动态验证
DSpark首先将生成单位从单个token扩展到了“块”。它的草稿器是半自回归的，能够一次并行生成一整组（一个块）的候选token。这本身比逐个token生成草稿要高效。更重要的飞跃在于验证端。DSpark为每个请求配备了一个置信度头和一套顺序温度缩放机制。这相当于给每个草稿token打上一个“可信度分数”。系统会根据这些分数和当前的服务器负载状态，动态地计算出一个“验证长度”——只去验证那些置信度较高的、最有可能猜对的前N个token。草稿质量高，就多验证几个；质量差，就果断提前止损，只验证开头几个。这样，计算资源被精准地投放在了最可能产出的地方，无效验证成本被大幅裁剪。
置信度和温度：一把精细的尺子
如何衡量“可信度”？DSpark的置信度头是专门为这个任务训练的小型神经网络模块，它能更准确地预测某个token被接受的概率。而顺序温度缩放则是一个更巧妙的调节阀。它在生成草稿的每一步，都根据当前生成的不确定性，微调采样温度。在高度确定的位置，保持低温，输出自信的结果；在模糊或困难的位置，提高温度，鼓励探索更多可能性。这确保了生成的草稿块本身质量就更高，为后续的动态验证打下了好基础。这把尺子，从生成的源头就开始丈量并优化每一步的决策。
SGLang的工程落地：把理论塞进发动机舱
算法论文是蓝图，而SGLang团队干的是把它改装成能飞上天的真飞机。他们面临的工程挑战一点也不比算法设计小。SGLang是一个追求极致推理效率的引擎，支持从密集模型（如Qwen3）到稀疏MoE模型（如DeepSeek-V4）的各种架构。DSpark带来的动态验证长度，意味着每个请求在每次迭代中需要处理的数据量和计算图都是不规则的，这对底层CUDA核函数的调度和内存管理是巨大的挑战。
为不规则计算铺路：图优化与模式选择
为了让CUDA硬件能高效处理这种“长短不一”的验证批次，SGLang采用了全CUDA图处理。CUDA图能将一系列GPU操作预先录制并优化，然后重放，极大减少CPU-GPU同步开销。即使每个请求的验证长度不同，SGLang也能通过ragged（不规则）CUDA图技术，将这些不规则的计算任务打包成高效的执行流，按字节级回收那些被“裁剪”掉的计算资源，绝不浪费。
在验证策略上，SGLang为用户提供了三种实用的“档位”选择： static模式，即传统的全长验证，适合追求最高接受率、不在乎算力开销的场景。 compact模式，这是DSpark动态验证的完整实现，是生产环境的首选，能自动平衡速度和验证成本。 cap-accept模式，则设定了一个最大接受上限，专门用于测量和评估模型在特定条件下的最大接受能力，是调试和分析的利器。 这种灵活性让开发者可以根据自己的业务需求和资源预算，选择最合适的“驾驶模式”。
系统级优化：调度与内核的融合
光有智能的算法和灵活的验证模式还不够，SGLang在系统流水线上也做了大量优化。他们实现了零开销调度，确保动态验证带来的额外调度决策不会成为新的瓶颈。同时，引入了一个基于离线成本表的在线调度器，它像一个经验丰富的交通指挥员，能够根据请求的特征（如预期草稿长度、模型类型）和实时服务器负载，预先估算并分配资源，让请求流更加平稳。 在最底层，他们甚至编写了融合的Triton核。Triton是一种用于编写高效GPU内核的Python DSL。通过将多个小操作融合成一个大的、优化的内核，减少了数据在显存与计算单元之间来回搬运的次数，进一步压榨硬件性能。这一系列从调度到内核的优化，共同确保了DSpark算法潜力的完全释放。
性能兑现：实测下的吞吐延迟权衡
一切优化，最终都要在硬碰硬的性能测试中见真章。在LMSYS使用最新DeepSeek-V4-Flash模型于H200 GPU上的测试中，SGLang集成了DSpark后表现出色。在整个并发请求量扫描的范围内，相比传统的多token预测（MTP）方法和不使用任何推测解码的基线方案，DSpark都实现了更优越的吞吐量-延迟权衡曲线。这意味着，在达到相同吞吐量时，它的延迟更低；或者在相同延迟要求下，它能承受更高的并发请求。特别是在单请求场景下，实现了383 tokens/s的速度，这对于对话式应用等延迟敏感场景，是一个即时可用的、可观的性能增益。 这版推测解码的工程落地，比论文本身更有看头。它展示了在追求AI模型能力极限的同时，如何通过精巧的算法和扎实的系统工程，将理论上的效率优势，转化为部署者手中实实在在、稳定可靠的吞吐提升和成本下降。当验证不再盲目，算力便能在围城中找到最锋利的突破口。
