高斯溅射移动端落地：手机跑 3DGS 不卡了？4.6MB 模型干到 127 帧，Mobile-GS 直接封神！-AI Express News

▋ 推荐阅读：

▍资源导航

• 论文链接：https://arxiv.org/abs/2603.11531
• 项目主页：https://xiaobiaodu.github.io/mobile-gs-project/
• GitHub Repo：https://github.com/xiaobiaodu/Mobile-GS
• Hugging Face：暂未提供官方预训练权重库
• 发布机构： University of Technology Sydney Adelaide University Li Auto Inc
• 发布日期：2026年3月
• 开源协议：Apache 2.0（允许免费商业使用，非常良心）

*(Apache 2.0协议意味着无论你是做学术还是做商业落地，都可以直接拿去用。)

3D Gaussian Splatting（3DGS）这两年有多火，不用多说了。

各种高保真渲染、新视角合成的Demo满天飞。但是，凡是亲自上手跑过的人都知道，这玩意儿在云端或者4090上跑着确实爽，一旦你想把它塞进手机、AR眼镜或者任何边缘设备里，瞬间就教你做人。动辄几百MB甚至上GB的模型体积，加上动不动就吃满显存的渲染开销。很多端侧实测的结果就是：发热、卡顿、甚至直接OOM（内存溢出）。

不过，Mobile-GS 刚刚开源了。这是一个被顶级会议接收的全新项目，专为移动设备量身定制的实时3DGS渲染框架。

当前端侧3DGS渲染在这个领域已经非常卷了，各种剪枝、量化方案层出不穷。但没想到这个项目直接从底层渲染管线和神经网络协同的角度截胡了。它是那种，既有算法上的结构创新，底层Infra（如Vulkan 2.0Shader优化）也很硬核的工程。

懒人速览：

它把原本需要大概840MB的3DGS模型，硬生生压缩到了 4.6MB。并且在搭载骁龙8 Gen 3的移动设备上，在1600×1063的高分辨率下，跑出了 127 FPS 的冷启动超高帧率（稳态也有74 FPS）。而且渲染质量（PSNR）甚至还能跟原版3DGS打得有来有回。

老规矩，先看技术细节（Paper和Repo分析），咱们再看实测表现。

行业背景与痛点剖析：为什么手机跑不动3DGS？

在聊Mobile-GS是怎么回事儿之前，我们得先了解一下病灶在哪。最近这一年，虽然类似Scaffold-GS、Mini-Splatting这类轻量化工作层出不穷。现在模型压缩和剪枝在3DGS上，感觉已经是基操了。大家都在努力减少高斯点的数量，或者用哈希表、八叉树存数据。

但这里面有一个致命的痛点，很少有人真正从根本上解决：深度排序（Depth Sorting）。

原生的3DGS为了实现Alpha Blending（透明度混合），必须严格按照从近到远的顺序渲染高斯点。只要你的视角一动，所有的点就得重新算一遍距离，重新排一次序。在几十万、上百万个点的规模下，这个排序过程在GPU上占用了巨大的计算开销。

[图：论文Figure 2 / Teaser 原图] 运行时分析明确指出，原生3DGS中排序操作在推理过程中产生了显著的计算开销。去掉排序后，速度能提升数倍。

现阶段，很多移动端AR/VR设备（大家可以脑补一下最近热门的几款头显），算力和内存带宽都极其有限。你让它每秒钟对百万个浮点数进行60次以上的排序，它唯一的抗议方式就是降频、发烫。

所以，Mobile-GS的核心切入点非常明确： 干掉排序，同时把体积打下来。

核心创新点 A：深度感知无序渲染 (Depth-aware Order-independent Rendering)

身份定义

这是一个纯粹的底层图形学与渲染管线优化，用来平替传统的Alpha Blending。

描述：它怎么渲染的？

Mobile-GS提出了一种“深度感知无序渲染”策略。它完全摒弃了依赖排序的3DGS混合模式，转而采用一种“一锅炖”的加权策略（Order-independent blending）。

具体来说，它不再等待谁在前谁在后。系统会在一次Pass中，并行计算所有相关高斯点的颜色。它构建了一个基于反向深度（Inverse Depth）和高斯点尺寸（Scale）的权重公式。离相机越近、体积越大的高斯点，被赋予的权重就越高；离得远的、小的点，权重就低。

行业对标与解决了什么？

这种无序透明度渲染（OIT）在传统图形学里其实不算新鲜事。以前打比赛或者做游戏引擎（比如K-buffer或者深度剥离）常用的手法。最近在3DGS领域也有类似SortFreeGS这样的工作在尝试。

