公里级场景也能稳住了，国产团队把长视频3D重建又往前推了一步

长视频 3D 重建最怕的，其实不是 "看不清"。

前面几十帧拍得再好，序列一拉长，轨迹就开始慢慢歪。模型在短片段上表现还行，但让它一口气吃掉几百上千帧，误差会一段接一段往后累。到了公里级大场景，这个问题被放得非常大。

浙江大学、地平线机器人和之江实验室最近的新工作Scal3R，要解决的就是这件事。

以往做长序列重建，大家主要在 "怎么切块、怎么拼回去" 上做文章。

Scal3R 则更进一步关注问题本质：推理时要处理超长序列，训练时也应该让模型见过超长序列。作者借助 test-time training 技术，设计了一个全局上下文模块和同步机制，将长序列训练、推理以及跨 chunk 的信息更新放进同一个流程里，大幅提升了长序列重建的稳定性和精度。

Scal3R 能够处理超万帧几千米的超大规模场景三维重建，输出精确的相机位姿和点云，下面是真实拍摄浙大紫金港校区的重建效果：

视频链接：https://mp.weixin.qq.com/s/Yi8AMQ3BxcTCLUDlzvLlcg

和 Depth Anything 3（Streaming 模式）的可视化对比：

视频链接：https://mp.weixin.qq.com/s/Yi8AMQ3BxcTCLUDlzvLlcg

论文 Scal3R: Scalable Test-Time Training for Large-Scale 3D Reconstruction 已上线 arXiv，代码和模型权重分别发布在 GitHub 和 Hugging Face 平台：

• 论文链接：https://arxiv.org/abs/2604.08542
• 论文主页：https://zju3dv.github.io/scal3r/
• 代码仓库：https://github.com/zju3dv/Scal3R
• 模型地址：https://huggingface.co/xbillowy/Scal3R

超大规模场景重建问题在哪

这两年 VGGT 这类前馈式 3D foundation model 已经能直接从 RGB 估计相机参数、深度和点云，精度相当不错。

但场景一变大、序列一拉长，麻烦就来了。

一方面，Transformer 的长序列建模本身就贵，计算和显存都会飞涨。

另一方面，很多方法训练和测试时面对的序列形态根本对不上。训练通常喂短序列或局部窗口，测试却要求模型吞几百帧甚至上千帧，这种错位会把长程漂移放大。

目前应对长序列大致有两条路。

一条是压缩 token，把更长序列硬塞进模型。确实能省一些计算，但细节和长程依赖也容易跟着被压掉。

另一条是 chunk-based 路线：先切成多个重叠片段各自重建，再做跨块对齐。这条路比较实用，扩展性也好，只是前提是每一块的局部几何预测要够准，否则块间误差会继续被放大。

所以问题的重点并不是 "怎么处理长序列"，而是怎么让模型训练时就学会处理长序列，再用同一套机制在测试时稳住局部几何和全局一致性。

Scal3R 是怎么做的

Scal3R 是在 VGGT 的视觉几何能力上往前走的。局部几何依然重要，Scal3R 没打算绕开它，只是希望这份能力在长序列训练和长序列推理里以一致方式被使用。

作者的想法很直接：要让模型测试时稳住长视频，就不能只拿短片段训练然后指望它自然泛化到长序列。所以 Scal3R 借助 test-time training 相关机制，把长序列训练、长序列推理以及跨 chunk 的信息更新放进同一个流程里

Scal3R 的整体框架。输入长序列首先被切成多个重叠 chunk 并行处理，训练和推理都围绕长序列展开，并通过测试时更新与跨 chunk 同步提升大规模场景重建的一致性。

围绕这个思路，论文给出了两个核心模块。

一个是全局上下文记忆模块（Global Context Memory，GCM）。

它由若干自适应存储单元（Adaptive Memory Units）组成，可以当成一组轻量的、可更新的上下文模块。每处理完一个 chunk，模型会通过自监督目标更新这些单元。GCM 在这里起两个作用：一是跨 chunk 累积并保留上下文信息；二是让训练和测试阶段用同一套逐 chunk 更新方式，模型从训练第一步起就在适应长序列。

另一个是全局上下文同步机制（Global Context Synchronization，GCS）。

GCM 管逐 chunk 更新和上下文累积，GCS 负责把这些更新在不同 chunk 之间同步起来，使用 PyTorch DDP 的 all-reduce 机制，在不同的 chunk 之间同步自适应存储单元的自监督梯度。

Scal3R 处理长序列时会把它切成多个重叠 chunk，分配到不同 GPU 上并行跑。GCS 让这些 chunk 的更新彼此同步，不管训练还是推理，整个长序列机制都是一致的，不会出现训练时学局部、测试时临时拼一下的情况。

关键的点是，作者并没有把 test-time training 当成测试阶段的临时补丁，而是把它变成支撑长序列训练和长序列推理对齐的一种方式；GCM/GCS 则在这种长序列机制里做更新、保留和同步。

为什么 Scal3R 的做法可以稳住长序列

长序列重建里最棘手的情形，经常不是 "看不见"，而是局部都能看懂、时间跨度一长就不一定稳得住。

大尺度室外场景里的重复纹理、长距离视角变化、稀疏采样、长走廊、回环闭合 —— 每一项都在考验局部几何预测的鲁棒性。局部块必须先算得准，跨块同步和长程约束才有意义；否则局部误差会顺着整条序列一路被放大。

Scal3R 的价值就在这里。

它没有把长视频简单切开再拼回去，而是让模型在训练阶段就反复经历 "长序列 + 逐 chunk 更新 + 跨 chunk 同步" 的完整过程。等到测试时，模型遇到的行为模式和训练时是一样的。

