TideGS 把”显存”踢出三维重建的瓶颈
arxiv 编号 2605.20150 的论文 TideGS: Out-of-Core Streaming for Billion-Scale Gaussian Splatting 在 5 月 21 日上线，第一作者为浙江大学计算机学院的邵凯祺，合著者来自浙大 CAD&CG 实验室与香港中文大学（深圳）。论文的核心结论是：在一张 RTX 4090（24GB 显存）上跑通了 12 亿个高斯点的场景重建，对比 3DGS 原版在同一张卡上的上限——大约 800 万到 1500 万高斯点——是两个数量级的跳跃。
原版 3DGS 为什么撞墙
从 2023 年 Inria 的 3D Gaussian Splatting 横空出世到现在，工程界一直被一个数字卡住：高斯点数量。每个高斯点要存位置、协方差、颜色、不透明度，加上反向传播时的梯度缓存，一个高斯点在 fp32 下大致占用 248 字节。一张 24GB 卡留给优化的可用显存大概 18GB，硬切出来上限就是 7700 万个点；考虑到 Adam 状态、激活值、渲染中间张量，实际可跑的规模是上限的五分之一到三分之一。要重建一座大教堂、一个工业园区、一段几公里长的街景，七千万个点远远不够——常见做法是把场景切分多个子模型分别训练，再做后处理融合，效果牺牲很大。
TideGS 的破题思路不是压缩高斯点（Sparse-GS、LightGS 这一系都在压），而是把高斯点搬到系统内存（DRAM）和 NVMe SSD 上，按”当前视角看到哪一块”动态把对应的子集流入显存做计算。论文里把这套调度叫”潮汐式 swap”，做了三件关键工程：第一，按八叉树空间划分把高斯点 tile 化，单 tile 平均 200 万点；第二，预测下一帧需要的 tile 集合，提前 2 帧异步 prefetch；第三，反向传播阶段把 tile 内的梯度先在显存累积、再批量回写 DRAM。
三个被同行拿出来反复讨论的数据
论文实验台是 RTX 4090 + 64GB DDR5 + 4TB NVMe SSD（PCIe 4.0），重建场景选了 ScanNet++、MatrixCity 以及作者自采的浙江大学紫金港校区航拍数据集（约 4.2 平方公里）。第一个数字是规模——紫金港数据集跑出 12.3 亿高斯点，PSNR 28.7dB，比基线 Hierarchical 3DGS（同卡跑 1.8 亿点）高 3.1dB。第二个数字是吞吐——TideGS 训练步骤平均比纯 GPU 方案慢 1.4 倍，但因为不需要分块独立训练，端到端时间反而少 35%。第三个数字是显存占用——12 亿点场景在显存里的常驻峰值只有 11.2GB，剩下都在 DRAM 和 SSD 上。
香港中文大学（深圳）林伟院教授作为通讯作者在论文 release 后做了一段简短的视频说明：”我们没有发明任何新的高斯点形式，只是承认了一件被工程师集体回避的事情——显存瓶颈是个调度问题，不是算法问题。把这件事用 PyTorch 的自定义 allocator 加 CUDA stream 解掉，比再发明一种压缩高斯点更直接。”这种把”重建质量”和”工程工艺”分开看待的态度，跟前几年这条赛道堆 trick 的风气有比较明显的差别。
同行评价偏向务实
NVIDIA Research 的 Karol Myszkowski 在 X 上转发时给的评价比较克制：”TideGS 的成绩在专业图形圈里是预料之中——out-of-core 在离线渲染领域已经做了三十年。它的工程价值在于把这套技术扎进了 PyTorch 训练栈，这一步以前没人做完。”另一位评价者是上海 AI Lab 的研究员李慧霞，她指出了一个 limitation：”论文的 prefetch 假设视角变化是连续的，自由视角生成（NVS）任务能跑，但是机器人 SLAM 的剧烈视角抖动会让 prefetch 击穿，效率会掉一半。这条路对消费级桌面应用更友好，对实时机器人感知不直接适用。”
开源版本同步放在 GitHub（zju-cs-cg/TideGS），首发版本是 PyTorch 扩展加 CUDA kernel，依赖 NVIDIA RAPIDS 的 RMM allocator。仓库 24 小时内拿到 1.4k star，issue 区集中在两个问题——AMD GPU 是否支持（目前 No，因为依赖 NVIDIA 私有的 unified memory 行为）、训练完成后的高斯点资产是否能直接给 Unreal Engine 5 用（论文给了一个转换脚本，但只支持 UE 5.4 以上）。
三维重建从”算法竞赛”切回”系统工程”
过去三年 Gaussian Splatting 的进展几乎都在算法层——更稀疏的表征、更智能的密化、更鲁棒的初始化。TideGS 把这条线拉回到系统层，承认了一个朴素事实：训练栈的内存调度是 DL 框架几年前就跨过的事情，但是图形重建这一支才刚开始补课。论文真正的影响不是 12 亿点这个具体数字（明年会有人在更大卡上做更大场景），而是它示范了一种工作方式——重建质量瓶颈如果是工程问题，就用工程手段解，不要再多套一层 trick。这种判断值得三维重建社区接住，否则下一个 18 个月还会在算法和压缩里来回打转。
参考链接：
