推测解码原本用“多算一点”换“少走几步”，并发升高后却可能因为验证太多候选token而反向拖慢服务。SGLang在7月25日发布0.5.16版，汇集574个PR和169名贡献者，把验证长度从固定值改成按请求置信度动态分配，同时重做混合注意力缓存与线性模型状态管理。这次更新的核心不是又多支持几个模型，而是让推理系统开始逐请求计算“这一步值得验证多少”。

三点看懂：速度、显存与升级风险同时变化

DSpark先判断“可能接受多少”，再决定算多少

传统推测解码让小型草稿模型先生成若干候选，再由目标模型一次验证。候选越多，减少串行步骤的机会越大；但在高并发下，目标模型每一步要处理“批量乘验证长度”的token，固定窗口很容易把不会被接受的尾部也算完。DSpark增加半自回归块草稿器、置信度头与顺序温度校准，把候选存活概率交给在线调度器。

SGLang的工程关键是“紧凑验证”：不同请求可拥有不同窗口，候选被前向打包进不等长缓冲区，再按总token数匹配CUDA图，而不是把所有请求补齐到同一宽度。团队在DeepSeek-V4-Pro、8路张量并行和B300、批量为1的条件下，记录到约5枚平均接受长度与383.7 token/秒。这个数字属于单一硬件和配置，不能外推为任意模型的普遍提速。

混合流量更能说明调度逻辑：官方示例中，数学、困难问答和诗歌请求的平均验证窗口分别为5.24、3.78和2.91，窗口对较难接受的内容自动收缩。当前成本模型仍是第一版，团队也明确表示上下文长度对单步成本的影响尚未被充分建模，实际运行点还有优化空间。

线性注意力模型的缓存账本也被重新整理

0.5.16把UnifiedRadixTree设为滑动窗口注意力、Mamba和DSA模型的默认缓存结构，目标是让前缀复用、状态同步和命中恢复不再各走一套路径。对GLM-5.2，DSA缓存层在预填充上下文并行下按层分片；官方测试以8192 token、78层和并行度4为条件，将每个rank的KV占用从0.77GB降至0.20GB，约减少74%。

另一项ReplaySSM环形推测验证取消每次草稿都保存完整状态快照。在Qwen3.5-35B-A3B、单路张量并行测试中，临时状态显存由11.5GB降到1.8GB，缩小6.4倍，团队称准确率与吞吐保持一致。两组数据都依赖指定模型、序列与并行设置，更适合作为容量设计线索，而不是采购或扩容承诺。

模型支持同步扩展到Inkling、LongCat 2.0 FP8、Mellum v2、Pi0.5与LongLive 2.0；Inkling覆盖Blackwell、H200与AMD MI350X/MI355X。MiniMax-M3虽然完成代码接入，但官方仍把端到端使用标记为开发镜像阶段，说明“合入框架”与“生产可用”之间仍有距离。

生产升级要先复现真实流量，再处理移除项

本版移除QServe W4A8和FBGEMM FP8实验路径，NVFP4矩阵乘改为依赖FlashInfer；水位调度和预填充重试参数也直接改名，没有兼容别名。扩散后训练的rollout端点从JSON和Base64张量切换为MsgPack原始字节，训练端与服务端必须同步升级。忽略这些变化，旧启动脚本会直接报错，接口消费者也可能无法解析响应。

已知问题同样具体：DeepSeek-V4-Flash FP4在数据并行注意力与可中断预填充CUDA图组合下，温度为0的相同请求仍可能产生不同结果；Mamba重叠调度的序列长度修复被回退，GB300自动化测试还因运行资源临时关闭。需要确定性输出、线性注意力或新硬件的团队，应把这些组合列为升级前必测项。

ATYUN编辑判断：SGLang 0.5.16释放的信号，是推理优化正从“给整批请求套一个更快算法”走向“为每个请求动态核算计算预算”。574个PR体现的是开源工程规模，不等于开箱即得的业务收益。真正值得追踪的，是DSpark在混合并发与长上下文中的稳定收益、统一缓存树对状态恢复的影响，以及新增复杂度能否在可观测性和确定性上得到偿还。