今日概览
- 推理早停换信号:从answer-level换到reasoning convergence — PUMA论证trial answer稳定不代表推理过程收敛,换成轻量Redundancy Detector监测语义停滞后,5个LRM平均省下26.2%的token,准确率不掉。
- 视频LLM的延迟瓶颈已从LLM端移到encoder端,FastV/VisionThink这一系post-hoc token压缩把LLM端负担压薄之后,per-frame encoder的耗时占比顶上来——沿用2024年的latency profile选今天的方案账可能算错。
- 估scaling law的算力账有机会下移到中小团队:这篇ICML工作把Successive Halving和surrogate model拼起来对差配置实时剪枝,相对均匀分配预算在真实和合成数据集上分别提升2.84%和5.47%,比起全网格扫最多省98.7%算力(但和你现有早停策略比能省多少,摘要里没给)。
重点关注
01 推理加速 答案先稳一阵再被推翻,早停信号该换地方看
reasoning model早停的现有方案大多盯着答案侧——confidence阈值,或几次trial answer连续一致就停。PUMA作者论证这套信号反映的只是「候选答案准备好了」,不是「推理过程真的收敛了」:trial answer完全可能在chain中段稳定一阵,再被后续的self-correction推翻,按answer-level判据提前停机会直接掉准确率,留下来的reasoning chain在语义上也不完整。他们换了个判据——一个轻量的Redundancy Detector监测后续step是否还在产生新进展,如果连续几步只是在重述既有结论就算trace收敛了,再让answer-level verification兜底确认能安全停。在5个LRM、5个reasoning benchmark上平均省下26.2%的token,准确率和保留下来的CoT质量都没掉,code generation和VLM任务上也复现了同样趋势。但Redundancy Detector本身要算开销,单条trace未必看得出ROI——真正的价值在batched serving里每个request长尾段累积出来的成本,部署前最好profile一下detector开销和省下token的比例。
原文:Stop When Reasoning Converges: Semantic-Preserving Early Exit for Reasoning Models
02 多模态 压了两年visual token,结果发现真凶不是LLM
压visual token压到一定程度之后,下一个瓶颈不是LLM——而是前面那个一直没人盯着的vision encoder。LiteFrame真正有价值的不是方法本身(用蒸馏让小encoder学会大模型的时空压缩表示),而是这个反转观察:过去两年FastV、VisionThink这些post-hoc token reduction路线默认「LLM推理是瓶颈」;而token一旦压得足够薄,per-frame encoder的耗时占比就顶上来了。换句话说,2026年视频LLM的优化重心已经从LLM端转移到encoder端。沿用2024年的latency profile选今天的方案,账很可能算错。
原文:LiteFrame: Efficient Vision Encoders Unlock Frame Scaling in Video LLMs
03 训练优化 估scaling law的算力账,能压到中小团队做得起吗
决定训多大模型、用什么架构之前,按(参数×数据×超参)grid训一组小模型估scaling law是标准操作,但把grid全扫一遍的算力账中小团队基本付不起——很多模型选型决策最后是凭直觉做的。这篇ICML工作把Successive Halving和surrogate model拼起来,训练过程中实时预测每个配置的学习曲线,把走势差的配置尽早砍掉,本质是把「按网格全扫」换成「实时问哪个配置最值得继续训」。论文报告相比均匀分配预算,真实和合成数据集上分别有2.84%和5.47%的相对提升,估到同等精度的scaling law最多能省98.7%算力。但98.7%是和「全部跑满」对比的上限值,多数团队本来也不会真把grid扫完——更现实的对照是和你现在的早停策略比能省多少,摘要里没给这组对比,需要看全文确认。即使打个折扣,把「先估scaling law再做决策」从大厂专属往下挪一档,做模型选型的小团队值得跟踪。
原文:Active Budget Allocation for Efficient Scaling Law Estimation via Surrogate-Guided Pruning

也值得关注
今日观察
PUMA早停和LiteFrame这两篇efficiency工作共享一个不太显眼的方法学特征——核心贡献不在「让X跑得更快」的工程改进,而在指认「过去优化的X不是该优化的对象」。PUMA把LRM早停的判据从answer-level signal换到reasoning convergence;LiteFrame把视频LLM的优化目标从LLM端visual token压缩换到per-frame encoder。合起来给从业者一个具体动作:在投efficiency engineering之前,重新profile一遍当前latency分布到底落在哪个组件——一年前的default assumption在今天的token压缩/chain长度水平下可能已经过期。具体怎么做:reasoning model团队量一下现有早停策略砍掉的token里到底有多少其实还会改写最终答案;视频LLM团队量一下pipeline里vision encoder和LLM forward pass各自占多少wall time,再决定下一轮efficiency投入投在哪一端。