本期仍覆盖 arXiv 当前可检索的同一批最新公告：发布日期 2026-09-10——经 export.arxiv.org/api/query 按 submittedDate 倒序直查核验（cat:cs.CV 与 cat:cs.CL 两路分别取最新 40 / 25 条），返回条目的发布日期全部为 2026-09-10，未出现 09-11 及之后的新条目（arXiv 周末不公告，与 #017–#021 记录一致）。因此本期与上期 #021 取自同一批次，但五篇完全不重复：#021 讲「世界写成程序、统一模型降本」，本期换一条线，讲「在预算内把事做对」。下列五篇的 arXiv ID、发布日期、分类、作者与摘要全文均取自官方页面原文，本刊未直读 PDF 正文；所有数字均引自摘要原文并归因于作者，摘要中未出现的数字本刊不做补充。

五篇合起来是一条主线加一个追问。主线「预算」：五篇都在回答同一个问题——当算力、帧数、参数量、延迟、训练量都被限制住时，系统该怎么设计？ 长视频理解篇把「看多少帧」变成查询级的一等成本（CFD）；视觉自回归篇指出「尺度内并行解码」是一个近似的解码规则而非容量问题（Logit Refiner）；视觉 token 化篇用循环复用同一组参数换掉堆参数（LoopVAE）；视频生成篇把目标定在实时 720p 与流式编辑（Vidu S2）；设计模板篇则冻结两个预训练骨干、只训练一个通信模块来学跨模态交互（InterIL）。追问「省下来的预算买到了什么」：五篇给出的答案分别是不丢时间结构、恢复尺度内依赖、更多算术换更少权重、可编辑性、以及联合分布——它们共同的前提是：先把「这类系统的瓶颈在哪一环」说清楚，再决定省哪一笔。本期气质与日报 #022 一致：真正的进展发生在接口、预算与度量这一层。

1. Caption-once, Frames-on-Demand：把「看多少帧」变成查询级的显式成本——边缘端一次字幕、云端按需取帧的长视频 Agent

论文：Caption-once, Frames-on-Demand: Visual-Need Routing for Budget-Aware Agentic Long Video Understanding（2026-09-10，cs.CV/cs.HC；EMNLP 2026 主会）

资源：HF Papers

问题。 作者把问题设定在边缘设备的长视频理解上：要在紧张的算力与带宽预算下推理数小时的内容。两条现有路线各有一处硬伤——对视觉 token 做子采样会丢失时间结构；而纯文本的视频记忆会丢失细粒度的视觉属性。换句话说：要么记得住「什么顺序发生」，要么记得住「长什么样」，但很难同时。

方法亮点。 作者先观察到一个「视觉—文本对偶性（visual-textual duality）」：语言记忆比稠密帧更能承载长程时间结构，而像素在属性级感知上仍然决定性的。据此提出 CFD（Caption-once, Frames-on-Demand），一个预算感知的边缘—云 Agent 框架。边缘侧只做一次离线字幕生成，构建「双轨叙事索引」——一条事件级的「故事骨架」加一条片段级的「微观日志」，并被缓存、跨查询复用而不重新打字幕。查询时，云侧 MLLM 在索引上以「故事优先（story-first）」的循环推理，核心是一个轻量的 Visual-Need Router：一个逐查询的门控模块，只对「感知类问题」（外观、屏上文字、属性消歧）触发有界的关键帧检索，而把「时序—结构类问题」留在语言空间里解决。作者强调，这个路由器把「视觉访问」变成了一等的、以查询为条件的成本，无论视频多长都限制每次查询的帧消耗上限。

证据。 摘要为定性陈述（作者口径）：「在长视频基准上的实验展示了较强的精度—效率权衡，同时大幅减少在线视觉处理。」 摘要未给出任何具体数字（无基准名、无分数、无帧数上限、无延迟或能耗数据）。