但Mobile-GS在这个基础上做得很聪明：它把高斯的Scale（尺度）加进了权重公式里。这招有啥用？如果没有Scale权重，有些离得很近但是极小的高斯点（可能是噪点），会遮挡住后面巨大的背景。加上Scale后，渲染不仅摆脱了排序的束缚，还能保持更合理的几何层次。

(我猜作者在做这一步的时候，肯定踩过很多远景糊掉的坑，最后才发现必须把尺度信息融进权重里才能稳住画面。)

[图：详见论文Figure 3渲染管线对比] Mobile-GS与传统3DGS的管线对比。Mobile-GS直接跳过了Tile-based sorting，实现了并行化的高斯点混合。

核心创新点 B：神经视图依赖增强 (Neural View-dependent Enhancement)

描述：它专门加强了什么？

无序渲染虽然极大地提升了速度，但它带来了一个巨大的副作用：透明度伪影（Transparency artifacts）。因为没有了严格的前后顺序，在几何体边缘、重叠区域或者半透明物体上，会产生颜色混乱和类似幽灵般的伪影。

Mobile-GS专门针对这个问题，设计了一个轻量级的MLP（多层感知机）来进行神经视图依赖增强。

细节：怎么做到的？

举个具体的Case： 理解“无序渲染”的副作用，就像大家常说的“延迟渲染”，但它直接在空间透明度上动刀子。本来渲染只需要按深度从近到远排个序然后叠图，现在的算法直接把所有点丢进池子里不管先后。这就导致：当你透过一辆自行车的轮辐看背景时，算法可能会因为无序，把背景的草地颜色错误地叠加在自行车的钢丝前面。

为了解决这个问题，Mobile-GS引入了一个三层的微型MLP（神经元数量分别是256->128->64）。这个MLP的输入是：

• 相机到高斯点的方向向量。
• 高斯点的几何特征（尺度、旋转）。
• 外观特征（球面谐波系数）。

它输出什么？输出一个动态的透明度（Opacity）修正值和视点权重调节因子（$phi$）。当网络发现某些点在当前视角下被遮挡时，就会动态地把它的透明度压低；反之则增强。这就是用神经网络的“预测能力”来弥补“无序渲染”丢失的遮挡关系。

[图：详见论文Figure 4] 神经网络视图依赖透明度建模的可视化。通过极小的MLP动态预测透明度，有效消除了伪影。

核心创新点 C：多重压缩链路 (Distillation & Quantization)

要在手机上跑，只有速度快不够，显存还得装得下。 Mobile-GS构建了一条非常完备的模型瘦身流水线。

1. 一阶球面谐波（SH）蒸馏

原生3DGS为了表现出“换个角度颜色不一样”的反光效果，使用了三阶球面谐波（3rd-order SH），这玩意儿每个点需要存48个参数，极其占空间。 Mobile-GS很生猛，直接用了一个强大的教师模型（基于Mini-Splatting），强行把特征蒸馏到了一阶SH（只有12个参数）。同时为了防止几何结构崩塌，还引入了尺度不变的深度蒸馏损失（Scale-invariant depth distillation loss）。教师模型不仅教颜色，还教深度。

2. 神经向量量化 (NVQ) 与拆分解码

降维之后，它又上了一套神经向量量化（Neural Vector Quantization）。基于K-means聚类，把高斯属性拆分到不同的子空间字典（Codebook）里。为了防止量化导致画面变成马赛克，它在推理阶段并没有直接用量化后的死数据。而是把SH特征分成了漫反射（Diffuse）和视点相关（View-dependent）两部分，用两个极小的16-bit MLP在运行时进行瞬间解码重构。

这就很有意思了： 它把庞大的静态存储数据，变成了一个压缩包，然后用算力（MLP解码）来换取存储空间。最后再加上TMC(GPCC)和Huffman熵编码，把体积直接干到了个位数MB。

[图：详见论文Figure 6] 在Mip-NeRF 360数据集上的运行时间分析。可以清晰看到MLP解码占用的时间微乎其微，并没有成为新的瓶颈。

核心创新点 D：基于贡献度的剪枝机制 (Contribution-based Pruning)

很多之前的轻量化工作，剪枝策略都比较粗暴，比如只看透明度（Opacity），低于某个值就删掉。但这样很容易把一些虽然透明、但对整体光影有关键贡献的大片区域（比如窗户的反光）给误杀。

Mobile-GS的机制更加聪明，它采用了透明度（Opacity）与空间尺度（Scale）双重指标联合剪枝。就像一场淘汰赛：只有当一个高斯点的透明度持续表现得非常低，并且它的几何体积也非常小的时候，两者的“淘汰票”累加超过阈值，它才会被真正删除。

