RLSplat：前馈 3D 高斯泼溅按指定高斯数生成，显存延迟一起降

速览

给模型一个数字 B，它只生成 B 个 3D 高斯，推理延迟和峰值显存也跟着 B 一起下降。这是 RLSplat 做到的事。在此之前，前馈式 3D 高斯泼溅里的预算旋钮只能改变输出表示有多大，改变不了生成这个表示的代价。

论文给出的一组数字是：8 个上下文视图、每视图 1K 预算时 PSNR 24.82 dB，比最强基线 F4Splat 高约 1.2 dB；2K 预算下峰值显存只有 F4Splat 的约 1/9.6，速度快 4.1 倍。这篇论文是 arXiv:2610.27712，作者来自 KAIST 与 Korea University，目前是预印本。这些数字的分量要看部署场景才能体会。机器人、AR、边缘设备给的是显存和延迟的硬上限，用户手里只有一个数字可以填。此前的方法填这个数字只能省下存储，省不下推理开销。

要把这件事说清，先接受一个物理事实。3D 高斯泼溅用一堆显式基元表示场景，每个高斯有自己的位置、协方差、不透明度和球谐颜色，渲染时全部要投影、排序、混合。3DGS 原文自述，大规模场景要把几百 MB 显存用来存放整个模型，光栅化器还要再占 30 到 500 MB。前馈式方法把逐场景优化换成一次前向，网络看完几张图直接吐出高斯，但每个高斯的账单没有变。pixelSplat 最早把这条路走通，对每个像素预测若干高斯，两个视图的高斯直接取并集而不去重，重复也就此埋下。pixelSplat

图注：3DGS 的原始管线。SfM 点云初始化出高斯集合，自适应密度控制增删高斯，相机与高斯一起进入投影和 tile 可微光栅化后输出图像；图例区分黑色的正向操作流与蓝色的反向梯度流。3DGS

沿着这条管线看前人的预算旋钮，问题就很具体。EcoSplat 和 F4Splat 这类方法都先预测一个远大于预算的密集集合，再从中挑选。F4Splat 的推理流程把这一点画得很直白：三个不同的目标高斯数指向同一个分配模块，backbone 和预测头始终是同一套，预算只改变阈值。F4Splat 自己的补充材料 S2 给了数字，高斯总数比均匀分配少 20%，峰值分配显存却从 8.699 GB 升到 8.855 GB，推理时间从 0.440 s 升到 0.488 s。F4Splat

图注：F4Splat 的总览图，上半是训练管线，下半是推理管线。下半图中三个蓝色预算标记 N̄_G、N̄'_G、N̄''_G 指向同一个空间自适应高斯分配模块，再输出三张规模不同的表示。F4Splat

EcoSplat 的附录表 5 更直接。24 视图下，5% 预算档 78K 高斯与 40% 预算档 629K 高斯，重建延迟都是 0.52 秒。预算差 8 倍，生成耗时一模一样，随预算变化的只有渲染 FPS 和存储体积。EcoSplat

同期的 ZipSplat 换了另一条路，在推理期用 k-means 把视觉 token 聚成场景 token，但压缩发生在密集预测之后。它附录自述 40 层 backbone 占约四分之三前向时间，压缩只能削掉剩下的四分之一，192 视图下压缩比调到 0.5，前向时间反而从 5.4 s 涨到 9.6 s。ZipSplat

于是 RLSplat 把要求写成一个定义。resource-linear 指三件事同时随预算 B 近似线性下降：表示大小、推理延迟、峰值显存。注意近似这个词，Fig 1(c) 的标注原文是 decreases approximately linearly，不是严格线性。

图注：Fig 1 三联图。(a) PSNR 随总高斯预算 B 变化的曲线；(b) 峰值显存与 PSNR 的对比，图内标注 9.6× less memory at higher PSNR；(c) 延迟随预算变化，图内标注 Nearly constant 两次、Decreases linearly 一次，轴刻度注明 1K = 1,024。RLSplat