边界。 无任何数字是最大的短板：既然论文的核心是「预算」，那么预算的具体额度、对应的精度损失曲线、以及相对基线的对比恰恰是最该给的信息，摘要一条都没有；「Visual-Need Router」的判定质量决定了整个系统的天花板——把问题误判成「不需要视觉」会丢属性，误判成「需要视觉」会白花预算，误报与漏报的代价不对称，摘要未讨论；「只做一次离线字幕」有隐含前提：视频内容、视角与标注质量在索引阶段就固定了，若索引字幕本身漏掉了关键视觉细节，后续再检索帧也补不回语义线索；边缘—云的分工带来了隐私与传输问题（哪些内容必须离开设备）未讨论；双轨索引的存储与更新成本未量化——「跨查询复用而不重新打字幕」意味着索引必须持久化，长视频的索引体积可能不小；评测的长视频基准构成未列出，无法判断是否覆盖了「数小时 + 高频属性查询」这一最难组合；EMNLP 主会接收本身不构成方法有效性的证据。

我的判断。 这篇的价值在于它把「长视频理解」重新表述成一个资源分配问题，而不是一个压缩问题。当前主流做法是「把视频压成更少的 token」，而这篇文章的观察更锋利：语言与像素擅长的是不同的东西——时间结构适合语言、属性细节必须看像素，因此正确的做法不是「统一压缩」，而是按问题的类型决定要不要付视觉的钱。这与本刊 #021 中 World in World（把控制证据统一成带标签的干净状态）、以及 #022 日报里网商银行那句「光是代码写得快并不够」（瓶颈在上下文传递而非编码）是同一种方法论：先把「哪一环真的贵」找出来，再针对性优化。「Visual-Need Router」这个名字下的东西其实是一个成本模型——它是全篇唯一真正的机制贡献。保留意见：摘要无数字、无失败分析，说明这篇目前更像一个架构提案；而它最脆弱的假设是「语言足以承载时间结构」——在需要精确到帧的动作、计时或因果判断时，这条界线会移动，作者没有讨论界线在哪。给读者的实用建议：这类工作最值得复用的不是模块，而是「把一次昂贵访问显式建模并设上限」这个模式——任何 Agent 系统都可以问自己：我最贵的那一次调用，是否被按需触发、且有上限？

2. Logit Refiner：指出视觉自回归模型的「尺度内并行」是一种平均场近似——用 10% 参数补回丢失的空间依赖

论文：Logit Refiner: Improving Visual Autoregressive Models via Intra-Scale Dependency Modeling（2026-09-10，cs.CV/cs.AI/cs.LG；ECCV 2026）

资源：HF Papers

问题。 视觉自回归模型（VAR）通过「下一尺度预测」生成图像，在同一尺度内并行产出所有 token。作者的诊断是：这种并行解码构成了一种「平均场式（mean-field-style）的近似」，它丢弃了同一尺度 token 之间的空间依赖——因此无论骨干容量多大，都会出现局部不一致的样本。作者强调，这是解码规则本身的局限，不是容量不足。

方法亮点。 针对这一点，作者提出 Logit Refiner：一个轻量的自回归模块，在冻结的骨干特征条件下顺序采样 token，从而恢复尺度内的依赖关系。它在工程上追求最小侵入：只需增加约 10% 的参数、少于基座模型 5% 的训练算力，即可插入任何预训练的 VAR 检查点而无需重新训练。作者用受控消融把「联合的尺度内采样」单独隔离出来，证明它——而非额外的容量或训练——才是关键成分。

证据。 摘要给出的数字（作者口径）：在 310M 到 2B 参数的多档骨干上、在类别条件 ImageNet 256×256 上，该精修器一致地改善生成质量，并使一个 1.1B 参数的模型超过两倍于它的模型；方法进一步泛化到文本到图像生成，作者据此认为「平均场瓶颈在 VAR 各变体中都存在，且被本方法有效缓解」。此外，摘要给出项目页链接。

