4.7 Exportación de modelos y despliegue en el edge

Por qué esto importa

En el capítulo anterior explicamos cómo entrenar un modelo YOLO personalizado y ejecutar inferencia con éxito en Jetson. En esa etapa, el modelo todavía estaba almacenado en formato .pt, que es el formato nativo comúnmente utilizado en el ecosistema de PyTorch. Este es un buen punto de partida porque demuestra que los resultados del entrenamiento son correctos y que el modelo ya puede realizar detección de objetos en el dispositivo objetivo.

En el capítulo anterior explicamos cómo entrenar un modelo YOLO personalizado y ejecutar inferencia con éxito en Jetson. En esa etapa, el modelo todavía estaba almacenado en formato .pt, que es el formato nativo comúnmente utilizado en el ecosistema de PyTorch. Este es un buen punto de partida porque demuestra que los resultados del entrenamiento son correctos y que el modelo ya puede realizar detección de objetos en el dispositivo objetivo.

Sin embargo, poder ejecutar un modelo en Jetson no significa que el modelo ya esté en su mejor forma de despliegue. El archivo .pt está diseñado principalmente para entrenamiento, validación y desarrollo, donde la flexibilidad importa más que la eficiencia de ejecución. Para el despliegue real en el edge, especialmente en plataformas embebidas como Jetson, nos preocupa mucho más que solo si el modelo se puede ejecutar. También nos importa lo rápido que se ejecuta, cuánta memoria consume, lo estable que es su throughput y cómo encaja con los límites de potencia y temperatura del dispositivo.

En otras palabras, un checkpoint entrenado es solo una parte del pipeline de despliegue. Para que un modelo YOLO sea verdaderamente adecuado para aplicaciones reales en Jetson, normalmente necesitamos convertirlo a un formato más apto para el despliegue y optimizarlo aún más para la inferencia embebida. Este es el paso clave que cierra la brecha entre el desarrollo de visión por computadora y la ingeniería en el edge.

Por lo tanto, después de entrenar un modelo, la siguiente pregunta importante no es simplemente "¿Puede ejecutarse?", sino más bien "¿Puede ejecutarse de forma eficiente en Jetson?" Para responder a esa pregunta, necesitamos entender por qué la optimización del modelo es necesaria.

¿Por qué necesitamos optimización del modelo?

La optimización del modelo es necesaria porque el modelo entrenado original normalmente no está diseñado para las restricciones del hardware embebido. Durante el entrenamiento, el principal objetivo es lograr buena precisión y convergencia. Sin embargo, durante el despliegue, el objetivo cambia. Necesitamos que el modelo ofrezca inferencia rápida, baja latencia, alto throughput, bajo uso de memoria y buena eficiencia energética.

Esto es especialmente importante para los dispositivos Jetson. En comparación con las GPUs de escritorio o los servidores en la nube, las plataformas Jetson tienen recursos de cómputo, ancho de banda de memoria y presupuesto de energía más limitados. En muchos escenarios de IA en el edge, como robótica, cámaras inteligentes, inspección industrial o sistemas autónomos, el modelo debe procesar los datos en tiempo real. Si la inferencia es demasiado lenta, el sistema puede perder fotogramas, responder demasiado tarde o no cumplir con los requisitos de la aplicación.

Ejecutar un modelo YOLO directamente en formato .pt a menudo introduce sobrecarga innecesaria del runtime de PyTorch. Aunque este enfoque es conveniente para pruebas y prototipado, no es ideal para extraer el máximo rendimiento del hardware Jetson. El modelo puede funcionar correctamente, pero puede no usar la GPU de la forma más eficiente posible. Como resultado, la latencia puede seguir siendo alta, el throughput puede estar limitado y el uso de recursos puede ser mayor de lo necesario.

La optimización del modelo ayuda a resolver estos problemas. Al exportar el modelo y optimizarlo para inferencia, podemos mejorar la forma en que la red se ejecuta en el hardware objetivo. Esto puede incluir reducir operaciones redundantes, fusionar capas, seleccionar kernels más eficientes, bajar la precisión de FP32 a FP16 o INT8 y mejorar el uso de memoria. Estas optimizaciones pueden mejorar significativamente el rendimiento de despliegue sin cambiar la tarea general del modelo.

Para el despliegue en Jetson, la optimización trae varios beneficios prácticos:

1. Menor latencia

Un modelo más rápido significa que cada fotograma de entrada puede procesarse más rápidamente. Esto es crítico para tareas en tiempo real como la detección y el seguimiento de objetos.

2. Mayor throughput

La optimización permite al sistema procesar más fotogramas por segundo, lo que es importante para análisis de vídeo y aplicaciones multistream.

3. Menor uso de memoria

Los dispositivos embebidos tienen recursos de memoria limitados. Un modelo optimizado puede reducir la huella de memoria y mejorar la estabilidad del sistema.

4. Mejor eficiencia energética

Los dispositivos Jetson se utilizan a menudo en entornos edge donde el consumo de energía importa. Un modelo más eficiente puede ayudar al sistema a funcionar más tiempo y de forma más fiable.

5. Mejor aprovechamiento del hardware

La optimización permite que el modelo aproveche mejor la aceleración de la GPU de NVIDIA en lugar de depender en gran medida de la ejecución del framework genérico.

Por estas razones, la optimización del modelo no es solo una mejora opcional. Es un paso necesario para transformar un modelo YOLO entrenado en una solución práctica de IA en el edge que pueda ejecutarse de forma eficiente bajo condiciones reales de despliegue.

