速评：调度器才是并行解码里拖后腿最狠的那个，没人看它。
这篇8月12号挂在arXiv上的dLLM解码方法，cs.CL，编号2608.11742，十个人署名，没喊任何“颠覆”口号——但干的事比同一天大部分通稿都有嚼头。它抓住的问题很简单：现有并行解码调度器，要等一个位置满足逐位置标准才提交。标准不达标就不放行，位置之间没有任何信息交换。一个位置卡住，后面一片跟着等。这不叫稳，这叫拖延症。
他们管那个发现叫“涟漪效应”，名字起得有点软，但内容很硬：提前提交一个中熵的枢轴位置，其余掩码位置的不确定性会显著下降。注意，是“中熵”——不是最有把握的，也不是最没把握的，取中间。这个选择很反直觉。大多数人抢着先交最稳的那个位置，但这篇论证的是，你交一个“还没完全想好但已经有点谱”的位置，它带来的信息量刚好能解开周围一片位置。
最稳的位置熵太低，交出去也挤不出多少信息喂给下游；最没把握的位置熵太高，交出去等于把错误扩散出去。中熵的意思是：这个位置已经在一半的方向上倾向明显了，但还没定死。你把它定下来，这个“定”的动作本身就是一个信息脉冲，顺着依赖关系传出去，后面一片掩码位置跟着降不确定性。降了不确定性，就有资格并行解锁更多token——你的并行度不是调度器给的，是“提前定下关键位置”这个动作挣来的。
RPS这套方法，不用训练，纯推理阶段干活的。选中熵位置当候选枢轴，再用前瞻评估判断哪个token分配能带来最大下游收益。这思路其实不新鲜，前一阵子卷speculative decoding的时候，大家都在赌“先交一个猜测，再让验证器兜底”。但RPS不需要草稿模型，直接利用去噪迭代本身的不确定性分布来挑位置，把“选哪个位置先提交”当成一个搜索问题，而不是碰运气。
说到这个有点尴尬。上个月我还写过一条评论，大意说解码效率的下一步在验证器而不在草稿模型。这篇RPS等于把答案又往调度策略那边推了一步——我说对了一半，验证器确实在卷，但调度器提前交卷了。
重点看wall-clock——4到10倍。这年头benchmark可以刷，FLOPs可以优化，但墙钟时间是用户亲自拿秒表测的，不好糊弄。比之前的前瞻基线准确率最高高出5.49个百分点，吞吐量多数设置下也更高。数据给的是范围，不是极限值，这就比“最高提升多少多少”的措辞诚实。再说配KV缓存，直接把提速推到18倍。为什么快？因为提前提交的那个位置一旦定了，KV缓存里就有东西可摸，不用回头重新算，全串起来了。
当然，arXiv论文首先是论文。4-10倍是在他们选定的3种dLLM和4个推理/代码生成基准上测的，是不是所有架构都吃这一套，得等复现。但RPS不需要训练这一点，把复现门槛降得很低——不用重新训模型，拿着现成的扩散大模型就能跑。这个可复现性比倍数本身更值钱，因为这个圈子里能刷出漂亮数字但别人复现不了的论文太多了，这篇至少把验证成本打了下来。
通稿里的形容词可以当情绪看，但墙钟时间是可以拿手机测的。调度器这层皮，还有得挤。