视觉几何 · Stage 2 实测
224-linear vs 512-linear · 6 对真实图 · RTX 5060 Ti 16GB · 2026.07
Stage-1 我们确认了:单目深度在 16GB 卡上不是瓶颈,Depth Anything V2 Base 就能稳定出相对深度。
但单目深度没有多视图约束——它不知道 B 视角该怎么和 A 对齐,也给不出真正的三维点。
Stage-2 上场的是 CVPR 2024 的 DUSt3R:输入两张图,直接回归 pointmap(每像素 3D 坐标)+ confidence。同一套 6 对真实图、同一块 RTX 5060 Ti,把 224-linear 和 512-linear 完整跑完,并附上全部真实可视化。

一句话结论:DUSt3R 在 16GB 上非常轻松(峰值约 2GB)。512 比 224 慢约 1.7×,但高置信点数量约 3.4×——要演示/点云质量选 512;要吞吐选 224。building / fire_academy 重建漂亮,cook 几乎失败(大基线场景的真实下限)。
Stage-0 · 2D 匹配(已测)
RoMa v2 / UFM:像素对应 + covisibility
Stage-1 · 单目深度(已测)
Depth Anything V2:相对深度图
Stage-2 · 双视图点云(本篇)
DUSt3R:pointmap + conf,真正的 3D
DUSt3R 的关键想法:不先求位姿再三角化,而是直接回归每张图在同一坐标系下的 3D 点图。下游再用置信度过滤,就能得到可用点云。
项 | 配置 |
|---|---|
GPU | RTX 5060 Ti 16GB |
模型 | DUSt3R ViT-L · 224-linear / 512-linear |
权重 | D:/models/dust3r(各约 2GB) |
数据 | 与 Stage-1 相同 6 real_pairs |
推理 | symmetrized pair · batch=1 · 串行加载 |
指标 | infer_ms / peak_GB / conf>3 占比 / 高置信点数 / 点云 extent / 相对旋转代理 |

图 1 · 224 vs 512 推理耗时与峰值显存
模型 | ms ↓ | GB ↓ | conf>3 | #pts |
|---|---|---|---|---|
224-linear | 298 | 2.02 | 41.8% | 2.1万 |
512-linear | 502 | 2.16 | 41.1% | 7.1万 |
显存几乎不是问题:Large 深度模型 Stage-1 也就 2GB,DUSt3R 同样量级。真正拉开差距的是有效三维点密度——512 平均多出约 3.4 倍高置信点。

图 2 · 分场景高置信覆盖率与点数
pair | 224 conf | 512 conf | 512 pts | 观感 |
|---|---|---|---|---|
building ★ | 93.0% | 87.8% | 17.3万 | 教堂纵深完整 |
fire_academy ★ | 82.7% | 76.1% | 10.6万 | 结构清晰 |
toronto | 35.3% | 27.1% | 5.3万 | 可用但不密 |
bike | 15.5% | 35.4% | 5.2万 | 512 明显更密 |
scene | 24.5% | 20.0% | 3.9万 | 局部可重建 |
cook ✗ | 0.0% | 0.4% | 865 | 基本失败 |
cook 为什么挂:这对图视角/场景变化极大,共视区域很少。DUSt3R 的 conf 几乎全灭——这不是显存问题,是几何可观测性问题。Stage-1 的单目深度仍能各自出图,但跨视角 3D 对不上,正好说明「深度好看 ≠ 能重建」。
以下全部为本机实测导出。
5.1 六场景深度总览(来自 pointmap 的 |XYZ|)

图 3 · 224 vs 512 · View A 深度(低置信区域已置黑)
5.2 building · 最好的一对

图 4 · building · 512:A/B 原图 + conf + depth

图 5 · building 点云:俯视 XY + 侧视 XZ,中殿纵深一目了然
这是本轮最漂亮的结果:置信图完整覆盖主结构,点云侧视能看到从近处长椅到远处祭坛的深度层次。相对旋转代理约 13°,属于合理量级。
5.3 fire_academy / toronto / bike

图 6 · fire_academy · 512

图 7 · fire_academy 点云

图 8 · toronto · 512

图 9 · toronto 点云

图 10 · bike · 512(近景细节,512 点数显著高于 224)

图 11 · bike 点云
5.4 cook · 失败案例(同样重要)

图 12 · cook · 512:conf 几乎全灭,点云无有效结构
把失败案例写进测评,比只晒成功图更有用:它标定了「双视图几何」的适用边界——共视太少时,再大的 foundation model 也变不成魔法。
维度 | Stage-1 DA-V2 | Stage-2 DUSt3R |
|---|---|---|
输入 | 单张图 | 图像对 |
输出 | 相对深度 | 3D pointmap + conf |
显存 | 0.8–1.9 GB | ~2.0–2.2 GB |
耗时 | ~110–340 ms/图 | ~300–500 ms/对 |
大基线 cook | 单图深度仍好看 | 3D 对齐失败 |
building | 深度层次清晰 | 点云结构完整 ★ |
两者不是替代关系:DA-V2 适合「每帧都要深度」的视频/产线;DUSt3R 适合「有重叠的两张图,要三维」的重建/量测。
默认 512-linear
演示、点云导出、结构分析;多 200ms、多 0.1GB 换 3× 有效点,很划算。
吞吐选 224-linear
批量筛场景、先看能不能重建;building/fire_academy 上 224 已经很能打。
上线前先过滤共视
用 RoMa/UFM 的 covisibility 或简单匹配 inlier 做门控,避免 cook 类 pair 浪费算力。
到这里,消费级 16GB 卡上的视觉几何链路已经串起来了:
匹配(RoMa/UFM)→ 深度(DA-V2)→ 点云(DUSt3R)
· 算力不是瓶颈,场景共视与基线才是;
· DUSt3R-512 是本机默认推荐的双视图 3D 引擎;
· 失败案例 cook 提醒我们:流水线要有「能不能重建」的前门控;
VISUAL GEOMETRY · STAGE 2
匹配已测 · 深度已测 · 点云已测
数据与图片均为本机实测