606 tok/s。LMSYS官方博客把蚂蚁Ling Infra团队和RadixArk SGLang团队的结果挂出来的时候，做推理优化的人应该都会停下手头的事：Ling-3.0-flash混合线性注意力MoE模型的单请求解码速度，从288 tok/s被拉到606 tok/s，平均TPOT从3.33毫秒压到1.53毫秒。单请求、batch=1、没有并发可以借用——这种场景每快一步都是硬功夫。而他们给出的方法论也很干脆：先把主机从GPU进度上解绑，再优化GPU关键路径。
单请求延迟，算力堆不出来的坎
并发玩家帮不上忙，单请求只能硬扛
多请求高吞吐的优化思路，放到单请求场景里几乎全部失效。batch越大，GPU的矩阵单元越有活干；可到了单请求解码，每一步都在等前一个token的结果，batch=1，算力天然喂不饱。Ling-3.0-flash本身的混合线性注意力MoE结构，在这种情况下显得很有性格：线性注意力让每步的状态读取变成紧凑的缓存访问，MoE又把每步激活的参数压得很小——这本来是优势，却也带来了另一个问题：单步计算太轻，周围那些传输、调度、同步的开销反而被衬得刺眼。
单请求解码更像一场接力赛，每一棒都只有一个人跑，再快的选手也得等上一棒递过来。优化能做的，就是把交接时间压到最短。
主机和GPU之间的同步，是块隐形短板
这里最值得琢磨的词是：进度同步。GPU每走一步，主机CPU都要知道它走到哪了，再准备下一步的输入。这个交互在批量推理时可以被下游请求填上，但单请求下没有任何东西可以填，等待实打实变成了GPU气泡。更麻烦的是，Blackwell这类新一代加速器的算力往前蹿了一大截，主机一侧还在按老节奏逐token汇报，GPU的启动节奏被CPU拽着走。
如果算力本身不在瓶颈上，那主机的同步等待就是最该先拆掉的那堵墙。想明白这一点，606里第一刀落在哪里就不好奇了。
3.33毫秒里，有多少时间真花在了计算上
从3.33ms到1.53ms，差值接近1.8ms，占总耗时的一半以上。这个量级的收益，不可能来自任何单算子优化，只能来自结构性浪费的清除。优化前的3.33毫秒里，纯粹的矩阵乘法和注意力计算可能连一半都占不到，剩下的时间被token生成调度、显存搬运、kernel启动和CPU-GPU握手分摊掉。推理优化做久了会产生一个直觉：当每步延迟明显偏大时，最先该动的是等待，而不是计算。
先松绑，再提速：606背后的两步棋
把主机摘出来，GPU才谈得上关键路径
他们的思路分两层。第一层是把主机从GPU的进度同步里解绑出来，让GPU执行过程不再因为CPU的配合而卡顿。第二层才回到GPU自己的关键路径上做文章。顺序不能反——主机还没解放时，GPU每一步都得停下来迁就CPU，这时候不管做算子融合还是解码加速，收益都会被气泡吃掉大半。
Spec Decode：让每一步提前彩排
关键路径上的主要加速手段是speculative decoding。小模型先草拟一串token，Ling-3.0-flash再一次性验证。对混合线性注意力来说，draft模型的缓存开销低，验证多个token时又能共享MoE中激活的专家参数，单位时间能走的路一下拉开了差距。这相当于把原来的串行生成改成了一条小型流水线：draft负责批量生产候选，target负责把关验收。RadixArk SGLang团队在这个环节里提供的不是某一两个算子，而是缓存复用与调度上的配合：radix树结构让相同前缀不再重复计算，tree attention和多token并行验证让每一步都在原地扩展开来。
606 tok/s不代表每一步的数学变简单了，而是每一步里塞进了更多并行验证的工作。
606之后，重新设计的起点在哪里
当主机不再是瓶颈、GPU关键路径被压到足够短，继续往下挖的空间出现在设计起点：模型结构、运行时调度、缓存层必须放在同一张图纸上。Ling-3.0-flash线性注意力带来的紧凑状态缓存，是SGLang能在缓存上做出收益的前提；换一个模型，同一个框架未必能复现同样的结果。系统优化最诚实的一面就在于此：瓶颈永远在路上。
这套打法的价值边界在哪里
模型无关的止损，模型相关的增益
收益要分两块来看。解除主机的同步等待这件事，和模型结构无关——无论什么模型，单请求解码都会经历同样的CPU-GPU互相等待；但spec decode能放大多少速度，则和模型高度相关。混合线性注意力的状态缓存、MoE的稀疏激活，都让draft和验证变得更便宜。一句话：止损是通用的，增益看模型配不配合。
SGLang这一仗，打的是系统工程
RadixArk SGLang团队在这里的角色，不该被简化成“推理框架提供了支持”。缓存前缀复用、异步调度、多token验证的批量组织，这些工作分散在运行时和调度层，缺了它们，模型侧再合适也跑不出606这个数字。低延迟优化的主战场正在从单一算子下沉到整个推理栈的协同设计。
这也是这篇博客值得被反复读的原因：它展示的是一种跨团队的系统工程能力，而非某个天才想法的一击制胜。
模型竞争见顶，工程竞争正热
LMSYS来发一篇推理工程的结果，这件事本身就说明风向在变。基础模型能力逐渐拉不开差距，单请求延迟反而成了下一代应用——实时语音、Agent动作链路、交互式编程——最直接的体验瓶颈。Ling-3.0-flash这次提速，把模型团队、框架团队、硬件特性三者捏合在一起，做了一次可复用的示范。接下来，谁能在几百个token里再抢出几毫秒，谁就会在下一轮应用竞赛里占住位置。
