GPU 开始伸手进算法了：摩尔线程要加速 3D 高斯训练 | ECCV 2026

让GPU学会给三维世界“排队”。

 GPU公司通常不太需要向别人解释自己为什么做GPU。

但当一家GPU公司开始亲自下场研究算法，事情就没那么简单了。

最近，摩尔线程团队的一篇论文被计算机视觉三大顶会之一的ECCV 2026正式接收。这篇论文把目光放到了3D Gaussian Splatting，也就是3DGS上，论文名叫LiteGS，做的事情可以概括为：把3DGS训练得更快。

但如果只把它理解成一次普通的算法优化，就低估了这篇论文的意思。

过去两年，空间智能（spatial intelligence）成了AI行业的高频词：李飞飞为它创立了World Labs，国内的具身智能与世界模型创业潮，讲的大多也是这件事。而3DGS，是目前把真实场景变成机器可计算的三维表示里，最务实的技术路线之一。

因为LiteGS并不是只在算法层面“抠性能”。它从GPU底层的光栅化方式开始改，到数据如何排列、如何进入缓存，再到3DGS什么时候应该增加新的高斯基元，三层一起动。摩尔线程把这件事称为system and algorithm codesign，也就是系统与算法协同设计。

LiteGS对真实场景进行3D Gaussian Splatting重建 

图源：摩尔线程

一家GPU公司，为什么要自己下场改一个3D视觉算法？要回答这个问题，得先看3DGS自己卡在了哪里。

01

从分工到错位：

3DGS为什么越训越慢

过去很长一段时间里，GPU和算法之间更像是一种分工关系。算法提出计算任务，GPU负责把它尽可能快地执行出来。GPU厂商真正需要做的，是让硬件拥有更多算力、更高带宽，以及更成熟的软件栈。

3DGS让这套分工出现了裂缝：瓶颈首先就不在“计算量太大”上。

一个三维场景可以由数百万个3D Gaussian表示。它们有自己的位置、尺度、颜色和透明度，并不断参与投影、排序、光栅化和梯度更新。看起来每一步都适合GPU并行计算，但真正跑起来，却充满了GPU不喜欢的东西：不规则的内存访问、线程之间的同步、缓存失效，以及大量并不必要的计算。

3DGS通过大量三维Gaussian基元表示真实场景

LiteGS更有意思的地方，也正从这里开始。

论文对“3DGS为什么慢”给出了一版和主流加速工作不太一样的诊断：这不是某一个环节慢，而是三个层面的缺陷互相咬合，形成了一个自我强化的负循环。

底层的光栅化器里，多个线程要往同一个像素上累加梯度，只能靠原子操作（AtomicAdd）排队，大量线程把时间花在等待上；中层的显存里，数据排列不讲空间秩序，缓存命中率上不去；顶层的致密化判断又太粗，一边制造冗余计算，一边错过真正需要细节的地方。

三层咬在一起的结果是：基元越多，缓存表现越差；缓存越差，单位算力的有效产出越低；训练越慢，每一步致密化的时间成本就越高。越训越慢，而且越来越慢。

于是问题发生了变化，算法本身的写法，可能就没有按照GPU最擅长的方式来组织。

LiteGS试图反过来问一句：如果我们知道GPU是怎么工作的，能不能从一开始就按照GPU的习惯重新设计3DGS？

这也是为什么这篇论文值得从“GPU厂商做算法”的角度来看。它的三层改造：warp-based raster、空间排序与聚类剔除、方差引导的致密化，恰好一一对应上面三个层面。

3DGS Tile-Based Rasterization示意图

02

让3DGS按照GPU的方式工作

三个层面的问题，对应着三处改动。第一处在GPU执行光栅化时最花时间的地方，第二处在内存，第三处在算法对场景的“增删”策略。

▎第一件事：让GPU少等一会儿

3DGS训练中的一个核心步骤是光栅化。简单说，就是把三维空间里的Gaussian投影到二维图像上，再根据它们对像素的影响计算梯度。

问题在于，这个过程并不像传统矩阵运算那样整齐。

原始3DGS的实现里，一个图块（tile）上的多个Gaussian由不同线程处理，像素梯度的累加要靠原子操作完成，相当于所有人都挤在同一个记账本上写字，谁都得等别人写完再落笔。线程越多，排队越长。