边界。 数字只覆盖提升方向，没有给出任何绝对值（精修后的 FID / IS / 一致性指标、以及相对各基线的差距都未列）；评测集中在类别条件 ImageNet 256×256 与文本到图像这一档分辨率，更高分辨率与更长 token 序列下，顺序采样的额外开销会如何增长未讨论——而这正是「省了训练算力、可能多花推理算力」的关键权衡；顺序采样与骨干的并行路径如何调度、推理延迟的实际增幅未给出（只给了参数与训练算力占比，没有给推理成本）；「1.1B 超过两倍大的模型」未指明被超越的模型与指标，无法判断这一结论的稳健性；消融只证明「联合采样重要」，但没有回答「采样多少步才够」；「平均场近似」是一个有理论色彩的表述，摘要未给出形式化定义或误差界，本刊只能把它记录为作者的类比框架。

我的判断。 这篇是本期的「度量与诊断」侧代表，其形式与 #021 的 OmniKVQuant 很接近：先指出一个被普遍使用的既有做法在机制上错了（那里是「把文本 LLM 的量化方法直接搬到 Omni 模型」，这里是「同一尺度内并行解码」），再给出一个最小改动。「这是解码规则的局限，不是容量不足」这句判断最有价值——它把改进方向从「换更大的模型」拉回到「改一小段采样逻辑」，而 10% 参数 / 5% 训练量这两个数字让这个主张具备了工程可行性。这类「外挂一个小模块修正基座规则」的形态，与日报 #022 中 Anthropic 报告的结论（安全干预要写在事实层）在精神上一致：真正有效的改动往往很小，前提是你知道它该改在哪。 保留意见：VAR 这条路线本身仍在快速演进，如果后续架构把尺度内依赖直接建成显式建模，这个精修器会被吸收掉；此外顺序采样会削弱 VAR 相对扩散模型的速度优势——省下的训练算力若能换来推理延迟上升，账就未必划得来，而摘要恰好没算这笔推理的账。判断上我倾向于：机制诊断可信，收益幅度待验证，推理成本待补。

3. LoopVAE：让同一个核心在尺度内与跨尺度循环复用——29M 参数达到 0.28 rFID，权重比 84M 参考 VAE 少约 65%

论文：LoopVAE: Recurrent Depth Across Scales for Visual Tokenization（2026-09-10，cs.CV；19 页 6 图 7 表，单作者）

资源：HF Papers

问题。 作者问的是一个架构经济学问题：层级式视觉 tokenizer 通常给不同的空间尺度分配不同的处理块（block）；那么，这些计算中有多少可以共用同一组参数？

方法亮点。 LoopVAE 在尺度之内与跨尺度之间复用一个「尺度—循环条件化（scale- and loop-conditioned）」的核心，只让改变分辨率的过渡部分保持独立。执行结构上，一个四块（four-block）核心在编码器或解码器上各执行 28 次块应用。作者把设计空间也一并交代了：同时给出卷积与 Transformer 两种算子，并支持单分辨率或多分辨率的潜变量接口。

证据。 摘要给出的数字（作者口径）：在 ImageNet-256 上，29M 参数的卷积模型在约 30 个 epoch 的两阶段训练预算下取得 0.28 rFID 与 32.54 dB PSNR，使用的参数比 84M 的参考 VAE 少约 65%。消融与诊断部分给出三条观察：① 同执行图、非对抗式训练的 Transformer 变体在全局共享下取得有竞争力的 PSNR 与 SSIM，但不共享的块在 LPIPS 上更好；② 有目标的循环干预（targeted loop interventions）显示，完成训练好的递归会改善重建，且即使是微小的特征更新也会产生显著的下游影响；③ 截断（truncation）会暴露输出范围错误，从而把「有用的递归计算」与「可靠的提前退出」区分开来。作者还给出一条成本侧的诚实记录：运行时剖析显示，更少的存储权重需要更多算术与更长运行时间。

