Zero-Host-Copy: cómo ejecutar YOLOv8m a 165–215 FPS sacando la CPU del bucle caliente

Has optimizado el modelo, lo has cuantizado a INT8 y la inferencia tarda un par de milisegundos. Y aun así los FPS están lejos de lo esperado. Es una historia conocida: el cuello de botella no es la unidad de cómputo, sino todo lo que la rodea. Un análisis publicado en Habr muestra cómo abordarlo en la práctica.

Dónde se pierden realmente los fotogramas

En una tarjeta gráfica discreta, cada fotograma de alta resolución que viaja a la memoria RAM y regresa paga un peaje al bus PCIe. Si además se envían de un lado a otro resultados intermedios, como los bounding boxes de la detección, el ancho de banda cae de forma notable. Cuanto más rápido es el modelo, más se nota este coste: calcula en 2 ms, pero la copia lleva más tiempo que el propio cálculo.

La idea de Zero-Host-Copy es simple: desde que los datos se leen del disco y se decodifican hasta la codificación final y la escritura, permanecen en la memoria de la GPU. Solo la tarjeta gráfica los procesa, y las copias GPU → CPU y de vuelta se reducen al mínimo. Una idea relacionada, Zero-Copy, consiste en pasar entre las etapas del pipeline un puntero al bloque de datos, y no el bloque en sí.

El asesino silencioso: cudaMalloc

El segundo problema es menos evidente. La llamada a cudaMalloc provoca una sincronización implícita: la CPU tiene que esperar a la GPU y el pipeline asíncrono deja de ser asíncrono. Una sola llamada de este tipo en el bucle de procesamiento de fotogramas puede causar una caída de rendimiento que el profiler mostrará como pausas misteriosas.

La solución es un ciclo de vida de tres fases:

• Inicialización. La aplicación asigna de antemano pools de memoria, búferes y colas con una profundidad inicial.
• Calentamiento. Se ejecuta la cola de procesamiento completa. Si se necesitan búferes adicionales, el sistema los asigna precisamente aquí.
• Funcionamiento activo. Tras los primeros fotogramas, la asignación dinámica queda prohibida: ni cudaMalloc ni new, solo reutilización de bloques ya asignados.

En el fondo es una técnica conocida de los motores de videojuegos y del procesamiento de audio: todo lo pesado se hace antes del arranque, y en el bucle caliente solo se reutiliza.

Resultados

El autor implementó un pipeline sin DeepStream en C++/CUDA puro. YOLOv8m con resolución 1024x1024 en INT8 muestra aproximadamente 165–215 FPS en una RTX 3060 Ti y unos 38 FPS en una Jetson Orin Nano Super. Para una plataforma embebida, es un resultado muy digno con este tamaño de entrada.

Limitaciones y conclusión

El precio del enfoque es la complejidad. Un pipeline bare-metal exige gestión manual de pools, sincronización de streams y ciclo de vida de los búferes. Un error en el tamaño del pool provocará un fallo o una degradación oculta en la fase caliente. Mantener algo así es más caro que montar una solución sobre DeepStream o un framework ya hecho. Además, las cifras se obtuvieron con un modelo concreto y un hardware concreto, y en el artículo, a juzgar por el anuncio, no hay comparación con stacks listos para usar en las mismas condiciones, así que conviene comprobar la ganancia con tus propios datos.

Conclusiones prácticas para quienes desarrollan videoanalítica o trabajan con dispositivos edge:

• Antes de seguir optimizando el modelo, mide cuánto tiempo se va en copias y asignaciones.
• Localiza en el bucle caliente todos los cudaMalloc, new y sincronizaciones implícitas, y llévalos a la inicialización.
• Diseña el pipeline para que el fotograma no abandone la GPU: decodificación por hardware, preprocesamiento, inferencia, posprocesamiento, codificación.
• Incluye una fase de calentamiento y comprueba que después no haya más asignaciones.

Cuando el modelo ya es rápido, la ganancia está en la disciplina de ingeniería a su alrededor. Para el tiempo real en flujos de vídeo, suele ser la forma más barata de conseguir un aumento múltiple de FPS.