3D 重建老是漏孔、发糊，问题出在"尺子"选错了：浙大和腾讯换掉那把尺，单张照片的重建直接反超

3分钟看懂

一句话先说结论：浙江大学的 3D 视觉团队和腾讯混元一起，把前馈式高斯泼溅（feed-forward 3DGS）里一个长期被忽略的"参照系"换掉了，换来的是同样的模型骨架下更完整的重建结果——论文 11 月 5 日挂上 arXiv，11 月 8 日代码、权重、在线 Demo 一起放开（GitHub 仓库和 Hugging Face 权重仓都是 11 月 8 日建的）。

它叫 SplatAnything，官方定位是自家 InfiniSplat 系列的第三代。

• 谁做的：Hao Yu、Yongzhen Hu、Xiaowei Zhou、Hujun Bao、Sida Peng（浙江大学，Sida Peng 另挂 Causa Robotics），加上腾讯混元的 Zhenwei Wang、Yuning Gong、Junta Wu、Tengfei Wang、Chunchao Guo。
• 解决什么：从几张照片（甚至一张）直接前馈出 3D 高斯场景时，镜头拉远、场景变大，重建结果会漏孔、发糊、比例失真。
• 差异点：不是加参数、不是加数据，而是换掉预测高斯属性时用的归一化空间。

先说清楚：前馈 3DGS 到底在干什么

传统 3DGS 要"一个场景训练一次"：拍几百张照片、算相机位姿、跑几十分钟优化。前馈式方法是另一条路——训练一个网络，喂进照片，一次前向就吐出整片高斯点云，不用针对新场景再训练。

好处很直白：快、能批量、能进产品。代价也很直白：网络是在"某种尺度感"下学会预测高斯点的位置和大小的，一旦新场景的尺度、相机配置跟训练分布对不上，预测就开始偏。

问题是"尺子"，不是"手"

论文指出的毛病，用生活化的话讲是这样：

网络要给每个像素预测一个高斯点，包括它的大小。可"大小"是个相对量，得先有个参照。现有主流做法是拿到相机的距离做参照（论文里叫径向距离归一化，RDNorm）：离相机 2 米的地方，高斯点该多大，用一个全局尺度把它标准化。

听起来合理，但真正决定画面会不会漏孔、会不会糊成一片的，不是"这个点离相机多远"，而是"隔壁那个高斯点离它多远"——也就是高斯间距。

于是出现一个很别扭的局面：两块看起来差不多的画面区域，因为场景尺度不同、相机配置不同，实际的高斯间距差了好几倍，但网络被要求给它们同一个"标准答案"。监督信号本身就自相矛盾，网络只能学出一个折中值，结果就是小物体上漏孔、大场景里过度平滑。

GSNorm：把"隔壁有多远"当标尺

作者提出的做法叫 Gaussian Spacing Normalization（GSNorm）：不再用相机距离当基准，而是先算这个场景里高斯间距的一个稳健统计量（中位数），用它把整个场景换算到统一的尺度，然后再预测高斯属性。

关键在"预测之前"这一步：先把尺子校准，再让网络去画。

论文的消融实验把这件事讲得很清楚（8 个输入视图，DISTS 越低越好）：

• 径向距离归一化：0.223
• 径向距离归一化 + 事后按中位间距缩放：0.252（更差）
• GSNorm：0.196

第二行最值得看。它说明"网络预测完再乘个系数修正"这种补救思路是无效的——甚至更差。因为歧义在监督信号里，不在输出端。这一点跟工程直觉相反，也是这篇论文最有说服力的地方。

数字：赢了大多数，但不是全部

评测铺得比常见做法宽：7 个数据集（ScanNet、NRGBD、DL3DV、Tanks and Temples、Mip-NeRF 360、ETH3D、DTU），输入视图从 1 张到 64 张，输入与目标视角的重叠度被刻意压在 0.2–0.6（重叠越低越难），分辨率覆盖约 480p 到 1K。

单图输入、不给相机位姿，看感知指标 LPIPS（越低越好）：

• ScanNet：0.207，次优 Mirror2-GS 是 0.222
• DTU：0.483，次优 0.617
• Tanks and Temples：0.299，次优 0.338
• ETH3D：0.049，输给 YoNoSplat 的 0.033

最后一条要留着。任何"全面领先"的说法都不该出现在这篇的转述里——它在 ETH3D 上确实没赢。

速度方面，官方给的是单张 H20、BF16、batch=1 的中位前向延迟：4 视图 411 毫秒、8 视图 761 毫秒、16 视图 1649 毫秒、64 视图 11037 毫秒。同设置下 DA3-GS 在 64 视图要 35904 毫秒，QuerySplat 要 39583 毫秒。