边界。 评测基本集中在 ImageNet-256 这一个设定（无视频、无高分辨率、无下游理解任务的迁移），「视觉 tokenization」这个名字下的另一端（token 能否支撑理解任务）完全没有涉及；「0.28 rFID / 32.54 dB PSNR」是摘要单点数字，无逐尺度或逐配置的完整表格，本刊无从判断在不同循环次数下的曲线形状；「更少权重 = 更多算术 + 更长运行时」这条作者主动披露的权衡未被量化——少了多少权重、多了多少算力、慢了多少，摘要没有数字，而这是部署侧最关键的一笔账；30-epoch 的两阶段训练预算属「轻量训练」，与大规模参考 VAE 的可比性需谨慎（若基线用了更长的训练预算，参数效率的对比就不完全等价）；递归深度与重建质量的关系未定界（提到「完成递归改善重建」，但深度上界、收敛性与计算增长未说明）；截断实验揭示的「输出范围错误」具体成因未展开；单作者 19 页稿件的实验规模在本刊无法评估，摘要只给了两条指标。

我的判断。 这篇的有趣之处在于它把「参数共享」提升为一个显式的设计轴，并给出了一个极端的选择：同一个核心复用 28 次。它与本期第 2 篇（用 10% 参数修基座规则）方向相反却同源——两篇都在削减「为每件事准备专用参数」这件事。最值得记的是作者自己披露的那条代价：递归复用省下的是显存里的权重，付出的是算术量与时延——这与 #021 中 LoopVAE 的远亲（循环 Transformer 类架构）遇到的是同一个问题，也与日报 #022 中「算力做成集装箱」的供给思路形成对照：参数与算力不是同一种资源，省哪一种取决于部署环境是「存不下」还是「算不快」。保留意见：单点指标 + 单数据集 + 未量化的时延代价，使它目前更像一次架构可行性演示；而「视觉 tokenizer 的终极目标是支撑理解」这件事，摘要完全没有触及——重建好不等于 token 有用，这是该方向长期存在的评价缺口。判断上：设计轴提得对，证据还太薄。

4. Vidu S2：把「实时」和「可编辑」同时塞进视频生成——720p 实时数字人、流式编辑与空间生成

论文：Vidu S2: Real-Time Interactive, Editable, and Spatial Video Generation（2026-09-10，cs.CV/cs.LG；作者列表 34 人）

资源：HF Papers

问题。 摘要没有铺陈动机，而是直接把「实时」作为设定：视频生成模型在交互式场景下的可用性取决于延迟与可控性。作者把系统拆成两个可用面：数字人（Avatar）与视频编辑，并另外探索「实时空间视频生成」对这两者是否可行。

方法亮点。 Vidu S2 由两部分组成：Vidu S2-Avatar，一个实时交互式数字人模型；Vidu S2-Editing，一个实时视频编辑模型。 相对前代 Vidu S1，作者列出 Avatar 的三处升级：支持实时 720p 视频生成、支持「动态参考」（dynamic references，可在任意时刻更新）、更强的指令遵循能力（原文举例：跳舞）。Vidu S2-Editing 支持对视频流进行实时编辑，涵盖风格渲染、服装替换、人物替换与背景替换四类。

证据。 摘要为定性陈述（作者口径）：「实验表明 Vidu S2 优于所有基线。」 作者另给出一个可在线播放的 demo 链接。摘要未给出任何数字——没有延迟、帧率、分辨率以外的规格、也没有基线名称。

边界。 「实时」是本篇的核心承诺，而摘要没有给出任何延迟数字（720p 是分辨率不是速度）；「优于所有基线」未列出基线是谁、用何种指标、由谁评测——「所有」在生成模型评测里是一个需要极大克制才敢使用的词；动态参考的「任意时刻更新」隐含一致性挑战（中途换了参考，人物身份、光照与既有帧如何保持一致）摘要未讨论；四类编辑（风格/服装/人物/背景）在流式条件下的时间一致性未给证据；「在线 demo 可播放」不等于可复现，且未提供模型权重、代码或评测协议；摘要提「探索实时空间视频生成是否可行」，但未说明探索结果——承诺了一项没有汇报的探索；34 人作者列表说明工程投入量级，但摘要无法区分哪些是方法贡献、哪些是系统集成；未讨论安全与滥用风险（实时换脸/换装类编辑的合规问题），这在人物替换类能力上是明显缺口。