这样既能大幅度减少高斯点的数量，又能保留住那些“虽然很暗但面积很大”的氛围光效点。

性能实测与竞品对比：究竟有多能打？

既然是端侧方案，不看实测数据都是耍流氓。文章横向对比了3DGS、LightGaussian、SortFreeGS、Mini-Splatting、Speedy-Splat等一众前沿模型。我们拿官方提供的数据（Mip-NeRF 360、Tanks&Temples、Deep Blending数据集）来扒一扒。

横向指标对比 (Table 1)

• 原生3DGS：PSNR 27.21，体积 839.9 MB。
• SortFreeGS：虽然也是无序渲染，但体积依然高达 851.4 MB。
• Speedy-Splat：体积79.4 MB，PSNR 26.92。
• Mobile-GS（本作）：PSNR 27.12，体积惊人的 4.6 MB！桌面端FPS达到了 1125 帧。

从数据上看，在保持渲染质量（PSNR/SSIM/LPIPS）几乎不降甚至略高于部分基线的前提下，体积缩小了将近 180 倍。

[图：详见论文Table 1 / Figure 5对比图] 各种方法的定量比较与画质定性比较。注意看Bicycle场景，Mobile-GS在极小体积下保留了自行车轮毂的清晰细节。

手机端“硬核”实测 (Table 2 & 12 & 13)

很多论文跑分只给桌面端，Mobile-GS这次给出了高通骁龙 8 Gen 3 GPU 的真机实测数据。这也是我觉得这份工作最实事求是、最接地气的地方。

在1600 × 1063的高分辨率下：

• 原生3DGS（量化后）：在手机上只有 8 FPS。
• SortFreeGS（量化后）：24 FPS。
• Mobile-GS：冷启动（刚点开软件时）跑到了 127 FPS。

划重点：热管理与稳态帧率。 手机跟电脑不一样，跑一会发热了必然会降频。论文极其坦诚地放出了稳态FPS（Steady-state FPS）数据：在设备发热、触发GPU降频和功耗墙之后，Mobile-GS的帧率下降到了 74 FPS。虽然有下降，但74 FPS在移动端依然是丝滑流畅的水平，而其他模型在稳态下甚至跌到了3 FPS（基本成了PPT）。

功耗实测： 通过高通 Trepn Profiler 测试，Mobile-GS 在手机上的总功耗仅为 0.83W。作为对比，原生3DGS是 5.89W，手机电池根本扛不住。

(看到这个功耗和稳态帧率，做过端侧部署的兄弟应该懂含金量了。不吹不黑，0.83W意味着你可以把它跑在很多散热拉胯的轻量化AR眼镜上，而不仅限于旗舰手机。)

[图：详见论文Table 12与13] 手机端冷热态帧率对比及功耗分析，0.83W的总功耗表现令人印象深刻。

本地部署与食用指南：

如果你想在本地跑起来这个项目，GitHub仓库已经开源了全套管线。不过注意，目前开源的流程主要集中在如何训练并压缩出一个能在手机上跑的模型，具体的Android/iOS App端渲染器可能需要参考Vulkan实现自行封装。

硬件与环境需求

• 训练端：推荐使用 RTX 3090 或以上级别的 GPU。
• 运行环境：Python 3.11, CUDA 12.1, PyTorch 2.5.1。
• 重要依赖：必须要安装 TMC (GPCC)，这是MPEGGroup的开源点云压缩工具，用来做底层的二进制压缩。代码里需要手动指定它的路径。如果你装 cuml 有问题，建议查阅 RAPIDS 官方文档。

核心Pipeline：分两步走

第一步：预训练（提取教师模型特征） 这里借用了 Mini-Splatting 的思路来打底。

#室外场景预训练示例
python pretrain.py -s &amp;lt;COLMAP路径&amp;gt; -m &amp;lt;模型路径&amp;gt; --eval --imp_metric outdoor --sh_degree 3 --iterations 30000

第二步：微调、蒸馏与量化（注入Mobile-GS灵魂） 基于上一步的 Checkpoint 开始微调。在这个阶段，模型会进行一阶SH蒸馏，并在第35,000步时启动神经向量量化（NVQ）。

python train.py -s &amp;lt;COLMAP路径&amp;gt; -m &amp;lt;模型路径&amp;gt; --eval --start_checkpoint &amp;lt;模型路径&amp;gt;/chkpnt30000.pth
#可选：如果想提升效果，可以加上 --mv 3 引入多视角约束（源自MVGS机制）