这张图把问题立住了。两条基线的延迟曲线几乎是水平的，只有 RLSplat 随预算往下走。预算在这条曲线上第一次同时是质量旋钮和成本旋钮。

解法是把预算先分给场景的局部区域，再只解码这么多高斯

RLSplat 的解法可以压成一句话：先把总预算分给场景的局部区域，再只解码这么多高斯。总量在生成之前就锁定，因此既不需要一个远大于预算的候选集，也没有事后裁剪这一步。

架构分三段。左侧几何 backbone 吃进无标定的上下文图像，输出相机参数和 N 个 anchor token，每个 token 代表一个局部 3D 区域。这一段用的是 Déjà View 的循环 transformer，推理跑 12 步，图像先上采样到 504×504。它本身的原生输出是逐像素的深度、射线和相机参数，RLSplat 把它编码出的局部区域特征当作 anchor token 使用。Déjà View

中段是分配策略。它读入所有 anchor token，再读入一个预算标量 u = log2(B/N)，用 FiLM 把 u 调制进特征，为每个 anchor 输出一个比例 p_n。训练时按 k ~ Mult(B, p) 采样，推理时改用固定相位 φ=1/2 的系统化取整，把 B·p_n 变成整数。这一步保证每个 k_n 只能取 floor(Bp_n) 或 ceil(Bp_n)，而所有 k_n 严格加起来等于 B。以 8 视图、每视图 1K 为例，B 是 8192，这笔预算在生成第一个高斯之前就已经分完。

讲解：预算怎么在生成前精确分完

右段是解码。每个 anchor 按分到的 k_n 生成 k_n 个高斯 token，全部拼成一条长度恰好为 B 的序列，再经局部交叉注意力精修，最后输出 B 个高斯。

图注：Fig 2 总体架构。左侧无标定上下文图像进入几何 backbone，输出相机参数与 anchor tokens；中段是离散分配，图上标出 Σk_n = B；右侧经层级邻居搜索与局部交叉注意力，输出恰好 B 个高斯。RLSplat

这种「总量拆给局部、局部各自动手」的结构和分治很像，子问题的预算之和恒等于总预算，所以精确的总量是分配出来的，不是裁剪凑出来的。差别在合并方式：这里合并的是空间上并列的局部结果，没有把子解合成一个新解。

线性是两处设计换来的：分配交给强化学习，解码只看 16 个近邻

线性不是免费的。它由两处设计换来：分配那一环必须真的能决定「挑哪里」，解码那一环必须把代价从平方压到线性。

分配为什么用强化学习。策略输出的是每个区域分几个高斯，这是离散决策，不可微。更麻烦的是，一次分配好不好没有局部标准，只能把高斯渲染出来，看图像像不像。于是 RLSplat 把它当成策略优化问题：一次完整分配是一条长度为 B 的序列，奖励取负的重建损失，同一场景同一预算下采 C=5 次，用组内标准化优势判断这次分配比同组其他几次好还是差，重要性比在序列级做长度归一化。这套工具来自 GSPO。GSPO

效果要如实看。在相同 base 模型上微调 1K 步后，学出来的策略是 24.83 dB，Sobel 梯度启发式 24.76，均匀分配 24.53，随机分配 24.18。策略确实比手工规则好，但相对最好的启发式只领先 0.07 dB，相对均匀分配是 0.30 dB。这组消融是短程微调，绝对值不能与主表横比。

分配也不是非得用强化学习。SplatWeaver 用一组按基数分化的专家加像素级路由，Gumbel-Softmax 直通让训练全程可微，但它不保证总数等于某个指定值，推理期也没有预算旋钮，总量是路由涌现出来的。SplatWeaver

解码侧的理由是复杂度。若每个高斯 token 对所有其他 token 做注意力，代价是 O(B²)。RLSplat 让每个 token 只对自己的近邻做交叉注意力，代价降到 O(B·K_gs)。近邻也不是现算的，而是分两层找：先在 anchor 质心上取 16 个最近的 anchor，再只在这些 anchor 之内取 16 个最近的高斯。两套邻域都只用 detached 的初始位置算一次，跨两层共享。

