Zero-Host-Copy: como rodar o YOLOv8m a 165–215 FPS removendo a CPU do loop quente

Você otimizou o modelo, quantizou para INT8, e a inferência leva alguns milissegundos. Mesmo assim, o FPS continua longe do esperado. É uma história conhecida: o gargalo não é a unidade de cálculo, mas tudo o que está ao redor dela. Uma análise publicada no Habr mostra como lidar com isso na prática.

Onde os quadros realmente se perdem

Em uma placa de vídeo dedicada, cada quadro de alta resolução que vai para a memória RAM e volta paga um pedágio ao barramento PCIe. Se, além disso, resultados intermediários, como bounding boxes da detecção, também são enviados de um lado para outro, a largura de banda cai de forma perceptível. Quanto mais rápido o modelo, mais esse custo salta aos olhos: ele calcula em 2 ms, mas a cópia leva mais tempo que o próprio cálculo.

A ideia do Zero-Host-Copy é simples: desde o momento em que os dados são lidos do disco e decodificados até a codificação final e a gravação, eles permanecem na memória da GPU. Somente a placa de vídeo os processa, e as cópias GPU → CPU e de volta são reduzidas ao mínimo. Uma ideia relacionada, o Zero-Copy, consiste em passar entre as etapas do pipeline um ponteiro para o bloco de dados, e não o bloco em si.

O assassino silencioso: cudaMalloc

O segundo problema é menos óbvio. A chamada a cudaMalloc provoca uma sincronização implícita: a CPU precisa esperar a GPU, e o pipeline assíncrono deixa de ser assíncrono. Uma única chamada dessas no loop de processamento de quadros pode causar uma queda que o profiler mostrará como pausas misteriosas.

A solução é um ciclo de vida em três fases:

• Inicialização. A aplicação aloca antecipadamente pools de memória, buffers e filas com profundidade inicial.
• Aquecimento. A fila de processamento completa é executada. Se forem necessários buffers adicionais, o sistema os aloca justamente aqui.
• Operação ativa. Depois dos primeiros quadros, a alocação dinâmica é proibida: nada de cudaMalloc e new, apenas reutilização de blocos já alocados.

Na essência, é uma técnica conhecida de engines de jogos e do processamento de áudio: tudo o que é pesado é feito antes do início, e no loop quente apenas se reutiliza.

O que foi obtido

O autor implementou um pipeline sem DeepStream em C++/CUDA puro. O YOLOv8m com resolução de 1024x1024 em INT8 apresenta cerca de 165–215 FPS em uma RTX 3060 Ti e aproximadamente 38 FPS em um Jetson Orin Nano Super. Para uma plataforma embarcada, é um resultado muito digno para esse tamanho de entrada.

Limitações e conclusão

O preço da abordagem é a complexidade. Um pipeline bare-metal exige gerenciamento manual de pools, sincronização de streams e ciclo de vida dos buffers. Um erro no tamanho do pool levará a uma falha ou a uma degradação oculta na fase quente. Manter algo assim é mais caro do que montar uma solução sobre o DeepStream ou um framework pronto. Além disso, os números foram obtidos com um modelo específico e um hardware específico, e no artigo, a julgar pelo anúncio, não há comparação com stacks prontos nas mesmas condições, então vale verificar o ganho com seus próprios dados.

Conclusões práticas para quem trabalha com videoanálise ou com dispositivos edge:

• Antes de otimizar mais o modelo, meça quanto tempo é gasto com cópias e alocações.
• Encontre no loop quente todos os cudaMalloc, new e sincronizações implícitas e mova-os para a inicialização.
• Projete o pipeline para que o quadro não saia da GPU: decodificação por hardware, pré-processamento, inferência, pós-processamento, codificação.
• Inclua uma fase de aquecimento e verifique que, depois dela, não há mais alocações.

Quando o modelo já é rápido, o ganho está na disciplina de engenharia ao redor dele. Para tempo real em fluxos de vídeo, essa costuma ser a maneira mais barata de obter um aumento múltiplo de FPS.