公里级场景也能稳住了，国产团队把长视频3 D重建又往前推了一步
长视频 3D 重建最怕的，其实不是 "看不清"。
前面几十帧拍得再好，序列一拉长，轨迹就开始慢慢歪。模型在短片段上表现还行，但让它一口气吃掉几百上千帧，误差会一段接一段往后累。到了公里级大场景，这个问题被放得非常大。
浙江大学、地平线机器人和之江实验室最近的新工作 Scal3R ，要解决的就是这件事。
以往做长序列重建，大家主要在 "怎么切块、怎么拼回去" 上做文章。
Scal3R 则更进一步关注问题本质： 推理时要处理超长序列，训练时也应该让模型见过超长序列 。作者借助 test-time training 技术，设计了一个全局上下文模块和同步机制，将长序列训练、推理以及跨 chunk 的信息更新放进同一个流程里，大幅提升了长序列重建的稳定性和精度。
Scal3R 能够处理超万帧几千米的超大规模场景三维重建，输出精确的相机位姿和点云，下面是真实拍摄浙大紫金港校区的重建效果：
和 Depth Anything 3（Streaming 模式）的可视化对比：
论文 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 不止是 "能跑长序列"，而是在长序列上把局部几何质量、效率和整体一致性都稳住了。
在基准测试上的效果
论文从相机位姿和三维重建两部分做了比较完整的评估，覆盖室内外和不同尺度的场景，结果显示提升很扎实。