2026年8月21日，RadixArk SGLang 团队与蚂蚁 Ling Infra 团队在 LMSYS 官方博客公布 Ling-3.0-flash 的单请求解码优化结果。在 4 块 NVIDIA Blackwell GPU、TP4、bf16、并发为 1 的固定环境中，调优后的 NEXTN 路径把平均输出吞吐从 288 tok/s 提高到 606 tok/s，平均每输出 token 时间从 3.33 毫秒降到 1.53 毫秒。
Batch 1 为什么难优化
这个结果针对只有一个请求持续解码的低并发场景。没有大批量请求分摊启动和调度开销，CPU 与 GPU 之间的同步、小内核启动延迟都会直接反映到用户等待时间，因此比高吞吐批处理更难隐藏系统开销。
性能不是靠一个内核突然翻倍
团队先移除了每步都会把主机卡住的 CPU 序列长度同步，让主机准备工作可以与 GPU 执行重叠；随后用程序化依赖启动串联 MoE、路由、KDA 和全归约路径，减少小内核之间的空档。剩余优化还包括算子融合、KDA 重调，以及把路由门和输出头的计算从 fp32 调整为 bf16。
这些改动共同缩短了关键路径。官方说明，bf16 路由门和输出头是结构调整之后最大的单项变化，带来约 10% 的提升。团队没有只看短时间峰值，而是用平均每 token 时间和接受长度评估稳定性。
DSpark 把“猜中更多 token”也纳入优化
同一篇报告还测试了 DSpark 置信度调度投机解码。在相同机器、相同命令和 1000 个请求的受控对比中，DSpark 达到平均 1120 tok/s、0.78 毫秒 TPOT，平均接受长度为 9.95。它的优势不只来自单步更快，还来自每次验证能提交更多预测 token。
但 1120 tok/s 不能直接当作所有任务的通用速度。测试使用固定 8192 token 输入、1024 token 输出、贪心解码和合成随机负载；提示内容、输出分布、上下文长度、采样设置和硬件都会影响投机 token 的接受率。官方也明确把 9.95 视为该工作负载下的结果，而不是模型固有常数。
对部署团队意味着什么
这次优化没有改变模型参数或回答质量，改变的是推理系统如何安排主机工作、GPU 内核和草稿验证。低并发延迟往往横跨调度、通信、数值精度和投机策略，单看显卡算力很难解释真实速度。
复现实验应锁定硬件、SGLang 版本、输入输出长度和解码参数，再比较 TPOT、吞吐与正确性。把实验数字直接套到不同 GPU 或业务流量上，容易得到过于乐观的容量估算。