这时 memory 的角色就清楚了：GCM 不替代局部几何预测，只是在逐 chunk 训练和推理里提供一份可更新的上下文状态，把前后 chunk 的信息接起来 —— 前提依然是局部几何得可靠。

所以 Scal3R 重要的地方不在削弱局部几何，而在把局部几何、可更新上下文、长序列训练、测试时同步这四件事放到同一个框架里。

一，长序列被拆成 chunk 来算。这把原本随序列长度平方增长的计算压力摊平了。按论文里的视角，全序列注意力的复杂度会随长度快速上升，chunk-wise 处理则把问题改写成更可控的局部计算，再通过融合扩展到整段序列。

二，不是简单分块，而是逐 chunk 更新、再做同步。很多分块方法块和块之间是割裂的，算完就算完了。Scal3R 会在每个 chunk 上算可更新模块的变化，再由 GCS 把这些更新在 chunk 之间同步起来。网络虽然按块处理，但训练和测试时都在学习怎么把局部结果放回长序列里。

三，训练时就直接面向长序列。论文里讲得比较清楚：训练阶段会直接采样连续长序列，再用不同 GPU 分组去覆盖不同的有效序列长度。TTT 在这里更像是一种手段 —— 让长序列训练可行，也让测试行为和训练行为保持一致。

这三条合起来就能解释为什么 Scal3R 不止是 "能跑长序列"，而是在长序列上把局部几何质量、效率和整体一致性都稳住了。

在基准测试上的效果

论文从相机位姿和三维重建两部分做了比较完整的评估，覆盖室内外和不同尺度的场景，结果显示提升很扎实。

论文主表中的位姿与资源对比，覆盖 VKITTI2、KITTI Odometry 和 Oxford Spires。

相机位姿估计：表里 baseline 大致可以分成三类。SLAM / SfM 方法在条件合适时很准，比如 COLMAP 在 Oxford Spires 上很强，DPVO++ 在 VKITTI2 上误差也低；但它们要么需要内参，要么速度慢，在资源统计中，COLMAP 平均一次推理要 6614.73 秒。前馈和 streaming 方法更快，但长序列漂移压不住，FastVGGT 还会遇到显存问题。最接近的对照是 VGGT-Long：它比不少 streaming baseline 稳，但 KITTI 上 ATE / RTE / RRE 仍是 25.94 / 9.67 / 1.71，而 Scal3R 是 14.55 / 4.61 / 0.97；Oxford Spires 上也从 15.46 m 降到 4.45 m。

大规模多场景轨迹对比。蓝线是预测轨迹，红色虚线是真值轨迹。

轨迹图更直观：KITTI 00 上 Scal3R 的 ATE 是 4.298，VGGT-Long 是 8.637；Oxford Keble 04 和 Oxford Quarter 01 上 ATE 分别是 2.448 和 1.624。蓝线基本能贴住真值轨迹，其他方法更容易漂成局部团块。

再看三维重建精度

三维重建点云评测，指标为 Chamfer Distance（越低越好）和 F1（越高越好）

这张表更直接。Scal3R 在 ETH3D、Oxford Spires、VKITTI2 三个数据集上六个指标都是最优：ETH3D 是 0.11 / 0.91，Oxford Spires 是 0.96 / 0.96，VKITTI2 是 0.40 / 0.91。对比最强的 VGGT-Long，ETH3D 从 0.24 / 0.84 提到 0.11 / 0.91；Oxford Spires 从 3.41 / 0.80 提到 0.96 / 0.96；VKITTI2 则从 1.78 / 0.70 提到 0.40 / 0.91。这里的差距不只是局部几何更准，也和前面的位姿稳定性有关：轨迹一旦漂了，后面拼出来的点云通常也会散。

重建对比图，展示 Oxford Keble 04 和 ETH3D Terrains 等场景。

定性图也对得上表格。像 Oxford Keble 04 这种大尺度校园场景，Scal3R 的建筑轮廓和庭院结构更完整；ETH3D Terrains 红框里的墙面和门框边界也更规整。FastVGGT、VGGT-Long、TTT3R 在不同场景里会出现局部破碎、漂散或者结构发糊，原因往往不是某一帧深度错了，而是长序列位姿和局部几何没有一起稳住。

精度之外再看下资源和扩展性。Scal3R 可以在单张 RTX 4090 上完成推理，它不是吞吐最快的方案，但在精度、长序列稳定性和可扩展性之间做了一个比较实用的取舍。补充材料里还分析了随序列变长的趋势：从 150 帧涨到 990 帧，整体运行时间基本呈线性增长，相对位姿误差则稳在 0.07 到 0.08 m，说明它不是只适配某个固定长度。

结语

Scal3R 最值得留意的地方，不只是又做出来一个更强的长序列 3D 重建方法，而是它把问题的重点重新摆过一遍。

它没有把 "大规模 3D 重建" 简单理解成更大的 backbone、更多 token 或者更激进的压缩，而是问了一个更靠前的问题：模型要想在测试时吞下长序列，训练时是不是也得先真正学过长序列？

顺着这个视角往下看，Scal3R 提出的其实不只是一个记忆模块，更像是一种把局部几何、可更新上下文、长序列训练和测试时同步串起来的思路。对 3D 重建如此，搬到更广泛的长视频场景理解任务上，可能也差不多。

如果你正在关心这几件事 —— 长视频怎么做高质量 3D 重建；foundation model 怎么扩展到公里级场景；test-time training 除了语言和分类任务，还能怎么真正落到 3D 视觉里 —— Scal3R 值得花点时间细读。

视频链接：https://mp.weixin.qq.com/s/Yi8AMQ3BxcTCLUDlzvLlcg