怎么用

仓库给了很直接的入口，两种模式：

• --mode rgb：只给照片，让模型自己预测相机位姿（会自动忽略目录里的相机文件）
• --mode pose：已经在场景目录里放好 prior_camera.json，用已知位姿和内参

python inference.py --input_path examples/object --mode rgb --output_path outputs/object/rgb

几个必须知道的默认值：

• 默认分辨率 756×756，宽高必须是 14 的倍数（可用 --resolution W H 改，支持 1K 以上）
• 输出包括 gaussians.ply、points.ply、相机、RGB 和深度
• 想去掉天空要额外开 --sky_seg，并准备一个 skyseg 的 ONNX 模型
• 另有两条应用线：Rig-Recon（自动驾驶多相机环视，示例一次重建 150 路视角，504×504）和 Pano-Recon（一张 360° 全景先拆成 24 张透视，再走同一套推理）

成本与门槛

• 权重体积：主模型 SplatAnything.ckpt 11.33 GB，几何主干 worldmirror2.safetensors 5.05 GB，天空分割 skyseg.onnx 0.18 GB，合计约 16.6 GB。
• 训练成本：64 张 H20、20000 步、输入 4–32 视图、分辨率 504–1024 动态变化。这是实验室级别的量，个人复现训练不现实。
• 推理显存：官方未说明。别按"一张 24GB 消费卡稳跑"去宣传，权重放得下不等于激活放得下。
• 许可：不是 Apache/MIT，是腾讯 HunyuanWorld-Mirror 社区协议。要点有三条——地域上排除欧盟、英国和韩国；月活超过 100 万要单独向腾讯申请商业授权；分发要带协议副本和 Notice 文件。

适用场景与不适用场景

适合谁：

• 做机器人导航、自动驾驶环视、AR/VR 全景的团队：要的是"多相机/全景进、连贯高斯场景出"的批量管线，且能接受社区协议
• 游戏与数字孪生场景的前期重建：先出可探索的高斯场景，再决定哪里补传统建模
• 研究团队：这套"归一化空间影响监督歧义"的分析框架可以迁到别的 3D 表示上

哪些人不适合：

• 要"一张图出一个能直接进 Unity 的干净网格"的人——这是高斯泼溅，不是网格生成，输出是 splat 不是拓扑规整的模型
• 需要无地域限制商用的人——欧盟、英国、韩国不在授权区域内
• 只有一张消费级显卡、希望开箱即用的人——16.6 GB 权重 + 未公布的显存需求，门槛不低
• 想要"在线点一下就出片"的人——HF Space 能用，但上传自己的图会把分辨率压到 896×896 以内

避坑

• 位姿模式最容易踩的坑：--mode pose 会先检查 prior_camera.json，缺失直接报错；而 --mode rgb 会无视这个文件，即使你放对了也不用。别一边改相机文件一边用 rgb 模式debug。
• 分辨率别乱填：必须是 14 的正整数倍。上传自己的图时，宽高会被"上传图片里最小的对应边"再向下取整到 14 的倍数，所以 800×600 会变成 798×588，别以为是 bug。
• 别把"事后缩放"当补丁：论文已经证明这条路更差（DISTS 0.223 → 0.252）。
• 别把系列搞混：站内 8 月发过的 InfiniSplat 是这一系的 v1，做的是"像素对齐改表面对齐"；这次 v3 换的是归一化空间，两个不同的技术点。
• 别漏看许可：仓库里叫 License.txt，是社区协议不是标准开源协议；NOASSERTION 在 GitHub 上就是这么显示的，不是"没写许可"。

行动建议

第一步，别急着下权重。先打开 Hugging Face 上那个 Gradio Demo，用你自己手机拍的 3–5 张同一场景照片跑一遍，看两件事：视角拉开后有没有漏孔，边缘细节有没有糊。这两点正是这篇论文声称解决的问题，也是最容易被"演示视频滤镜"掩盖的地方。

第二步，如果效果成立，再评估许可。欧盟、英国、韩国的团队，或者月活接近百万的产品，现在就该去问授权，而不是等接进产品线才发现不能用。

第三步，把它当成"重建管线里的一个环节"，而不是终点。输出的 gaussians.ply 要进你的渲染器或引擎，中间还有坐标系、缩放、合并（仓库里有 voxel merge 的说明）这些活要干。

参考来源

https://arxiv.org/abs/2611.08264

https://github.com/zju3dv/SplatAnything

https://zju3dv.github.io/SplatAnything/

（本文技术数据取自论文正文与仓库文件；媒体侧跟进报道包括 AI Weekly 11 月 9 日、Blockchain.News 11 月 10 日，相关背景基于多家媒体转述整理。）