第三步：解码与渲染测试 跑完之后，你会得到一个极其微小（大约几MB）的 comp.xz 压缩文件。你可以通过以下命令直接使用该压缩包进行实时渲染解码测试：

python render.py -s &amp;lt;COLMAP路径&amp;gt; -m &amp;lt;模型路径&amp;gt; --decode

(提醒：目前项目主页和代码库展示的是算法层的完整实现，底层基于Vulkan 2.0的C++ Shader跨平台部署细节，可能需要进一步深入源码研究。)

消融实验：扒一扒技术的底裤

为了证明没有胡乱堆料，论文的消融实验（Ablation Study）做得很扎实。我们挑几个有意思的看（基于MIP-NeRF 360数据集）。

• 如果不使用“神经视图增强（MLP）”会怎样？

PSNR直接从 27.12 暴跌到 26.68，画面会出现明显的透明度错乱。这就是前面说的，光提速不补画质是不行的。（详见论文Table 3）

• 量化字典大小（Codebook size）怎么选？

论文测试了从 $2^6$ 到 $2^{12}$ 的大小。如果字典太小（$2^6$），PSNR只有25.52，全是马赛克；如果太大（$2^{12}$），体积会飙升到7.9MB。最终权衡下来，$2^{10}$ 实现了 27.12 的PSNR和 4.6MB 的体积，属于甜点位。（详见论文Table 7）

• 剪枝策略的博弈

如果你只看透明度（Opacity）来剪枝，渲染质量会掉到 26.84。双管齐下（透明度+尺度）才能稳在 27.12。证明了那些“大而淡”的高斯点是万万不可删的。

[图：详见论文Figure 7] 视图依赖增强策略对比。没有该策略（左），自行车与背景草地存在严重的透明度混淆；加入该策略（右），前后景分离清晰。

局限性分析与客观评价

作为一篇探讨技术的文章，必须实事求是。Mobile-GS虽然在移动端表现惊艳，但它同样存在现阶段的技术短板（论文作者也很实在地列出来了）：

• 训练成本与复杂性依然很高

虽然推理（Inference time scaling）快到起飞，但它的训练管线异常繁琐。你需要先跑一个Mini-Splatting预训练，然后再接上多视角的微调、蒸馏、量化聚类。目前这套流程必须在桌面级强力GPU上跑完，无法在手机上实现实时的数据采集和边采边训。

• 泛化能力受限（Per-scene Optimization）

这是目前大多数3DGS的通病：一景一训。Mobile-GS同样不具备跨场景的泛化能力。如果你想用它做那种“掏出手机扫一圈，立刻生成AR模型”的应用，目前还做不到即时计算，必须传回云端处理。

• 极致量化带来的细节损失

客观地说，虽然量化器和MLP解码器尽力弥补了画质，但在某些极其精细的纹理区域（比如复杂的反光金属面），它依然不可避免地会出现轻微的色彩偏移或模糊。这是将800MB数据塞进4MB的物理极限妥协。

总结与行业思考

这两年端侧AI的呼声越来越高，尤其是随着苹果、Meta等大厂在XR硬件上的持续发力，行业内出现了一个非常明显的矛盾：算法越来越重，而边缘设备的电池和散热并没有质的飞跃。

Mobile-GS 的出现，给我们提供了一个非常好的解题思路：打破常规管线的束缚（放弃深度排序），用极小代价的AI算力（MLP解码）去填补物理渲染的缺陷，最终用工程化的手段（Vulkan/内存优化）去落地。

不得不说，这套“提速->补质->极度压缩”的连招打得非常漂亮。如果你正在做空间计算、AR/VR应用，或者正在死磕手机端的高性能3D渲染，这个项目的源码和思路，绝对值得你拉下来仔细拆解一番。

[图：详见论文Figure 8] 更多场景下与Speedy-Splat、SortFreeGS等优秀框架的可视化对比。Mobile-GS在极高的压缩率下，依然保持了不错的场景层次感。

这就是今天对 Mobile-GS 的深度硬核拆解。项目刚刚出炉，热乎的，代码也已经在GitHub上开源，感兴趣的兄弟们可以赶紧去跑跑看了。有啥问题，咱们评论区见。

<原文链接：https://mp.weixin.qq.com/s/_YBP-ukbTg5DtR8S7OHj3Q

文章版权归作者所有，未经允许请勿转载。

THE END

AI 资讯

高斯溅射移动端落地：手机跑 3DGS 不卡了？4.6MB 模型干到 127 帧，Mobile-GS 直接封神！