Honeycomb：一个能"记住"场景却永不发胖的视频生成大脑 每日快报

假设你在玩一个第一人称探索游戏，走进一个房间，看了看墙上的画，又走到厨房瞅了眼冰箱，然后转身回到客厅。你会下意识期待，客厅还是你离开时的样子，沙发没挪地方,墙上的画也还挂在原处。

【资料图】

这个期待听起来理所当然，但对AI生成视频来说，这其实是个大麻烦。

现在的视频世界模型（能根据相机轨迹生成连续视频画面的AI系统）在生成长视频时，有一个几乎绕不开的毛病：走远了再回头，场景就变了样。墙上的画可能消失了，家具挪了位置,连房子的外立面颜色都可能悄悄换了一种。这不是偶然的生成失误，而是一个结构性问题：生成模型只能"看见"最近几帧的内容，早期看过的东西，一旦超出它的记忆窗口，就相当于从没发生过。

研究者们当然想到了办法，给模型配一个外部记忆库，把之前生成或观察到的内容存起来，需要的时候再调出来用。思路没错，问题出在存储方式上。

核心问题：记忆系统为什么越用越臃肿

目前主流的两种做法是这样的。

一种叫Spatia，它把每一帧生成的RGB画面反投影成三维点云，存下来。你每往前走一步，相机就能看到新的场景，这些新观察到的点就会不断往点云里添加。走得越远，点云越大,这就好比你每去一个新地方旅游都要带一块石头回家做纪念，十年后你家可能已经堆不下了。

另一种叫LSM-World，做法类似，只是存的不是RGB像素，而是扩散模型内部的潜在特征（latent，指神经网络内部处理数据时的压缩表示，比原始像素更紧凑但依然携带丰富信息）点云。本质上还是在不断追加新数据,存储量同样随着生成的帧数线性增长。

问题就在这儿：如果你要生成一个几分钟甚至更长的视频漫游,这个记忆库会越滚越大，显存和计算成本直线上升。想象一下，如果Google Maps每次你导航到一个新地方，都把沿途看到的每一栋楼的照片原封不动存进你手机相册,不出一个月，你的手机内存就会被挤爆。这不是危言耸听，而是这类点云式记忆方法的真实命运。

研究团队由此提出了一个值得深思的问题：能不能让记忆的"大小"始终保持不变,同时还能记住足够多的场景信息？这篇来自哈佛大学、新加坡国立大学、MIT等机构的论文给出的答案，就是Honeycomb。

HexMemory：把记忆压缩进六块"面板"

Honeycomb的核心创新是一种叫HexMemory的记忆表示方法。它不用不断膨胀的点云，而是用六个固定大小的二维特征平面来存储整个场景的信息。

这六个平面分为两组，一组是三个纯空间平面（XY、XZ、YZ），分别对应从正面、俯视、侧面看场景的切片；另一组是三个时空平面（ZT、YT、XT），把某个空间轴和"写入时间"轴配对起来，记录场景内容是什么时候被观察到的。

HexPlane：这是HexMemory设计的灵感来源，一种用低秩分解表示动态场景的方法，原本是针对单个场景做独立优化的，而Honeycomb把它改造成了一个可以跨场景复用、不需要每次都重新训练的通用结构。

这样设计的好处显而易见。不管你的相机走了多远，看了多少个房间，这六块平面的尺寸永远不变。新的观察内容进来，不是往后面"追加"，而是"融合"进已有的格子里。这就好比一块白板，你往上面写新内容时不是不断加纸，而是把旧字擦淡一点，腾出空间写新东西,整块白板的物理尺寸从头到尾都是那么大。如果不这样做会怎样？那就回到了Spatia和LSM-World的老路,存储随时间无限增长，长视频生成的成本变得不可控。

那新观察的内容具体是怎么"写"进这六块平面的呢？这就要说到论文的第二个核心设计:一个前馈式的记忆写入器。

前馈写入器：不用每次都从头学一遍

传统的HexPlane用法是针对每个场景单独做梯度下降优化,说白了就是每来一个新场景，都要重新训练一遍网络去拟合这个场景的特征平面。这在论文的实验里被称为"直接优化"方案，效果不错，但代价极其高昂：每次写入要3000多毫秒，比Honeycomb的方案慢了240倍左右。

Honeycomb设计了一个前馈式写入器（Feed-Forward Memory Writer），它不需要针对每个场景单独优化，而是像一个训练好的翻译官，接收新一批观察到的潜在特征点,这些点来自深度估计和相机参数反投影出的三维坐标,然后直接把它们映射成六个平面上的特征贡献。

