SGLang 团队和蚂蚁 Ling Infra 团队在 8 月 21 日公开了一份联合调优记录：在 4 张 Blackwell 显卡上跑 Ling-3.0-flash，把并发为 1 时的单 token 输出耗时（TPOT）从 3.33 毫秒降到 1.53 毫秒，降幅 54%，吞吐从每秒 288 个 token 提到 606 个。换上他们训练的 DSpark 草稿模型之后，平均 TPOT 进一步压到 0.78 毫秒，吞吐到每秒 1120 个 token，平均一次能接受 9.95 个草稿 token。
Ling-3.0-flash 是一个混合线性注意力的 MoE 模型，42 层里有 35 层用 KDA 线性注意力、7 层用 MLA 全注意力，512 个路由专家，隐藏层宽度 2560，词表约 15.7 万，bf16 下每张卡要装约 63 GB 权重。测试用张量并行切成 4 份，精度 bf16。
闲着的其实是显卡
这次优化的对象是 batch size 等于 1 的场景。绝大多数推理优化的公开成果都在冲高并发下的总吞吐，因为那是云厂商的账单结构。另一类负载的体感更直接，就是并发为 1：本地跑模型、代码补全、Agent 串行执行一条长链——同一时刻只有一个请求在跑，用户盯着屏幕等字往外蹦。
并发一低，显卡就闲下来了。每一步解码的计算量小到微不足道，GPU 干完活就在等下一批指令，而发指令的是 CPU。只要主机侧有一处需要读回显存里的数值再决定下一步做什么，整条流水线就得停下来等这次同步完成。
“at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble.” 并发为 1 时，先去找主机路径上对显存数值的阻塞读取——每一处都会把原本藏在后台的主机开销变成一个 GPU 空泡。
逐个拆掉等待
第一类是主机空转。做法是把每一步的 GPU 同步点去掉：在 KDA 注意力后端里声明无须把序列长度取回 CPU，让相关索引全程留在显存里。这样第 k+1 步的指令可以在还不知道第 k 步接受了几个草稿 token 的情况下就先发出去，主机不再排队等结果。
第二类是缩短 GPU 关键路径上的活。用程序化依赖启动（PDL）把不依赖上一个核函数产出的权重加载提前发出去；把路由和 MoE 从两次核函数启动合并成一次，对 512 个专家这种规模，光是启动开销就很可观；把 router gate 和 lm_head 的计算精度从 fp32 换成 bf16，单这一项就拿到约 10% 的提升。KDA 在投机解码下的循环状态改成分阶段更新、验证通过之后再提交。
这些改动都进了 SGLang：元数据粘合图捕获、融合后的 KDA 验证核、由主机直接下发的 FlashInfer 计划表（省掉阻塞式的显存回读），以及把草稿、验证、扩展三步合并的调度顺序。
换算成人能感知的时间
拿一个 5000 token 的长回答算笔粗账。3.33 毫秒一个 token，写完要 16.6 秒；1.53 毫秒是 7.7 秒；0.78 毫秒是 3.9 秒。同一台机器、同一个模型、同一个人在等，从”泡杯茶回来”变成”话没说完就写完了”。这个差别不靠换显卡，靠的是把主机侧的等待挖干净。
DSpark 那一档的关键数字是平均接受长度 9.95。投机解码的逻辑是让小模型先猜一串，大模型一次性验证，猜中多少就白赚多少步。接受长度接近 10，意味着大模型每验证一次能顶将近十次常规解码。这个数字跟草稿模型的训练方式直接相关——DSpark 的草稿模型是照着 Ling-3.0-flash 后训练之后的输出分布蒸馏的，损失函数里还专门加了对接受长度的优化项，猜得准这件事是训出来的，跟碰运气无关。
一次上游的合作
这份记录背后是三方署名：SGLang 侧的 RadixArk、蚂蚁的 Ling Infra 团队，以及蚂蚁的 inclusionAI。模型权重和复现命令一起放了出来，包括 DSpark 变体。
国产开源模型这两年在榜单上的位置已经不稀奇，稀奇的是推理栈这一层的话语权——这次的优化没有停在等上游框架适配，是自己带着硬件账单和真实负载去改上游代码，改完合回去。对下游用同一套框架部署的人来说，这批开关打开就能用，跟模型是谁家的关系不大。
参考来源：SGLang 官方技术博客、CocoLoop、蚂蚁 inclusionAI 公开模型卡；以博客给出的复现命令与基准结果核验 TPOT、吞吐、接受长度三项口径均为并发 1、4 卡张量并行、bf16 条件下测得。