这相当于查邻接表，而不是把所有节点两两比较一遍。代价从平方级降到只看自己的邻居，前提是邻居表建得准。

邻居表要准，靠三个正则。去掉 projection 项，anchor 与它编码来源的图像区域脱钩，训练直接失败，PSNR 5.80、SSIM 0.007。去掉 offset 项，精修会把高斯挪离初始位置，掉 0.53 dB。再去掉 Voronoi 项，高斯跑出自己 anchor 的势力范围，层级搜索取不到真近邻，最近邻命中一致率从 99.0% 掉到 60.2%，累计掉 2.51 dB。另外，单独去掉局部精修模块则掉 0.96 dB。三个正则不是装饰，是「只查 16 个邻居」这个近似能够成立的前提。

代价也量过。65,536 个高斯时，层级搜索 8.1 ms，精确搜索 220.8 ms，端到端从 539.2 ms 降到 328.3 ms。搜索耗时取自 Table 5，同一实验在正文 §4.2 写作 219.6 ms。搜索快了约 27 倍，端到端只快约 1.6 倍，因为剩下的是与高斯数量无关的固定开销。这个比例在最后一章还要用到。

讲解：查 16 个邻居，代价从平方变线性

策略在做什么，Fig 6 给了直观答案。

图注：Fig 6 学习到的分配策略。两组 RE10K 场景，每组两个输入视图、平均每视图 1024 个高斯。热图编码相对均匀分配的偏离，红色表示分得更多、蓝色表示更少，为显示做过平滑。RLSplat

预算从平坦墙面和水面挪向床、楼梯、建筑立面这类结构复杂的区域，这与「把高斯花在难重建的地方」的直觉一致。

预算越低差距越大：1K 时比 F4Splat 高 1.2 dB，2K 时显存少约 9.6 倍

结果的优势集中在低预算区，而且只在特定口径下成立，所以先讲口径再讲数字。训练用 RE10K，评测是 ACID 零样本 249 个测试场景，分辨率 256×256，预算按每个上下文视图记，1K 就是 1024。延迟与峰值显存只测高斯生成，明确排除数据加载、位姿对齐与渲染，单张 RTX A6000，batch=1，每个预算丢掉首个场景预热并重置峰值计数器。协议沿用 F4Splat。

这个口径有两个直接后果。表里的 #GS 是每场景总数，所以 8 视图、每视图 1K 对应 8K 个高斯。延迟数字不含渲染，不能与端到端出图的耗时并列。下面是 8 视图下三档预算的 PSNR。

三行数字里最值得看的是 EcoSplat 那一列。1K 时它掉到 18.99 dB，比 4K 档低了 4.3 dB。先密集预测再裁剪的路线在小预算下会断崖，因为可挑的东西本来就不多。RLSplat 的曲线几乎是平的，从 1K 到 4K 只涨 0.42 dB，F4Splat 则涨 0.89 dB。相对 F4Splat 的优势随预算下降而扩大：4K 时 0.74 dB，2K 时 0.99 dB，1K 时 1.22 dB。1K 的 1.22 dB 取自正文 §4.1，表内相减是 1.21 dB，差在四舍五入。

24 视图还有一组更醒目的对比。RLSplat 用 24K 高斯到 25.58 dB，SPFSplat 用 1536K 高斯只到 25.00 dB，更高的 PSNR 只用了 1/64 的基元。SPFSplat 这类 budget-fixed 方法的高斯数会随视图数自己往上爬，因为数量由像素或体素决定，接口里根本没有目标数量这个输入。AnySplat

9.6 倍显存和 4.1 倍速度只在 2K 预算、且只对 F4Splat 成立。论文没有给逐预算的显存与延迟数值表，只有趋势和这一个单点，所以不能把倍数外推到 1K 或 4K。

这些提升算真能用还是刷了个榜，判断依据是它在哪一段预算上赢。低预算正是旧方法崩掉的地方，也正是边缘部署通常只能选的档位。但它赢得并不宽：4K 时只剩 0.74 dB，说明预算宽松时密集预测加裁剪的路线依然够用。

