今日概览
- 纯微调就能让LLM一步吐多个token, MARS不改架构不加参数,Qwen2.5-7B实测加速1.71倍,部署迁移成本几乎为零
- 图像自编码器压缩崩了别急着加channel——TC-AE发现真正塌缩的是token利用率,从token空间入手反而更简单有效
- World model的空间一致性和实时性终于不用二选一。 INSPATIO-WORLD把两件事拆成独立模块,单视频输入即可生成可实时导航的4D场景
- RL对齐扩散模型的rollout太贵? 探索阶段用FP4、训练阶段用BF16,收敛速度最高提升4.64倍,质量不降
重点关注
01 推理加速 零改动、零额外参数,微调一下LLM就学会了多token生成
多token预测这条路不新鲜,但之前的方案都有代价——投机解码需要单独维护一个草稿模型,Medusa要给模型加额外的预测头。MARS的做法干净得多:不改架构、不加参数、不引入任何新组件,只在现有指令数据上继续微调,同一个模型就学会了一步预测多个token。而且完全向后兼容:逐token调用时6个benchmark上持平或更优,切到多token模式吞吐提升1.5-1.7倍,在Qwen2.5-7B上实测墙钟加速达1.71倍。更妙的是它自带运行时调速能力——通过置信度阈值控制每步接受几个token,请求高峰期自动提速,不用换模型不用重启服务。这意味着推理加速第一次变成了一个纯微调问题:拿到现有模型,跑一轮训练,API不变、部署流程不变、调用方式不变,吞吐直接涨上来。做LLM serving的团队值得认真评估这个方案——迁移成本可能比你想的低得多。
原文:MARS: Enabling Autoregressive Models Multi-Token Generation
02 多模态 World model的实用化拐点:空间一致性和实时性能不能兼得?
World model(世界模型)目前卡在一个两难上:要空间一致性就得牺牲速度,要实时交互就容易走几步画面就崩。INSPATIO-WORLD的做法是把这两件事拆成两个模块分别解决——一个隐式时空缓存维护全局场景一致性,一个显式空间约束模块处理几何结构和相机轨迹控制。输入是单段参考视频,输出是可实时导航的4D交互场景,这不是视频生成的改良,而是world model在交互性上的跨越。另一个值得注意的设计是联合分布匹配蒸馏(JDMD),用真实数据分布来矫正合成数据训练带来的质量退化。在WorldScore-Dynamic benchmark的实时交互方法中排名第一,空间一致性和交互精度都优于现有方案。
原文:INSPATIO-WORLD: A Real-Time 4D World Simulator via Spatiotemporal Autoregressive Modeling
03 图像生成 所有人都在加channel,但图像自编码器崩的是token
图像自编码器压缩比一拉高就表示塌缩,加channel是所有人的第一反应——但TC-AE指出这个直觉从根上就错了。在深度压缩下,大部分token已经塌缩成近似相同的表示,加channel只是给崩掉的token更多维度来重复同样的东西。真正的瓶颈在token到latent(潜在表示)的压缩过于激进,结构信息在中间就丢了。他们的做法反而更简单:把压缩拆成两个阶段来保留结构信息,再用自监督训练给token注入语义结构,不需要更复杂的架构。深度压缩下重建和生成性能都有明显提升,做视觉tokenizer的团队该重新审视压缩路径了。
原文:TC-AE: Unlocking Token Capacity for Deep Compression Autoencoders
04 训练优化 RL对齐扩散模型,探索和训练凭什么要用同一精度?
RL对齐扩散模型时,rollout阶段本质是在采样——生成大量候选图像,从中筛出对比性强的样本对。这个过程不涉及梯度计算,对数值精度的容忍度远高于策略更新。Sol-RL利用了这个结构性差异:FP4跑高吞吐rollout生成海量候选池,筛选后用BF16重新生成并做梯度优化。在FLUX.1-12B、SANA、SD3.5-L上的实验显示,训练质量与纯BF16持平,收敛速度最高提升4.64倍。思路不复杂,但精准地抓住了RL训练中「探索≠学习」的结构差异——做扩散模型RL对齐的团队值得关注。
原文:FP4 Explore, BF16 Train: Diffusion Reinforcement Learning via Efficient Rollout Scaling

也值得关注
今日观察
今天四篇论文各自解决不同问题,但底层逻辑撞到了一起:系统中不同部分对资源的需求是不均匀的,均匀分配就是浪费。MARS发现连续token的可预测性差异巨大,确定性高的位置一步跳过去就行;Sol-RL发现RL训练中探索阶段只是在采样,FP4精度绰绰有余,把BF16留给真正需要数值精度的梯度更新;TC-AE发现高压缩下大部分token塌缩成相同表示,问题不是精度不够而是token利用率不均;Q-Zoom发现不同查询需要关注的视觉区域完全不同,全局高分辨率是在喂注意力机制吃垃圾。
这里面有一个值得内化的工程直觉:碰到资源瓶颈时,第一反应不该是「整体压缩」或「全面降配」,而是先问「哪些部分其实根本不需要这么多资源」。非均匀分配几乎总是优于均匀压缩——因为均匀策略隐含了一个几乎永远为假的假设:所有部分同等重要。下次遇到推理延迟、显存不够、训练太慢的问题,试试先做一次profiling,找出资源消耗的分布——你大概率会发现,80%的资源花在了20%的真正需要它们的地方,剩下那80%的位置可以大幅削减而几乎不影响结果。