LiteGS重新组织了GPU上的计算方式：把一个图块的处理交给一个warp，也就是GPU最小的线程执行单元，32个线程为一组，让组内线程共享数据、分工接力，从源头上减少同步与原子操作。这就是论文里的warp-based raster。

它的思路并不是简单地增加计算资源，而是让线程之间少一点等待、少一点同步，也少做一些重复工作。

效果直接写在消融实验里：在garden场景上，重构后的光栅化器比原始的atomic方案快7到13倍，比此前以快著称的Taming 3DGS还快约4倍，比近期用Tensor Core加速的方案也快约2倍。

这听起来是一个很底层的优化，却恰恰体现了GPU厂商的视角。算法研究者可能会问：这个步骤怎么算得更准确？

GPU系统研究者还会继续问：这个步骤为什么要这样算？GPU真正花时间的地方在哪里？能不能换一种计算组织方式？

LiteGS选择的是后一个问题。

▎第二件事：让内存里的三维世界也有空间秩序

3DGS还有一个很容易被忽视的问题：三维世界里的“邻近”，不一定意味着计算机内存里的“邻近”。

两个Gaussian在现实空间中可能紧紧挨着，但它们在显存中的位置却可能相隔很远。GPU读取数据时，就容易出现缓存命中率下降、内存访问效率降低的问题。

而且这不是一个静态问题。训练过程中致密化不断插入、删除Gaussian，数据的物理排列只会越来越乱。

LiteGS在这里引入了基于Morton coding的动态空间排序。

Morton code可以把三维空间中的位置映射成一维序列，让空间上相近的Gaussian尽可能在数据结构中靠近，相当于给每个空间位置发一张“一维身份证”，号码相邻，意味着空间相邻。

这样一来，原本属于“几何世界”的空间关系，被转化成了GPU更容易利用的内存关系。

在这之上，LiteGS搭了一条Cluster-Cull-Compact流水线，分三步：先把空间上连续的Gaussian组成簇；渲染前用每簇的包围盒和相机视锥做相交测试，看不见的整簇剔除；再把可见的数据紧凑地排进连续的显存缓冲区，让后续访存吃到合并访问的红利。

消融实验给这层工作标了价：关掉这条流水线，Mip-NeRF 360数据集的平均训练时间会从515秒涨到701秒，慢了36%。

▎第三件事：别让三维世界无止境地膨胀

3DGS的训练并不是一开始就知道应该用多少个Gaussian。

模型会在训练过程中不断densification，也就是在细节不足的区域增加新的Gaussian。这样可以让模型越来越精细，但也会带来一个问题：Gaussian越来越多，计算量和显存占用也随之上涨。

如果增加得不够，细节恢复不好；如果增加得太多，模型就会越来越臃肿。

关键在于怎么判断“哪里真的需要新几何”。原始3DGS的判据比较粗：看所有像素不透明度梯度的平均值。但一个区域里所有像素都在均匀地“想要更多细节”，和一部分像素强烈想要、另一部分无所谓，平均值可能一样，含义却完全不同。

LiteGS改用梯度的方差做判据：分歧，才说明这个区域的表示能力真的不够。同时配合更稳定的opacity控制——把原来“定期把不透明度硬性清零”改成“减半衰减”，避免全场景的梯度被周期性地剧烈扰动。

消融数据同样清楚：方差判据和opacity衰减各自贡献约0.3到0.6 dB的PSNR；两个都去掉，Mip-NeRF 360上的PSNR会从28.12掉到27.13。

换句话说，它不只是想让GPU“算得更快”，还想让算法少让GPU算一些不必要的东西。这也是system and algorithm codesign真正成立的地方。

硬件优化和算法优化并不是两个孤立的模块，而是开始互相约束。算法知道硬件喜欢什么，硬件也反过来影响算法应该怎么长。

03
训练一个三维世界，

到底能有多快？

到了验收的时候。

LiteGS提供turbo、balance、quality三档配置，分别对应小参数量快速训练、均衡训练、以及参数量对齐原始3DGS的高质量训练。所有实验都在单张NVIDIA RTX 3090上完成。