这条线性有地板：图像编码不随预算缩小，评测也只到 256×256

这条线性有地板。图像编码是与预算无关的固定成本，因此总耗时近似是「常数项加上与预算成正比的一项」，预算越小常数项占比越大，端到端加速比就在这里封顶。Fig 1(c) 的延迟曲线不会穿过零点，原因也在这里。

这也解释了上一章末那组数字。搜索从 220.8 ms 降到 8.1 ms，端到端只从 539.2 ms 降到 328.3 ms，因为 backbone 那一段没有随预算缩小。Déjà View 那个 117M 参数、75.9 TFLOPs 的 backbone，前向代价只随视图数、输入分辨率和推理步数变化，预算 B 根本不进入它。

其余边界论文自己在附录里写了三条。只在 256×256 评测。只有一次跨数据集设定，RE10K 训练、ACID 零样本，没有同域评测。下游任务没有做，3D 视觉语言模型和机器人学习只列为下一步。

还有一条容易被混读。Anchor3DGS 也用 anchor，但它的 anchor 是从几何脚手架采样的三维场景点，总数由 32,768 这个全局超参固定，每个 anchor 解码 8 个局部高斯，约 0.26M 每场景，与视角数无关。它让数量与输入解耦，却没有报告延迟随预算变化的曲线，评测也在 448×448。RLSplat 的 anchor token 是 backbone 的特征载体，分到几个高斯由策略决定，两侧口径不能直接比高低。Anchor3DGS

复现成本要说清。评测与推理代码、预训练权重已经发布，训练代码尚未发布，环境需要从 pinned commit 安装 DVLT 与 PyTorch3D，不是一条 pip 命令能跑起来。RLSplat 仓库

所以它适合谁：显存和延迟有硬上限、预算偏小、需要严格总量控制的部署。如果分辨率远高于 256×256，或者希望渲染那一侧也随预算变快，这篇论文没有验证。它解决的是「预算该管到生成代价」这个问题，不是「整条前馈管线都能按预算伸缩」。

一句话记住它：预算第一次同时决定了表示有多大、生成要多久。想深入可以读原文：RLSplat: Resource-Linear Budget Control for Feed-forward 3D Gaussian Splatting，arXiv:2610.27712。

参考文献

1. RLSplat: Resource-Linear Budget Control for Feed-forward 3D Gaussian Splatting，https://arxiv.org/abs/2610.27712
2. 3D Gaussian Splatting for Real-Time Radiance Field Rendering，https://arxiv.org/abs/2308.04079
3. pixelSplat: 3D Gaussian Splats from Image Pairs for Scalable Generalizable 3D Reconstruction，https://arxiv.org/abs/2312.12337
4. EcoSplat: Efficiency-controllable Feed-forward 3D Gaussian Splatting from Multi-view Images，https://arxiv.org/abs/2512.18692
5. F4Splat: Feed-Forward Predictive Densification for Feed-Forward 3D Gaussian Splatting，https://arxiv.org/abs/2603.21304
6. AnySplat: Feed-forward 3D Gaussian Splatting from Unconstrained Views，https://arxiv.org/abs/2505.23716
7. C3G: Learning Compact 3D Representations with 2K Gaussians，https://arxiv.org/abs/2512.04021
8. ZipSplat: Fewer Gaussians, Better Splats，https://arxiv.org/abs/2606.05102
9. Anchor3DGS: Feed-Forward 3D Gaussian Splatting with Compact Anchor-Based Representation，https://arxiv.org/abs/2610.21634
10. SplatWeaver: Learning to Allocate Gaussian Primitives for Generalizable Novel View Synthesis，https://arxiv.org/abs/2605.07287
11. Déjà View: Looping Transformers for Multi-View 3D Reconstruction，https://arxiv.org/abs/2605.30215
12. Group Sequence Policy Optimization，https://arxiv.org/abs/2507.18071