Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследователи из Indian Institute of Technology Jodhpur представили H3DNAS — систему сжатия 3D-моделей непосредственно на уровне ONNX-графа; работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, самый быстрый вариант выполнял вывод на центральном процессоре до 1,99 раза быстрее исходной модели. Подход важен командам, которым досталась готовая ONNX-модель без исходного кода, но нужно разместить её на периферийном устройстве с ограничениями по памяти и времени ответа.
Что сделали
H3DNAS принимает сериализованную ONNX-модель и работает с ней как с вычислительным графом. Система восстанавливает формы тензоров, оценивает число параметров и вычислительных операций, а затем определяет, какие каналы можно удалить без нарушения связей между операторами.
Для этого авторы построили граф зависимостей каналов. Операции в нём разделяются на создающие каналы, пропускающие их без изменений, связывающие размеры нескольких тензоров и завершающие обработку канального измерения. Ограничениями также становятся групповые свёртки, сложение вычисляемых тензоров, зафиксированные формы, параметры нормализации и выходной слой.
Такой анализ должен заранее показывать, какая часть модели доступна для структурного прореживания — удаления целых каналов вместе с соответствующими весами. В отличие от удаления отдельных весов, структурное прореживание может ускорять обычное плотное выполнение без специализированной поддержки разреженных матриц.
Поиск проходит в два этапа. Сначала H3DNAS меняет ширину слоёв и удаляет каналы с наименьшей суммой абсолютных значений весов. Выбранные индексы распространяются на следующие операции и параметры пакетной нормализации, чтобы изменённый граф оставался согласованным.
Кандидаты предварительно ранжируются без меток: система подаёт одинаковые случайные входы в исходную и сжатую модели, после чего сравнивает направления их выходных векторов с помощью косинусного сходства. До полноценной проверки доходят варианты, чьи выходы ближе к исходным.
На втором этапе отдельные свёртки можно заменить структурой GhostConv. Она вычисляет часть признаков обычной свёрткой, а остальные получает более дешёвыми поканальными операциями. Затем система объединяет кандидатов и оставляет Парето-фронт — варианты, для которых нельзя одновременно улучшить точность и сократить вычислительную стоимость. Ограничения по числу параметров, размеру файла, операциям и задержке проверяются внутри поиска.
Что показали
Основные эксперименты авторы провели на классификации облаков точек из ModelNet40:
- для PointNet число параметров уменьшилось на 65,5%;
- для PointNet++ — на 43,2%;
- для PointMLP — на 49,1%;
- ускорение на центральном процессоре составило от 1,29 до 1,99 раза в зависимости от архитектуры.
Результаты показывают различие между размером модели и фактической задержкой. Сокращение почти половины параметров не гарантировало двукратного ускорения: эффект зависел от структуры графа и реализации операций. Поэтому H3DNAS измеряет время выполнения на целевом устройстве, а не использует число параметров как его замену.
Ограничения
Главная проверка охватывает один датасет, три архитектуры облаков точек и одну платформу семейства NVIDIA Jetson. Это не показывает, как метод ведёт себя на других периферийных ускорителях, задачах обнаружения и сегментации или моделях с нестандартными ONNX-операциями. Более широкая проверка ONNX-графов подтверждает в основном техническую возможность получить исполняемый граф, но не тот же выигрыш в точности и задержке.
Сравнение с другими методами структурного прореживания авторы провели только для PointNet и при отдельном, более умеренном бюджете сжатия. Сопоставленные методы требовали исходного кода и дообучения, поэтому работа не даёт прямого сравнения с другой системой, которая решала бы ту же задачу исключительно по ONNX-файлу.
Есть и внутреннее расхождение в описании графа зависимостей. В одной части работы доля свободных параметров названа верхней границей сжатия, а в расширенных результатах — лишь показателем безопасности, который фактическое сокращение может превысить за счёт уменьшения входов следующих слоёв. Пока это определение не уточнено, показатель нельзя использовать как строгую гарантию достижимого размера.
Наконец, поиск не требует размеченных данных, но итоговую точность авторы проверяют на размеченной выборке. Близость выходов к исходной модели — фильтр кандидатов, а не доказательство сохранения качества на целевой задаче.
Что это значит
Работа меняет планы команд в одном конкретном сценарии: когда исходный код модели недоступен или несовместим с текущим стеком, но имеется ONNX-файл. В таком случае восстановление исходного проекта перестаёт быть обязательным первым шагом. Можно начать с анализа графа, проверить доступные для удаления каналы и провести поиск под реальные ограничения устройства.
Для действующего продукта H3DNAS пока стоит рассматривать как основу для опытного внедрения, а не как готовую замену существующего конвейера оптимизации. Проверка должна включать не только размер модели, но и задержку с тем же поставщиком выполнения, пакетным размером и формой входа, которые используются в продукте. Отдельно потребуется измерить качество на собственных данных и проверить все изменённые графы средствами ONNX Runtime или TensorRT.
Если у команды есть исходный код и возможность дообучения, работа не доказывает преимущество H3DNAS перед обычным структурным прореживанием. Её практическая ценность находится в другом: авторы показали воспроизводимый путь от закрытого ONNX-бинарника к нескольким аппаратно проверенным вариантам без участия исходного фреймворка в поиске.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