论文报告的结果是，最高可以达到相较原始3DGS约13.4倍的训练加速，同时保持具有竞争力的重建质量。具体到最常被引用的garden场景：原始3DGS要训练将近36分钟，LiteGS五分钟出头就能完成，精度还更高一点。

quality档在Mip-NeRF 360上拿到28.25 dB的PSNR，论文将其列为高质量重建的SOTA结果。turbo档则把训练时间压到145秒，相比Mini-Splatting v2的214秒快约1.5倍，同时PSNR高出0.37 dB。这个优势并非只出现在Mip-NeRF 360上，在Tanks & Temples和Deep Blending上，LiteGS-turbo同样同时取得了更短的训练时间和更高的PSNR。

摩尔线程随后将LiteGS开源，并以“Training 3DGS in 50 seconds!”作为项目介绍，这个数字来自仓库里的激进档配置：固定一百万基元、压缩迭代次数，在RTX 3090上训练完bicycle场景只要50秒。牺牲一部分精度换取极致速度，把“多快算快”的选择权交给使用者。

官方还披露，LiteGS曾获得SIGGRAPH Asia 2025 3DGS Challenge银奖。那场比赛里，它在平均PSNR 27.58的精度下，把单场景重建压到了34秒。

值得关注的并不仅限于这个数字本身。因为对于3DGS来说，训练时间从几十分钟甚至更长，压缩到分钟乃至亚分钟，改变的不只是一个benchmark上的成绩。

它意味着三维重建开始更接近一种可以被反复调用的计算能力。

今天拍一组照片，等几十分钟得到一个三维场景，和拍完之后很快就能得到一个可以继续编辑、渲染、分析的三维表示，是两种完全不同的工作流。

04

为什么偏偏是一家GPU公司？

答案到这里其实已经比较清楚了。

如果3DGS只是一个普通的视觉算法，GPU厂商完全可以等别人把算法做好，再负责把它跑起来。

3DGS不在“普通”之列。它身后站着的，正是过去两年行业里讲得最多的方向：空间智能。李飞飞在《从文字到世界》那篇长文里形容大语言模型是“黑暗中的文字匠”，能言善辩却缺乏经验、缺乏根基。但如果未来AI真的要进入物理世界，情况就会嬗变。

机器人需要理解空间，自驾系统需要构建环境，数字孪生需要复制现实场景，世界模型需要持续建立和更新对物理世界的表示。

这些任务最终都要落到真实的计算系统上。于是，GPU厂商面对的问题就不再只是“给模型提供多少算力”。

还包括：这个模型应该怎样计算，数据应该怎样组织，内存应该怎样访问，以及算法本身是不是适合在GPU上运行。

一个值得注意的细节是，LiteGS的所有实验都跑在NVIDIA的卡上，代码以CUDA形式开源。换句话说，这不是一次“自家芯片跑分”式的宣传，它证明的是团队对GPU计算栈的理解深度，而这种理解与具体硬件解耦，恰恰是摩尔线程自己的MUSA软件栈最需要的东西。

LiteGS其实就是一个很具体的例子。它没有停留在“我们有一块GPU，所以3DGS可以跑得更快”这个层面，而是从GPU的执行方式出发，反过来修改3DGS的计算方式。

这也是为什么一篇关于3DGS的论文，会出现在一家GPU公司的技术路线里。LiteGS展示出的则是一种更深的关系：

当算法越来越复杂，单纯堆算力未必能解决所有问题。真正的性能提升，有时来自重新思考算法、数据结构和硬件之间的关系。

从这个角度看，摩尔线程做LiteGS的意义，是在回答一个属于GPU厂商自己的问题：当AI开始从语言走向三维世界，GPU应该只是提供算力，还是应该开始参与“世界如何被计算”？至少在LiteGS里，摩尔线程选择了后者。

而这可能也是国产GPU真正需要建立的另一种能力：不只是做出一块能跑AI的芯片，还要让算法越来越懂这块芯片。

LiteGS现已开源

https://github.com/MooreThreads/LiteGS

LiteGS学术论文

https://arxiv.org/pdf/2503.01199

文章来自于"AI科技评论"，作者 "吴思梦"。