点击下方卡片，关注「3D视觉工坊」公众号
选择星标，干货第一时间送达
3D视觉硬件汇总，包括结构光3D相机(支持室内外，焊接，机械臂抓取等场景)，相位偏折术、散斑、机械臂抓取和焊接软件，手持扫描仪(支持定位、重定位、稠密建图)、四足狗和小车定位和导航，底盘。点击->查看详情：
2026 年的 3DGS 顶会成果，有一个非常清晰的信号：学界和工业界正在集中火力解决 3DGS 的“落地之痛”。
3D Gaussian Splatting（3DGS）凭借惊人的渲染速度和画质，早已成为三维视觉领域最炙手可热的技术。但它的三个老大难问题始终卡着大规模应用的脖子：训练太慢（动辄几十分钟）、显存太大（一个场景吃掉数 GB）、基元数不可控（端侧设备根本跑不动）。
今年，三篇来自不同顶级会议的重磅论文，恰好从三个维度同时给出了答案——LiteGS（ECCV 2026）解决训练速度，MEGS²（ICLR 2026）解决显存瓶颈，EcoSplat（CVPR 2026 Highlight）解决基元可控。
它们各自切入了3DGS全链路中一个最痛的环节，合在一起，几乎拼出了3DGS从"实验室炫技"到"端侧落地"的完整拼图。
LiteGS（ECCV 2026）：训练 3DGS，约 50-60 秒就够了
一句话总结：从 GPU 底层到算法顶层，三层协同优化，把 3DGS 训练时间从几十分钟压缩到约一分钟。
它解决了什么问题？
3DGS 训练慢，大家都知道。但为什么慢？大多数加速工作给出的答案是"计算量太大"。但 LiteGS 的诊断不一样：这不是某一个环节慢，而是三个层面的缺陷互相咬合，形成了一个自我强化的负循环。
底层的光栅化器里，多个线程要往同一个像素上累加梯度，只能靠原子操作排队，大量线程把时间花在等待上；中层的显存里，数据排列不讲空间秩序，缓存命中率上不去；顶层的致密化判断又太粗，一边制造冗余计算，一边错过真正需要细节的地方。
三层咬在一起的结果是：基元越多，缓存表现越差；缓存越差，单位算力的有效产出越低；训练越慢，每一步致密化的时间成本就越高。越训越慢，而且越来越慢。
核心方案：三层改造，一一对应
LiteGS 提出了一种 "系统与算法协同设计" 的思路——既然算法本身的写法没有按照 GPU 最擅长的方式来组织，那就从头按照 GPU 的习惯重新设计。
第一层（GPU 计算层）：Warp-based Raster
传统 3DGS 的每个渲染块（tile）需要多个 warp 并行处理，然后通过大量原子操作累加梯度。LiteGS 提出"一个 warp 负责一个 tile"的新范式，每个线程处理多个像素，将原本需要多次 warp 级规约的操作压缩到单次 warp 规约，大幅减少了原子操作的排队开销。
在200万个 primitive 规模下，LiteGS 相比原始 3DGS 加速了 5-7 倍。
为了缓解"单 warp 单 tile"带来的寄存器压力，LiteGS 还引入了扫描线算法和混合精度计算两项配套技术。
第二层（数据管理层）：Cluster-Cull-Compact
训练过程中，新的高斯基元被不断追加到数组末尾，导致缓存命中率随着训练推进持续下降。LiteGS 引入 Morton 编码（Z-order 曲线） 对基元进行动态空间排序，每 128 个基元组成一个簇并计算包围盒，然后以簇为单位进行视锥体裁剪和内存压缩。
实验表明，这一模块单独贡献了 36% 的训练加速（Mip-NeRF360 上从 701 秒降至 515 秒）。
第三层（算法层）：Opacity Gradient Variance
原始 3DGS 的致密化依赖视图空间位置梯度的幅值来判断哪里需要增加基元。LiteGS 改用不透明度梯度的方差作为致密化指标：方差低说明梯度方向一致，模型只是还没收敛，不需要加基元；方差高说明不同像素对同一个基元的要求相互冲突，这才是真正需要分裂或克隆的地方。
使用梯度方差指标配合软衰减，比原始策略在 PSNR 上提升了近 1 dB，证明了新致密化指标的鲁棒性。
效果有多惊人？
LiteGS 在 Mip-NeRF360 数据集上，使用 100 万个基元、在 RTX 3090 上训练平均仅需 64 秒（RTX 4090 上平均仅需 40 秒），PSNR 达到 27.59。相比原始 3DGS，训练加速最高达 13.4 倍。
值得一提的是，LiteGS 来自摩尔线程——一家国产GPU公司。它已经在图形学顶级会议 SIGGRAPH Asia 2025 的 3DGS 重建挑战赛中斩获银奖，以平均 PSNR 27.58 在精度与效率两项指标上取得均衡表现。从顶会竞赛获奖到 ECCV 2026 论文录用，LiteGS 是国产 GPU 厂商在 3DGS 领域少有的系统性突破。
📦 代码与模型
代码仓库：https://github.com/MooreThreads/LiteGS
四大核心特性：
模块化设计：将前向和反向拆分为多个 PyTorch 扩展函数，中间变量可直接访问，部分场景下借助 PyTorch Autograd 无需手动推导梯度公式 双 API 灵活选择：提供 CUDA 版（高性能）和 纯 Python 版（快速原型开发）两套 API。Python API 无需修改 C 代码即可调整计算逻辑 性能更强、资源更少：相比原始 3DGS 实现加速 4.7 倍，GPU 内存减少约 30% 算法保留：保留 3DGS 核心算法，仅因聚类对训练逻辑做了微小调整
渲染流水线拆解
Cluster Culling：将高斯点分为若干 chunk（每块 1024 点），先做视锥体裁剪 Cluster Compact：类似网格渲染，将可见基元重排到连续内存中 3DGS Projection：将高斯点投影到屏幕空间（与原始实现一致） Create Visibility Table：建立 tile 到可见基元的映射表 Rasterization：每个 tile 并行光栅化其可见基元
快速开始：
# 安装依赖
pip install litegs/submodules/simple-knn
pip install litegs/submodules/fused_ssim
pip install litegs/submodules/gaussian_raster
pip install -r requirement.txt
# 开始训练
./example_train.py --sh_degree 3 -s DATA_SOURCE -i IMAGE_FOLDER -m OUTPUT_PATH
全量评估：
python ./full_eval.py --mipnerf360 SOURCE_PATH1 --tanksandtemples SOURCE_PATH2 --deepblending SOURCE_PATH3
MEGS²（ICLR 2026）：让 3DGS 在手机上跑起来
用球面高斯替代球谐函数 + 统一软剪枝，实现 8 倍静态 VRAM 压缩和 6 倍渲染 VRAM 压缩，首次让 3DGS 在移动端实时运行。
它解决了什么问题？
现有 3DGS 压缩方法有一个普遍的误区：绝大多数只关注存储压缩（减小文件大小），而忽视了渲染 VRAM 压缩。基于神经压缩、向量量化的方法虽然存储压缩率很高，但渲染前必须把全部参数解压回原始精度，VRAM 甚至比不压缩还要大。原始 3DGS 在 Bicycle 场景下，静态 VRAM 高达 1794 MB、渲染 VRAM 高达 2955 MB——手机根本加载不了。
根本原因在于一个简单的公式：
大多数方法只优化了其中一个因素。
核心方案：双管齐下
第一步：用球面高斯（SG）替代球谐函数（SH）
原始 3DGS 用 48 个参数的球谐函数表示视角依赖颜色。球谐函数是全局基函数，需要大量高阶系数才能表示局部高频细节（比如锐利高光）。MEGS² 改用可裁剪的、任意方向的球面高斯（SG）——它是局部基函数，只需少量"lobe"就能高效建模视角效果，且 lobe 数量可灵活调整，天然适合剪枝。
一个 SG lobe 的形式为：
其中 为 lobe 轴方向， 控制锐度， 为 RGB 幅值。最终颜色由漫射项 加上多个 SG lobe 求和得到：
更关键的是，MEGS²允许每个SG lobe朝向任意方向，而不是像SG-Splatting那样限制在正交轴上——这一灵活性带来了更强的表达能力。
第二步：统一软剪枝框架
MEGS²首次将 primitive 剪枝和 lobe 剪枝建模为单一的内存约束优化问题：
其中 为透明度向量， 为 sharpness 向量， 和 分别对应每个 primitive 和每个 SG lobe 的基参数量， 为总参数预算。
它采用 ADMM-inspired 的优化算法，在总参数预算的约束下，自动决定"删掉哪些 primitive"和"每个 primitive 保留几个 lobe"。剪枝后还通过颜色补偿策略将删除 lobe 的能量均摊到漫反射项中：
效果有多惊人？
在 Mip-NeRF360 数据集上，MEGS² 相比原始 3DGS 实现了 8 倍静态 VRAM 压缩和 6 倍渲染 VRAM 压缩，同时 PSNR 几乎无损。
在 WebGL-based 移动端测试中，原始 3DGS 在手机上几乎不可用，而 MEGS² 在骁龙 8+ Gen 1 上跑出了 120.9 FPS。
这是首次让高质量3DGS在中低端手机芯片（骁龙888）上达到流畅的 60 FPS 实时运行。
存储方面，MEGS² 在 Mip-NeRF360 上仅需 55 MB，在 DeepBlending 上仅需 54 MB，甚至优于 EAGLES 等专用压缩方案。
代码与模型（读者关心的）
代码仓库：https://github.com/IGL-HKUST/MEGS-2
环境与依赖：
已在 RTX 3090 + CUDA 11.7 上完成测试 代码基于https://github.com/noodle-lab/GaussianSpa.git修改而来 数据集需准备 Mip-NeRF360、Tanks&Temples 和 Deep Blending
推理参数：
--prune_ratio1 | |
--prune_ratio2 | |
--sharpness_ratio | |
--sharpness_threshold | |
--optimizing_spa_interval |
WebGL 移动端渲染器：
MEGS² 提供了一个完整的 WebGL 浏览器端渲染器，可直接在手机和电脑上运行：
main_sg.js：加载 MEGS² 的 SG（球面高斯）模型main_sh.js：加载原始 3DGS 的 SH（球谐函数）模型已添加对三阶 SH 系数的支持（比原版 splat 仓库负载更重） 运行方式： cd WebGL_viewer && http-server
这意味着读者可以拿着自己的 .ply 模型，直接在浏览器里测试 MEGS² 在真实手机上的帧率——这对评估端侧部署价值极大。
EcoSplat（CVPR 2026 Highlight）：想要多少个高斯，你说了算
首个"数量可控"的前馈式 3DGS 框架，推理时给定任意目标基元数 ，模型自动挑出最重要的 个高斯来渲染。
它解决了什么问题？
前馈式 3DGS（如 PixelSplat、MVSplat）的主流做法是"逐像素对齐"——每张输入图的每个像素反投影成一个 3D 高斯，再把所有视图的高斯并起来。这导致基元总数随输入视图数和图像分辨率线性增长：24 视图、256×256 分辨率下动辄上百万个高斯。
更关键的问题是：这些方法对输出高斯数量没有任何显式控制。你没法告诉模型"我只要 5 万个高斯来渲染"。实际部署中，重建在服务器端做一次，但渲染要分发给算力各异的手机、AR/VR 头显等端侧设备——按需控制基元数是刚需。
现有省内存方案（AnySplat 的可微体素化、GGN 的图聚合、Long-LRM 的不透明度剪枝）都是基于阈值的——体素大小、相似度阈值等超参对场景敏感，剪出来的基元数因场景而异、不稳定。
核心方案：让模型学会"按预算排序"
EcoSplat 的核心思想是：与其事后剪枝，不如让模型在训练时就学会"按预算排序高斯重要性" ——把目标基元数 作为条件信号注入模型，让模型主动压低不重要高斯的不透明度，推理时直接保留不透明度最高的 个即可。
具体采用两阶段训练：
像素对齐高斯训练（PGT）：模型先学习初始的逐像素高斯预测，损失函数为标准渲染损失：
重要性感知高斯微调（IGF）：将目标基元数 作为条件注入，通过重要性感知不透明度损失鼓励模型抑制不重要基元的透明度：
其中 为根据图像梯度和深度法线变化生成的伪真实重要性掩码。
从输入图像计算光度变化图（图像梯度幅值）+ 几何变化图（法线图梯度幅值）→ 取平均得到变化图 → 根据保护率 取分位数二值化 → 高变化区域全部保留 + 低变化区域通过 K-means 合并 → 投影得到重要性掩码 。
配合渐进式学习策略（PLGC）让模型逐渐适应从宽松到激进的剪枝范围， 的采样区间从 逐步退火到 。
这直观地展示了 EcoSplat 确实学会了根据预算动态调整基元的"生死"。
推理时，EcoSplat 还会根据不同视图的信息量（高频成分占比）自适应分配每个视图的基元配额，视图重要性因子 通过频谱高频占比的 softmax 计算：
信息量大的视图分到更多基元，信息量小的视图分到更少。
效果有多惊人？
在 RE10K 数据集、24 视图输入下，即使将高斯压缩到仅剩 5% 的极端情况，EcoSplat 仍能达到 24.72 PSNR、0.822 SSIM 的高质量渲染。相比之下，AnySplat 在同样 5% 的压缩率下 PSNR 仅 8.08，WorldMirror 仅 8.09，几乎完全失效。在 40% 压缩率下，EcoSplat 达到 25.11 PSNR，远超 AnySplat 的 19.66 和 WorldMirror 的 19.66。
在极端压缩（5%）下，EcoSplat 的 PSNR 比第二名 AnySplat 高出惊人的 16.6 dB，证明了其基元筛选机制的高效性。
在渲染速度方面，使用仅 7.8 万个高斯时，EcoSplat 的推理速度高达 1042 FPS。
EcoSplat不仅重建速度最快（0.52秒），而且在仅用 7.8万个基元时，画质（24.72 PSNR）依然碾压使用 50万个基元的 GGN（15.80 PSNR）。
更值得一提的是，EcoSplat 在跨数据集泛化（从 RE10K 迁移到 ACID）上也表现优异。在 ACID 数据集上，EcoSplat 以 40% 的基元数（仅 62.9 万个）达到了 24.02 PSNR，远超 GGN 的 18.06 和 AnySplat 的 21.96。
IGF阶段是EcoSplat最关键的贡献——没有 IGF 的情况下，5% 压缩时 PSNR 暴跌至 6.45，几乎完全失效。
代码与模型（读者关心的）
代码仓库：https://github.com/KAIST-VICLab/EcoSplat
两个可用分支：
eco_spfsplat分支（默认）：基于 SPFSplat 底座，支持无需相机位姿（pose-free）的稀疏视图前馈 3DGSeco_zpressor分支：基于 ZPressor 底座，同时支持视图间和视图内压缩（MVSplat baseline + IGF）
核心可复用组件：EcoSplat 的效率控制被实现为一个与底座无关的可复用包ecosplat_wrapper/，其中封装了 IGF（重要性感知高斯微调）训练策略。如果你想将 EcoSplat 的机制迁移到其他底座模型，可以直接阅读 ecosplat_wrapper/README.md。
预训练模型：
EcoSplat（IGF）checkpoint 已在 Hugging Face 上开源： ecosplat-spfsplat-re10k.ckpt训练需要从 SPFSplat 的 stage-1 checkpoint 开始微调，SPFSplat 模型库也已在 Hugging Face 上开放
训练与推理：
IGF 训练通过 model.encoder.igf配置控制，默认参数与论文一致（loss_weight=0.1、io_weight=0.1、PLGC 退火范围0.85→0.95）推理时可通过 inference_rho（保护率 ）任意指定目标基元数，rho越低 → 渲染使用的高斯越少官方提供了 eval_igf_rho{0p7,0p4,0p1,0p02}.sh四个预算档位的评估脚本
三篇顶会，一条主线
| LiteGS | ||||
| MEGS² | 8 倍 | |||
| EcoSplat |
这三篇论文放在一起，恰好覆盖了 3DGS 从训练→存储→渲染的全链路效率问题：
LiteGS 管的是训练阶段：怎么让 3DGS 学得更快。 MEGS² 管的是存储与加载阶段：怎么让 3DGS 在端侧装得下、跑得动。 EcoSplat 管的是渲染适配阶段：怎么让同一个 3DGS 模型适配不同算力的设备。
三篇合在一起，基本回答了 3DGS 落地中最核心的三个问题：训得够快吗？装得下吗？跑得动吗？
inference_rho | ||
WebGL_viewer/main_sg.js | ||
./example_train.py | ||
call_script()） | ||
.ply 文件 |
2026年，3DGS正在从"实验室炫技"走向"端侧可用"。LiteGS、MEGS²和EcoSplat，就是这条路上三个关键的里程碑。对于关注3DGS工程落地的算法研究员和开发者来说，这三篇论文值得花时间仔细研读——它们的代码都已经或即将开源。
本文仅做学术分享，如有侵权，请联系删文。
。
添加微信：cv3d001，备注：姓名+方向+单位，邀请入群。
