Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Конвейер, который сводит камеры и лидар в вид сцены сверху, удалось запустить без привязки всех вычислений к CUDA. Хотя работу Rohit Verma и Anand V Bodas не рецензировали и все числа получили сами авторы, BEVPIPE ускорил обработку в 19,5 раза и сохранил 98,5% качества эталона по mAP — усреднённой точности обнаружения. Для команд это превращает выбор GPU из свойства модели в решение на уровне нескольких внешних модулей.
Среда инференса понимает только часть BEV-конвейера
Модель строит представление сцены с высоты птичьего полёта (BEV) из изображений и облака точек. Внутри такого конвейера соседствуют плотные, разреженные и геометрические операции, но стандартные среды инференса хорошо оптимизируют только первую группу.
Плотные свёртки, преобразователи и полносвязные слои работают с регулярными тензорами известных размеров. Среда может объединять соседние операции, заранее распределять память и подбирать ядра под конкретный GPU.
Разреженная трёхмерная свёртка устроена иначе. Она обрабатывает только занятые воксели, а их набор и связи между соседями меняются с каждым облаком точек. Статический вычислительный граф не может заранее выразить такую структуру.
Геометрические операции создают ещё один разрыв. Вокселизация раскладывает точки по пространственным ячейкам, а проекция признаков от камер записывает значения в сетку вида сверху. Обе операции используют хеш-таблицы, ветвления по координатам и конкурентное накопление значений.
Если среда не знает такую операцию, она переносит её на процессор, требует отдельного подключаемого ядра или отвергает модель. Существующие библиотеки разреженных свёрток связаны с PyTorch и CUDA, поэтому перенос на GPU другого производителя затрагивает не только сборку, но и весь путь выполнения модели.
Границу провели вокруг целой ветви, а не каждого слоя
BEVPIPE оставляет обработку изображений, объединение признаков и детектор внутри производственной среды инференса. Внешние модули берут на себя вокселизацию, разреженный кодировщик лидара и проекцию камер в вид сверху. Их ядра написаны через переносимые GPU API OpenCL и SYCL.
Все части работают в общем контексте GPU и передают тензоры через общую память. Это убирает копирование через оперативную память процессора, но само переключение между средой и внешним модулем всё равно требует синхронизации. Кроме того, на такой границе среда уже не может объединять операции и самостоятельно управлять промежуточными буферами.
Поэтому отдельное расширение на каждый разреженный слой оказалось неудачной схемой. BEVPIPE помещает весь кодировщик в один крупный модуль вместе с нормализацией, активациями, остаточными связями и преобразованием разреженного результата в плотную карту.
Внутри модуля признаки не покидают GPU. Хеш-таблицы и карты соседей используются повторно, два постоянных буфера по очереди принимают вход и результат, а веса преобразуются в нужный формат при первом запуске. Среда инференса видит только вход и выход ветви, а не её внутренние слои.
Для вокселизации и проекции авторы заменили сложное накопление чисел с плавающей точкой на целочисленные атомарные операции с фиксированным масштабом. Проекция также пропускает маловероятные варианты глубины. Эти решения сокращают число конкурентных записей в одну ячейку и не требуют CUDA-специфичных примитивов.
Переносимость меняет архитектуру, но не отменяет замеры на целевом GPU
В сравнении использовали одинаковые GPU-ядра и меняли только размер внешних модулей. Мелкое разбиение ускорило полный конвейер в 10,1 раза относительно варианта с переносом неподдерживаемых операций на процессор, среднее — в 14,9 раза. Максимальный результат дало укрупнение по ветвям, поэтому разница связана с числом границ, а не с более быстрыми свёртками.
Профилирование показывает, почему дальнейшая оптимизация самих вычислительных ядер даст ограниченный эффект: 52,91% времени разреженного кодировщика занимали запуск команд и синхронизация. Узким местом стала организация работы между процессором и GPU, а не арифметика свёртки.
Производительность измеряли на подмножестве из 81 примера и встроенном Intel GPU с 96 исполнительными блоками. Переносимость проверяли отдельно через SYCL на Intel и NVIDIA: исходный код ядер и управляющей части не меняли, а результаты обнаружения остались близки к варианту на OpenCL. Это подтверждает функциональный перенос, но не равную задержку на разных GPU.
Число ускорения относится к базовой схеме, где неподдерживаемые операции выполняет процессор. Его нельзя напрямую использовать как преимущество перед оптимизированным конвейером на TensorRT с собственными CUDA-модулями.
Работа меняет планы команд, которым нужен один BEV-конвейер для нескольких семейств GPU. В архитектуре стоит заранее разделить плотные, разреженные и геометрические вычисления, закрепить форматы тензоров на границах и укрупнить внешние модули до уровня ветвей. Тогда смена оборудования затронет переносимый вычислительный слой, а не всю модель.
Если продукт остаётся на NVIDIA и уже использует настроенные CUDA-модули, BEVPIPE не даёт основания немедленно их заменять. Практический результат работы здесь другой: при выборе нового оборудования нужно измерять не только скорость отдельных ядер, но и полную стоимость границ, очередей команд и синхронизации.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