¿Qué es TensorRT?

TensorRT es el framework y runtime de inferencia de deep learning de alto rendimiento de NVIDIA. Está diseñado específicamente para optimizar redes neuronales entrenadas y ejecutarlas de forma eficiente en hardware NVIDIA, incluidos los dispositivos Jetson.

En términos simples, TensorRT es la herramienta que ayuda a convertir un modelo entrenado en una forma más adecuada para el despliegue. En lugar de ejecutar el modelo a través de un framework de deep learning de propósito general, TensorRT construye un motor de inferencia optimizado adaptado a la GPU NVIDIA objetivo. Esto permite que el modelo se ejecute más rápido y de forma más eficiente.

Para Jetson, TensorRT desempeña un papel central en el despliegue porque está diseñado para explotar plenamente las capacidades de las GPUs embebidas de NVIDIA. Realiza una variedad de optimizaciones, tales como:

fusión de capas, que combina múltiples operaciones en una ruta de ejecución más eficiente
selección automática de kernels, que elige la mejor implementación para el hardware
optimización de precisión, como aceleración FP16 o INT8
optimización de memoria, que reduce el movimiento innecesario de memoria y mejora la eficiencia en runtime

Como resultado, TensorRT puede mejorar significativamente el rendimiento de inferencia de un modelo YOLO en comparación con ejecutar directamente el modelo .pt original.

Un flujo de trabajo común de despliegue en Jetson se ve así:

Modelo PyTorch .pt -> Modelo ONNX -> Motor TensorRT -> Inferencia en Jetson

En este flujo de trabajo:

el modelo .pt es el resultado del entrenamiento
el modelo ONNX sirve como formato intermedio de intercambio
el motor TensorRT es el artefacto de despliegue optimizado utilizado para inferencia en Jetson

Este proceso muestra que TensorRT no es solo un conversor, sino una capa clave de optimización y ejecución para el despliegue de IA embebida.

Desde una perspectiva de ingeniería, TensorRT es importante porque convierte un modelo que es meramente entrenable y testeable en uno verdaderamente desplegable y eficiente. Para los usuarios de Jetson, TensorRT suele ser el paso más importante para alcanzar un rendimiento práctico en tiempo real.

Formatos de modelo comunes

Formato	Rol principal
PyTorch checkpoint	flexible para entrenamiento y experimentación
ONNX	formato intermedio portátil
TensorRT engine	formato de runtime optimizado para hardware NVIDIA

Precisión vs Velocidad vs Energía

Un modelo más preciso suele ser más grande, más lento y consume más energía, mientras que un modelo más rápido suele ser más ligero pero menos preciso. Por lo tanto, en el despliegue real, debemos encontrar un equilibrio que se ajuste al dispositivo y a la tarea. El despliegue en el edge siempre se trata de compromisos.

A menudo equilibras:

precisión del modelo
velocidad de inferencia
uso de memoria
límites térmicos y de energía

Modos de precisión

La precisión del modelo significa cuántos bits se utilizan para almacenar números dentro del modelo, como pesos y activaciones. Una precisión mayor, como FP32, conserva más detalle numérico, mientras que una precisión menor, como FP16 o INT8, utiliza menos bits. Una precisión menor puede hacer la inferencia más rápida y usar menos memoria, lo cual es muy útil en dispositivos edge como Jetson. Pero si la precisión se reduce demasiado, el modelo puede perder algo de exactitud, por lo que necesitamos equilibrar velocidad y fiabilidad.

Ejemplo de código

Exportar a ONNX

bash

yolo export model=yolo26s.pt format=onnx imgsz=640

Exportar a TensorRT en Jetson

bash

yolo export model=yolo26s.pt format=engine imgsz=640 half=True device=0

Comandos útiles del runtime de Jetson

bash

#turn on max mode
sudo nvpmodel -m 0
#turn on jetson clocks
sudo jetson_clocks

Pruébalo

bash

cd 4.7-Model-Export-and-Edge-Deployment/code
python compare_yolo26_pt_vs_engine.py --video ./cat.mp4

🚀 Observa los cambios en la latencia de inferencia del modelo optimizado

4月3日

Errores comunes

"Si el modelo se exporta con éxito, el despliegue está resuelto."
- La exportación es solo un paso. La validación en runtime sigue siendo importante.
"El modelo más rápido siempre es el mejor modelo."
- Un modelo más rápido no es útil si pierde casos importantes.
"INT8 siempre es mejor que FP16."
- INT8 puede ser potente, pero solo si la precisión sigue siendo aceptable.

Ejercicios / Reflexión

Exporta un modelo entrenado a ONNX y registra el comando.
Compara por escrito para qué es mejor cada uno: checkpoint, ONNX, motor TensorRT.
Imagina que un modelo es preciso pero demasiado lento. Lista tres formas de hacer el despliegue más práctico.
Explica por qué el modo de energía importa en un dispositivo edge.

Resumen

La exportación de modelos y el despliegue en el edge no son cosas accesorias. Son parte del flujo de trabajo completo de visión por computadora. Después de que un alumno comprenda los datos, el entrenamiento y la evaluación, el siguiente reto es convertir ese modelo en algo práctico para hardware real.

Siguiente paso sugerido

Continúa con 4.8 Frameworks de pipeline de visión en tiempo real.

Referencias

PreviousEntrena e implementa tu propio modelo de visión

NextFrameworks de canalización de visión en tiempo real