我的判断。 这篇是本期唯一的「产品能力」型论文，它的价值判断必须与「论文价值判断」分开：作为系统报告，「实时 720p + 流式编辑 + 动态参考」这三项同时成立本身就是一个不低的要求（生成模型的实时化一直是延迟与一致性之间的硬仗）；但作为学术材料，它几乎没有提供可验证的信息——无数字、无基线、无评测协议。与本刊 #020/#021 记录的 World in World、Recursive Code World Models 相比，后两者至少在方法层给了可复用的结构（证据路由、递归构造），而这篇给的是能力清单。保留意见与建议：如果读者关心的是「实时可控视频生成现在到哪一步了」，这篇值得点开 demo 亲自看一遍（可交互性是它唯一无法在摘要里被检验、却最容易被眼睛判断的东西）；如果关心的是「它怎么做到的」，需要等完整版本——摘要里没有任何机制细节。

5. InterIL：把图像与布局放进同一个生成过程——冻结两个预训练骨干，只训练一个「通信模块」学跨模态交互

论文：Learning Interaction between Image and Layout Priors for Joint Image-Layout Generation in Design Templates（2026-09-10，cs.CV/cs.AI/cs.GR；投稿 IEEE TVCG）

资源：HF Papers

问题。 作者处理的是平面设计模板生成：从一段文本出发，同时生成背景图像与前景元素的布局，形成和谐的构图。作者对既有路线的批评很具体：此前工作多采用序贯范式（sequential paradigm），逐个生成设计元素——而这种序贯方案无法忠实刻画背景与布局之间的依赖关系（即联合的图像—布局分布），从而限制了生成模板的质量。

方法亮点。 作者提出 InterIL，在单个生成过程中联合生成两种模态（背景图像与布局）。关键设计是用一个可学习的「通信模块（communication module）」连接预训练的图像扩散模型与布局扩散模型的骨干，显式建模双向的图像—布局交互。训练策略是本文最值得记的一点：训练时冻结图像与布局骨干，只更新通信模块——目的是保持并利用两大预训练单模态先验，让模型专注于学习跨模态交互，从而更好地捕捉联合分布以提升构图和谐度。作者还强调该模型不含设计专属的归纳偏置（design-specific inductive bias），因此更能保留真实设计本来的特征。此外引入测试时引导策略（test-time guidance），让用户在推理阶段施加偏好。

证据。 摘要为定性陈述（作者口径）：「实验显示，与先前方法相比，我们的模型在图像、布局以及图像—布局协调性三方面都能生成显著更好的结果，产出更接近真实样本；同时我们展示了在推理时无需重新训练即可施加用户偏好的灵活性。」 摘要未给出任何具体分数、指标名或数据集名。

边界。 无数字：三个维度（图像 / 布局 / 协调性）的「显著更好」没有指标与分差，「更接近真实样本」也没有分布距离度量；「冻结骨干 + 只训通信模块」的代价未讨论——若两个单模态先验的接口在表示空间上不匹配，通信模块可能学到的是一个很浅的转译层，而无法真正改变任一侧的生成分布（这正是「联合生成」与「条件生成 + 后处理」之间最容易被混淆的地方）；「无设计专属归纳偏置」是优点也是缺点：缺乏结构先验可能让可读性、留白、层级这类设计规则的学习更依赖数据，摘要未讨论数据规模与来源；测试时引导的具体形式（分类器引导？梯度引导？）与代价未说明；评测是否包含真实设计师的偏好研究未知——设计任务的目标函数本身是主观的；投稿 IEEE TVCG 属图形学/可视化方向，评审口径与 CV 会议不同，本刊不据此判断质量；未提供代码或数据链接。

我的判断。 这篇的真正贡献在「怎么用最少的新参数把两个已经很强的单模态先验对接起来」这个问题上——冻结两侧、只训一个通信模块，这是一个在小算力预算下修改联合分布的干净做法，与本期第 2 篇（10% 参数改解码规则）、第 3 篇（复用同一核心）属于同一族思路：新增的是「连接」而不是「容量」。值得记的第二个点是「序贯 vs 联合」的论证方式：作者没有说序贯生成的每一步更差，而是说序贯结构无法表示联合分布——这是一个关于模型类表达能力的判断，比「效果不好」有力得多。保留意见：无数字、无数据集、无代码，使它目前只是方向主张；而设计模板这个任务本身缺乏公认的评测标准（「和谐」难以定义），因此即便有数字也需要谨慎对待。判断上：机制动机成立，「冻结 + 通信」的范式值得在其他跨模态联合任务上试；但它现在还不能被当作已证实的方案。