这个过程用了一种叫双线性splatting（bilinear splatting，指把一个点的数值按照距离权重分摊到周围四个网格单元里，这样哪怕点的位置不是正好落在网格中心，信息也不会丢失）的技术：每个三维点投影到某个平面上的位置后，它携带的特征值会按距离远近分配给周围四个格子，距离越近分配的权重越大。每个格子最后把收到的所有贡献做加权平均，同时记录下收到的总权重作为"置信度"。

这里有个细节特别值得琢磨：写入器处理的只是"新的那一小块"观察,而不是把整个历史重新过一遍。这就好比你记笔记,好的做法是只在空白处补充新内容，而不是每次都把整本笔记本撕了重抄一遍。如果采用"重建式"写入（论文里称为Replacement方案,每次都用所有历史点云重新生成平面），效果确实和Honeycomb的方案差不多,但写入时间会随着视频变长而不断增加，从11毫秒涨到40毫秒。Honeycomb的递归写入方案则始终稳定在13毫秒左右，不随视频长度变化。

融合新旧记忆：置信度加权和"纠错网络"

写入新内容之前，还有一道工序：当相机探索的空间范围扩大，或者时间跨度变长，原来那六块固定大小的平面需要先"变形"去适应新的边界范围，这个过程叫内存变形（Memory Warp）。打个比方,这就像你把一张地图从"显示一条街"扩展成"显示整个城区"，原来那张街道地图的内容还得保留,只是要按比例缩小、嵌进更大的地图里，腾出的空白区域再填充新探索到的内容。

变形之后，旧的平面和新写入器产出的平面要融合在一起。融合的方式是置信度加权池化：哪个来源的置信度（也就是前面提到的累积插值权重）高，就更多地相信哪个来源的数值。

在此基础上，论文还加了一层学习出来的残差修正网络，用来微调这个加权平均的结果，而且这个修正网络的输出层一开始被初始化为零，意味着训练刚开始时，融合完全等同于简单的置信度加权平均，之后网络会慢慢学会在哪些地方需要做额外纠正。这种"先保底、再优化"的设计思路，本质上是在保证系统不会一上来就学坏，这是深度学习里相当常见也相当聪明的一种稳健性技巧。

读取记忆：生成新画面前先"问一下"过去

存进去的记忆要怎么用呢？这就是读取环节（Memory Readout）。

在生成新的一段视频之前，系统会把目标相机视角下每个像素对应的三维坐标投影出来，去HexMemory里查询对应位置存了什么特征。查到的结果会和一个可见性掩码（标记哪些像素位置确实查到了历史记录）一起，通过一个叫ControlNet（一种常见于图像/视频生成模型里的旁路控制分支，能把额外的条件信息注入到主干生成网络里而不破坏原有的生成能力）的侧路分支，送进负责实际生成画面的扩散变换器（DiT，Diffusion Transformer，这篇论文用的主干网络是阿里的Wan2.2,一个50亿参数级别的视频扩散模型）。

整个流程就是：读取过去的记忆 → 用它指导新一段视频的生成 → 把新生成内容重新写回记忆,一轮一轮循环下去,内存大小始终保持恒定。

实验说话：数字背后的真实差距

说了这么多设计思路，实际效果到底怎样？论文在两个基准上做了测试：WorldScore（一个包含3000个图生视频样本、评估静态和动态场景生成质量的统一基准）和RealEstate10K（一个常用的室内房产漫游视频数据集）。

在WorldScore的综合评分上，Honeycomb拿到65.52分，比次好的Spatia（63.21分）高出2.3分左右，也明显超过了Wan2.1等通用视频生成模型（55.21分）。在RealEstate10K的新视角合成任务上，Honeycomb的PSNR（峰值信噪比，数值越高说明生成图像和真实图像越接近）达到18.45分贝，而Spatia是15.58分贝，LSM-World是17.46分贝。

更关键的是"重访一致性"测试,也就是论文反复提到的那个场景：相机离开又回来，看最后一帧和最初那一帧像不像。这个测试的结果最能说明HexMemory的价值所在,Honeycomb的闭环PSNR达到17.22分贝，比LSM-World（15.12）高出整整2.1分贝，而且光流误差（衡量两帧画面之间运动/变化幅度的指标，数值越小代表画面越"静止一致"）从Spatia的6.64像素骤降到3.00像素，降幅超过一半。

这组数字背后其实有个挺直观的解读：光流误差从6.64降到3.00，意味着当相机绕一圈回到起点时，Honeycomb生成的画面比起点画面平均只"挪动"了3个像素左右的视觉差异，而Spatia的画面平均挪动了6.64个像素,差不多是两倍的晃动感。对观众来说，这种差别可能就是"这房间好像一直没变"和"这房间好像悄悄重新装修过"之间的区别。

方法 平均分 静态分 动态分 3D一致性 光照一致性 风格一致性

WonderJourney 54.19 63.75 44.63 80.60 79.03 62.82

