Zero-Host-Copy: как гнать YOLOv8m на 165–215 FPS, убрав CPU из горячего цикла

Вы оптимизировали модель, квантовали её в INT8, и инференс занимает пару миллисекунд. А FPS всё равно далёк от ожидаемого. Знакомая история: узким местом становится не вычислитель, а всё, что вокруг него. Разбор на Хабре показывает, как с этим справиться на практике.

Где на самом деле теряются кадры

На дискретной видеокарте каждый кадр высокого разрешения, который уезжает в оперативную память и возвращается обратно, платит налог шиной PCIe. Если дополнительно гонять туда-сюда промежуточные результаты, например bounding boxes для детекции, пропускная способность падает заметно. Чем быстрее модель, тем сильнее эта цена бросается в глаза: считает она за 2 мс, а копирование занимает больше самого расчёта.

Идея Zero-Host-Copy проста: данные с момента чтения с диска и декодирования до финального кодирования и записи остаются в памяти GPU. Обрабатывает их только видеокарта, а копии GPU → CPU и обратно сводятся к минимуму. Родственная идея Zero-Copy: между этапами конвейера передаётся указатель на блок данных, а не сам блок.

Тихий убийца: cudaMalloc

Вторая проблема менее очевидна. Вызов cudaMalloc приводит к неявной синхронизации: CPU вынужден ждать GPU, и асинхронный конвейер перестаёт быть асинхронным. Один такой вызов в цикле обработки кадров может дать просадку, которую профилировщик покажет как загадочные паузы.

Решение — жизненный цикл из трёх фаз:

• Инициализация. Приложение заранее выделяет пулы памяти, буферы и очереди с начальной глубиной.
• Прогрев. Запускается полная очередь обработки. Если нужны дополнительные буферы, система выделяет их именно здесь.
• Активная работа. После нескольких первых кадров динамическое выделение запрещено: никаких cudaMalloc и new, только повторное использование уже выделенных блоков.

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

Что получилось

Автор реализовал конвейер без DeepStream на чистом C++/CUDA. YOLOv8m при разрешении 1024x1024 в INT8 показывает примерно 165–215 FPS на RTX 3060 Ti и около 38 FPS на Jetson Orin Nano Super. Для встраиваемой платформы это очень достойный результат при таком размере входа.

Ограничения и вывод

Цена подхода — сложность. Bare-metal конвейер требует ручного управления пулами, синхронизацией потоков и жизненным циклом буферов. Ошибка в размере пула приведёт к падению или скрытой деградации в горячей фазе. Поддерживать такое дороже, чем собрать решение на DeepStream или готовом фреймворке. Кроме того, цифры получены на конкретной модели и конкретном железе, а в статье, судя по анонсу, нет сравнения с готовыми стеками на тех же условиях, так что выигрыш стоит проверять на своих данных.

Практический вывод для тех, кто делает видеоаналитику или работает с edge-устройствами:

• Прежде чем оптимизировать модель дальше, измерьте, сколько времени уходит на копирование и аллокации.
• Найдите в горячем цикле все cudaMalloc, new и неявные синхронизации и вынесите их в инициализацию.
• Проектируйте конвейер так, чтобы кадр не покидал GPU: аппаратное декодирование, препроцессинг, инференс, постобработка, кодирование.
• Заложите прогревочную фазу и проверяйте, что после неё аллокаций больше нет.

Когда модель уже быстрая, выигрыш лежит в инженерной дисциплине вокруг неё. Для реального времени на видеопотоках это часто самый дешёвый способ получить кратный прирост FPS.