今日阅读线索

用一句话概括本期：这五篇不是在想「怎么让模型更强」，而是在想「预算给定了，我该把哪一笔花在哪里」——而且五篇都先把「哪一环真的贵」说清楚了。

第一条线索：把隐性的成本显性化。 CFD 的贡献是把「看多少帧」从隐含假设变成一个按查询触发、带上限的一等成本；Logit Refiner 的贡献是把「同一尺度并行解码」这个默认规则指出为一种近似；LoopVAE 的贡献是主动披露「少存权重 = 多算算术 + 更长时延」。三者都在做同一件事：让原本藏在实现里的那笔账露出来。这与日报 #022 的暗线完全吻合——Anthropic 用「孤立判断 79% vs 上下文中 1%」把「有偏推理」变成可测的数字，Clay 用「deliberately unhurried」把时间从竞争速度里抢回来，Epoch AI 的「饱和」口径把「累积答对过」与「稳定达到」分开。度量做清楚，是这一轮所有领域共同的瓶颈。

第二条线索：新增「连接」，而不是新增「容量」。 InterIL 冻结两个骨干、只训通信模块；Logit Refiner 只加约 10% 参数；LoopVAE 复用同一个核心 28 次。三篇都在削减「为每件事准备专用参数」这件事，而它们各自的瓶颈判断又非常不同（联合分布的表达能力、解码规则、权重存储）。给读者的可复用提问：你手上的系统如果真的加不动参数了，第一个该问的问题是——我的模型类本身是否表达了需要的关系（如 InterIL 所说的序贯结构缺联合分布），还是我只是把参数摆错了位置（如 LoopVAE 的跨尺度复用）？

第三条线索（也是本期最弱的一环）：实时与交互的代价没有被算。 Vidu S2 把「实时 720p + 流式编辑 + 动态参考」作为产品能力提出，但没有给延迟、没有给基线、没有给评测协议；LoopVAE 同样量化了参数收益却没量化时延代价。这两处空白指向同一个缺口：当研究的卖点是「实时」时，「实时」本身必须成为被测量的对象，而不是被声称的属性。 如果只跟进一条线，我会选这条——因为它是当前「能力清单」与「可验证结论」之间差距最大的地方。

旁注（标题级线索，未读摘要）：本期同批次的 cs.CL/cs.LG 里有一篇标题为 The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement（arXiv 2609.11873）——「RSI（递归自我改进）」这一天同时出现在 arXiv、Anthropic CEO 的公开警告与国内一篇世界模型发布会上（见同期 AI 日报 #022 第 3–4 条与简讯 ①）。仅记录线索，本刊本期未读其摘要，不做判断。

本刊注：本期五篇论文的 arXiv ID、发布日期、分类、作者、页数与评论信息，以及摘要全文，均经本机直接抓取 arxiv.org/abs/<id> 页面与 export.arxiv.org/api/query（Atom feed）核验；本刊未直读任何 PDF 正文。批次说明：截至发布时，cat:cs.CV 最新 40 条与 cat:cs.CL 最新 25 条按 submittedDate 倒序返回的发布日期全部为 2026-09-10，未出现 09-11 及之后的新公告批次（arXiv 周末不公告，与本刊 #017–#021 记录一致）——因此本期与上期 #021 同批但选题不重复。所有性能与规模数字均为论文作者口径，本刊未复现；凡摘要中未出现的数字，本刊不做补充；摘要中未讨论的边界（推理时延、数据许可、评测协议、向真实场景迁移等），已在上文「边界」段落中逐条标注为「未说明/未讨论」。代码、项目页与在线 demo 链接取自摘要原文，本刊未核验其可用性。