公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！ 👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～
龙哥推荐理由：
3D场景生成一直卡在两个字：太大。SceneTok偏偏反着来，把场景先压成少量无序token，再把“渲染”和“生成”拆开做，结果是压缩率高得离谱，速度还不慢，挺像把大卡车拆成乐高再开回去。
原论文信息如下：
论文标题:
SceneTok: A Compressed, Diffusable Token Space for 3D Scenes 发表日期:
2026年02月 发表单位:
Max Planck Institute for Informatics, Saarland Informatics Campus 原文链接:
https://arxiv.org/pdf/2602.18882.pdf 开源代码链接:
geometric-rl.mpi-inf.mpg.de/scenetok/
3D 场景生成长期被两个问题卡着：表示太重，生成太慢。SceneTok 的思路很直接——先把场景压成少量、无序、可扩散的 token，再把“看图”和“造景”拆成两步做。这样既保住了新视角合成能力，又把生成速度拉到了“终于能用”的区间。 更关键的是，它不是只会压缩的“瘦身器”，而是把 token 空间做成了能被扩散模型直接操作的隐空间。对做 3D 重建、场景生成、机器人感知的人来说，这种设计的价值很现实：模型更轻，训练更像样，部署门槛也没那么吓人了。
Mohammad Asim, Christopher Wewer, Thomas Wimmer, Bernt Schiele, and Jan Eric Lenssen. Met3R: Measuring multi-view consistency in generated images. In CVPR, 2024. Roman Bachmann, Jesse Allardice, David Mizrahi, Enrico Fini, Oguzhan Fatih Kar, Elmira Amirloo, Alaaeldin ElNouby, Amir Zamir, and Afshin Dehghan. Flextok: Resampling images into 1d token sequences of flexible length. In ICML, 2025. Eric R. Chan, Koki Nagano, Matthew A. Chan, Alexander W. Bergman, Jeong Joon Park, Axel Levy, Miika Aittala, Shalini De Mello, Tero Karras, and Gordon Wetzstein. GeNVS: Generative novel view synthesis with 3D-aware diffusion models. In arXiv, 2023. David Charatan, Sizhe Li, Andrea Tagliasacchi, and Vincent Sitzmann. pixelsplat: 3d gaussian splats from image pairs for scalable generalizable 3d reconstruction. In CVPR, 2024. Yuedong Chen, Haofei Xu, Chuanxia Zheng, Bohan Zhuang, Marc Pollefeys, Andreas Geiger, Tat-Jen Cham, and Jianfei Cai. Mvsplat: Efficient 3d gaussian splatting from sparse multi-view images. In NeurIPS, 2024. Yuedong Chen, Chuanxia Zheng, Haofei Xu, Bohan Zhuang, Andrea Vedaldi, Tat-Jen Cham, and Jianfei Cai. Mvsplat360: Feed-forward 360 scene synthesis from sparse views. In NeurIPS, 2024. Hanwen Jiang, Hao Tan, Peng Wang, Haian Jin, Yue Zhao, Sai Bi, Kai Zhang, Fujun Luan, Kalyan Sunkavalli, Qixing Huang, et al. Rayzer: A self-supervised large view synthesis model. In ICCV, 2025.
3D 场景表示这件事，听起来像“把世界装进模型里”，实际做起来更像“把一辆卡车塞进电梯”。场景太大、视角太多、细节太杂，传统 3D 结构一上来就很重，生成模型也常常被迫在视图空间里边渲染边造景，结果就是慢、贵、还容易乱。 SceneTok 试图把这件事掰直：先把多视图场景压成一小串无序 token，再让轻量级生成式解码器负责新视角渲染，最后再在这个 token 空间里做场景生成。它的核心不是“再造一个更大的 3D 表示”，而是干脆把 3D 场景变成一个更适合生成模型处理的压缩隐空间。
整套方法分两步：第一步是 SceneTok，把输入视图压缩成 token；第二步是 SceneGen，在 token 空间里直接生成场景。这样做的好处很朴素：渲染和生成不再绑成一团麻花，前者交给轻量解码器，后者交给扩散模型，谁干谁的活，效率就上来了。 
图2：方法总览。SceneTok 先用 VA-VAE 压缩图像，再用 scene perceiver 把多视图信息聚成无序 token；随后，基于 rectified flow 的生成式解码器负责新视角渲染。第二阶段的 SceneGen 则直接在 token 空间里做扩散生成，并可由单张或少量图像和锚点位姿进行条件控制。 
图1：整体设置总览。作者把视图集编码成高度压缩的 token，既能从新轨迹渲染出图，又能在 5 秒内完成潜在空间生成。这个数字很关键，因为它说明 SceneTok 不是只会“压”，而是真的把“压缩”变成了可用的生成接口。 
图3：单个 scene perceiver 模块。它用一组可学习的 scene queries 去和多视图 patch token 交互，再通过 cross-attention 把场景信息收进 token 里。相机位姿不是摆设，而是通过 ray map 和 AdaLN 真正参与条件建模。
下面是龙哥对于大家可能的一些问题的解答： 如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
3D 场景最难的不是“看见”，而是“装得下”。一旦把多视图、位姿、细节、遮挡、不确定性全塞进同一个表示里，模型就很容易变成一台又大又慢的显卡吞噬机。传统 3D 结构有表达力，但训练和生成成本都高；纯视图生成虽然更容易吃到大规模视频数据的红利，却常常把“渲染”和“生成”绑死在一起，每次想看个新角度，都得重新把整套生成流程跑一遍。
SceneTok 的切入点很直接：别再把场景硬塞进 3D 网格或超长 token 序列里了，先把它压成一个无序、可压缩、可扩散的 token 空间，再让后续模型围着这个空间做文章。这样一来，场景表示不再依赖空间网格的排列顺序，生成模型终于能在一个更像“隐空间乐高盒子”的地方工作。
这也是这篇论文最值得注意的地方：它不是单纯把新视角合成做得更准，而是把 3D 场景表示重新定义成了一个适合生成模型处理的接口。对于想把 3D 世界接进大模型、扩散模型或者多模态系统的人来说，这种“先压缩、再生成”的路线，比继续堆更重的 3D 表示要现实得多。
图1：整体设置总览。SceneTok 把视图集编码成高度压缩的 token，再用轻量生成式解码器从新轨迹渲染出图；token 空间还能被扩散模型直接操作，用来做 5 秒级的场景生成。
SceneTok 的方法很像先修地基、再盖房子。第一步是 SceneTok autoencoder，把多视图场景压成少量 token；第二步是 SceneGen，在这个 token 空间里做条件生成。这样拆开以后，渲染和生成不再互相拖后腿：渲染只负责把已有场景还原出来，生成只负责在压缩后的隐空间里“造新场景”。
这里有两个关键缩写得先说清楚。VA-VAE 是 Video Auto-Encoder 的变体，可理解为“视频/图像压缩器”；RoPE 是 Rotary Positional Encoding，负责让 transformer 知道 token 之间的位置信息。
更重要的是，SceneTok 不是把 token 当成“图像 patch 的另一种写法”，而是把它当成一个与空间网格解耦的场景表示。网格表示天然有顺序和结构，但场景本身并不关心 token 排列成什么顺序，只关心这些 token 能不能把场景信息讲明白。于是，SceneTok 的 token 具备了更强的通用性，也更适合后续扩散建模。
图2：方法总览。SceneTok autoencoder 由 VA-VAE 图像压缩器和 scene perceiver 组成，先把多视图压成 token，再用基于 rectified flow 的生成式解码器渲染新视角；SceneGen 则在 token 空间中做扩散生成，并可由单张或少量图像和锚点位姿进行条件控制。
图3：单个 scene perceiver 模块。它由两条分支组成：一条处理多视图 patch token，另一条处理可学习的 scene queries。两条分支通过 self-attention 和 cross-attention 交互，再结合 ray embedding 和 AdaLN，把相机位姿真正注入场景表示里。
SceneTok 的编码器不是简单把图像缩小，而是先把每个输入视图压成低分辨率 latent feature，再通过 scene perceiver 汇聚成一小组连续 token。这里的 trick 在于：token 数量很少，但每个 token 都不是孤立存在，它们通过多视图注意力吸收了相机位姿、视角关系和场景内容。
编码器内部先把相机位姿变成 ray map，也就是每个像素对应的射线原点和方向。然后这些 ray embedding 通过 AdaLN 调制 patch token，再进入多视图 attention。这样做的好处很实际：场景信息不是只靠外观拼接，而是和几何条件绑在一起学，token 更像“懂空间关系的压缩语义”，而不是单纯的图像摘要。
论文还特意讨论了位置编码。它发现，如果把视频里常见的 3D RoPE 直接搬进来，编码器会对输入视图顺序产生“时间偏好”，这会让 token 偏向输入轨迹，后面一旦要渲染偏离原轨迹的新视角，就容易出现不自然的偏置。于是作者选择只用 2D RoPE，让编码器尽量保持顺序无关性。这个选择很朴素，但很对路：3D 场景不是视频时间轴，别硬套。
图13：编码器中 3D RoPE 与 2D RoPE 的对比。3D RoPE 会让后向轨迹的渲染方差更高，说明 token 带上了输入顺序的偏置；2D RoPE 则更接近顺序无关的场景表示，更适合后续从任意轨迹渲染。
解码器这边就更有意思了。SceneTok 不是直接回归一张确定图，而是用 rectified flow 形式的生成式渲染器去采样条件分布。直白点说，token 里信息很清楚的地方，解码器就认真还原；token 里本来就缺信息或者被压缩抹掉细节的地方，解码器允许自己“合理补全”。这比一味追求单点预测更符合 3D 场景的现实：遮挡后的区域本来就不唯一，硬算一个死答案反而容易出错。
解码器的实现也很工程化：先在 latent 空间里做去噪，再用视频解码器把 latent 还原成像素。这样做比直接在像素空间生成便宜得多，特别适合“要渲染很多视角”的场景。论文里给出的结果也说明了这一点：32 张新视图可以在 1 秒内完成渲染，速度已经不是“论文里能看”，而是“真能跑”。
图9：SceneTok 解码器模块。它把 scene tokens 和目标轨迹的 ray map 一起送入 rectified flow 生成器，再由视频解码器还原成图像。这个结构的重点不是“更深”，而是“把不确定性留给生成模型处理”。
训练时，SceneTok 把 VA-VAE 编码器和视频解码器冻结，只训练其余部分，并用 rectified flow matching 目标做端到端优化。这个目标本质上是在 latent 空间里学一个向量场，让噪声样本逐步走向真实样本。它的优点是训练形式干净，和扩散模型的生成逻辑天然兼容；缺点也很现实，最终效果会受到基础视频 VAE 的上限约束，底层压缩器不够强，场景细节就很难凭空长出来。
图8：预训练视频 VAE 对 SceneTok 解码器的影响。换成 WanVAE 后，高频细节更好，说明 SceneTok 的上限部分受制于底层视频 VAE。这个结论不花哨，但很诚实：上游压缩器不行，下游再会补也补不出真细节。
SceneGen 是这篇论文的另一半，也是最容易让人眼前一亮的地方。传统 3D 生成常常要么直接生成 3D 结构，要么在视图空间里一步步扩散，前者太重，后者太慢。SceneGen 选择在 SceneTok 的 token 空间里做生成，相当于把“造景”从大工程改成了“先生成场景骨架，再交给轻量渲染器展开”。
这里的条件输入也很聪明。模型可以只看一张或少量图像，再配上一组 anchor poses，也就是定义场景空间范围的锚点位姿。这样做的好处是，生成不是漫无目的地“凭空画世界”，而是被锚点约束住大致布局和空间尺度。说白了，先告诉模型“房子大概在哪、镜头大概怎么走”，再让它补齐 token 里的内容，效率和可控性都更高。
SceneGen 用的是 diffusion transformer，也就是把 transformer 和扩散建模结合起来做 token 生成。它的训练目标仍然是 rectified flow，这样和上游 SceneTok 的训练范式保持一致。这个统一性很重要：上游学的是压缩表示，下游学的是这个表示的分布，接口对齐以后，整个系统才像一个完整的闭环，而不是两坨勉强拼起来的模块。
图11：场景 token 的 UMAP 分布。室内和室外 token 会自然分簇，说明这个隐空间不是乱糟糟一锅粥，而是已经学到了一定的语义结构。对后续生成来说，这种可分性很有价值，因为扩散模型更喜欢“有规律的空间”，不喜欢完全发散的表示。
更有意思的是，SceneTok 还分析了 token 的不确定性。随着 mask 比例上升，token 里缺失的信息更多，渲染输出的方差也会变大；而当 context views 增加时，token 信息更完整，方差会下降。这个现象说明 SceneTok 的 decoder 不是在“死抠一个答案”，而是在根据可见信息量动态调整生成强度。简单说，知道得多就少猜，知道得少就多补，这才像个正常的生成模型。
图6：遮挡比例与像素方差。随着 mask 比例从 0% 增加到 100%，渲染结果的方差逐渐变大，说明 token 中缺失信息越多，decoder 越需要依赖生成而不是还原。
图8：上下文视图数量与像素方差。上下文视图越多，token 里可用的信息越完整，未观察区域的渲染方差越低，说明 SceneTok 会随着观测增加而变得更“确定”。
先说结论：SceneTok 不是那种“指标全线碾压”的童话型工作，但它确实把两个最难兼得的东西同时往前推了一大步——压缩率和可生成性。这在 3D 场景表示里非常难得，因为很多方法要么表示大得离谱，要么压缩后就只剩“能看个大概”。SceneTok 至少证明了一件事：场景 token 这条路是能走通的。
从实验设置看，论文覆盖了 RealEstate10K、DL3DV 和零样本 ACID，还额外做了轨迹迁移和多视图一致性分析。这个设计比较合理，因为 SceneTok 的卖点不是单一指标，而是“压缩后还能不能真用”。如果只看重建分数，很多大表示方法都能做得很好；但一旦要看新轨迹渲染、跨场景泛化和生成速度，差距就会露出来。
表1：RealEstate10K 上的新视角合成定量比较。SceneTok 在 5 视图和 12 视图设置下都能保持较小表示规模，同时在 PSNR、LPIPS、rFVD 和 rFID 上取得很强的综合表现。更关键的是，它的表示大小只有 32.76K 浮点数，和动辄百万、千万级浮点数的基线相比，压缩优势非常明显。
这张表最值得注意的地方，不是 SceneTok 在某一个指标上“突然封神”，而是它在几乎不牺牲重建质量的前提下，把表示大小压到了一个非常夸张的水平。对生成任务来说，这种压缩比比 PSNR 多抬高 0.2 分更重要，因为扩散模型要吃的是表示复杂度，不是单纯的像素误差。
图4：定性新视角合成对比。基线方法即使没有压缩，也常出现模糊和细节断裂；SceneTok 在少量 token 的前提下，能给出更干净的渲染结果。这个图的意思很直白：不是 token 少就一定糊，关键看 token 里到底装没装对信息。
表2：DL3DV-140 和零样本 ACID 上的比较。SceneTok 在大多数指标上都优于基线，尤其在零样本场景下还能保持较好的泛化，这说明它学到的不是某个数据集的死记硬背，而是更通用的场景表示。
再看轨迹迁移。这个实验很有意思：把一个场景的目标位姿换成另一个场景的轨迹，看看模型能不能跟着新轨迹走。结果显示 SceneTok 的 TPS 指标明显优于 LVSM 和 RayZer，说明它不是只会沿着输入轨迹做插值，而是真的具备一定的“轨迹可迁移性”。这点很重要，因为如果一个 3D 表示只能沿着原轨迹补帧，那它本质上还是视图插值，不是真正的 3D 场景表示。
表3 和表4：轨迹迁移与多视图一致性。SceneTok 在 TPS 上显著优于对比方法，说明它对新轨迹的跟随能力更强；在 MEt3R 上也保持了不错的一致性，说明生成出来的多个视图之间没有明显“前后打架”的问题。
场景生成部分更像是“效率战”。SceneGen 在指标上大体能跟前沿多视图/视频生成方法站在同一梯队，但推理速度明显更快。论文里给出的一个很实在的数字是：SceneGen 在 H100 上生成加渲染总共约 26 秒，而在 RTX 4090 上也能跑到约 10 秒级别。对比那些动辄百秒、千秒甚至直接 OOM 的方法，这个差距非常现实，已经不是“论文好看”而是“工程上能不能活”的区别了。
表5：单视图生成比较。SceneGen 的指标和前沿方法接近，但推理速度明显更快，说明 token 空间确实把生成成本压下来了。它不是细节最华丽的那个，但很可能是最接近“能部署”的那个。
看到这里，最容易冒出来的感受不是“完美”，而是“这事终于有点像样了”。SceneTok 的短板也很明确：它的细节上限仍然受底层视频 VAE 影响，高频纹理和复杂局部结构不一定总能打赢直接像素空间生成的方法；另外，训练成本虽然不算离谱，但也不是轻量级小模型，想拿来直接在普通消费级设备上全流程训练，还是有门槛。
下面是龙哥对于大家可能的一些问题的解答：
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
SceneTok: A Compressed, Diffusable Token Space for 3D Scenes 发表日期:
2026年02月 发表单位:
Max Planck Institute for Informatics, Saarland Informatics Campus 原文链接:
https://arxiv.org/pdf/2602.18882.pdf 开源代码链接:
geometric-rl.mpi-inf.mpg.de/scenetok/
引言
主要参考文献
引言
方法概述
龙迷三问
为什么要把 3D 场景先压成 token，而不是直接在 3D 结构里生成？因为直接在 3D 结构里生成，算力和存储会很快爆表。SceneTok 的思路是把场景变成更小、更规整的隐空间，让生成模型面对的是“少量 token”，不是“整座城”。
它为什么能做新视角渲染，还能处理不确定性？因为解码器不是死记硬背一张图，而是用 rectified flow 按条件分布采样。换句话说，token 里信息足够确定的地方就老老实实还原，信息缺失的地方就允许模型“合理补全”。
这套方法最现实的价值是什么？不是单纯把指标刷高，而是把“重建”和“生成”拆成更容易扩展的两层。对后续做大规模 3D 生成、机器人世界模型、视频到场景表示的人来说，这种 token 空间更像能继续长大的地基。
3D场景的表征困境：为什么需要一个新的Token空间？
SceneTok核心方法：两步走，压缩与生成解耦
第一步：打造“超级压缩器”和“快速渲染器”
第二步：在高度压缩的隐空间中进行场景生成
实验结果：又快又好，但仍有提升空间
龙迷三问
这篇论文到底解决了什么问题？它解决的是 3D 场景表示“太重、太慢、太难生成”的老毛病。SceneTok 先把场景压成少量 token，再把渲染和生成拆开，因此既能做新视角合成，又能在 token 空间里高效生成场景。
SceneTok 里的“diffusable token space”是什么意思？意思是这个 token 空间不是死的编码表，而是可以被扩散/rectified flow 模型直接建模和采样的隐空间。也就是说，token 不只是压缩结果，还是后续生成的工作台。
为什么它能比很多方法更快？因为它把最贵的部分从视图空间搬到了压缩后的 token 空间。生成时先生成少量场景 token，再交给轻量解码器展开，避免了在高维 3D 结构或长视频帧序列里反复做重计算。
龙哥点评
论文创新性分数：★★★★☆
SceneTok 真正新的是“把 3D 场景做成可扩散 token 空间”这件事，而不是单纯把某个模块换皮。这个方向有明显的方法论价值，属于能给后续工作开路的那种创新。实验合理度：★★★★☆
对比方法覆盖了显式表示、潜在表示和生成模型三类路线，指标也同时看重重建、泛化和速度，实验设计比较完整。唯一遗憾是部分结果仍受底层 VAE 影响，说明上限还没完全打开。学术研究价值：★★★★★
它把 3D 场景表示从“重结构”往“轻隐空间”推进了一大步，对未来做世界模型、可控生成和多模态 3D 理解都有启发。稳定性：★★★☆☆
能做新视角渲染，也能处理一定不确定性，但高频细节和边界场景仍受压缩器限制，离“拿来就稳”还有距离。适应性以及泛化能力：★★★★☆
在零样本 ACID 和轨迹迁移上表现不错，说明 token 空间不是只记住训练集。但更复杂、更多样的真实世界场景还需要继续验证。硬件需求及成本：★★★☆☆
训练仍需要多张 A100，推理端倒是明显友好很多，4090 也能跑。属于“训练不便宜、部署开始像样”的路线。复现难度：★★★☆☆
代码已开源是加分项，但整套系统包含压缩器、perceiver、rectified flow 和生成器，工程链路不短，复现还是有一定门槛。产品化成熟度：★★★☆☆
新视角渲染和场景生成都已经有实用雏形，尤其是速度很有吸引力；但要进到稳定产品，还得补细节质量、鲁棒性和跨域验证。可能的问题：最强点是压缩和速度，但细节上限受底层 VAE 牵制，且复杂真实场景的稳定性还需要更多验证。
主要参考文献