LingBot-Map双向scale帧是什么为什么推理前需要8帧标定【免费下载链接】lingbot-mapA feed-forward 3D foundation model for reconstructing scenes from streaming data项目地址: https://gitcode.com/GitHub_Trending/li/lingbot-mapLingBot-Map是一个流式 3D 重建基座模型逐帧输入视频画面实时输出相机位姿与 3D 点云。它最核心的机制就是双向 scale 帧bidirectional scale frames——推理开始前先把前 8 帧作为一个整体做双向注意力处理为整个序列标定出全局尺度后续所有帧再在这个尺度基准上因果流式推理。本文带你读懂这套8帧标定的设计。一、先搞清楚scale 帧在重建中负责什么单目/视频 3D 重建有一个天生理亏尺度不可观。模型只能告诉你这栋楼相对那张桌子有多大却答不出1 个单位等于多少米——位姿、深度、点云都可能被整体放大或缩小。流式推理还会带来第二个问题逐帧因果推理时每一帧只能看到过去早期的位姿误差会像雪球一样越滚越大漂移。LingBot-Map 的答案是用序列最前面的若干帧做标定锚这就是scale 帧num_scale_frames默认8。二、双向指的是双向注意力推理分两个阶段见 lingbot_map/models/gct_stream.py阶段 1scale 帧阶段——前 8 帧被当作一个 block 一次性送入模型num_frame_per_blockscale_frames。这 8 帧之间互相可见是双向注意力第 1 帧能看到第 8 帧第 8 帧也能看到第 1 帧。阶段 2流式阶段——第 9 帧起逐帧推理只能看过去因果注意力 KV cache此时 KV cache 中已包含被标定的 scale 帧上下文。对比一下就很直观普通逐帧推理里每帧只能单向看前帧8 帧 scale 阶段是整条序列里唯一一段全知窗口。注意力掩码的实现就在 lingbot_map/layers/attention.py前num_frame_for_scale帧之间被强制打开全连接global attention for the first num_frame_for_scale frames且所有后续帧都可以回头关注这 8 帧。三、为什么 scale 帧要常驻KV cache在分页 KV cache 的内存管理里lingbot_map/layers/flashinfer_cache.py缓存页分两类普通帧的 KV 页 → 滑动窗口淘汰默认只保留最近 64 帧见 _kv_cache_sliding_window: 64 scale 帧的 KV 页 → 永不驱逐never evicted这意味着无论你推理到第 5 万帧每一帧仍然可以回头关注最初的 8 帧。它们承担三重职责全局尺度基准所有深度/点云输出都与这个基准对齐尺度不会中途漂移锚点上下文anchor context配合轨迹记忆抑制长序列累积漂移25000 帧室内长序列见 README.md 的 Featured 示例能保持整体闭环滑窗推理的衔接带--mode windowed下相邻窗口之间的重叠帧就是下一个窗口的 scale 帧用双向注意力获得最高质量预测保证跨窗口位姿对齐lingbot_map/models/gct_stream_window_v2.py。window_size也是按槽位计的128 个槽位里前 8 个留给 scale 帧剩下 120 个才是关键帧。四、为什么恰好是 8 帧帧数后果太少如 1~2覆盖的基线太短尺度估计噪声大标定不稳8默认基线足够长、信息多样同时把阶段 1 的激活内存峰值控制在可接受范围太多阶段 1 一次性处理更多帧显存峰值更高KV 常驻页更多8 是标定质量与显存占用之间的平衡点也是模型训练时的设定配置见 benchmark/configs/methods/lingbot_map.yaml_num_scale_frames: 8。五、8 帧标定不够用显存吃紧可以调小显存紧张时README.md 给了一个明确的急救开关——把双向 scale 帧从 8 降到 2直接压低初始 scale 阶段的激活峰值python demo.py --model_path /path/to/lingbot-map.pt \ --image_folder example/courthouse --mask_sky \ --num_scale_frames 2⚠️ 代价是尺度标定变弱长序列漂移可能更明显短序列、显存吃紧场景下性价比最高。其他两个值得了解的参数--keyframe_intervalscale 帧之后每 N 帧取 1 帧作为关键帧存入 cache非关键帧照常出预测可把 cache 占用降到约 1/N适合 320 帧的长序列--camera_num_iterations相机头迭代精修次数默认 4调到 1 可提速但损失少量位姿精度。六、想实测各阶段的耗时仓库提供了性能剖析脚本 gct_profile.py它会单独打印Phase 18 个 scale 帧的双向阶段耗时以及流式阶段 10%/50%/90% 进度处的帧耗时与 FPS很适合用来验证 scale 阶段在总耗时中的占比python gct_profile.py --backend flashinfer --dtype bf16 --compile总结概念一句话解释scale 帧序列最前面的 8 帧一次性双向处理负责标定全局尺度双向注意力scale 帧之间互相可见是流式因果推理前的唯一全知窗口常驻 KV cachescale 帧的缓存永不驱逐供之后所有帧持续回看抑制漂移8 帧的原因标定质量与显存峰值的平衡点显存不足可用--num_scale_frames 2降级理解了先双向标定、再因果流式这条主线LingBot-Map 的流式重建框架anchor context / pose-reference window / trajectory memory基本就通透了 ️【免费下载链接】lingbot-mapA feed-forward 3D foundation model for reconstructing scenes from streaming data项目地址: https://gitcode.com/GitHub_Trending/li/lingbot-map创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LingBot-Map双向scale帧是什么？为什么推理前需要8帧标定
LingBot-Map双向scale帧是什么为什么推理前需要8帧标定【免费下载链接】lingbot-mapA feed-forward 3D foundation model for reconstructing scenes from streaming data项目地址: https://gitcode.com/GitHub_Trending/li/lingbot-mapLingBot-Map是一个流式 3D 重建基座模型逐帧输入视频画面实时输出相机位姿与 3D 点云。它最核心的机制就是双向 scale 帧bidirectional scale frames——推理开始前先把前 8 帧作为一个整体做双向注意力处理为整个序列标定出全局尺度后续所有帧再在这个尺度基准上因果流式推理。本文带你读懂这套8帧标定的设计。一、先搞清楚scale 帧在重建中负责什么单目/视频 3D 重建有一个天生理亏尺度不可观。模型只能告诉你这栋楼相对那张桌子有多大却答不出1 个单位等于多少米——位姿、深度、点云都可能被整体放大或缩小。流式推理还会带来第二个问题逐帧因果推理时每一帧只能看到过去早期的位姿误差会像雪球一样越滚越大漂移。LingBot-Map 的答案是用序列最前面的若干帧做标定锚这就是scale 帧num_scale_frames默认8。二、双向指的是双向注意力推理分两个阶段见 lingbot_map/models/gct_stream.py阶段 1scale 帧阶段——前 8 帧被当作一个 block 一次性送入模型num_frame_per_blockscale_frames。这 8 帧之间互相可见是双向注意力第 1 帧能看到第 8 帧第 8 帧也能看到第 1 帧。阶段 2流式阶段——第 9 帧起逐帧推理只能看过去因果注意力 KV cache此时 KV cache 中已包含被标定的 scale 帧上下文。对比一下就很直观普通逐帧推理里每帧只能单向看前帧8 帧 scale 阶段是整条序列里唯一一段全知窗口。注意力掩码的实现就在 lingbot_map/layers/attention.py前num_frame_for_scale帧之间被强制打开全连接global attention for the first num_frame_for_scale frames且所有后续帧都可以回头关注这 8 帧。三、为什么 scale 帧要常驻KV cache在分页 KV cache 的内存管理里lingbot_map/layers/flashinfer_cache.py缓存页分两类普通帧的 KV 页 → 滑动窗口淘汰默认只保留最近 64 帧见 _kv_cache_sliding_window: 64 scale 帧的 KV 页 → 永不驱逐never evicted这意味着无论你推理到第 5 万帧每一帧仍然可以回头关注最初的 8 帧。它们承担三重职责全局尺度基准所有深度/点云输出都与这个基准对齐尺度不会中途漂移锚点上下文anchor context配合轨迹记忆抑制长序列累积漂移25000 帧室内长序列见 README.md 的 Featured 示例能保持整体闭环滑窗推理的衔接带--mode windowed下相邻窗口之间的重叠帧就是下一个窗口的 scale 帧用双向注意力获得最高质量预测保证跨窗口位姿对齐lingbot_map/models/gct_stream_window_v2.py。window_size也是按槽位计的128 个槽位里前 8 个留给 scale 帧剩下 120 个才是关键帧。四、为什么恰好是 8 帧帧数后果太少如 1~2覆盖的基线太短尺度估计噪声大标定不稳8默认基线足够长、信息多样同时把阶段 1 的激活内存峰值控制在可接受范围太多阶段 1 一次性处理更多帧显存峰值更高KV 常驻页更多8 是标定质量与显存占用之间的平衡点也是模型训练时的设定配置见 benchmark/configs/methods/lingbot_map.yaml_num_scale_frames: 8。五、8 帧标定不够用显存吃紧可以调小显存紧张时README.md 给了一个明确的急救开关——把双向 scale 帧从 8 降到 2直接压低初始 scale 阶段的激活峰值python demo.py --model_path /path/to/lingbot-map.pt \ --image_folder example/courthouse --mask_sky \ --num_scale_frames 2⚠️ 代价是尺度标定变弱长序列漂移可能更明显短序列、显存吃紧场景下性价比最高。其他两个值得了解的参数--keyframe_intervalscale 帧之后每 N 帧取 1 帧作为关键帧存入 cache非关键帧照常出预测可把 cache 占用降到约 1/N适合 320 帧的长序列--camera_num_iterations相机头迭代精修次数默认 4调到 1 可提速但损失少量位姿精度。六、想实测各阶段的耗时仓库提供了性能剖析脚本 gct_profile.py它会单独打印Phase 18 个 scale 帧的双向阶段耗时以及流式阶段 10%/50%/90% 进度处的帧耗时与 FPS很适合用来验证 scale 阶段在总耗时中的占比python gct_profile.py --backend flashinfer --dtype bf16 --compile总结概念一句话解释scale 帧序列最前面的 8 帧一次性双向处理负责标定全局尺度双向注意力scale 帧之间互相可见是流式因果推理前的唯一全知窗口常驻 KV cachescale 帧的缓存永不驱逐供之后所有帧持续回看抑制漂移8 帧的原因标定质量与显存峰值的平衡点显存不足可用--num_scale_frames 2降级理解了先双向标定、再因果流式这条主线LingBot-Map 的流式重建框架anchor context / pose-reference window / trajectory memory基本就通透了 ️【免费下载链接】lingbot-mapA feed-forward 3D foundation model for reconstructing scenes from streaming data项目地址: https://gitcode.com/GitHub_Trending/li/lingbot-map创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考