英伟达又放出一个让做三维视觉的人没法淡定的名字——Lyra。标题里“ICLR‘26开源”、“蒸馏3D高斯泼溅”、“静态和动态场景重建新SOTA”这几个词摆在一起基本等于明说这是一篇要冲击场景重建范式的工作。做3DGS的人都知道静态重建这两年已经被卷到接近天花板动态重建却始终差一口气。Lyra把蒸馏拉进来目标是同时把静态和动态都推到SOTA这个方向本身就很值得拆开看。我先说清楚我这篇内容的定位目前公开能看到的信息主要是标题和少量摘要完整论文和代码还没有全部放出。下面关于方法论的拆解部分是基于3DGS、知识蒸馏和动态场景重建这几个方向的主流技术路线做的合理推演。等正式版论文和仓库放出来你们拿训练配置对一遍就知道哪些是猜的、哪些是命中的。我会把推断和常识分开讲尽量不让你们走弯路。1. 拆开标题这个工作为什么让三维视觉圈不淡定1.1 ICLR’26意味着什么不是顶会灌水是系统级背书先聊会议本身。ICLR是深度学习圈公认的顶会跟CVPR、NeurIPS平级但口味上更偏“方法有没有启发性和通用性”。英伟达把这个工作投到ICLR说明它有一个完整的故事不只是“我们刷了个分数”而是提出了一种可复用的训练范式并且有一堆对比实验和消融做支撑。还要注意是“开源”。英伟达近年发工作越来越倾向于论文和代码一起放甚至提前放出权重。这对做应用的人来说是天大的好事——意味着你可以直接拿它来跑自己的数据而不是看个demo干瞪眼。对于论文复现党来说开源代码就是最好的“说明书”尤其是3DGS这种工程细节多到爆炸的方向光看论文根本复现不出同样的效果。ICLR’26的投稿周期其实从2025年下半年就开始了目前正是审稿和公开讨论的阶段。能被挂上这种会议的标题说明方法经过了至少一轮严肃的同侪评审。这个背书的分量业内人都懂——很多挂arXiv的工作可能永远不会有这种程度的打磨。1.2 3D高斯泼溅从NeRF手里接棒的新地基3D高斯泼溅也就是3D Gaussian Splatting3DGS是Kerbl等人2023年提出来的渲染与重建方法。核心思路是用一堆三维高斯函数可以理解成一群有颜色、有透明度、有形状和朝向的“小发光球”来显式表达一个场景然后用光栅化的方式把它们投影到图像平面上生成逼真的画面。相比NeRF那种用神经网络做隐式表达的方案3DGS的杀手锏是渲染速度。训练完后一张高分辨率图像可以以几十到几百FPS的速度渲染而且训练时间也大幅度缩短不少场景从几个小时压缩到几十分钟。这直接让“训练一个重建模型然后实时看效果”变成了常规操作。静态场景重建这个赛道几乎被3DGS系方法洗了一遍牌。我简单对比一下两种方式在工程视角下的差异维度NeRF类隐式表达3DGS显式表达场景表示坐标到颜色/密度的连续函数数千到数百万个显式高斯点渲染速度慢通常需多级采样极快类光栅化渲染训练成本高单场景普遍以小时计低分钟到小时级可编辑性弱改局部需要整个网络重新调强直接挪点/改属性动态化扩展需要额外网络建模变形可以加运动字段来驱动点云3DGS也不是没有毛病。它的显存占用比较夸张场景越大高斯点越多存储压力就上来了同时它的静态假设很强一旦场景里有运动物体直接把它当静态重建就会出现明显撕裂和鬼影。这也是动态场景成为下一个主战场的原因。1.3 蒸馏才是灵魂动作不是压缩模型是知识迁移“蒸馏”这个词最早出自模型压缩领域。Hinton在2015年提出的知识蒸馏核心是一个“大模型教小模型”的过程先训练一个能力强的大教师模型然后让一个小学生模型去模仿大模型的输出把“知识”从大模型迁移到小模型。但在Lyra这个语境下蒸馏的意义要宽很多。它不完全是在压缩模型更像是在做“能力迁移”。具体来说静态场景重建相对成熟能从多视角图像中学到很扎实的几何和纹理先验动态场景呢因为物体在动、有遮挡变化、有拓扑变化监督信号混乱模型不容易学稳。如果能让一个动态场景模型在一个静态教师模型的指导下训练就相当于让新手在老师傅的监督下干活——几何和材质这些“基本功夫”不用从头摸索只需要专注学好“怎么动”。这种用法在视觉领域其实已经开始流行了。单目深度估计有蒸馏人体姿态估计有蒸馏现在把它用到3DGS上解决的恰好是动态场景监督不足这个老大难问题。标题用“蒸馏”而不是“联合训练”或“多任务”说明作者认为这种单向知识迁移是最关键的机制。这也是我理解Lyra整个工作的钥匙。2. 静态与动态的统一思路Lyra可能怎么做2.1 静态场景已经很香动态场景才是硬骨头静态场景重建输入一堆从不同角度拍的图片输出一个能自由漫游的三维模型这个流程已经被3DGS解决得相当漂亮。住宅、街景、古迹、器物只要光线稳定、相机标定准确基本都能得到很好的结果。动态场景就是另一个世界了。动态意味着时间维度的引入同样一个场景每一帧里物体位置都在变化还有形变、遮挡、光影变化。如果只是把所有帧当作独立静态场景去重建那得到的模型数量爆炸而且帧间不连续根本没法渲染成流畅的视频。现有的动态重建技术大致分成两类路线。第一类是隐式神经场用额外的神经网络预测时空坐标把时间维度塞进去代表性工作包括D-NeRF、K-Planes这类。优点是表达能力强缺点是训练慢、渲染慢工程落地很难受。第二类是基于3DGS的动态扩展比如Deformable 3D Gaussians、4D Gaussian Splatting。思路通常是给每个高斯点加一个“运动偏移量”或者用一个形变场网络去预测点在每个时刻的位置和形状变化。优点是能继承静态3DGS的高渲染速度缺点是运动学建模复杂很容易过拟合训练帧、泛化到新视角时容易糊。Lyra想做的很可能就是把第二类路线做到极致再用蒸馏机制把静态先验注入进来。这种“统一框架”的好处是你不需要为静态和动态各维护一套模型一个系统两种模式通吃工程上非常吸引人。2.2 蒸馏怎么搭桥教师静态、学生动态的合理推演我知道现在很多人最想知道的是Lyra具体怎么蒸馏我基于主流技术路线做一次逻辑推演你们可以参考。最自然的方案是“教师–学生”架构。教师是一个在静态场景上训练充分的3DGS模型它见过足够多的高质量多视角图像对几何结构和材质反射有很强的先验。学生则是一个动态3DGS模型同一份场景数据输入进来额外多一个时间维度。训练时教师冻结参数学生接收同样的输入但学生不仅要拟合原始图像损失还要拟合教师在相同视角下给出的渲染结果。这个“渲染结果对渲染结果”的蒸馏本质上是让学生模仿教师在静态几何上的判断。学生网络在起步阶段输出的高斯点位置、颜色、形状可能乱七八糟但有了教师渲染图作为软目标它至少能知道“这个角度看起来大概应该是什么样”。相比原始图像提供的像素级监督教师提供的是一种“带语义的、多视角一致的”监督信号优化起来更平滑。还有另一种做法是在特征层面蒸馏不只是比较渲染图像。比如教师网络内部某个中间层输出的几何特征拿去约束学生对应层的学习。这种做法的好处是信息更密集能把教师的“理解方式”也迁移过来但坏处是对网络结构一致性要求高不一定好拉通。论文里具体用了哪种甚至可能是两种混着来得等代码出来才知道。2.3 统一框架的训练红利静态SOTA给动态当脚手架做研究的人看SOTA做工程的人更在意“一个框架能不能吃两种场景”。Lyra如果真的实现了静态和动态的统一表达那它的价值不止是刷榜而是提供了一个可以落地的完整系统。我推测它的训练流程大概是这样的先用静态场景数据把教师3DGS训练到一个很好的状态然后进入学生阶段对同一个场景采样多个时间帧学生在每个时间帧上做动态预测同时受教师的静态输出约束。经过蒸馏之后再微调学生模型在高动态场景下的表现可以反超独立训练的模型。这个设计还有一个隐藏红利它天然做成了“从静态到动态的课程学习”。课程学习是深度学习里一个很实用的技巧先让模型做简单的任务再逐步过渡到难的。静态拟合是相对简单的任务动态拟合是复杂任务蒸馏机制刚好实现了这个过渡。这也是为什么这一招往往比直接端到端硬训练效果更稳——优化路径被拉直了损失地形没那么崎岖。3. 复现前的准备环境、数据与仓库判读3.1 GPU环境与依赖安装建议如果你们团队想在Lyra开源后第一时间复现环境这块得先准备好。英伟达的工作自然首先吃英伟达GPU生态。3DGS本身是CUDA重度依赖的项目大量自定义算子要即时编译所以驱动、CUDA、PyTorch和编译工具链的版本必须对齐。实操建议是按仓库要求的版本来不要自己“用最新”。我见过太多人图新鲜装了最新的PyTorch或CUDA结果算子在编译期报错一查发现只支持某个范围内的版本。比较稳的组合是Ubuntu 22.04、CUDA 12.1、PyTorch 2.1.x、GCC 9或11。显存的话训练动态场景建议至少24GB起步跟A5000、3090、4090平级A100/A6000当然更舒服。安装依赖时用conda隔离环境是常规操作不要裸装在系统Python里。3DGS的依赖链里有pybind11、nvdiffrast这些编译期组件环境干净能省掉大量头疼时间。一个常见流程是这样conda create -n lyra python3.10 -y conda activate lyra pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 git clone Lyra官方仓库 lyra cd lyra pip install -r requirements.txt pip install -e . # 通常是自定义算子需要3.2 动态数据集怎么选、怎么处理成标准格式动态场景重建的数据集和静态不太一样。静态数据集通常是一组任意视角的图片动态数据集则需要“多视角同步时间帧”每个时刻都有多个相机同时拍摄这样才能重建出运动。常见的公开数据集包括D-NeRF数据集、NHR数据集、DyCheck数据集还有一些室内人体表演捕捉数据。选数据集有个原则先小后大。第一次跑通的目的是验证链路不是刷SOTA所以选一个规模小、运动相对简单的场景比如D-NeRF里的某个单物体动画。全部跑通、代码改熟悉了再上大场景。数据处理方面3DGS系方法一般要求你先把图像、位姿、内参整理成标准COLMAP格式或者直接提供已有的相机参数文件。动态数据则还要额外提供时间帧的索引。很多仓库会自带预处理脚本把关键帧抽出来再把图像序列按时间和视角分组。我建议拿到仓库后先看数据集目录结构搞清楚每个文件是什么再动手跑。3.3 仓库到手之后先看这四个文件很多同学拿到一个开源项目先急着跑demo跑了半天改来改去都不知道自己在看什么。我复现这类项目有个固定习惯先找四个东西。第一是README里的“Quick Start”不看这个的人会连数据放哪都不知道。第二是配置文件可能是config目录下的yaml也可能是脚本里的argparse参数。动态3DGS的参数特别多学习率、密度化间隔、蒸馏损失权重、运动场网络层数全在这里。第三是训练脚本入口看它接收哪些参数、输出日志到什么目录、多少步存一次checkpoint。第四是loss定义文件这个最关键——所有“蒸馏”的魔法都在loss里你把loss代码看懂整篇文章就懂了一半。花一个下午把四个文件过一遍比盲跑十遍demo都有用。跑通只是开始能改配置、能换数据集、能定位问题才算真的复现了。4. 训练动态高斯时的常见坑与排查实录4.1 显存直接爆掉动态高斯的内存管理动态3DGS训练最现实的坑就是显存不够。静态3DGS已经有“高斯基元多到爆显存”的问题了动态版还要加运动场网络每个时刻都要新算一份变形后的高斯基元显存消耗成倍增加。我见过不少人在24GB卡上训练中等动态场景直接OOM。基本排查思路是先看数据加载有没有问题。有时候不是模型吃显存而是加载器把整批图像全塞进显存做预处理了。把加载器改成边读边算显存能省一大截。再一个常用手段是限制每个batch的“高斯点数量”动态场景大几十万甚至上百万个点全部反传是很吃显存的可以看仓库有没有梯度裁剪或子采样机制。还有就是周期性清空中间变量。这类项目的反传其实只在最近几帧上进行不是全时间步都参与梯度计算。如果你发现代码里每个时间步都保留着用于反传的中间张量那大概率是显存泄漏的根源。改成分段累积梯度能稳定省出好几GB。4.2 运动大或遮挡多的场景糊成一片怎么查动态场景训练出来拖影、模糊、鬼影这是最常见的质量问题。第一反应先看你的运动场建模是否够表达给定的运动。大幅位移需要更高的运动场网络容量如果你用的隐藏层太少模型根本学不动。第二个常见原因是正则化强度不够。动态高斯比静态高斯更容易“放飞自我”高斯点位置乱飞、尺寸失控。很多项目里会加一个形变正则项约束相邻时间步的运动场输出不要突变。如果发现训练时损失下降很顺但渲染画面疯狂抖动那就是正则太弱把运动平滑权重往上调。第三个排查点是数据本身。动态场景对时间的标注要求很高如果不同相机的帧对不齐任何模型都学不出来。我遇到过最诡异的一回是数据的FPS和运动速度对不上模型反复拟合同一套姿势自然怎么调都糊。先用可视化工具把输入数据的运动轨迹过一遍确认运动平滑合理再怀疑模型的问题。4.3 Windows下WSL2与NVIDIA驱动配合的边界情况现在不少人在Windows下用WSL2跑深度学习。WSL2里能不能用GPU取决于Windows主机的NVIDIA驱动是否支持。基本规律是新版本驱动都支持WSL2的CUDA重定向你在Linux子系统里装CUDA工具链实际调用的是宿主机驱动。判断驱动有没有生效在WSL2里跑nvidia-smi能看到GPU信息就说明通了。我在实践中遇到过几次很磨人的问题。一种是WSL2里看到的显存和宿主机不一致这是因为WSL2有缓存和共享内存机制数值仅供参考不用慌。另一种是驱动版本够新但CUDA toolkit版本不匹配导致编译3DGS算子时nvcc报错。解决方式是别在WSL2里重装驱动只把CUDA toolkit装在子系统里版本跟宿主机驱动支持的最高CUDA版本对齐。特别注意如果宿主机GPU出现“错误代码43”这类症状Windows上的驱动已经不稳定了这时候调WSL2是没用的。先把宿主机的驱动回滚或重装干净再回来跑训练。很多人把时间浪费在子系统配置上最后发现是Windows侧驱动崩了。4.4 搜错项目Lyra重名问题一箩筐这里必须提醒一件容易被坑的事Lyra这个名字在游戏引擎领域还有一个大名鼎鼎的项目就是Unreal Engine 5自带的Lyra示例游戏