WonderWorld 61.79 72.69 50.88 **86.87** 85.56 70.57

Spatia 63.21 64.88 61.54 83.26 **89.09** 83.33

LSM-World 61.20 62.69 59.70 80.88 76.10 –

Wan2.1 55.21 57.56 52.85 78.74 78.36 77.18

Honeycomb **65.52** **68.01** **63.03** 82.29 85.76 **84.21**

内存瘦身实验：到底能压缩到什么程度

研究者还做了一组很实在的消融实验，专门测试把HexMemory的平面分辨率往下调，会对效果造成多大损失。

把分辨率从512降到256，HexMemory的存储占用从73.9MB骤降到19.8MB，相当于省掉73%的空间，而闭环PSNR只从17.22掉到17.10，几乎可以忽略不计。这说明场景里真正重要的信息其实没那么"密集"，大部分格子存的是冗余或者低价值的细节，压缩起来并不心疼。但如果继续压到128分辨率，存储降到5.8MB，PSNR就明显掉到16.77,说明压缩是有底线的，不是越小越好。

这就好比收拾行李箱，你一开始塞的衣服里有一半是"可能用得上"的备用品，扔掉它们对旅行体验几乎没影响；但如果你连常穿的那几件也扔了，麻烦就真的来了。

记忆会不会"失忆"：一个跨越多轮写入的追踪实验

论文里还有个挺有意思的补充实验,专门追踪"旧记忆会不会随着新内容写入而逐渐被冲淡"。

研究者在一个129帧的长序列里，连续写入了四个视频片段，每写一次就回头测试一次第一个片段的重建质量。结果是：完全不用记忆时，第一个片段的重建PSNR只有12.29分贝；记忆写入一次后跳到16.71分贝；再经过三次额外的写入，分别降到16.67、16.35、16.30分贝,三次写入总共才掉了0.41分贝，平均每次写入损失0.14分贝。到第五次写入后，重建效果依然比完全没有记忆时高出4.01分贝。

这个数据挺打消疑虑的,至少在这个测试场景里，HexMemory并不是那种"写一次就覆盖一次、旧的东西马上被冲掉"的健忘症患者，它更像一个记性不错的老朋友，聊了很多新话题之后，你问起几年前的一件旧事，他依然能说出个大概，只是细节稍微模糊了一点点。

写在后面

读完这篇论文,我其实对"固定大小"这个设计选择本身有点意外。我们习惯性地认为，记得越多信息量越大的东西才叫"记忆好"，但Honeycomb反而证明了一件事：用六块永远不变大小的平面，照样能装下一个相当复杂的三维场景，而且效果比那些不断膨胀的点云方法还要好。这说明场景信息本身其实存在大量冗余，真正有效的记忆未必需要和观察数据量成正比地增长，关键在于怎么把信息"压实"而不是单纯"堆起来"。

另一个让我多想了一下的细节是消融实验里"直接优化"方案的数字:它比Honeycomb的前馈写入方案质量略高一丁点（17.44对17.22分贝），但代价是慢了240倍。这组对比让我想起一个挺朴素的道理：很多时候工程上的"够用就好"，远比追求理论最优更值钱。如果一个视频生成系统每生成一段画面都要等好几秒钟去做场景记忆的梯度下降优化，这个系统在实际产品里根本没法用,再高的分数也没有意义。

论文里没有展开讨论的一点是，HexMemory目前依然依赖单目深度估计（monocular depth estimator）来把二维画面提升到三维坐标,这个环节本身的误差会不会在长时间的循环写入里被放大、累积，论文没有给出特别细致的分析。如果深度估计在某一帧出了偏差，这个偏差会不会像滚雪球一样越滚越大？这大概是接下来值得追问的一个问题。

Q&A

Q1：Honeycomb和HexMemory是什么关系？

A：Honeycomb是一个完整的视频世界模型，它内部搭载了HexMemory这种固定大小的场景记忆表示方法。HexMemory负责存储和更新场景特征，Honeycomb则负责用这些记忆去指导视频的实际生成。

Q2：HexMemory和Spatia、LSM-World这类方法最大的区别是什么？

A：Spatia和LSM-World都是通过不断往点云里追加新观察内容来存储记忆，视频越长存储量越大。HexMemory则用六块固定尺寸的特征平面存储信息，不管生成多长的视频，存储大小始终不变。

Q3：Honeycomb生成视频时相机绕一圈回到起点，画面会变样吗？

A：论文的闭环测试显示Honeycomb在这种场景下表现明显优于对比方法，光流误差只有3.00像素，比Spatia的6.64像素小了一半以上，说明重新回到起点时画面变化更小，场景一致性更好。

关键词： 相机 像素 点云 视频生成 旗舰基座模型 honeycomb