RLSplat учит 3D Gaussian Splatting экономить: до 4,1× быстрее и в 9,6× меньше памяти

Feed-forward 3D Gaussian Splatting собирает трёхмерную сцену из набора фотографий за один проход нейросети, без долгой пооптимизации под каждую сцену. Метод RLSplat добавляет к этому то, чего у предшественников не было: задержка, пиковая память и размер представления снижаются линейно вместе с заданным бюджетом гауссиан. В zero-shot-тестах он обходит прежние бюджетно-управляемые подходы при любом бюджете и опережает сильнейший baseline, даже имея в четыре раза меньше гауссиан. На малых бюджетах он работает до 4,1 раза быстрее и использует в 9,6 раза меньше пиковой памяти.

Прореживание, которое съедает всю экономию

Идея бюджетного контроля в FF3DGS понятна: на выходе сцена должна уложиться в лимит по хранилищу или по времени рендеринга. Телефону или headset нужна лёгкая сцена, серверу с запасом ресурсов подойдёт плотная. Существующие методы дают такую регулировку, но с подвохом. Чтобы получить, скажем, 50 тысяч гауссиан, они сначала предсказывают плотное множество, а затем отбирают или отсекают лишнее.

Итог: итоговый файл действительно маленький, но путь к нему стоит одинаково дорого. Задержка вывода и пиковая память остаются почти постоянными независимо от бюджета. Для устройства, у которого проблема именно в памяти во время инференса, такой «бюджет» ничего не решает: ресурсы на плотный этап всё равно нужны.

Как RLSplat раздаёт гауссианы

Авторы убирают сам этап «сначала много, потом меньше». Вместо прунинга или селекции RLSplat обучает политику аллокации. Она распределяет заданный бюджет по локальным областям сцены, и в результате создаётся ровно запрошенное число гауссиан. Сложные участки получают больше, простые меньше.

Вторая часть решения касается уточнения параметров. Гауссианы проходят через resource-linear Gaussian decoding: каждая обращается с вниманием только к ближайшим соседям, которых находит эффективный иерархический поиск. Полное внимание между всеми гауссианами росло бы быстрее, чем число самих элементов. Локальное внимание делает стоимость декодирования линейной, поэтому при сокращении бюджета падает и время, и память.

Ключевые характеристики из работы:

• Бюджет: число гауссиан задаётся при инференсе и выдаётся точно, без пост-отбора.
• Масштабирование: размер представления, задержка и пиковая память снижаются линейно с бюджетом.
• Скорость: до 4,1× быстрее предыдущих методов на малых бюджетах.
• Память: до 9,6× меньше пиковой на малых бюджетах.
• Качество: лучше прежних бюджетно-управляемых методов при каждом бюджете в zero-shot-оценке.
• Эффективность: превосходит сильнейший baseline, используя в 4 раза меньше гауссиан.

Где это можно применить

Сильнее всего результат касается сценариев с жёстким потолком по ресурсам: AR и VR на автономных гарнитурах, мобильные приложения для быстрого сканирования помещений, робототехника, где карту нужно обновлять на борту, и облачные сервисы, которые обрабатывают тысячи сцен параллельно. В последнем случае девятикратная экономия пиковой памяти означает возможность разместить больше задач на одном ускорителе.

Для инженеров вывод практичный. Если вы выбираете реконструкционный пайплайн под устройство с ограниченной памятью, смотреть нужно не только на размер итоговой сцены, но и на то, как меняются латентность и пик потребления при снижении бюджета. Подход с отбором из плотного множества на таком тесте выглядит слабее. Подход с аллокацией сразу под целевой бюджет, как в RLSplat, позволяет подбирать качество под железо плавно: уменьшили бюджет, получили пропорционально более быстрый и лёгкий результат.

Тот факт, что выигрыш получен в zero-shot-режиме, то есть без дообучения под новые данные, делает метод кандидатом для встраивания в продукты, где сцены заранее неизвестны. Остаётся проверить, как политика аллокации ведёт себя на очень больших или нетипичных сценах, но принцип уже ясен: стоимость вывода должна масштабироваться вместе с запрошенным результатом.